WTF are you talking about. I AM talking about WindowsNT. Right now I'm running NT4, I don't even have Win9x installed. And it takes only one reboot on NT. As for setting up a Linux box, I've set up a RedHat, a Mandrake, and a Slackware (my distro of choice) on my system. I've configured both Linux and NT into a functional desktop OS (meaning I installed NVIDIA graphics drivers, ALSA drivers on Linux, and installed both GNOME and KDE.) I can tell you right now, NT4 was set up in hours rather than the three days Linux took me. (And I'm not a Linux newbie, I've still got Slackware 3.5 CDs.)
I'm talking FUNCTIONAL distribution. The Linux kernel is a work of art, and that is more or less what that 1.44 MB distro is. The core part of BeOS (which includes all the servers, the windowing system, tracker, etc) is about 16.5 megs (700K kernel, 3.5 megs servers, 2 megs tracker, 10 megs for libraries, everything from OpenGL to C++ and C libraries) If you can find a functional Linux distro that has the GUI, a desktop environment, runs any available Linux app, and fits in 17MB, I'd like to see it. As for my comment about bloat, it's true. My system, Slackware 7.1 with GNOME 1.2 and KDE 2 Beta3 takes up more memory at startup than WindowsNT 4.0
Why? BeOS is an orphaned product. Be has shifted focus to the Internet Appliance space. BeOS is
just for diehard be fans.
>>>>>>>>>>>
BeOS is NOT an orphaned product. Let's see, you've got the upcoming network environment, the new accelerated OpenGL implementation, Opera 4.0, and Java2. Oh yea, Be has TOTALLY abandoned BeOS. (And none of this is vaporware, OpenGL and the networking environment (BONE) are deep in beta, and JavaSE is already running on BeIA.) Also, the shift is designed so any improvements to BeIA can be quickly rolled into BeOS. Seeing as Be has just made some deals with companies like Compaq, I'm thinking they are far from dead.
What should happen is we should take the good parts, and not so much source but the ideas, of BeOS and the Be API and incorporate them in the toolkit(s) for X and the kernel.
>>>>>>
Oh yea, add yet another toolkit to X and make it even MORE bloated!
The only big advantage BeOS had over Linux IMHO was the fact that it came with a journalling FS out of the box.
>>>>>
Sure that's the only advantage. The 3 millisecond latencies (BTW that's not hype. Read the BeNews article about the hardware company that shifted from using a proprietary OS to BeOS for their mixing hardware) great handling of video, easy API, and fast GUI are no big thing. Not the mention the utter "zen" of the user-interface. When I see something as cool as Cortex on another OS I'll be impressed.
These days all my servers run off of ReiserFS.
>>>>>>>>
ReiserFS STILL doesn't have database capabilities (it's planned.) BFS has had database capabilities for years.
I just downloaded the CVS tree from SGI XFS server, going to give it a spin on a spare box next week. Now if someone would produce a pervasively multithreading toolkit for X I'd be all set.
>>>>>>>
Great, yet another X toolkit! Really, do you think some new APIs and another toolkit are going to defeat the 20 million lines of code and 30 years of UNIX baggage (not all of it bad, though) that make up the average Linux system. Face it, Linux may be a great system, but in terms of sheer speed, it still doesn't compare to BeOS. I don't use BeOS because I'm a fanatic. I have both Windows and Linux (Slackware 7.1, a man's distro) on my system. I don't use BeOS just for the hell of it, I find myself being more productive in it. I like the API, the user interface, and find the applications on the platform to be very original, if a little lacking in features. I like the tight integration between the CLI and the GUI. I like the fact that the workflow is so fast, and that apps are so easy to install. For example, I just downloaded Jikes for BeOS. The installed automatically configured BeIDE for it, and all I had to do to uninstall it was delte the folder.
So fine, critize BeOS for what it lacks. I'm totally okay with that, in fact I'll point some stuff out for you right now.
A) It doesn't expose hardware acceleration comparable to what DirectX does.
B) It doesn't have as nice of a joystick API as DirectInput.
C) I lacks a decent web-browser.
D) Replicants are weak compared to systems like OLE or OpenDOC.
E) It lacks an object model.
F) Navigating multiple browser windows is awkward.
Complain all you want about valid problems. However, don't belittle it by saying that Linux is just a toolkit and an API away from bettering it.
Re:KDE/GNOME war hurts developers...
on
KDE Strikes Back
·
· Score: 2
Actually, KParts isn't the object model. It is the embedding system. Think of it has the OLE of the KDE world. KPart's object model is DCOP, which is KDE's COM, and is the component you should be comparing with CORBA. Your mentaility, that desktop application servers will become big so leave the option open, is exactly what leads to UNIX becoming the increasing overweight system it is. Does no-one have any concept of specialized, lightweigth systems anymore? There is no proof that desktop application servers will become big. There isn't even an indication that mainframe computing (which is essentially what an application server is) will become big. Even if they do, shoehorning an existing technology into that paradim would be suboptimal. Do you seriously think that objects that are designed at the core to be run on the local machine are going to fare well when run remotely? (Actually, DCOP can be run remotely as well, it's just that CORBA has more features to do it.)
As for DCOP it is far from a quick-and dirty hack. It is just a wrapper over the standard X11 ICE library, which is quite mature.
I don't support either side that much. (In fact, I think GNOME Foundation is a good thing.) My point is that in the last two days, I've noticed several comments about how GNOME is going to dominate the Linux desktop and how KDE should be running scared. After the IBM thing, several GNOME people have decided to rub KDE people's noses in it. This is a big change from the past when GNOME was billed as bringing more freedom, and everyone talked about cooexisting and all.
Re:KDE/GNOME war hurts developers...
on
KDE Strikes Back
·
· Score: 2
I base it on praticality. What are the odds that you'll be using a CORBA component on a remote server running HP-UX? Seriously? Read up on KDE's stance on the issue. The think that CORBA is very cool technology, but not suitable for desktop components. (BTW KDE offers CORBA too, it just doesn't use it for desktop components.) 99% of people want to embed a spread sheet into their document, not embed a remote-spread sheet running on a computer 50 miles away. Anyway, those specialized applications that DO need to embed something over CORBA have the freedom to do so. What the KDE developers think is that desktop components will almost never need to be embeeded on a remote OS running a different OS. They don't preclude using CORBA to embed something more specialized, but the acknolodege that there is no need for the two to share the same protocol. From a pragmatic standpoint it makes sense. For local desktop components use DCOP that offers high performance for the user. Still, offer CORBA for those specialized components that need it's power. Chances are that the two won't need to interact, so there is no reason for them to use the same system.
Huh? What phsychology? Development for Be does NOT suck that bad. BeOS IS good enough to attract good programmers. What the hell are you talking about? My point is instead of writing yet another GUI toolkit for X, go help fill in the gaps in the BeOS software line.
Did they really pull of REAL alpha-blending ala MacOS X? The transparent terminal thing is possible in everything from Enlightenment to BeOS, but the effect goes away the minute the window below changes. If they pulled it off well, that's great.
Well, my Riva TNT is detected as a Riva128 by that same distro. It doesn't detect my Intellimouse PS/2 correctly. The point is that Windows almost always detects hardware correctly while X doesn't.
The reason it's so slow is because it really wasnt' designed with current desktop configurations in mind
A) It really wasn't built to take good advantage of powerful client machines. XFree86 has really helped in this regard with the XFree4.0, but the architecture is set in stone and there is only so much they can do.
B) It wasn't designed to take good advantage of hardware acceleration. Again, XFree has really helped with the rewrite of XAA, but they can only do so much.
C) There are many protocol limitations. For example, the reason they are having so many problems with anti-aliased text is that X only sees a font as a monochrome bitmap. Also, TrueType fonts are a bit of a hack on X, and general font support is poor. These are things about the protocol that just have to be worked around.
D) It seems that the API is pretty inefficient. As somebody pointed out to me a while ago on/., you really have to do a lot of things in X that shouldn't be necessary. (What I really want to see, though is a windowing system that totally ditches the concept of a palatte. Screw the 256 color users, let them put up with automatic dithering.)
However, the client server model really doesn't seem to be THAT big a problem. It is probably largely due to poor design decesions. For example, the Windows GDI is notoriously slow. It is largely 16 bit code that needs to thunk in every call to it. However, MS managed to get it to a decent speed by rewriting parts of it in ASM and putting it into the kernel. The GDI is actually just a DLL that is loaded by the client application. There isn't a server there. Despite these hacks, the GDI is still slow. (Though not slower than X.) The BeOS API, however, uses messaging and a client server model. Ask anyone, they'll tell you that it's the fastest GUI around.
"X WindowsThe first commercial release of X Windows was X10.4 in 1986, and was the basis for some commercial applications. The next release was X11R1 in 1987, followed by X11R2 in 1988. Version 11 was a complete windowing package that outperformed X10 in its speed, flexibility of features, and styles for multiple screens. X11 and later versions have become the de facto standard GUI for UNIX systems and are, therefore, the focus of this chapter."
Thus, X1-9 were apparently inhouse releases (just like the first several UNIX releases.)
Why does the X consortium produce software that nobody uses? I really don't understand the concept of actually coding a sample implementation that nobody uses. Coding a sample implementation is not that much easier than coding one releasable one. So why do it? Why not just do a little more work on it and release it as a usable product? It would speed stuff up too. Instead of waiting for XFree86 to roll in the changes (which, probably won't happen for several months) a new implementation would be usable when it is released.
Alpha transparency is nothing new. BeOS has it, Enlightenment has it, Windows 2000 has it, MacOS X has it, NeXT had the capability to do it, and all modern 3D graphics cards accelerate it in hardware. FSAA is something totally different. It would be a BAD idea to do full-screen antialiasing on the desktop. That would mean the whole desktop would be a little blurry. That's good in a game since it smooths thing out, but is NOT good for anything else. As for anti-aliased text, I don't know what's holding X back. Everyone and their mother has anti-aliasied text these days. (/. looks great anti-aliased!) As for configuration problems, I think it has to do with the fact that most cards are designed for winows and Windows tends to have more accurate plug and play.
You know, the best thing for X would really be to dicate a bit more policy. The whole concept of X is to provide the low level services that higher level window managers need. Thus, X can provide a common foundation, while window manager provide the actual user-interface. However, this concept has faded in recent times. Now, you have things like GNOME and KDE implementing things that really should be in X. Things like printing services, imaging systems, and object models, that aren't really part of the user-interface, but part of the lower-level "services" layer that X provides. The benifits of integrating more of this into X are obvious. Instead of having the two competing desktop environments that you have now, you would have a common base of X windows applications that would work in any window manager. In the process, there really isn't any freedom lost. Are the two desktop environments really that different? Aside from the look (which belongs in the window manager anyway) the two environements pretty much provide the same services in more or less the same way. Sure you know have one object model, one imaging system, etc. Of course, you only have one graphics system for X, you only have one X input API. You can't choose the input subsystem for X, so why should you be able to choose the object model? For that matter, why should you care? At some layer of the system, you have to standardize something or all hell breaks loose. SOMEBODY has to dictate policy or else you end up with a sysem THAT HAS NO POLICY. In return for a little freedom for the developer, think of what you gain. The user gains the choice to use what desktop environment they want. Developer gain the freedom to not have to worry if they are cutting of people by using the wrong DE. Commercial vendors gain the freedom to write applications to a desktop environment instead of just statically linking Motif.
How's the speed of this release? On my 300MHz machine, KDE 1.92 is pretty poky. Especially Konqueror which takes a second or two to start up. It's shouldn't be because it is a debug build because I compiled the sources myself, and stripped everything. In fact, all the KDE apps seem to have a built in delay. Everything from Kontrol Center (several seconds) to simple applets (a second or so) take a long time to start up.
Read my other post. On UNIX, there are a lot of ways to get things done, but they're all compatible. All window managers (generally) are compatible with each other. You can pipe information from yacc to any type of awk you choose. You can use any compiler you want on ANSI C code. That's not true with GNOME and KDE. It's not you who is doing the choosing, it's the application developer.
However, FreeBSD and Linux are more or less source compatible. GNOME and KDE are not. If several OSs are source compatible, then they survive because software written for one is quickly ported to the other. However, if they are not source compatible, one or the other dies. Think about it. Would anybody use FreeBSD if it wasn't UNIX compatible? Not that many people develop for FreeBSD in particular. If it didn't have UNIX compatiblity, it wouldn't get any apps. Sure it would still have it's own merits, but the total lack of software would kill it. That's the way it is with GNOME and KDE. You can't write an application that works on both (unless you don't take any advantage of the DEs and write a straight X application.) Thus, developers will undoubtedly choose one, and one will undoubtedly win. Due to the nature of Open Source, the other won't die, but will become very marginalized. Take GNUStep. Sure it's not dead, but is it really ALIVE? Also, I find your concept of "freedom of choice" increadibly self-serving. Two incompatible APIs are only freedom of choice for the developer, not the user. Back when there were only window managers, there WAS freedom of choice. Developers generally had to program to the X API (either directly or through toolkits) and all applications worked on all window managers. A person could choose any window manager they wanted, and still be guarenteed that they could run all the applications. Now, you've got to choose one. Either GNOME or KDE. (Or you could use both, but considering their sheer size, that's a bad proposition as well.) Now, it's the developers who choose what environment YOU run. Now, if you want to run KDevelop, your stuck with KDE. (Even if it is inside GNOME, it is still a KDE application. It looks and acts like one, and integrates best with other KDE apps.) If you want GNapster, your going to have to have GNOME. That's not freedom for the masses, that's freedom for developers. Whether it is Microsoft, KDE, GNOME, there is somebody deciding what your going to use.
Re:KDE/GNOME war hurts developers...
on
KDE Strikes Back
·
· Score: 2
Bonobo is way to fat for a DE. The statement on the KDE technology page sums it up pretty well. You can find it here.
Slashdot Mirror
I was talking about the Windows95 GDI.
WTF are you talking about. I AM talking about WindowsNT. Right now I'm running NT4, I don't even have Win9x installed. And it takes only one reboot on NT. As for setting up a Linux box, I've set up a RedHat, a Mandrake, and a Slackware (my distro of choice) on my system. I've configured both Linux and NT into a functional desktop OS (meaning I installed NVIDIA graphics drivers, ALSA drivers on Linux, and installed both GNOME and KDE.) I can tell you right now, NT4 was set up in hours rather than the three days Linux took me. (And I'm not a Linux newbie, I've still got Slackware 3.5 CDs.)
I'm talking FUNCTIONAL distribution. The Linux kernel is a work of art, and that is more or less what that 1.44 MB distro is. The core part of BeOS (which includes all the servers, the windowing system, tracker, etc) is about 16.5 megs (700K kernel, 3.5 megs servers, 2 megs tracker, 10 megs for libraries, everything from OpenGL to C++ and C libraries) If you can find a functional Linux distro that has the GUI, a desktop environment, runs any available Linux app, and fits in 17MB, I'd like to see it. As for my comment about bloat, it's true. My system, Slackware 7.1 with GNOME 1.2 and KDE 2 Beta3 takes up more memory at startup than WindowsNT 4.0
Why? BeOS is an orphaned product. Be has shifted focus to the Internet Appliance space. BeOS is
just for diehard be fans.
>>>>>>>>>>>
BeOS is NOT an orphaned product. Let's see, you've got the upcoming network environment, the new accelerated OpenGL implementation, Opera 4.0, and Java2. Oh yea, Be has TOTALLY abandoned BeOS. (And none of this is vaporware, OpenGL and the networking environment (BONE) are deep in beta, and JavaSE is already running on BeIA.) Also, the shift is designed so any improvements to BeIA can be quickly rolled into BeOS. Seeing as Be has just made some deals with companies like Compaq, I'm thinking they are far from dead.
What should happen is we should take the good parts, and not so much source but the ideas, of BeOS and the Be API and incorporate them in the toolkit(s) for X and the kernel.
>>>>>>
Oh yea, add yet another toolkit to X and make it even MORE bloated!
The only big advantage BeOS had over Linux IMHO was the fact that it came with a journalling FS out of the box.
>>>>>
Sure that's the only advantage. The 3 millisecond latencies (BTW that's not hype. Read the BeNews article about the hardware company that shifted from using a proprietary OS to BeOS for their mixing hardware) great handling of video, easy API, and fast GUI are no big thing. Not the mention the utter "zen" of the user-interface. When I see something as cool as Cortex on another OS I'll be impressed.
These days all my servers run off of ReiserFS.
>>>>>>>>
ReiserFS STILL doesn't have database capabilities (it's planned.) BFS has had database capabilities for years.
I just downloaded the CVS tree from SGI XFS server, going to give it a spin on a spare box next week. Now if someone would produce a pervasively multithreading toolkit for X I'd be all set.
>>>>>>>
Great, yet another X toolkit! Really, do you think some new APIs and another toolkit are going to defeat the 20 million lines of code and 30 years of UNIX baggage (not all of it bad, though) that make up the average Linux system. Face it, Linux may be a great system, but in terms of sheer speed, it still doesn't compare to BeOS. I don't use BeOS because I'm a fanatic. I have both Windows and Linux (Slackware 7.1, a man's distro) on my system. I don't use BeOS just for the hell of it, I find myself being more productive in it. I like the API, the user interface, and find the applications on the platform to be very original, if a little lacking in features. I like the tight integration between the CLI and the GUI. I like the fact that the workflow is so fast, and that apps are so easy to install. For example, I just downloaded Jikes for BeOS. The installed automatically configured BeIDE for it, and all I had to do to uninstall it was delte the folder.
So fine, critize BeOS for what it lacks. I'm totally okay with that, in fact I'll point some stuff out for you right now.
A) It doesn't expose hardware acceleration comparable to what DirectX does.
B) It doesn't have as nice of a joystick API as DirectInput.
C) I lacks a decent web-browser.
D) Replicants are weak compared to systems like OLE or OpenDOC.
E) It lacks an object model.
F) Navigating multiple browser windows is awkward.
Complain all you want about valid problems. However, don't belittle it by saying that Linux is just a toolkit and an API away from bettering it.
Actually, KParts isn't the object model. It is the embedding system. Think of it has the OLE of the KDE world. KPart's object model is DCOP, which is KDE's COM, and is the component you should be comparing with CORBA. Your mentaility, that desktop application servers will become big so leave the option open, is exactly what leads to UNIX becoming the increasing overweight system it is. Does no-one have any concept of specialized, lightweigth systems anymore? There is no proof that desktop application servers will become big. There isn't even an indication that mainframe computing (which is essentially what an application server is) will become big. Even if they do, shoehorning an existing technology into that paradim would be suboptimal. Do you seriously think that objects that are designed at the core to be run on the local machine are going to fare well when run remotely? (Actually, DCOP can be run remotely as well, it's just that CORBA has more features to do it.)
As for DCOP it is far from a quick-and dirty hack. It is just a wrapper over the standard X11 ICE library, which is quite mature.
I don't support either side that much. (In fact, I think GNOME Foundation is a good thing.) My point is that in the last two days, I've noticed several comments about how GNOME is going to dominate the Linux desktop and how KDE should be running scared. After the IBM thing, several GNOME people have decided to rub KDE people's noses in it. This is a big change from the past when GNOME was billed as bringing more freedom, and everyone talked about cooexisting and all.
I base it on praticality. What are the odds that you'll be using a CORBA component on a remote server running HP-UX? Seriously? Read up on KDE's stance on the issue. The think that CORBA is very cool technology, but not suitable for desktop components. (BTW KDE offers CORBA too, it just doesn't use it for desktop components.) 99% of people want to embed a spread sheet into their document, not embed a remote-spread sheet running on a computer 50 miles away. Anyway, those specialized applications that DO need to embed something over CORBA have the freedom to do so. What the KDE developers think is that desktop components will almost never need to be embeeded on a remote OS running a different OS. They don't preclude using CORBA to embed something more specialized, but the acknolodege that there is no need for the two to share the same protocol. From a pragmatic standpoint it makes sense. For local desktop components use DCOP that offers high performance for the user. Still, offer CORBA for those specialized components that need it's power. Chances are that the two won't need to interact, so there is no reason for them to use the same system.
Linux: The OTHER OS that's bloated as Windows.
Huh? What phsychology? Development for Be does NOT suck that bad. BeOS IS good enough to attract good programmers. What the hell are you talking about? My point is instead of writing yet another GUI toolkit for X, go help fill in the gaps in the BeOS software line.
Still supressing them memory of GNOME 1.0?
Did they really pull of REAL alpha-blending ala MacOS X? The transparent terminal thing is possible in everything from Enlightenment to BeOS, but the effect goes away the minute the window below changes. If they pulled it off well, that's great.
Well, my Riva TNT is detected as a Riva128 by that same distro. It doesn't detect my Intellimouse PS/2 correctly. The point is that Windows almost always detects hardware correctly while X doesn't.
The reason it's so slow is because it really wasnt' designed with current desktop configurations in mind
/., you really have to do a lot of things in X that shouldn't be necessary. (What I really want to see, though is a windowing system that totally ditches the concept of a palatte. Screw the 256 color users, let them put up with automatic dithering.)
A) It really wasn't built to take good advantage of powerful client machines. XFree86 has really helped in this regard with the XFree4.0, but the architecture is set in stone and there is only so much they can do.
B) It wasn't designed to take good advantage of hardware acceleration. Again, XFree has really helped with the rewrite of XAA, but they can only do so much.
C) There are many protocol limitations. For example, the reason they are having so many problems with anti-aliased text is that X only sees a font as a monochrome bitmap. Also, TrueType fonts are a bit of a hack on X, and general font support is poor. These are things about the protocol that just have to be worked around.
D) It seems that the API is pretty inefficient. As somebody pointed out to me a while ago on
However, the client server model really doesn't seem to be THAT big a problem. It is probably largely due to poor design decesions. For example, the Windows GDI is notoriously slow. It is largely 16 bit code that needs to thunk in every call to it. However, MS managed to get it to a decent speed by rewriting parts of it in ASM and putting it into the kernel. The GDI is actually just a DLL that is loaded by the client application. There isn't a server there. Despite these hacks, the GDI is still slow. (Though not slower than X.) The BeOS API, however, uses messaging and a client server model. Ask anyone, they'll tell you that it's the fastest GUI around.
From UNIX Unleashed...
"X WindowsThe first commercial release of X Windows was X10.4 in 1986, and was the basis for some commercial applications. The next release was X11R1 in 1987, followed by X11R2 in 1988. Version 11 was a complete windowing package that outperformed X10 in its speed, flexibility of features, and styles for multiple screens. X11 and later versions have become the de facto standard GUI for UNIX systems and are, therefore, the focus of this chapter."
Thus, X1-9 were apparently inhouse releases (just like the first several UNIX releases.)
Why does the X consortium produce software that nobody uses? I really don't understand the concept of actually coding a sample implementation that nobody uses. Coding a sample implementation is not that much easier than coding one releasable one. So why do it? Why not just do a little more work on it and release it as a usable product? It would speed stuff up too. Instead of waiting for XFree86 to roll in the changes (which, probably won't happen for several months) a new implementation would be usable when it is released.
Actually it's X11R6.4 (what XFree86 uses.)
Alpha transparency is nothing new. BeOS has it, Enlightenment has it, Windows 2000 has it, MacOS X has it, NeXT had the capability to do it, and all modern 3D graphics cards accelerate it in hardware. FSAA is something totally different. It would be a BAD idea to do full-screen antialiasing on the desktop. That would mean the whole desktop would be a little blurry. That's good in a game since it smooths thing out, but is NOT good for anything else. As for anti-aliased text, I don't know what's holding X back. Everyone and their mother has anti-aliasied text these days. (/. looks great anti-aliased!) As for configuration problems, I think it has to do with the fact that most cards are designed for winows and Windows tends to have more accurate plug and play.
You know, the best thing for X would really be to dicate a bit more policy. The whole concept of X is to provide the low level services that higher level window managers need. Thus, X can provide a common foundation, while window manager provide the actual user-interface. However, this concept has faded in recent times. Now, you have things like GNOME and KDE implementing things that really should be in X. Things like printing services, imaging systems, and object models, that aren't really part of the user-interface, but part of the lower-level "services" layer that X provides. The benifits of integrating more of this into X are obvious. Instead of having the two competing desktop environments that you have now, you would have a common base of X windows applications that would work in any window manager. In the process, there really isn't any freedom lost. Are the two desktop environments really that different? Aside from the look (which belongs in the window manager anyway) the two environements pretty much provide the same services in more or less the same way. Sure you know have one object model, one imaging system, etc. Of course, you only have one graphics system for X, you only have one X input API. You can't choose the input subsystem for X, so why should you be able to choose the object model? For that matter, why should you care? At some layer of the system, you have to standardize something or all hell breaks loose. SOMEBODY has to dictate policy or else you end up with a sysem THAT HAS NO POLICY. In return for a little freedom for the developer, think of what you gain. The user gains the choice to use what desktop environment they want. Developer gain the freedom to not have to worry if they are cutting of people by using the wrong DE. Commercial vendors gain the freedom to write applications to a desktop environment instead of just statically linking Motif.
I don't really understand the way X is released. Is the thing the X group releases a sample implementation or what? Is is actually a usable product?
Actually, these days local stuff is done through sockets. And X uses shared memory as well.
How's the speed of this release? On my 300MHz machine, KDE 1.92 is pretty poky. Especially Konqueror which takes a second or two to start up. It's shouldn't be because it is a debug build because I compiled the sources myself, and stripped everything. In fact, all the KDE apps seem to have a built in delay. Everything from Kontrol Center (several seconds) to simple applets (a second or so) take a long time to start up.
Why does everyone always neglect Slackware packages? As of yesterday, there STILL aren't any Slackware packages for 1.92, much less 1.93.
Read my other post. On UNIX, there are a lot of ways to get things done, but they're all compatible. All window managers (generally) are compatible with each other. You can pipe information from yacc to any type of awk you choose. You can use any compiler you want on ANSI C code. That's not true with GNOME and KDE. It's not you who is doing the choosing, it's the application developer.
However, FreeBSD and Linux are more or less source compatible. GNOME and KDE are not. If several OSs are source compatible, then they survive because software written for one is quickly ported to the other. However, if they are not source compatible, one or the other dies. Think about it. Would anybody use FreeBSD if it wasn't UNIX compatible? Not that many people develop for FreeBSD in particular. If it didn't have UNIX compatiblity, it wouldn't get any apps. Sure it would still have it's own merits, but the total lack of software would kill it. That's the way it is with GNOME and KDE. You can't write an application that works on both (unless you don't take any advantage of the DEs and write a straight X application.) Thus, developers will undoubtedly choose one, and one will undoubtedly win. Due to the nature of Open Source, the other won't die, but will become very marginalized. Take GNUStep. Sure it's not dead, but is it really ALIVE? Also, I find your concept of "freedom of choice" increadibly self-serving. Two incompatible APIs are only freedom of choice for the developer, not the user. Back when there were only window managers, there WAS freedom of choice. Developers generally had to program to the X API (either directly or through toolkits) and all applications worked on all window managers. A person could choose any window manager they wanted, and still be guarenteed that they could run all the applications. Now, you've got to choose one. Either GNOME or KDE. (Or you could use both, but considering their sheer size, that's a bad proposition as well.) Now, it's the developers who choose what environment YOU run. Now, if you want to run KDevelop, your stuck with KDE. (Even if it is inside GNOME, it is still a KDE application. It looks and acts like one, and integrates best with other KDE apps.) If you want GNapster, your going to have to have GNOME. That's not freedom for the masses, that's freedom for developers. Whether it is Microsoft, KDE, GNOME, there is somebody deciding what your going to use.
Bonobo is way to fat for a DE. The statement on the KDE technology page sums it up pretty well. You can find it here.