Of course, not every single person maintaining a library is as careful as the glibc people
The glibc people aren't careful at all. They are quite, quite happy to break software if they believe the users programs to be "broken". They've broken even high profile apps like Mozilla this way, because their interpretation of a spec was different to everybody elses. But no, Mozilla was "broken" and whoever wrote that function should be "punished" according to the maintainer.
The glibc group, along with many many other free software projects, usually believe they are maintaining backwards compatibility. In practice they are at most maintaining ABI compatibility which is not enough: the interface of an API is so much more than the layout of its structures and prototypes of its functions.
I've written a guide on how to write good shared libraries. It deals a lot with versioning and how to avoid breaking software.
I'm hoping it can be peer reviewed and published somewhere soonish, in the next few weeks. I'd post the draft here but the server hosting it seems to be down.
I guess we disagree on the meaning of integrated. As far as I'm concerned, the kernel is what lives in kernelspace, therefore if something is running in kernel mode it's a part of the kernel.
Apple have the advantage that they can just throw hardware at the problem and say "well, just buy our shiny new mac!". When the decision was made to move the windowing code into the NT kernel Microsoft were trying to meet very aggressive minimum system requirements. There's a lot in Windows that is there because they wanted as many computers as possible to be able to run it.
Yes. That DLL is shipped as a part of IE but obviously as IE is a part of the OS, other programs started using it too. Same for a lot of similar DLLS (mlang, for instance).
Even the IE main loop is in a documented, API providing DLL (shdocvw). It's not an extreme interpretation at all... IE and Windows are as one, with functions like DeleteIE3Cache() co-existing side by side with HTTP utility functions used by apps like iTunes.
Nope, I'm pretty sure the windowing system is done at kernel level as well (things like message routing definitely are). If you have specific evidence that the GUI objects are run in a standard userspace process I'd like to see that - what is the task name, for starters.
No it's not. See XPLite to remove all traces of IE.
Yes it is. If you remove "all traces" of IE then presumably you are also removing things like wininet, urlmon, hhhelp and the other million and one components of the OS that are shipped and developed as part of IE and on which applications depend.
Believe me, you pull IE and all kinds of random stuff breaks. I've spent the last two years working on Wine and one thing it's taught me is that there is no way IE can be disentangled from the OS (unless you could deleting iexplore.exe, which achieves nothing). Too many programs expect it to be there and will break if it's not.
With NT4, the meat of win32 was moved into kernel mode (win32k.sys) to reduce context switching overhead; win32 was not then and still isn't integrated into the kernel itself.
I have to take exception to that. The GUI subsystem most certainly is integrated into the kernel - not only does it run in kernel mode but its location there basically makes objects like menus, windows, images... even metafiles (!) kernel level objects which can be created in one process and then passed to another and used there. Applications rely on this ability.
Don't forget crap like the registry running in kernel mode as well.
I mean, how on earth do you define integrated into the kernel if not by applications expecting it to be there?
WindowBlinds is a pretty old app but it's not exactly a shining advert for Windows. Yes it was slow but more problematically it destabilised the system quite significantly. It worked by overriding and hooking *large* parts of the Windows API, changing the semantics and behaviour of those APIs out from underneath the apps. Windows provided no native support for this until XP, and even then applications have to opt in to it. Adding theming to Windows was a breaking change, that's why some apps on XP are themed and some aren't.
No, the overhead of the X protocol is negligable. When doing profiling runs the bottlenecks are nearly always either in the serverhardware link or inside the toolkit. The applicationserver link doesn't really slow much down at all.
There's no way to apply the Windows alpha support to the entire desktop systematically - for instance, window management in windows is done in-process by a DLL rather than by an external process co-ordinating things. That makes it rather harder to do stuff like drop shadows if you're not Microsoft and they are not apparently in any hurry.
Windows alpha support is basically "Make this window sorta transparent". The Windows desktop isn't actually composited: only when a translucent window is over another window is the contents of that window buffered. The rest of the time you're still in flicker-land.
I guess back in 2001 when XP was released average machine didn't have enough RAM to make it doable. Many perhaps still don't, but nonetheless Windows is last in the composited desktop arena.
The first, and biggest reason (as far as I know) is that modern Linux widget toolkits are doing a lot more work than the Windows widget toolkit is.
For instance, full UTF-8/unicode rendering support combined with containment based layout, along with stock clipart using an alpha channel which is all double buffered simply requires more CPU time than a positional based toolkit which doesn't really support alpha-blended images (or indeed, stock artwork at all), flickers constantly and whos i18n support is patchy at best.
These are features which are useful and you don't want to lose. They make the GUI look great due to having professional artwork, smooth when resizing (internally), support users from all cultures and mean that resizable windows which react properly to font size changes are the norm not the exception like on Windows.
There are other issues. The focus of most Linux developers has not been optimization as of yet, as development effort has been concentrating on filling in the missing pieces (like HAL) and on catching up with the competition (this sort of X work). As an example I think Xrender and therefore font renderning had some serious bottlenecks until recently. There are a few notable exceptions. Soeren Sandmann for instance has been working on optimizing Linux graphics and GTK for some time now, and has been doing a great job.
Then there are scheduling/kernel issues. Con Kolivas mentioned some issues with respect to scheduling lately, I forget exactly what, but he seemed to think some change in the X server could allow the 2.6 scheduler to do a much better job. Also last time I checked the kernel did not expose vertical retrace intervals to the X server.
Finally there are issues within the toolkits themselves. GTK+ seems to really suck at rapidly responding to Expose events. I'm not sure why. However on COMPOSITE enabled machines this isn't an issue as everything is double-buffered at the server level anyway so time taken to react to Expose events isn't a factor. Just try the new distros if/when they come out with compositing enabled - they will feel a lot faster due to this change alone, assuming you have enough memory.
This is an amusing troll. If it isn't a deliberate troll then you need to learn how to express yourself more clearly instead of in vague buzzwords.
When can we see a trusted computing environment?
SELinux integration with the X server (SE-X) to allow you to lock applications down tighter is being worked on in a branch of Xorg CVS. It's not done yet AFAIK. The idea here is that you can take the features of "trusted" military-strength windowing systems where it's possible to have secure windows such that you cannot screenshot them, other apps cannot send events to them and so on.
When will we see fully improved network/remote access?
This statement is meaningless but NX compression is clearly the way forward here.
When will we see some innovation instead of eye candy?
Again, totally useless statement. Nowhere do you define "innovation" or even show that it's a good thing (hint: I'll take an efficient and usable desktop over and pointlessly innovative one any day).
The hooks for modular gui plugins should be there - just as with any gui. OS/2 had the object based interface, windows has the pretty indepth theme integration and OSX has the PDF display..
Again a meaningless statement. There are actually some pretty convincing arguments out there that DPDF/DPS type systems are the wrong way to implement a graphics system, and that XRENDER type trapezoid rendering is the right way. I suggest you investigate first.
Windows XP has themes - great. You realise that Linux has pioneered the way when it comes to theming? It was the first to have a totally themable desktop (I think this is true even if you include gross hacks like WindowBlinds), still the only OS to have systematic icon theming, the only one I know of that has mouse cursor theming etc.
Why not work on something to compete against microsofts new gui/api interffaces based upon 3d rendering instead of pixel rendering?
I think you've misunderstood what Avalon is. It's not about 3D GUIs, it may include using 3D acceleration to speed up rendering on machines that support it but this doesn't affect the APIs.
Quick release cycles don't do anything for corporate adoption. Give us the "killer app" - in this case a desktop/windowing system that delivers everything we seem to bash in other systems as insecure or proprietary.
I don't know of any other open, standardised windowing system with the security features X has. If you can show me one, I'd be interested.
It was flamebait, as you clearly haven't understood the principle that operating system component releases are different to operating system releases. I haven't had to tweak any X configuration file for a long time now, thanks to the Red Hat/Fedora config tools. I have no doubt that when I upgrade to FC3 this will all be set up automatically. That's what a distribution does, right?
The new extensions are just that, protocol extensions. They haven't changed the wire format.
Having said that, the presence of the new ARGB visuals is known to confuse and break some programs. Worryingly, Mozilla+Flash and GTK 1.2 apps (like XMMS, VMware, etc) are amongst the things that have apparently broken.
To "unbreak" them you need to set a magic environment variable but as of yet there is no automatic blacklisting mechanism in place for userspace apps so.... you just have to be able to diagnose this breakage yourself.
End users are notoriously bad at judging package quality. Given how many developers I've met who have had issues with the way their software was packaged for Debian or Gentoo (I'm one of them) I think you'd have to give really good supporting arguments that they were of a consistently high quality.
Let's face the facts: like it or not, Apple is the innovator here, and one of very, very few in the industry.
I'm not sure getting rid of old cruft is "innovative". If so then the definition of the word has been stretched a fair bit from what it used to be.
Anyway, who cares? One mans "innovation" is anothers backwards compatibility. Floppy drives are so cheap, that it's really not a big deal if you include one. Given that some people may find them useful, what's the benefit to taking them out? Hell the machine in front of me has a gig of RAM and a 3ghz P4, yet it still has a floppy drive. Why not?
Well the guy said It causes distress and health problems in many cows though given that you presumably have to take the milk out of the cow to add chemicals to it, I'm not sure how that works...
Pretty much any UI that has a listbox with 10,000+ items in it has problems usability wise... when you consider that it makes no distinction between glibc-devel and frozen-bubble it gets even worse.
There are other issues as well... it's such a low level tool that it lets you shoot yourself in the foot as easily as doing the right thing.
These problems are fixable but only by developing a lot of new infrastructure. It's on the todo list.
The Future of Money is one of his better known ones, there are others. I think one is called the secrets of money, or maybe it was the history of money. I forget. Something like that. It tells you in the future of money covering material.
I agree wholeheartedly. I'm doing my best to support Codeweavers, but it's hard sometimes. I get especially frustrated when I see them concentrating an entire release on making iTunes work instead of something like Quickbooks.
Actually, we are almost always working on multiple things at once. Often quite a few of us are working on bugfixes for large, corporate proprietary apps - this is mostly separate to our CrossOver work where we focus on the home/enthusiast Linux users market. The contract work we do for such programs isn't public but the patches go back to WineHQ immediately just the same as work for CrossOver does.
Often these bugfixes are the sort of thing which affect many GUI desktop apps, including things like QuickBooks. So you could say we are working on it in an indirect way.
But I know, I know, you want us to work on QuickBooks specifically, so it runs in CrossOver. Believe me, we'd love to do that too - the only Windows machine in our office is used by the secretary (or as we call her, our Chief Non Geek). She's said she'd be happy to run Linux. So why doesn't she? Right, you guessed it - we use QuickBooks ourselves.
Unfortunately, being a (small) company that isn't exactly rolling in money, we have to focus entirely on what our customers are most willing to pay for. As you can see from our top voted apps list iTunes comes first by a long way with 118 votes, and QuickBooks Pro comes in at number 22 with 16 votes. We can't magically divine what CrossOver users are willing to pay for, so we have to go via these sorts of lists.
I hope that explains our slightly odd focus. Unfortunately Linux on the corporate desktop hasn't taken off yet: given the huge resources Red Hat and Novell are marshalling behind it I'm hoping it has to happen soon, but currently, it hasn't. That means Wine development is driven mostly by personal users.
I noticed in their bug list the other day somebody asked them to support UPS Worldship, which is a *simple* app that would be perfect for running on Linux. Their response was "no" without even considering it
Our bugzilla isn't public so I guess you are talking about the C4 site I linked to above. Our experience shows that there is no such thing as a "simple" app when it comes to Wine - even very straightforward and apparently simple programs can make use of obscure functionality or hit edge-case bugs in Wine that mean they don't work right. By definition if somebody asked us to support it, it doesn't work correctly. We can either choose to spend the time tracking and fixing those bugs, or the bugs that affect high profile, popular apps.
Fortunately we're supported by (and in turn support) the Wine community. We resync with WineHQ regularly (every few weeks usually) so it's definitely possible that a fix for UPS Worldship will make it in from there, or we'll fix it in the course of making other apps work. We term this "collatoral damage", somewhat flippantly - basically it means that as we work on improvements for one program, all the others start working better as well. For example, Office now runs about 50% faster (according to officebench) in the upcoming CrossOver 3.1 relative to 3.0 due entirely to optimizations developed whilst working on iTunes.
OK, I hope I explained how we set our priorities well enough. Thanks for supporting us and the Wine project!
Slashdot Mirror
The glibc people aren't careful at all. They are quite, quite happy to break software if they believe the users programs to be "broken". They've broken even high profile apps like Mozilla this way, because their interpretation of a spec was different to everybody elses. But no, Mozilla was "broken" and whoever wrote that function should be "punished" according to the maintainer.
The glibc group, along with many many other free software projects, usually believe they are maintaining backwards compatibility. In practice they are at most maintaining ABI compatibility which is not enough: the interface of an API is so much more than the layout of its structures and prototypes of its functions.
I've written a guide on how to write good shared libraries. It deals a lot with versioning and how to avoid breaking software.
I'm hoping it can be peer reviewed and published somewhere soonish, in the next few weeks. I'd post the draft here but the server hosting it seems to be down.
I guess we disagree on the meaning of integrated. As far as I'm concerned, the kernel is what lives in kernelspace, therefore if something is running in kernel mode it's a part of the kernel.
Apple have the advantage that they can just throw hardware at the problem and say "well, just buy our shiny new mac!". When the decision was made to move the windowing code into the NT kernel Microsoft were trying to meet very aggressive minimum system requirements. There's a lot in Windows that is there because they wanted as many computers as possible to be able to run it.
Even the IE main loop is in a documented, API providing DLL (shdocvw). It's not an extreme interpretation at all ... IE and Windows are as one, with functions like DeleteIE3Cache() co-existing side by side with HTTP utility functions used by apps like iTunes.
Nope, I'm pretty sure the windowing system is done at kernel level as well (things like message routing definitely are). If you have specific evidence that the GUI objects are run in a standard userspace process I'd like to see that - what is the task name, for starters.
Blind fanboyism doesn't get you anywhere ...
Yes it is. If you remove "all traces" of IE then presumably you are also removing things like wininet, urlmon, hhhelp and the other million and one components of the OS that are shipped and developed as part of IE and on which applications depend.
Believe me, you pull IE and all kinds of random stuff breaks. I've spent the last two years working on Wine and one thing it's taught me is that there is no way IE can be disentangled from the OS (unless you could deleting iexplore.exe, which achieves nothing). Too many programs expect it to be there and will break if it's not.
I have to take exception to that. The GUI subsystem most certainly is integrated into the kernel - not only does it run in kernel mode but its location there basically makes objects like menus, windows, images ... even metafiles (!) kernel level objects which can be created in one process and then passed to another and used there. Applications rely on this ability.
Don't forget crap like the registry running in kernel mode as well.
I mean, how on earth do you define integrated into the kernel if not by applications expecting it to be there?
Old as in "been around a long time".
WindowBlinds is a pretty old app but it's not exactly a shining advert for Windows. Yes it was slow but more problematically it destabilised the system quite significantly. It worked by overriding and hooking *large* parts of the Windows API, changing the semantics and behaviour of those APIs out from underneath the apps. Windows provided no native support for this until XP, and even then applications have to opt in to it. Adding theming to Windows was a breaking change, that's why some apps on XP are themed and some aren't.
No, the overhead of the X protocol is negligable. When doing profiling runs the bottlenecks are nearly always either in the serverhardware link or inside the toolkit. The applicationserver link doesn't really slow much down at all.
Windows alpha support is basically "Make this window sorta transparent". The Windows desktop isn't actually composited: only when a translucent window is over another window is the contents of that window buffered. The rest of the time you're still in flicker-land.
I guess back in 2001 when XP was released average machine didn't have enough RAM to make it doable. Many perhaps still don't, but nonetheless Windows is last in the composited desktop arena.
The first, and biggest reason (as far as I know) is that modern Linux widget toolkits are doing a lot more work than the Windows widget toolkit is.
For instance, full UTF-8/unicode rendering support combined with containment based layout, along with stock clipart using an alpha channel which is all double buffered simply requires more CPU time than a positional based toolkit which doesn't really support alpha-blended images (or indeed, stock artwork at all), flickers constantly and whos i18n support is patchy at best.
These are features which are useful and you don't want to lose. They make the GUI look great due to having professional artwork, smooth when resizing (internally), support users from all cultures and mean that resizable windows which react properly to font size changes are the norm not the exception like on Windows.
There are other issues. The focus of most Linux developers has not been optimization as of yet, as development effort has been concentrating on filling in the missing pieces (like HAL) and on catching up with the competition (this sort of X work). As an example I think Xrender and therefore font renderning had some serious bottlenecks until recently. There are a few notable exceptions. Soeren Sandmann for instance has been working on optimizing Linux graphics and GTK for some time now, and has been doing a great job.
Then there are scheduling/kernel issues. Con Kolivas mentioned some issues with respect to scheduling lately, I forget exactly what, but he seemed to think some change in the X server could allow the 2.6 scheduler to do a much better job. Also last time I checked the kernel did not expose vertical retrace intervals to the X server.
Finally there are issues within the toolkits themselves. GTK+ seems to really suck at rapidly responding to Expose events. I'm not sure why. However on COMPOSITE enabled machines this isn't an issue as everything is double-buffered at the server level anyway so time taken to react to Expose events isn't a factor. Just try the new distros if/when they come out with compositing enabled - they will feel a lot faster due to this change alone, assuming you have enough memory.
When can we see a trusted computing environment?
SELinux integration with the X server (SE-X) to allow you to lock applications down tighter is being worked on in a branch of Xorg CVS. It's not done yet AFAIK. The idea here is that you can take the features of "trusted" military-strength windowing systems where it's possible to have secure windows such that you cannot screenshot them, other apps cannot send events to them and so on.
When will we see fully improved network/remote access?
This statement is meaningless but NX compression is clearly the way forward here.
When will we see some innovation instead of eye candy?
Again, totally useless statement. Nowhere do you define "innovation" or even show that it's a good thing (hint: I'll take an efficient and usable desktop over and pointlessly innovative one any day).
The hooks for modular gui plugins should be there - just as with any gui. OS/2 had the object based interface, windows has the pretty indepth theme integration and OSX has the PDF display..
Again a meaningless statement. There are actually some pretty convincing arguments out there that DPDF/DPS type systems are the wrong way to implement a graphics system, and that XRENDER type trapezoid rendering is the right way. I suggest you investigate first.
Windows XP has themes - great. You realise that Linux has pioneered the way when it comes to theming? It was the first to have a totally themable desktop (I think this is true even if you include gross hacks like WindowBlinds), still the only OS to have systematic icon theming, the only one I know of that has mouse cursor theming etc.
Why not work on something to compete against microsofts new gui/api interffaces based upon 3d rendering instead of pixel rendering?
I think you've misunderstood what Avalon is. It's not about 3D GUIs, it may include using 3D acceleration to speed up rendering on machines that support it but this doesn't affect the APIs.
Quick release cycles don't do anything for corporate adoption. Give us the "killer app" - in this case a desktop/windowing system that delivers everything we seem to bash in other systems as insecure or proprietary.
I don't know of any other open, standardised windowing system with the security features X has. If you can show me one, I'd be interested.
It was flamebait, as you clearly haven't understood the principle that operating system component releases are different to operating system releases. I haven't had to tweak any X configuration file for a long time now, thanks to the Red Hat/Fedora config tools. I have no doubt that when I upgrade to FC3 this will all be set up automatically. That's what a distribution does, right?
Having said that, the presence of the new ARGB visuals is known to confuse and break some programs. Worryingly, Mozilla+Flash and GTK 1.2 apps (like XMMS, VMware, etc) are amongst the things that have apparently broken.
To "unbreak" them you need to set a magic environment variable but as of yet there is no automatic blacklisting mechanism in place for userspace apps so .... you just have to be able to diagnose this breakage yourself.
Hence the fact that it's described as unstable.
End users are notoriously bad at judging package quality. Given how many developers I've met who have had issues with the way their software was packaged for Debian or Gentoo (I'm one of them) I think you'd have to give really good supporting arguments that they were of a consistently high quality.
How exactly is the floppy disk holding anything back? Last time I checked both PCs and Macs used IDE ...
I'm not sure getting rid of old cruft is "innovative". If so then the definition of the word has been stretched a fair bit from what it used to be.
Anyway, who cares? One mans "innovation" is anothers backwards compatibility. Floppy drives are so cheap, that it's really not a big deal if you include one. Given that some people may find them useful, what's the benefit to taking them out? Hell the machine in front of me has a gig of RAM and a 3ghz P4, yet it still has a floppy drive. Why not?
Well the guy said It causes distress and health problems in many cows though given that you presumably have to take the milk out of the cow to add chemicals to it, I'm not sure how that works ...
What, you'd prefer it to trash your home directory instead? ;)
It works in 3.1 which is currently in beta. We'll update C4 when you can actually buy the product in which it works.
There are other issues as well ... it's such a low level tool that it lets you shoot yourself in the foot as easily as doing the right thing.
These problems are fixable but only by developing a lot of new infrastructure. It's on the todo list.
The Future of Money is one of his better known ones, there are others. I think one is called the secrets of money, or maybe it was the history of money. I forget. Something like that. It tells you in the future of money covering material.
Actually, we are almost always working on multiple things at once. Often quite a few of us are working on bugfixes for large, corporate proprietary apps - this is mostly separate to our CrossOver work where we focus on the home/enthusiast Linux users market. The contract work we do for such programs isn't public but the patches go back to WineHQ immediately just the same as work for CrossOver does.
Often these bugfixes are the sort of thing which affect many GUI desktop apps, including things like QuickBooks. So you could say we are working on it in an indirect way.
But I know, I know, you want us to work on QuickBooks specifically, so it runs in CrossOver. Believe me, we'd love to do that too - the only Windows machine in our office is used by the secretary (or as we call her, our Chief Non Geek). She's said she'd be happy to run Linux. So why doesn't she? Right, you guessed it - we use QuickBooks ourselves.
Unfortunately, being a (small) company that isn't exactly rolling in money, we have to focus entirely on what our customers are most willing to pay for. As you can see from our top voted apps list iTunes comes first by a long way with 118 votes, and QuickBooks Pro comes in at number 22 with 16 votes. We can't magically divine what CrossOver users are willing to pay for, so we have to go via these sorts of lists.
I hope that explains our slightly odd focus. Unfortunately Linux on the corporate desktop hasn't taken off yet: given the huge resources Red Hat and Novell are marshalling behind it I'm hoping it has to happen soon, but currently, it hasn't. That means Wine development is driven mostly by personal users.
Our bugzilla isn't public so I guess you are talking about the C4 site I linked to above. Our experience shows that there is no such thing as a "simple" app when it comes to Wine - even very straightforward and apparently simple programs can make use of obscure functionality or hit edge-case bugs in Wine that mean they don't work right. By definition if somebody asked us to support it, it doesn't work correctly. We can either choose to spend the time tracking and fixing those bugs, or the bugs that affect high profile, popular apps.
Fortunately we're supported by (and in turn support) the Wine community. We resync with WineHQ regularly (every few weeks usually) so it's definitely possible that a fix for UPS Worldship will make it in from there, or we'll fix it in the course of making other apps work. We term this "collatoral damage", somewhat flippantly - basically it means that as we work on improvements for one program, all the others start working better as well. For example, Office now runs about 50% faster (according to officebench) in the upcoming CrossOver 3.1 relative to 3.0 due entirely to optimizations developed whilst working on iTunes.
OK, I hope I explained how we set our priorities well enough. Thanks for supporting us and the Wine project!