Re: Problems with X.org and incompatibilities with in-house software
On 1 March 2010 03:04, Russell Shaw rjs...@netspace.net.au wrote: Interesting http://web.archive.org/web/20080413140042/http://people.freedesktop.org/~jg/roadmap.html#mozTocId778727 I put the archive.org link into the Wikipedia article because the original fell off the web. Is there another canonical copy up anywhere? This is a pretty important document. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Hi Richard, On Sun, Feb 28, 2010 at 05:48:50PM -0500, Richard Brown wrote: To our much dismay we have recently found after attempting to install new Linux boxes that these extensions no longer appear to be available. This has caused most of our internal applications to blow up and to be completely ruined and unusable in the process. Dozens of applications have now blown up and are not able to be used, involving millions of lines of code. Thousands of dollars already invested in upgrade to new Linux systems appears to be completely useless now, as none of our applications can be used on these new systems. We advertised the deprecations fairly widely, and it was done in a staggered manner. No-one complained. It is well past time that your organisation make backwards compatibility with core X11 and all extensions to it a primary principle of your organisation. To many have invested too much money into developing software to utilise these extensions than to have them mindlessly removed and thus blowing up dozens of our internal applications. We have decided that we will probably move to an entirely Win32 platform instead of investing hundreds of thousands of dollars into an extensive rewriting of our existing X applications, as it seems like, from what we have already seen, it no longer seems as though we can count on this platform to provide the backwards compatibility we need. We have been talking to Microsoft extensively about this issue and they have indeed provided us with huge resources and have iron clad commitments to maintaining compatibility with their older interfaces, so we can rest assured that with them that code we write today will still work years and years from now. The key here is in what you've said -- you're paying Microsoft to make these things happen. If you want to pay a competent UNIX vendor (Red Hat or Sun, basically), then I'm sure they could help you guys out. It's pretty hard to do anything when you have to guess as to what someone who you've never previously interacted with is going to say in several years' time (when did PEX and XIE disappear -- late 1990s? early 2000s?). But I'm pleased to announce that old versions of X still work every bit as well now as they do previously, so if you don't want to upgrade then no-one's holding a gun to your head. Cheers, Daniel (PS: Ask Microsoft how you go running 16-bit DOS applications under Windows 7.) pgpyWRLPho8Ts.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Daniel Stone wrote: Hi Richard, On Sun, Feb 28, 2010 at 05:48:50PM -0500, Richard Brown wrote: To our much dismay we have recently found after attempting to install new Linux boxes that these extensions no longer appear to be available. This has caused most of our internal applications to blow up and to be completely ruined and unusable in the process. Dozens of applications have now blown up and are not able to be used, involving millions of lines of code. Thousands of dollars already invested in upgrade to new Linux systems appears to be completely useless now, as none of our applications can be used on these new systems. We advertised the deprecations fairly widely, and it was done in a staggered manner. No-one complained. It is well past time that your organisation make backwards compatibility with core X11 and all extensions to it a primary principle of your organisation. To many have invested too much money into developing software to utilise these extensions than to have them mindlessly removed and thus blowing up dozens of our internal applications. We have decided that we will probably move to an entirely Win32 platform instead of investing hundreds of thousands of dollars into an extensive rewriting of our existing X applications, as it seems like, from what we have already seen, it no longer seems as though we can count on this platform to provide the backwards compatibility we need. We have been talking to Microsoft extensively about this issue and they have indeed provided us with huge resources and have iron clad commitments to maintaining compatibility with their older interfaces, so we can rest assured that with them that code we write today will still work years and years from now. The key here is in what you've said -- you're paying Microsoft to make these things happen. If you want to pay a competent UNIX vendor (Red Hat or Sun, basically), then I'm sure they could help you guys out. It's pretty hard to do anything when you have to guess as to what someone who you've never previously interacted with is going to say in several years' time (when did PEX and XIE disappear -- late 1990s? early 2000s?). But I'm pleased to announce that old versions of X still work every bit as well now as they do previously, so if you don't want to upgrade then no-one's holding a gun to your head. Cheers, Daniel (PS: Ask Microsoft how you go running 16-bit DOS applications under Windows 7.) Thank you for your help, on this matter. I do apologise for the tone of the previous letter. I had just gotten back from a bar and was rather drunk. Anyhoo, I am not of asking X.org to maintain these old extensions which have functionality available elsewhere or no longer provide functionality, and have broken or questionable code security wise. We will be staying with X.org. I am very high up in the decision process at our corporation (though i do try to avoid making decisions while i am drunk), so that decision is quite final. Our applications are not too dependent on these extensions and we are planning to update to fix our apps to not use them and keep them running. I apologise if the previous letter was ill conceived. Many of my statements were made in poor judgment and were ignorant. I will admit that. (one too many of the cold ones in one evening can do that, i need to break my drinking habit and attend my AA sessions more frequently). I do think that x.org is a wonderful product and i do appreciate it. I do appreciate backwards compatibility in the core protocol and the network transparency is very useful to us. I am interesting in helping with X development, but i do not know the sligthest thing about the X server, any pointers to explanation of X internals? Thank you for the great window system and keep up the good work. Sincerely, Richard Brown ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Can I ask what OSes you have been running on previously? Dave sorry for top posting phone email client On Monday, March 1, 2010, Richard Brown rbrown1...@gmail.com wrote: Dear X.org, I work for a large corporation which has used X Window System in its internal systems since the 1980s. We have code going back to since the mid 80s which has used X which are a critical part of our corporations internal infrastructures and information systems. We have dozens of applications written using xlib involving millions of lines of code. We have significant investments on in house applications written with Xlib and have used at various times, dumb terminals, then XFree86, and now X.org on the display end. X.org is now the standard server on Linux systems which we would have liked to use. We make extensive use of X's network transparency as we run major server farms which run applications which are displayed over our networks to terminals throughout our office complex. Recently, however, we have been shocked and dismayed at what we consider extremely poor design decisions made by X.org which show indifference to backwards compatibility and the needs of many users. We have always depended on the high degree of backwards compatibility that X provides, as we have applications directly tied to xlib and to a number of extensions and as well clients which run on older server systems using older versions of X connecting to new and more recent Linux X servers. Our applications make extensive use of a large number of X extensions, these include, but are not limited to, MIT-Sundry-Nonstandard (many of our oldest programs from the early days use this) ,TOG-CUP, Xtrap, Xfree86-Misc, XEvIE, EVI, PEX, (for many of our 3D modelling and CAD applications), Appgroup, Xprint (many of our apps use this to print out forms, documents and schematics), and Ximage (we use this heavily to display images). Xlib is very much intergrated into all of our programs and we make extensive use of every single feature in xlib. and of every extension. I do not believe that there is an extension anywhere or any feature of xlib that we have not utilised in some way. To our much dismay we have recently found after attempting to install new Linux boxes that these extensions no longer appear to be available. This has caused most of our internal applications to blow up and to be completely ruined and unusable in the process. Dozens of applications have now blown up and are not able to be used, involving millions of lines of code. Thousands of dollars already invested in upgrade to new Linux systems appears to be completely useless now, as none of our applications can be used on these new systems. This has caused great harm to our company and a loss of vast investments we have made of millions of lines of code written over a period of over 22 years, heavily interlinked with these X extensions and dependent on them have been rendered completely non functional due to X.org's bad design decisions. It is well past time that your organisation make backwards compatibility with core X11 and all extensions to it a primary principle of your organisation. To many have invested too much money into developing software to utilise these extensions than to have them mindlessly removed and thus blowing up dozens of our internal applications. We have decided that we will probably move to an entirely Win32 platform instead of investing hundreds of thousands of dollars into an extensive rewriting of our existing X applications, as it seems like, from what we have already seen, it no longer seems as though we can count on this platform to provide the backwards compatibility we need. We have been talking to Microsoft extensively about this issue and they have indeed provided us with huge resources and have iron clad commitments to maintaining compatibility with their older interfaces, so we can rest assured that with them that code we write today will still work years and years from now. It is very sad that it has come to this, and that X no longer seems to be taking the need for backwards compatibility seriously. Backwards compatibility is ESSENTIAL! We used to find X the perfect platform, but it seems those days are gone. Needless to say we have been burned badly by X.org and its lack of concern for its users applications and their need for backwards compatability. I feel very badly that a once sound platform such as X has resorted to such shoddy, ignorant, and poorly thought out actions and behaviours. I am sure your platform will suffer greatly as a result. Sincerely, Richard Brown ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org
Re: Problems with X.org and incompatibilities with in-house software
Richard Brown wrote: Our applications make extensive use of a large number of X extensions, these include, but are not limited to, MIT-Sundry-Nonstandard (many of our oldest programs from the early days use this) ,TOG-CUP, Xtrap, Xfree86-Misc, XEvIE, EVI, PEX, (for many of our 3D modelling and CAD applications), PEX? Really? And you've had this supported on any system made since the mid-90's? Even Sun dropped that in Solaris 7 in 1998, and XFree86 removed it long ago, before the current X.Org organization took over the development of X. -- -Alan Coopersmith- alan.coopersm...@sun.com Oracle Solaris Platform Engineering: X Window System ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
To our much dismay we have recently found after attempting to install new Linux boxes that these extensions no longer appear to be available. PEX was dropped in what was it 2004, so six years ago... taken you a while to notice and it was dropped because nobody could actually find a single user of it. By the time PEX stuff ever approached any real implementation OpenGL had buried it because of the need for things like texture mapping. But then if you wanted people to believe you were genuine you wouldn't I susppect be posting from what the analysis tools say is a new google account and without naming the company. You'd have approached X.org as a company through management and had a rational discussion about the best way to support the extensiosn you need (or had that discussion with your Linux vendor) and spent a lot less by making sure the commercial justification was there for someone to support it. Still if you'd rather rewrite all your code, pay Microsoft zillions and not pay a consultant to do the updating on the modules you need for resubmission (or even pay an undergrad minimum wage to knock you off a package of an old build) don't let me stop you ;) Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Alan Cox wrote: To our much dismay we have recently found after attempting to install new Linux boxes that these extensions no longer appear to be available. PEX was dropped in what was it 2004, so six years ago... taken you a while to notice and it was dropped because nobody could actually find a single user of it. By the time PEX stuff ever approached any real implementation OpenGL had buried it because of the need for things like texture mapping. But then if you wanted people to believe you were genuine you wouldn't I susppect be posting from what the analysis tools say is a new google account and without naming the company. You'd have approached X.org as a company through management and had a rational discussion about the best way to support the extensiosn you need (or had that discussion with your Linux vendor) and spent a lot less by making sure the commercial justification was there for someone to support it. Still if you'd rather rewrite all your code, pay Microsoft zillions and not pay a consultant to do the updating on the modules you need for resubmission (or even pay an undergrad minimum wage to knock you off a package of an old build) don't let me stop you ;) Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Ok, indeed. We dont really use PEX that much, more into OpenGL these days so its not important. I certainly wouldnt ask a lot of effort to support it. Only if it could be re-enabled with simply adding it back into the compile process would i suggest that be considered. I would say the same about the other extensions. if it requires a lot of major work to get those working again, okay, i can understand that, no problem, i would not ask you to commit such an effort. But to just remove something because we dont like how that looks there, which is working fine however and in a useable state, does not make a lot of sense. Why not just leave it in? We dont like how something works, or we dont *think* anyone is using this, are not good reasons to remove support. There would have to be a severe problem with the code, broken code, that would necessitate a extension being disabled. So of these disabled, removed extensions. How many of these are disabled as a result of actual broken code, vs, how many are disabled because, we don't like how it looks? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Alan Coopersmith wrote: Richard Brown wrote: Our applications make extensive use of a large number of X extensions, these include, but are not limited to, MIT-Sundry-Nonstandard (many of our oldest programs from the early days use this) ,TOG-CUP, Xtrap, Xfree86-Misc, XEvIE, EVI, PEX, (for many of our 3D modelling and CAD applications), PEX? Really? And you've had this supported on any system made since the mid-90's? Even Sun dropped that in Solaris 7 in 1998, and XFree86 removed it long ago, before the current X.Org organization took over the development of X. We've used PEX with some older hardware, though we done most stuff over by now with OpenGL. I suppose PEX is not that important anymore and we can move completely to OpenGL. If PEX does not have any software renderer that does not need a hardware support, and it could be re-enabled with just setting it back into the compile process, why not put it back in. If supporting any of these features would drain your resources and take massive amounts of time, I can understand that, and would not ask that. But if it would just take just changing a few compile time things to bring it back in, why not put this stuff back into X.org. I can understand if some of these extensions would require massive reworking to make working again, I could not ask anyone to commit that kind of time. We will probably work to rewrite our software to work around many of the problems and stay with X. I would be interested in the rationale to disable extensions. This isn't needed anymore is not good enough. Assume that there is someone still using the extension, somewhere, an older program that needs it. Perhaps, if the extension required rewriting of thousands of lines of code to keep it working, that might be a good reason to disable it. But dropping support for these things because we can or because we didnt like how it looked there, didnt seem like a good idea. Xprint: This allows printing to a postscript file. Seems immensely useful to me as it allows X itself to be used as a printer API. Why was this removed? Is there any major code problem that would have to be fixed? Xtrap, TOG-CUP, Xfree86-misc, XeVIE, EVI, MIT-Sundry-Nonstandard. Again, some programs may need it. Any code problems that would have to be fixed, again, wht are the technical problems, are these broken, do they require major work? XeVIE seemed very recent. Why was this removed? Is there really huge amounts of broken code there? Xtrap allows capturing of user events? Why remove such functionality? Again, does it contain broken code? If it requires major work to get these back in, i can understand and i will not request that, we will just spend the time to rework our software to not use them. But if its a simple thing of putting them back into the compile, why not? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Twas brillig at 19:05:25 28.02.2010 UTC-05 when rbrown1...@gmail.com did gyre and gimble: RB So of these disabled, removed extensions. How many of these are RB disabled as a result of actual broken code, vs, how many are RB disabled because, we don't like how it looks? Most of them were removed because they were broken for years (literally) and nobody complained. -- http://fossarchy.blogspot.com/ pgpjeBlsNviHB.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Mikhail Gusarov wrote: Twas brillig at 19:05:25 28.02.2010 UTC-05 when rbrown1...@gmail.com did gyre and gimble: RB So of these disabled, removed extensions. How many of these are RB disabled as a result of actual broken code, vs, how many are RB disabled because, we don't like how it looks? Most of them were removed because they were broken for years (literally) and nobody complained. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg If the extensions are removed because of broken code, i can understand, especially for the extensions which have duplicitous functionality which can be obtained by using other X11 features, i do not ask for time to expended to get broken code working. But, if the extensions are in working order, there is no reason or justification to remove them, even if their functionality is duplicated, different applications may be tied to a certain API. We dont like how it looks is not a good reason to remove extensions. Xprint, was this actually broken code, for instance. Ximage, was this broken code? XEVIE, again, was that broken code. If the extension is broken code, dont waste your time, Im not asking you to spend time on it, we will do our best here to move off of them. But, if the extension is in working order, why not put it back in? To justify removing an extension, the extension needs to be in a broken, non working order, and that it is causing technical problems for the rest of the X system, and to require extensive reworking, and apps can implement what it needs in another way. We dont like how it looks, or we dont think people use this, are not good justifications. Since X.org officially has had all of these extensions until very recently, apparently although they may have been in a non working state, at the same time, they were not causing a problem, so I cannot see the action as being justified to remove them. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
On Sun, Feb 28, 2010 at 05:48:50PM -0500, Richard Brown wrote: Dear X.org, I work for a large corporation which has used X Window System in its internal systems since the 1980s. We have code going back to since the mid 80s which has used X which are a critical part of our corporations internal infrastructures and information systems. We have dozens of applications written using xlib involving millions of lines of code. We have significant investments on in house applications written with Xlib and have used at various times, dumb terminals, then XFree86, and now X.org on the display end. X.org is now the standard server on Linux systems which we would have liked to use. We make extensive use of X's network transparency as we run major server farms which run applications which are displayed over our networks to terminals throughout our office complex. Recently, however, we have been shocked and dismayed at what we consider extremely poor design decisions made by X.org which show indifference to backwards compatibility and the needs of many users. We have always depended on the high degree of backwards compatibility that X provides, as we have applications directly tied to xlib and to a number of extensions and as well clients which run on older server systems using older versions of X connecting to new and more recent Linux X servers. Our applications make extensive use of a large number of X extensions, these include, but are not limited to, MIT-Sundry-Nonstandard (many of our oldest programs from the early days use this) ,TOG-CUP, Xtrap, Xfree86-Misc, XEvIE, EVI, PEX, (for many of our 3D modelling and CAD applications), Appgroup, Xprint (many of our apps use this to print out forms, documents and schematics), and Ximage (we use this heavily to display images). Xlib is very much intergrated into all of our programs and we make extensive use of every single feature in xlib. and of every extension. I do not believe that there is an extension anywhere or any feature of xlib that we have not utilised in some way. To our much dismay we have recently found after attempting to install new Linux boxes that these extensions no longer appear to be available. This has caused most of our internal applications to blow up and to be completely ruined and unusable in the process. Dozens of applications have now blown up and are not able to be used, involving millions of lines of code. Thousands of dollars already invested in upgrade to new Linux systems appears to be completely useless now, as none of our applications can be used on these new systems. This has caused great harm to our company and a loss of vast investments we have made of millions of lines of code written over a period of over 22 years, heavily interlinked with these X extensions and dependent on them have been rendered completely non functional due to X.org's bad design decisions. It is well past time that your organisation make backwards compatibility with core X11 and all extensions to it a primary principle of your organisation. To many have invested too much money into developing software to utilise these extensions than to have them mindlessly removed and thus blowing up dozens of our internal applications. We have decided that we will probably move to an entirely Win32 platform instead of investing hundreds of thousands of dollars into an extensive rewriting of our existing X applications, as it seems like, from what we have already seen, it no longer seems as though we can count on this platform to provide the backwards compatibility we need. We have been talking to Microsoft extensively about this issue and they have indeed provided us with huge resources and have iron clad commitments to maintaining compatibility with their older interfaces, so we can rest assured that with them that code we write today will still work years and years from now. It is very sad that it has come to this, and that X no longer seems to be taking the need for backwards compatibility seriously. Backwards compatibility is ESSENTIAL! We used to find X the perfect platform, but it seems those days are gone. Needless to say we have been burned badly by X.org and its lack of concern for its users applications and their need for backwards compatability. I feel very badly that a once sound platform such as X has resorted to such shoddy, ignorant, and poorly thought out actions and behaviours. I am sure your platform will suffer greatly as a result. Sincerely, Richard Brown It would be interesting to know what corporation this is, so that enterprise linux distributors and other enterprise service providers see what sort of big clients, who are now investing a ton of money and manpower in a windows based solution, they just lost out on. Richard, who provided you with support
Re: Problems with X.org and incompatibilities with in-house software
disabled, removed extensions. How many of these are disabled as a result of actual broken code, vs, how many are disabled because, we don't like how it looks? Most are disabled because they don't work (and often havent worked for ages, or have been disabled by distributions by default for years and nobody noticed), others are just not shipped by default and probably work (eg Xprint still gets some love now and again). There are other things to think about - eg X extensions that are old and unmaintained often pre-date the world of the 'leet hacker dude' and the coding isn't neccessarily as robust as it should be. Enabling such things by default is exposing people to a risk with no economic justification. Really the only way to maintain an X extension is to have someone who uses it and has a true self interest in keeping it working, whether because they work for a vendor whose customer pays good money for a system that delivers the feature, or because they need it in-house. The extensions are still there in the history of the codebase. It just needs someone who needs that extension to check it out, rebuild test and debug it. If it's cheaper to maintain it than port the code using it then it makes sense for those who can save money to maintain it or pay someone to do so, if not then it's probably time to go. Rational economic behaviour ought to resolve such questions (ok given perfect information I admit) Some of the ancient video drivers would certainly be more expensive to port than to simply replace the few remaining cards for example. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Richard Brown wrote: Mikhail Gusarov wrote: Twas brillig at 19:05:25 28.02.2010 UTC-05 when rbrown1...@gmail.com did gyre and gimble: RB So of these disabled, removed extensions. How many of these are RB disabled as a result of actual broken code, vs, how many are RB disabled because, we don't like how it looks? Most of them were removed because they were broken for years (literally) and nobody complained. If the extensions are removed because of broken code, i can understand, especially for the extensions which have duplicitous functionality which can be obtained by using other X11 features, i do not ask for time to expended to get broken code working. But, if the extensions are in working order, there is no reason or justification to remove them, even if their functionality is duplicated, different applications may be tied to a certain API. We dont like how it looks is not a good reason to remove extensions. Xprint, was this actually broken code, for instance. Ximage, was this broken code? XEVIE, again, was that broken code. What are you referring to by Ximage ? If the extension is broken code, dont waste your time, Im not asking you to spend time on it, we will do our best here to move off of them. But, if the extension is in working order, why not put it back in? To justify removing an extension, the extension needs to be in a broken, non working order, and that it is causing technical problems for the rest of the X system, and to require extensive reworking, and apps can implement what it needs in another way. We dont like how it looks, or we dont think people use this, are not good justifications. Since X.org officially has had all of these extensions until very recently, apparently although they may have been in a non working state, at the same time, they were not causing a problem, so I cannot see the action as being justified to remove them. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Alan Cox wrote: disabled, removed extensions. How many of these are disabled as a result of actual broken code, vs, how many are disabled because, we don't like how it looks? Most are disabled because they don't work (and often havent worked for ages, or have been disabled by distributions by default for years and nobody noticed), others are just not shipped by default and probably work (eg Xprint still gets some love now and again). There are other things to think about - eg X extensions that are old and unmaintained often pre-date the world of the 'leet hacker dude' and the coding isn't neccessarily as robust as it should be. Enabling such things by default is exposing people to a risk with no economic justification. Really the only way to maintain an X extension is to have someone who uses it and has a true self interest in keeping it working, whether because they work for a vendor whose customer pays good money for a system that delivers the feature, or because they need it in-house. The extensions are still there in the history of the codebase. It just needs someone who needs that extension to check it out, rebuild test and debug it. If it's cheaper to maintain it than port the code using it then it makes sense for those who can save money to maintain it or pay someone to do so, if not then it's probably time to go. Rational economic behaviour ought to resolve such questions (ok given perfect information I admit) Some of the ancient video drivers would certainly be more expensive to port than to simply replace the few remaining cards for example. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Yes. I can certainly conclude that security issues would be a reason for code to be disabled. If the code is broken or has some problems like that, then, yes, not building it in seems to be reasonable. I do apologise for the tone of my original letter. We will be staying with X in the future and we will not be moving to another platform. I do still find backwards comptability to be important, especially in the core protocol. We use a mix of new and old stuff, and the network transparency is also a very important feature to us as well. I can understand if an extension has broken code or has some security problems it may be a good idea to disable that. I do not fault that. One of the extensions removed was Xtrap. I suppose that its functionality can be found in XRecord, i suppose. One area of course that is useful for us for that is screen reader software for accessibility for the blind. Having a mechanism for OCR software to insert text or give text to another application, is also a valuable feature as well. It may also be of interest security mechanisms in regading to one application accessing data of another application. Perhaps there should be some kind of security measure to prevent an application from doing this that one does not wish to have access to this feature. One possibility might be a security interface that would allow a security manager program to monitor requests for such actions, and perhaps give the user notification of them to ask if the user wishes to deny or allow one client to for instance access keyboard strokes going to the X server as a whole or to a single client. Certainly capturing keystrokes to particular xclients and for the entire server can be valuable, its a mechanism that may be needed by something but it could be disallowed except for progrms which the user explicitely allows it for. The user could in their X configuration perhaps specify a program which would control access to those kinds of interclient features. It could be provided initially exclusive access to APIs to monitor requests for controlled activities, and to permit or deny them, and provide if it chooses access to these APIs, and other controlled APIs to other programs. There is good reason for such features being avialable in certain cases and not allowed in others. In some cases a bad or compromised program could log passwords, and if programs running at different privelege levels are being displayed to the same Xserver, we wouldnt want a program which perhaps has been hijacked running as a nonpriveleged user to access data regarding other clients, including ones perhaps running as root. While we are on security issues, what would prevent X being run as non root? Perhaps there could be some way added to the OS if necessary so that X can be given access to just those resources it needs, such as input and output devices. Perhaps allowing for a special X user who has access to just those resources it needs? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Russell Shaw wrote: Richard Brown wrote: Mikhail Gusarov wrote: Twas brillig at 19:05:25 28.02.2010 UTC-05 when rbrown1...@gmail.com did gyre and gimble: RB So of these disabled, removed extensions. How many of these are RB disabled as a result of actual broken code, vs, how many are RB disabled because, we don't like how it looks? Most of them were removed because they were broken for years (literally) and nobody complained. If the extensions are removed because of broken code, i can understand, especially for the extensions which have duplicitous functionality which can be obtained by using other X11 features, i do not ask for time to expended to get broken code working. But, if the extensions are in working order, there is no reason or justification to remove them, even if their functionality is duplicated, different applications may be tied to a certain API. We dont like how it looks is not a good reason to remove extensions. Xprint, was this actually broken code, for instance. Ximage, was this broken code? XEVIE, again, was that broken code. What are you referring to by Ximage ? Ximage extension to the X server. It has been superceded by MIT shared memory. However, some ancient apps may still use it. If the extension is broken code, dont waste your time, Im not asking you to spend time on it, we will do our best here to move off of them. But, if the extension is in working order, why not put it back in? To justify removing an extension, the extension needs to be in a broken, non working order, and that it is causing technical problems for the rest of the X system, and to require extensive reworking, and apps can implement what it needs in another way. We dont like how it looks, or we dont think people use this, are not good justifications. Since X.org officially has had all of these extensions until very recently, apparently although they may have been in a non working state, at the same time, they were not causing a problem, so I cannot see the action as being justified to remove them. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
On 1 March 2010 01:28, Richard Brown rbrown1...@gmail.com wrote: Russell Shaw wrote: What are you referring to by Ximage ? Ximage extension to the X server. It has been superceded by MIT shared memory. However, some ancient apps may still use it. It's not clear that *anyone* ever manage to use it successfully. http://en.wikipedia.org/wiki/X_Image_Extension - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
On Sun, Feb 28, 2010 at 08:25:12PM -0500, Richard Brown wrote: I do apologise for the tone of my original letter. We will be staying with X in the future and we will not be moving to another platform. Your large corporation certainly has a lightning fast decision making process. Luc Verhaegen. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
David Gerard wrote: On 1 March 2010 01:28, Richard Brown rbrown1...@gmail.com wrote: Russell Shaw wrote: What are you referring to by Ximage ? Ximage extension to the X server. It has been superceded by MIT shared memory. However, some ancient apps may still use it. It's not clear that *anyone* ever manage to use it successfully. http://en.wikipedia.org/wiki/X_Image_Extension Interesting http://web.archive.org/web/20080413140042/http://people.freedesktop.org/~jg/roadmap.html#mozTocId778727 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Posting w/o quotes because, frankly, there's a lot of text here. MIT-Sundry-Nonstandard never was on any Xorg server I can recall; I remember UT2k4 bitched bitterly at me over it, back when I was still an fglrx user. Google and git suggest that it's been disabled since before 2006 and was finally nuked in 2008. Xprint client code still lives on in Mozilla; have you checked in with them? They may have working server patches. AFAIK the only reason it has bitrotted to the current state is because of a lack of actual clients using it; any intrepid person could probably keep it alive. IIUC RECORD supersedes XTrap and XEvIE although I'm not really up-to-date on the input stuff. Admittedly, I'm kind of young, but I had to go Google all the other extensions to even get a hint of what they do. That's probably not a good sign. :3 -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Richard Brown wrote: I would be interested in the rationale to disable extensions. This isn't needed anymore is not good enough. Assume that there is someone still using the extension, somewhere, an older program that needs it. Perhaps, if the extension required rewriting of thousands of lines of code to keep it working, that might be a good reason to disable it. But dropping support for these things because we can or because we didnt like how it looked there, didnt seem like a good idea. We don't have people running around checking all the extensions for Best if used by dates and chucking the old ones, and it's more than just flipping a switch to enable or disable these. Many were deleted because they didn't keep up with changes in the rest of the X server or would require too much work to be made to work with them. Every extension we keep alive has multiple costs: - it's another vector for security issues, since by definition, an X11 extension is more protocol to parse/handle - if you look at the recent X security issues, many were in individual extensions: http://www.x.org/wiki/Development/Security - it's another set of operations to analyze, classify, and add permission checks to for the frameworks adding higher security levels, such as SELinux Solaris Trusted Extensions. - it's more code to change test whenever we make improvements to the core server or related areas of functionality, and if there are no known users, how do we test we haven't broken them? - it's more code loaded into the system when it's running, and with some extensions either into common code paths or requiring the common code paths to be more complex to allow for it, with the associated performance penalties. Xprint: This allows printing to a postscript file. Seems immensely useful to me as it allows X itself to be used as a printer API. Why was this removed? Is there any major code problem that would have to be fixed? Xprint was never part of the core Xorg server, but a separate Xprt server. Changes to the shared code kept breaking Xprint in different ways, and the requirements Xprint placed on the core server got in the way of other changes. Unlike the others, Xprint wasn't just deleted - it was simply moved into a separate code tree, where it would no longer get broken by shared changes and those who wanted to use it could continue to support it. No vendors that I'm aware of have chosen to ship it, but the code is still made available from X.Org to those who want it. You should even be able to build it yourself, though I haven't tried in quite a while myself. Xtrap, TOG-CUP, Xfree86-misc, XeVIE, EVI, MIT-Sundry-Nonstandard. Again, some programs may need it. Any code problems that would have to be fixed, again, wht are the technical problems, are these broken, do they require major work? Do you even know what most of those do? What program did you have that required MIT-Sundry-Nonstandard to enable compatibility with one specific X11R3 bug, and why didn't you fix it to work with the standard specification in the 20 years since X11R4 came out and warned that behavior was a bug and that it was deprecated and would not be supported forever? Do you still run many systems in 8-bit-only graphics to need the colormap management provided by TOG-CUP? Did you ever have a graphics card report additional useful information from EVI that it doesn't get now via GLX calls? XeVIE seemed very recent. Why was this removed? Is there really huge amounts of broken code there? Xtrap allows capturing of user events? Why remove such functionality? Again, does it contain broken code? The input devices subsystems underwent major overhauls recently with the work for input device hotplugging, XInput extension 2.0, and MPX, and at least XEvIE was left non-working and would need large amounts of work to make working again. That work wasn't done because no one came forward and said they needed it badly enough to make the work happen. (I have actually been surprised by that for XEvIE - we went through all the work to add it because it was supposed to be crucial for accessibility software needed for all of the OS vendors to meet the US government Sec. 508 ADA requirements, and similar requirements of EU and other governments, yet I've not heard that the open source desktop accessibility has been damaged by XEvIE's sudden demise.) Xtrap was an obsolete solution that was replaced in X11R6.0 by the XTest and Record extensions - you've had over 15 years to move your software forward before the deletion, that's hardly a quick turnover. (The obsoletion notice is so old, it tells you to contact engineers at DEC with questions: http://www.x.org/releases/X11R7.5/doc/man/man1/xtrap.1.html#toc6 ) Like other major open source efforts that form core pieces of the OS (very much like the Linux kernel), a majority of the development work is done by people paid by corporations with
Re: Problems with X.org and incompatibilities with in-house software
Corbin Simpson wrote: Admittedly, I'm kind of young, but I had to go Google all the other extensions to even get a hint of what they do. That's probably not a good sign. :3 You will undoubtedly not be the only X developer who is younger than some of this code. Even with everything that's been dumped, X.Org still has a lot of 20-25 year old code left in it, and a lot of that is unlikely to ever go away. You can complain about the server extensions going away, but any portable, well written client always had to check if they were present and do something sane if they weren't - only in recent history has the world coalesced to just a few X server implementations, now that most of the proprietary variants of the days of the Unix wars have died out.(Really, it's mainly just the X.Org implementation (as Xorg, Xwin, Xquartz or kdrive) on almost all Unix-like systems with a desktop these days, and a few others on other systems, like the commercial options for native X servers on Microsoft Windows.) On the client side we've pretty much preserved API ABI compatibility, even when that required major gyrations for the XCB effort - while we encouarage migration to the new XCB libraries, it will be a couple decades before libX11 fades away. -- -Alan Coopersmith- alan.coopersm...@sun.com Oracle Solaris Platform Engineering: X Window System ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
Alan Coopersmith wrote: Corbin Simpson wrote: Admittedly, I'm kind of young, but I had to go Google all the other extensions to even get a hint of what they do. That's probably not a good sign. :3 You will undoubtedly not be the only X developer who is younger than some of this code. Even with everything that's been dumped, X.Org still has a lot of 20-25 year old code left in it, and a lot of that is unlikely to ever go away. You can complain about the server extensions going away, but any portable, well written client always had to check if they were present and do something sane if they weren't - only in recent history has the world coalesced to just a few X server implementations, now that most of the proprietary variants of the days of the Unix wars have died out.(Really, it's mainly just the X.Org implementation (as Xorg, Xwin, Xquartz or kdrive) on almost all Unix-like systems with a desktop these days, and a few others on other systems, like the commercial options for native X servers on Microsoft Windows.) On the client side we've pretty much preserved API ABI compatibility, even when that required major gyrations for the XCB effort - while we encouarage migration to the new XCB libraries, it will be a couple decades before libX11 fades away. I do not expect xlib to ever go away. There is so much written for it, its sort of pointless to refactor apps because we can. If one makes a new app, XCB may be a good choice, when it is mature. I am not sure what benefits XCB has however. It could be as well, the way things often go, someone will forget some needed feature in XCB and Xlib may end up being a better choice in some situations. Ive often seen things like that happen. Case in point ., i upgraded t KDE 4.0. The new Konsole does not take the escape codes for setting the title bar with program name/path name i have sent by tcsh precmd and postcmd. I deleted KDE 4 and went back to KDE 3. Someone didnt understand the importance of this and didnt include this. KDE 4 for me was a downgrade, it actually regressed. An age of code is no indicator of its quality. Old code can be better in cases. Consider most modern applications such as Firefox which are bloated memory hogs compared to older software. Code quality seems to have decline rather than improve. As far as the extensions. I understand if the code in them was a security hazard, i can see why they would not be wanted to be included in the default compiles. And as well, some with broken code, with features duplicated elsewhere and with not many apps which use them, it may not be a good investment of time to try to fix them, considering there is more valuable uses of time resources. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
On Sun, Feb 28, 2010 at 8:13 PM, Richard Brown rbrown1...@gmail.com wrote: Alan Coopersmith wrote: On the client side we've pretty much preserved API ABI compatibility, even when that required major gyrations for the XCB effort - while we encouarage migration to the new XCB libraries, it will be a couple decades before libX11 fades away. I do not expect xlib to ever go away. There is so much written for it, its sort of pointless to refactor apps because we can. If one makes a new app, XCB may be a good choice, when it is mature. I am not sure what benefits XCB has however. It could be as well, the way things often go, someone will forget some needed feature in XCB and Xlib may end up being a better choice in some situations. Ive often seen things like that happen. Case in point ., i upgraded t KDE 4.0. The new Konsole does not take the escape codes for setting the title bar with program name/path name i have sent by tcsh precmd and postcmd. I deleted KDE 4 and went back to KDE 3. Someone didnt understand the importance of this and didnt include this. KDE 4 for me was a downgrade, it actually regressed. XCB cannot possibly omit any protocol information because of the way it's crafted: It is directly generated at build-time from descriptions of the X wire protocol. It also is far more intelligent about avoiding round-trips to the server and such. That said, people generally wait until the very last minute to switch away from legacy software, so it's not like people are switching in droves. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
On Sun, Feb 28, 2010 at 09:18:35PM -0800, Corbin Simpson wrote: On Sun, Feb 28, 2010 at 8:13 PM, Richard Brown rbrown1...@gmail.com wrote: Alan Coopersmith wrote: On the client side we've pretty much preserved API ABI compatibility, even when that required major gyrations for the XCB effort - while we encouarage migration to the new XCB libraries, it will be a couple decades before libX11 fades away. I do not expect xlib to ever go away. There is so much written for it, its sort of pointless to refactor apps because we can. If one makes a new app, XCB may be a good choice, when it is mature. I am not sure what benefits XCB has however. It could be as well, the way things often go, someone will forget some needed feature in XCB and Xlib may end up being a better choice in some situations. Ive often seen things like that happen. Case in point ., i upgraded t KDE 4.0. The new Konsole does not take the escape codes for setting the title bar with program name/path name i have sent by tcsh precmd and postcmd. I deleted KDE 4 and went back to KDE 3. Someone didnt understand the importance of this and didnt include this. KDE 4 for me was a downgrade, it actually regressed. XCB cannot possibly omit any protocol information because of the way it's crafted: It is directly generated at build-time from descriptions of the X wire protocol. These protocol descriptions may be missing though (e.g. XI is afaik still incomplete). so even with xcb you might find that what you want to do isn't possible and libX11 is the only choice for now. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
