So, let's talk about your third-party apps. You say that the API for transparency is in W2K. Do you seriously think that that degrades the performance of W2K? No, of course not! USING it does.
>>>>
Except that it doesn't. Transparency in Windows is a hell of a lot smoother than transparency in GNOME, and GNOME transparency isn't even REAL transparency.
Does this make Linux desktops (using eterm or gnome-terminal) more "bloated" or "slower" than Windows? No, it's just that the feature set is different by default. That's been my point all along.
>>>>>>>
Yes. GNOME is slower than Windows both with the cool features on and the cool features off. Except for resizing (which transparency kills of course) Windows WITH the features is faster than GNOME WITHOUT the features.
Actually, the best benchmark is real usage. Try just opening up a bunch of desktop apps and manipulating them. Cell highlighting in KSpread, for example, is jerky while it is butter-smooth in excel. I have yet to see a X widget set that draws as fast as the Windows default one. Windows apps (especially on XP) start faster than comparable KDE or GNOME apps. In Windows, my mouse never hiccups, while it does so regularly in Linux. This usage tests are quite apples to apples. I'm trying to do the same types of things with similar apps. Both systems are tweeked because I use them on a regular basis.
There is no doubt that Linux is faster, more stable, and more memory efficient that Windows. But if the software base built on it (including GNOME and KDE) suck in terms of performance, can anyone say that Linux the platform is faster than Windows the platform?
Its not all vector based, there are plenty of bitmaps flying around.
>>>>>>
True, but those bitmaps are objects too, and have to be stored in memory anyway. There is no point in storing the bitmaps again in the backing store.
A backing store is "the right way" to do it. The perpixel backing store is what allows all the funky blending operations like shadows & transparency.
>>>>>>>>
First, shadows and transparency are stupid features to begin with. The nifty advantage of the backing store isn't shadows, but the fact that the OS can repaint part of a window when it is exposed. Using the scene graph to rerender the window would take much less memory and (assuming a good hardware implementation) be just as fast. If you really wanted shadows, you could always render the window to a bitmap and alpha-blend that, it wouldn't be appreciably slower.
No, Windows cannot to pixmap themes and transparency. Sure, there are third-party apps for that, but that's not the point.
>>>>>>>>
But it can! Are you telling me that those programs don't really exist? What's this third party bullshit? Like GNOME or KDE aren't third party programs on top of X? Plus, if you'd bothered to read the opacity website, the API for transparency is built into Windows 2000. Its just that its a totally useless feature that doesn't warrent a utility coming with the OS. As for pixmap themes, some level of theming support has to be built into the widget API, or else Window Blinds wouldn't be able to override the default look. For a while, Win95 had the feature to be able to look like Win 3.x, so the look isn't as hard-coded as you'd like to believe. Besides, that's a moot point anyway. XP officially has theming support and a visual styles API.
I just find it terribly frustrating that I am forced to buy the latest and greatest version of Caligari's TrueSpace, simply to be able to create some, nifty to me, 3D rendered objects.
>>>>>>>
Blame Caligari. It had no business basing a 3D moderling in DX. The state of D3D at the time the early versions of TrueSpace came out was not at the level necessary for a 3D modeler. D3D has changed entirely, and its hard to expect D3D to maintain compatibility with an app that is pushing the API to its limits anway. (I wouldn't be suprised if the early versions for TrueSpace are full of D3D workarounds.)
And the benefits of a platform-independent binary format would be *huge*.
>>>>>>
Uh, no. Last time I checked, almost all Linux software distros release binaries for each supported arch. Besides, everyone (statistically) uses x86, so who cares?
I care about speed, Windows wins. I have yet to see a widget set on X that matches the performance of Win32 in terms of redraw speed. Hell, even Qt on Windows is faster than Qt on Linux.
I care about unification, Windows wins.
>>>>>>>
I like GIMP, and I like KDevelop. I don't have infinite RAM and I like my apps to look the same. What do I do?
I care about predictability, Windows wins.
>>>>>>>
The other day, I installed AbiWord, and it didnt' like the fact that I'd removed its crappy Type1 fonts from my path. Why? Why is the app so damn bound to its fonts? I tried to install the mandrake kernel source RPM the other day, to find that it needed GCC 2.96. GCC 3.0.1 (which I have installed, in RPM form no less) works fine for the kernel, why is it so attached to its obsolete RPM? There are just too many factors in Linux that can fuck up. In theory, Linux is quite elegant and powerful, but in practice, its really not. Not as a GUI machine anyway.
I care about stability, Windows wins:
Its true. KDE-2 has crashed more often on me than Windows 2000. Of course, you'll tell me to go use Window Maker, then I'll ask where my unified GUI is, and you'll then tell me to use KDE-2.
I care about audio, Windows wins:
The Linux audio system is probably the most f*cked up thing ever. aRts on top of OSS/ALSA? WTF? Aren't software mixers archaic relics of the early 1990's? And why is aRts nifty media framework tied to a dumb software mixer? I wnat to use my SBLive! fully! ALSA is quite powerful, and quite speedy. Build a media framework on that instead.
Of course, Linux has tons of strong points. The kernel whips Windows to all hell. The VM system is (finally, thanks AA) much better, the filesystems are faster, and everything is just smoother. With the preempt and lowlat patches, BeOS finally loses the audio-latency performance crown for a general purpose OS (as long as you don't use aRtsd or esound!) urpmi is nifty (when it works). Konqourer is really a step forward. Auroura boot is just plain cool. I use Linux on a daily basis these days, but I don't enjoy it as much as I should. XFce and GNOME are decently fast, but lacking in features I enjoyed in Windows. I can use XMMS/ALSA and get good sound, but I have to live without the media framework I had in BeOS. It certainly gets the job done, but it has so much more potential its disgusting. Everything is already there. If only someone non-braindead came along to organize it all...
Nope. Can't do pixmap themes (that is, themes where all of the widgets, title-bars, etc have pixmaps, not just flat colors or gradients).
>>>>>
Nope, sorry. Try Window Blinds
Can't do windows with transparent backgrounds.
>>>>>
Wrong again. transparency too. Plus, this is even better than GNOME's transparency. Performance is great. Moving is instananeous, and resizing is only a little worse than KDE-2's without transparency. Plus, you can make any window transparent, play a video, and then put the transparent window over it. The video will by alpha-blended with the window in real time, without ANY flickering or jerking. I tried it with the opacity program web page, and the logo overlaid perfectly over a CNN newfeed. Last I heard, X won't allow *real* transparent windows, where the window underneath can update and the updates will show through. Oh, and all this is on a lowly PII-300 with 256MB of RAM.
Can't do much of the customization that you can do with Gnome.
>>>>>>
Like?
MS has just failed to put in the features that I'm suggesting low-end users turn off.
>>>>>
So, these features are just in my mind? I'm imagining real transparency because its so late at night?
Sorry about that. I meant that it doesn't have to be native to the windowing system. Windows 2000's GUI runs in the kernel, but it supports remote GUI just fine. Network transparency isn't why X is a seperate process, saftey is. X runs in a different address space so it can't crash the kernel.
The image buffering thing is really unsettling. Given that Quartz is an inherently vector-based system, wouldn't it make much more sense to store the vector representation of the window, rather than the image contents? The memory requirements for this would be much more nominal.
Oh, and another thing. (feeble attempt to get back on topic) My iBook and my friend's PBG4 feel just about the same under OS 10.1 with 384 MB of RAM each. Both very, very usable.
>>>>
You do realize how incredibly pathetic it is that you've got a fast G3 processor and gobs of RAM, yet your OS is only "very, very usable."
Yes, trolling, I know. But only for my crusade against bloated system software...
First, XFree86 isn't designed with fast communications channels in mind, and thus doesn't benifet much from shared memory channels. Second, I wasn't talking about putting X11 in the kernel or anything like that. I was saying that the window manager, instead of being a seperate process, could by a dynamic library. The real reason the WM (like Blackbox or whatever) is seperate is for flexibility. Back when X was designed, dynamically loaded libraries didn't exist, so the WM was put into another program. Now that we have dynamic libraries, you could load the WM as a X server module and get the benifets of flexibilty AND speed. This would speed up stuff like moving windows which are slow in X because of the communication required between the WM and the X server.
Yahoo. You don't need a client-server architecture achieve remote usage. There's a program on Windows called Citrix ICA. It allows you to run programs remotely. On a T1, Excel runs only a little slower than running KSpread does locally! The real reason X runs as a seperate process isn't network transparency, but protection. The GUI needs to protected place where it can maintain data about the windowing system. On Windows, this windowing code is put in the kernel. Here, user apps can't crash it, but it can crash the kernel. The only other safe place is a seperate process. In theory, one could put the windowing system into a library, so all UI calls would be simple function calls, but on most chips, there is no way to protect library data structures from the user process. The old x86 segmentation mechanism used to be able to check a memory access based on the privelege level of the segment holding the calling code. If something like this could be done for pages (only the GUI's code pages would have the right to access GUI data), then we could get rid of this whole windowing process crap altogether. But, I digress. That wasn't my point in the first place. I was saying that you could put the window manage in a library and dynamically load it into the X server. The X sever doesn't need to be protected from the window manager, and putting it in a library would offer most of the flexibility of putting it in a seperate process. This would speed up a lot of the window/manipulation operations that are so slow in X today.
Most of this is just the routine memory-conservation that any desktop can benefit from. Gnome gives you a WHOLE LOT of rope, because some users WANT to take advantage of 512MB of RAM to load background pixmaps, pixmap-heavy themes and 6 huge apps!
>>>>>>
The funny thing is, I can do all this stuff in Windows *without* killing performanc. Even on my relatively old computer. GNOME is nice (and so is KDE) but performance isn't a strong suit.
Being technically superior to Windows wasn't enough for Java, and it won't be enough for the Linux desktop.
>>>>>
The Linux desktop hasn't even gotten to the "technically superior" phase yet. I use it everyday, but Windows has a really big edge in the technical superiority department.
You're perfectly right about breaking binary compatibility due to source changes. I was talking about binary compatibility between GCC releases (C++ libraries in GCC break every new release). As for virtual methods, they don't totally solve the problem, but don't incur a speed hit either. The virtual method type thing you're referring to is what COM does. You can't easily subclass such an object, and most C++ libraries depend heavily on that capability. Second, virtual C++ calls are no slower than C library calls. In C, all library calls refer to a table of function offsets. The call first jumps to that table, which then jumps to the actual function. (Or it reads the address of the function from the table, it depends on the implementation.) This is done so that you can map libraries into different places in the process address space (say one day at 0x600 then the next at 0x1200) and you only have to change the values in the table rather than all the function calls in the code. With C++ virtual function calls, the process is similar (in Visual C++'s compiler anyway). When the library is dynamically linked to the program, the vtables of each class are written with the addresses of the functions that implement each method. Thus, the call is a single-indirect calls, just like a C library call.
You can't really blame some DirectX programs for breaking. DirectX has evolved so much, that there are basically 3 different DirectXs, pre-5.x, 5.x-6.x, and 7.x-9.x. Even within catagories (such as 7.x-9.x), some things have been totally overhauled. Then, you add the fact that DirectX most DirectX games were originally designed for Windows 95, but most still run on the totally different Windows 2000. At that point, its a miracle that MS has been able to keep DirectX as backwards compatbile as it is. Certainly nothing in the Linux world compares to it.
have the GCC people thought of any ways to make binary compatibility easier to maintain in C++ programs without requiring vtable hacks and other ugliness?
>>>>>>>>>
Hopefully, C++ binary incompatibility should be passe. There is a standard C++ ABI for Itanium, and GCC 3.0's C++ ABI should be standard for x86. I don't know if other compiler vendors will follow suit (one hopes, but doubts), but the GCC people shouldn't change it.
Qt isn't the problem. On Windows, even widget-heavy Qt apps redrawing smoothly. I have absolutely now idea why redraw performance on Linux is so bad. Its probably not XFree86's rendering core, since I hear XAA is quite speedy. It probably comes down the communication required by X's design. The seperate window manager process (IMHO, a dumb idea, a dynamically loaded window manager module would have sufficed) needs to communicate heavily with X whenever the user manipulates windows.
Good for you. However, on my lowly machine (300MHz) everything takes too damn long to compile. If I just want to get a utility or something to do something quick, no way in hell am I going to wait 10 minutes for the damn thing to compile. Also, compiling KDE or GNOME on a slow machine is quite a challenge. You have to compile each component (kde-libs, kde-base) seperately, so you have to go to the trouble of writing a shell script to do it.
Also, whenever a thread unblocks on I/O, it gets a priority boost so it can run again, quickly issue another I/O, and go back to sleep. The boost varies depending on the thing that it unblocked from, such as audio or input. Input tends to get large boosts, which is one reason why Windows tends to be "Snappier" than Linux.
it really creates a bad perception in the user's mind about the speed of KDE
>>>>>>>>
No, I believe it is the ass-slow redraw and glacial startup times that do that.
PS> I use KDE myself, so don't accuse me of being a GNOME-bigot!
So, first, does "fully-preemtive" traditionally mean with or without locks? Are Solaris, NT, and RTOS preemtible when locks are held?
>>>>>
I don't know about those, but BeOS isn't preemptible during a spinlock either. BeOS requires you to disable local interrupts before acquiring a spinlock, which means that the scheduler never even gets to run on that CPU because it won't take the timer interrupt. I'd surmise that almost all preemptible kernels work like this. Judging from this doc it would appear QNX does it this way as well. This method shouldn't effect latency, because you are only supposed to hold a spinlock for a very short time.
Slashdot Mirror
So, let's talk about your third-party apps. You say that the API for transparency is in W2K. Do you seriously think that that degrades the performance of W2K? No, of course not! USING it does.
>>>>
Except that it doesn't. Transparency in Windows is a hell of a lot smoother than transparency in GNOME, and GNOME transparency isn't even REAL transparency.
Does this make Linux desktops (using eterm or gnome-terminal) more "bloated" or "slower" than Windows? No, it's just that the feature set is different by default. That's been my point all along.
>>>>>>>
Yes. GNOME is slower than Windows both with the cool features on and the cool features off. Except for resizing (which transparency kills of course) Windows WITH the features is faster than GNOME WITHOUT the features.
Actually, the best benchmark is real usage. Try just opening up a bunch of desktop apps and manipulating them. Cell highlighting in KSpread, for example, is jerky while it is butter-smooth in excel. I have yet to see a X widget set that draws as fast as the Windows default one. Windows apps (especially on XP) start faster than comparable KDE or GNOME apps. In Windows, my mouse never hiccups, while it does so regularly in Linux. This usage tests are quite apples to apples. I'm trying to do the same types of things with similar apps. Both systems are tweeked because I use them on a regular basis.
There is no doubt that Linux is faster, more stable, and more memory efficient that Windows. But if the software base built on it (including GNOME and KDE) suck in terms of performance, can anyone say that Linux the platform is faster than Windows the platform?
No.
>>>>
Debatable.
Its not all vector based, there are plenty of bitmaps flying around.
>>>>>>
True, but those bitmaps are objects too, and have to be stored in memory anyway. There is no point in storing the bitmaps again in the backing store.
A backing store is "the right way" to do it. The perpixel backing store is what allows all the funky blending operations like shadows & transparency.
>>>>>>>>
First, shadows and transparency are stupid features to begin with. The nifty advantage of the backing store isn't shadows, but the fact that the OS can repaint part of a window when it is exposed. Using the scene graph to rerender the window would take much less memory and (assuming a good hardware implementation) be just as fast. If you really wanted shadows, you could always render the window to a bitmap and alpha-blend that, it wouldn't be appreciably slower.
No, Windows cannot to pixmap themes and transparency. Sure, there are third-party apps for that, but that's not the point.
>>>>>>>>
But it can! Are you telling me that those programs don't really exist? What's this third party bullshit? Like GNOME or KDE aren't third party programs on top of X? Plus, if you'd bothered to read the opacity website, the API for transparency is built into Windows 2000. Its just that its a totally useless feature that doesn't warrent a utility coming with the OS. As for pixmap themes, some level of theming support has to be built into the widget API, or else Window Blinds wouldn't be able to override the default look. For a while, Win95 had the feature to be able to look like Win 3.x, so the look isn't as hard-coded as you'd like to believe. Besides, that's a moot point anyway. XP officially has theming support and a visual styles API.
I just find it terribly frustrating that I am forced to buy the latest and greatest version of Caligari's TrueSpace, simply to be able to create some, nifty to me, 3D rendered objects.
>>>>>>>
Blame Caligari. It had no business basing a 3D moderling in DX. The state of D3D at the time the early versions of TrueSpace came out was not at the level necessary for a 3D modeler. D3D has changed entirely, and its hard to expect D3D to maintain compatibility with an app that is pushing the API to its limits anway. (I wouldn't be suprised if the early versions for TrueSpace are full of D3D workarounds.)
And the benefits of a platform-independent binary format would be *huge*.
>>>>>>
Uh, no. Last time I checked, almost all Linux software distros release binaries for each supported arch. Besides, everyone (statistically) uses x86, so who cares?
I care about speed, Windows wins. I have yet to see a widget set on X that matches the performance of Win32 in terms of redraw speed. Hell, even Qt on Windows is faster than Qt on Linux.
I care about unification, Windows wins.
>>>>>>>
I like GIMP, and I like KDevelop. I don't have infinite RAM and I like my apps to look the same. What do I do?
I care about predictability, Windows wins.
>>>>>>>
The other day, I installed AbiWord, and it didnt' like the fact that I'd removed its crappy Type1 fonts from my path. Why? Why is the app so damn bound to its fonts? I tried to install the mandrake kernel source RPM the other day, to find that it needed GCC 2.96. GCC 3.0.1 (which I have installed, in RPM form no less) works fine for the kernel, why is it so attached to its obsolete RPM? There are just too many factors in Linux that can fuck up. In theory, Linux is quite elegant and powerful, but in practice, its really not. Not as a GUI machine anyway.
I care about stability, Windows wins:
Its true. KDE-2 has crashed more often on me than Windows 2000. Of course, you'll tell me to go use Window Maker, then I'll ask where my unified GUI is, and you'll then tell me to use KDE-2.
I care about audio, Windows wins:
The Linux audio system is probably the most f*cked up thing ever. aRts on top of OSS/ALSA? WTF? Aren't software mixers archaic relics of the early 1990's? And why is aRts nifty media framework tied to a dumb software mixer? I wnat to use my SBLive! fully! ALSA is quite powerful, and quite speedy. Build a media framework on that instead.
Of course, Linux has tons of strong points. The kernel whips Windows to all hell. The VM system is (finally, thanks AA) much better, the filesystems are faster, and everything is just smoother. With the preempt and lowlat patches, BeOS finally loses the audio-latency performance crown for a general purpose OS (as long as you don't use aRtsd or esound!) urpmi is nifty (when it works). Konqourer is really a step forward. Auroura boot is just plain cool. I use Linux on a daily basis these days, but I don't enjoy it as much as I should. XFce and GNOME are decently fast, but lacking in features I enjoyed in Windows. I can use XMMS/ALSA and get good sound, but I have to live without the media framework I had in BeOS. It certainly gets the job done, but it has so much more potential its disgusting. Everything is already there. If only someone non-braindead came along to organize it all...
Nope. Can't do pixmap themes (that is, themes where all of the widgets, title-bars, etc have pixmaps, not just flat colors or gradients).
>>>>>
Nope, sorry. Try Window Blinds
Can't do windows with transparent backgrounds.
>>>>>
Wrong again. transparency too. Plus, this is even better than GNOME's transparency. Performance is great. Moving is instananeous, and resizing is only a little worse than KDE-2's without transparency. Plus, you can make any window transparent, play a video, and then put the transparent window over it. The video will by alpha-blended with the window in real time, without ANY flickering or jerking. I tried it with the opacity program web page, and the logo overlaid perfectly over a CNN newfeed. Last I heard, X won't allow *real* transparent windows, where the window underneath can update and the updates will show through. Oh, and all this is on a lowly PII-300 with 256MB of RAM.
Can't do much of the customization that you can do with Gnome.
>>>>>>
Like?
MS has just failed to put in the features that I'm suggesting low-end users turn off.
>>>>>
So, these features are just in my mind? I'm imagining real transparency because its so late at night?
Sorry about that. I meant that it doesn't have to be native to the windowing system. Windows 2000's GUI runs in the kernel, but it supports remote GUI just fine. Network transparency isn't why X is a seperate process, saftey is. X runs in a different address space so it can't crash the kernel.
The image buffering thing is really unsettling. Given that Quartz is an inherently vector-based system, wouldn't it make much more sense to store the vector representation of the window, rather than the image contents? The memory requirements for this would be much more nominal.
Oh, and another thing. (feeble attempt to get back on topic) My iBook and my friend's PBG4 feel just about the same under OS 10.1 with 384 MB of RAM each. Both very, very usable.
>>>>
You do realize how incredibly pathetic it is that you've got a fast G3 processor and gobs of RAM, yet your OS is only "very, very usable."
Yes, trolling, I know. But only for my crusade against bloated system software...
First, XFree86 isn't designed with fast communications channels in mind, and thus doesn't benifet much from shared memory channels. Second, I wasn't talking about putting X11 in the kernel or anything like that. I was saying that the window manager, instead of being a seperate process, could by a dynamic library. The real reason the WM (like Blackbox or whatever) is seperate is for flexibility. Back when X was designed, dynamically loaded libraries didn't exist, so the WM was put into another program. Now that we have dynamic libraries, you could load the WM as a X server module and get the benifets of flexibilty AND speed. This would speed up stuff like moving windows which are slow in X because of the communication required between the WM and the X server.
Yahoo. You don't need a client-server architecture achieve remote usage. There's a program on Windows called Citrix ICA. It allows you to run programs remotely. On a T1, Excel runs only a little slower than running KSpread does locally! The real reason X runs as a seperate process isn't network transparency, but protection. The GUI needs to protected place where it can maintain data about the windowing system. On Windows, this windowing code is put in the kernel. Here, user apps can't crash it, but it can crash the kernel. The only other safe place is a seperate process. In theory, one could put the windowing system into a library, so all UI calls would be simple function calls, but on most chips, there is no way to protect library data structures from the user process. The old x86 segmentation mechanism used to be able to check a memory access based on the privelege level of the segment holding the calling code. If something like this could be done for pages (only the GUI's code pages would have the right to access GUI data), then we could get rid of this whole windowing process crap altogether. But, I digress. That wasn't my point in the first place. I was saying that you could put the window manage in a library and dynamically load it into the X server. The X sever doesn't need to be protected from the window manager, and putting it in a library would offer most of the flexibility of putting it in a seperate process. This would speed up a lot of the window/manipulation operations that are so slow in X today.
Most of this is just the routine memory-conservation that any desktop can benefit from. Gnome gives you a WHOLE LOT of rope, because some users WANT to take advantage of 512MB of RAM to load background pixmaps, pixmap-heavy themes and 6 huge apps!
>>>>>>
The funny thing is, I can do all this stuff in Windows *without* killing performanc. Even on my relatively old computer. GNOME is nice (and so is KDE) but performance isn't a strong suit.
Being technically superior to Windows wasn't enough for Java, and it won't be enough for the Linux desktop.
>>>>>
The Linux desktop hasn't even gotten to the "technically superior" phase yet. I use it everyday, but Windows has a really big edge in the technical superiority department.
Who cares? Linux programs are open source, and so the only thing you'd gain from a VM is negative speed.
You're perfectly right about breaking binary compatibility due to source changes. I was talking about binary compatibility between GCC releases (C++ libraries in GCC break every new release). As for virtual methods, they don't totally solve the problem, but don't incur a speed hit either. The virtual method type thing you're referring to is what COM does. You can't easily subclass such an object, and most C++ libraries depend heavily on that capability. Second, virtual C++ calls are no slower than C library calls. In C, all library calls refer to a table of function offsets. The call first jumps to that table, which then jumps to the actual function. (Or it reads the address of the function from the table, it depends on the implementation.) This is done so that you can map libraries into different places in the process address space (say one day at 0x600 then the next at 0x1200) and you only have to change the values in the table rather than all the function calls in the code. With C++ virtual function calls, the process is similar (in Visual C++'s compiler anyway). When the library is dynamically linked to the program, the vtables of each class are written with the addresses of the functions that implement each method. Thus, the call is a single-indirect calls, just like a C library call.
Qt 1.x and Qt 2.x installed already
>>>>>>>>
Great, now you'll have Qt 1.x, 2.x, AND 3.x.
UNIX is about power, elegance, and simplicity. Somewhere along the line, elegance and simplicity got lost in features and bloat.
You can't really blame some DirectX programs for breaking. DirectX has evolved so much, that there are basically 3 different DirectXs, pre-5.x, 5.x-6.x, and 7.x-9.x. Even within catagories (such as 7.x-9.x), some things have been totally overhauled. Then, you add the fact that DirectX most DirectX games were originally designed for Windows 95, but most still run on the totally different Windows 2000. At that point, its a miracle that MS has been able to keep DirectX as backwards compatbile as it is. Certainly nothing in the Linux world compares to it.
have the GCC people thought of any ways to make binary compatibility easier to maintain in C++ programs without requiring vtable hacks and other ugliness?
>>>>>>>>>
Hopefully, C++ binary incompatibility should be passe. There is a standard C++ ABI for Itanium, and GCC 3.0's C++ ABI should be standard for x86. I don't know if other compiler vendors will follow suit (one hopes, but doubts), but the GCC people shouldn't change it.
Qt isn't the problem. On Windows, even widget-heavy Qt apps redrawing smoothly. I have absolutely now idea why redraw performance on Linux is so bad. Its probably not XFree86's rendering core, since I hear XAA is quite speedy. It probably comes down the communication required by X's design. The seperate window manager process (IMHO, a dumb idea, a dynamically loaded window manager module would have sufficed) needs to communicate heavily with X whenever the user manipulates windows.
Good for you. However, on my lowly machine (300MHz) everything takes too damn long to compile. If I just want to get a utility or something to do something quick, no way in hell am I going to wait 10 minutes for the damn thing to compile. Also, compiling KDE or GNOME on a slow machine is quite a challenge. You have to compile each component (kde-libs, kde-base) seperately, so you have to go to the trouble of writing a shell script to do it.
Also, whenever a thread unblocks on I/O, it gets a priority boost so it can run again, quickly issue another I/O, and go back to sleep. The boost varies depending on the thing that it unblocked from, such as audio or input. Input tends to get large boosts, which is one reason why Windows tends to be "Snappier" than Linux.
it really creates a bad perception in the user's mind about the speed of KDE
>>>>>>>>
No, I believe it is the ass-slow redraw and glacial startup times that do that.
PS> I use KDE myself, so don't accuse me of being a GNOME-bigot!
So, first, does "fully-preemtive" traditionally mean with or without locks? Are Solaris, NT, and RTOS preemtible when locks are held?
>>>>>
I don't know about those, but BeOS isn't preemptible during a spinlock either. BeOS requires you to disable local interrupts before acquiring a spinlock, which means that the scheduler never even gets to run on that CPU because it won't take the timer interrupt. I'd surmise that almost all preemptible kernels work like this. Judging from this doc it would appear QNX does it this way as well. This method shouldn't effect latency, because you are only supposed to hold a spinlock for a very short time.
True, also, you can always chicken out and use big global locks if you need something quick.