What's needed is less arrogance, and more understanding that Small Is Beautiful (And Bloody Fast).
>>>>>>>>>>>>>>>>
Good god. If only the Linux GUI developers would think the way the networking developers do!
BTW> This was directly inspired by the recent GNOME article...
I've done Be programming, and because of the design, it really isn't hard to keep the interactions straight. Windows probably does have a problem with threads, mainly because of the C style of the API. However, in Be, multi-threading is explicitly done in window threads. Since, the window interface is contained within a set of C++ classes, all one has to remember to do is be aware of thread interactions in any code that you put into the window subclass. Also, most threads are wrapped in Loopers (essentially message loops) so it again comes down to making sure that any code within a particular object is thread-safe. BeOS does have some problems, but instability in the apps is not one of them. (Not more than in any other OS, anyway) As for the OS itself, I can't say if Be has better programmers (though I'd like to think so;) but I think the emphasis on keeping the design extremely simple and clean has a lot to do with the stability of the threading model. BeOS is not a feature-laden OS. It has some well-chosen luxuries that really enhance the user experience, but it doesn't try to make everyone happy.
How about getting Linux's interactive GUI performance to equal Windows? It will never happen, if only because of the disadvantages it would introduce to other types of programs. This back and forth will never lead to anything. I value desktop performance over everything, you value open systems and generalized performance. Ideally, the two stances could be reconciled in one OS, but that isn't the case in the real world, so in the end, I use what I want, and you use what you want.
Last time I checked, about.5% of the population was willing to dump their x86 boxes and switch top MacOS X/PPC (which has serious speed problems btw) just for the desktop. Unless Quartz and Aqua become open source, this isn't even a point worth considering.
How does the new x86 backend generated code perform in relation to previous compilers. I know icl (Intel C compiler) is coming out for Linux, and from the demoes of it I've used on Windows, it looks pretty damn spiff. (Stupid 30 limit...) Compile speed is fast too. If you look at the icl docs, you'll find that the optimizer on this thing is insane, it does all sorts of inter-intra function optimizations and prepiplines code and everything. I have only a vague understanding of what the hell that means, but it sure SOUNDS fast. Anyway, I'll try out the Windows version and see how it performs in relation to gcc. I'll post benchmarks when I get the chance. I'd appreciate it if someone would post Linux benchmarks as well, because as much as I like Windows, I can barely stand not having bash. (Ah... BeOS, where art thou?)
Re:The road to closed PC hardware?
on
nVidia nForce
·
· Score: 1
That is their problem. Perhaps they shouldn't have used licensed code? Food for though, eh?
>>>>>>>>>>
Maybe releasing high quality drivers on time was more important for them than appeasing the 1% of the market that are die hard OSS zealots? Food for thought, eh?
You do realize that drivers are hardware specific, right?
>>>>>>>
Go to www.opengl.org and look up the term ICD. OpenGL ICDs are entire implementations of OpenGL pipelines. Unlike a network driver (for example) the host OS doesn't do anything for the OpenGL subsystem (except give it access to a window) Thus, everything from glVertex3f() down to register banging is done by the ICD. If you've looked at the OpenGL standard, the upper (hardware independant) levels are the hard part. Why do you think Matrox and ATI are having so many problems with their drivers? If ATI had NVIDIA's OpenGL driver, they could easily squeeze another 10-15% out of their hardware. NVIDIA spent a lot of time developing their ICD, why should ATI get it for free?
Re:The road to closed PC hardware?
on
nVidia nForce
·
· Score: 1
Good god, man. Judge a company by what it does, not what it has the *potential* to do. There are so many good things about NVIDIA I don't have the time to iterate them now. NVIDIA got where they are by making good products and having good support. It is a disrespect to them to suggest they're trying to control the world, when they've given no such signs.
As for the driver thing, get your head out of your ass. It's called licensed code. (Plus the fact that they have the best OpenGL implementation available. Why should they write ATI's driver for them?)
Re:Integrated devices... no thanks!
on
nVidia nForce
·
· Score: 2
Actually, for the longest time, everyone has been shipping integrated graphics with AGP slots. HP used to not do that, and they caught hell for it. I doubt you'll find many computers at Best Buy that have integrated graphics and no AGP slot.
One can look at it another way. The majority of developers use Win32! Why can't Linux get with the program?
If you're benchmarking an OS, you use whatever is fastest on the OS. And since most Win2K server programs WILL use whatever is fastest on Win2K, the benchmark can be valid as a real-world test (assuming all other factors are correct, of course!)
>>>>>
For the English-imparied, I'm not advocating that Linux switch to Win32. I'm simply stating that what is "normal" is in the eye of the beholder.
Any programming construct can be harmful. Pointers, explicit memory allocation, anything! However, if interfaces are clearly defined, and and the code is kept simple (ie. lack of feature creep, something that the "new" (GNOME, KDE, etc) UNIX guys don't seem to understand) threading is just as harmless as pointers. I'm not going to get theoretical here, but I'll give you an actual example: BeOS. Say what you will about it being dead or the company being stupid or whatever, it has a kick-ass threading implementation. The app_server regularly runs with 60+ threads and the damn thing only crashes on me when I'm playing with a kernel driver. The apps, too, are stable, even though they are forced into using multi-threading due to the GUI architecture. If you want to see why this is the case, take a look at the BeBook (the API). Every time there is a possible thread interaction, they warn you about it. Just as you have to keep memory ownership clear, you have to do the same thing for threads. Theoretical rules aside, an entire platform begs to differ with you.
Actually, if you look at the PE file format, there are fields for not one but two version fields (library and subsystem) and something resembling a soname. So Windows supports it, its just that Windows developers don't use it.
If there is no other process to run (with a higher priority) of course the kernel will let the current process run its full timeslice. However, any process that needs attention and has a higher priority than the current running one preempts it and gets to run (within 10-20ms).
>>>>>>>
True. However, that requires processes to have a higher priority. However, on a normal system, Linux doesn't automatically manage these priorities. While "goodness" does have some effect, the Linux sheduler doesn't use tricks like the Windows sheduler does to make sure that GUI apps get fast response times. If you look at the case study of Win2K in Tannenbaum's new book, you'll see that Win2K does all sorts of priority mucking to make sure that GUI apps have a higher ability to preempt than other apps. While this might be bad for a server, or a generalized system, it certainly does wonders for GUI response.
"run a good deal faster", and what runs a good deal faster? The BeOS UI is certainly much slower on my box these days, but I suspect that has something to do with the AMD-challenged optimizations in the Be kernel.
>>>>>>>.
BeOS doesn't properly support the mtrrs in AMD chips.
Haven't tried QNX recently.
>>>>>>
You should. Not only does it have the nicest fonts I've ever seen, but it is fast as all hell.
Point is that with properly prioritized processes you can make Linux just as responsive as for example BeOS.
>>>>>>>.
On a desktop or workstation OS, this shouldn't be necessary. The OS should manage that. Besides, I've been running X at -20 as long as I can remember, and while it improves the speed, it still doesn't work as well as Win2K or BeOS.
The advantage BeOS has is that it does this automatically for you, it's a single user OS, with no security. (I'll take multi-user Linux over it anyday though!)
>>>>>>>>
Why? On a workstation, what's the point?
t they are not transparent to applications
What do you mean, not transparent?
>>>>>>>>
For example, in DirectX, an app uses whatever features the API has available. If the features are not implemented in hardware, they are emulated. (Or, in the case of some 3D features, just not implemented. In these cases, however, you get fine-grained information about the exact capabilities of hardware, so it is quite easy to enable turning on and turning off of features.) In either case, when hardware that supports that feature becomes available, the software automatically takes advantage of it, no recompilation, no patches, no nothing. Thus, if X had this design, all apps would automatically take advantage of whatever features were available. AA text could be done without requiring application support. Different rendering back-ends could be put in without messing with apps. In general, lots of stuff that X should do automagically, but can't. While this is more of a problem for OpenGL (where features are introduced monthly) X isn't immune to it, as evidenced by the silliness of Render. While DirectX in reality has deviated somewhat from the ideal of feature transparency, it still does a hell of a better job than any extension mechanisms. This is evidenced by the fact that developers sternly told MS not to make DirectX extendible.
Where are you getting these numbers from? And what constitutes sending a message?
>>>>>>
A simple program shunting data from one app to another. The messages were various sizes, and used whatever IPC mechanism was native on the OS (ports in BeOS, send, recieve in QNX). With 32 byte messages (the size of an X packet) BeOS hit 90,000 messages per second on a PII. QNX was in the 40s. With big messages (10K and up) BeOS could move data at memcpy speeds approaching 400MB/sec.
The answer is quite easy. Simply stop making so many shared libraries! On Linux, there are at least a dozen different libraries that do the same thing the same way, and progams use all of them. If GTK+ and Qt weren't equally used by different programs, there would be a dozen libraries you could remove right off the bat. If people didn't keep releasing toolkits and wrappers as fast as they could code them, the total library bloat would greatly decrease. Say what you will about closed-source OSes, they do have one advantage. A closed source OS is usually managed as a whole (rather than having seperate projects for the kernel, GUI, etc.) Thus they are able to impose standards on developers (yes, imposing standards is a good thing, just like imposing law) who, while free to not follow the standards, do so at the risk of pissing off consumers who have grown used to uniformity.
This is simply not true. Both your 2.2 and 2.4 numbers are dead wrong.
>>>>>>>>>>>..
I don't think so. The length of a jiffy (the timer interrupt) in Linux is 10ms. However, the quantum is 50ms. Most processes are not preempted within the 10ms jiffy.
X is in userpace.
>>>>
That's my point. QNX and BeOS both run in userspace, just like X, and run a good deal faster.
The design is about 20 years old, and still going strong.
>>>>
It's still alive... But so is Strom Thurmond.
Luckily enough they tought of X extensions. Oh wait, X extensions are bad right?
>>>>>>>>>>>>
Yes, extensions are by definition bad when they are used to implement core functionality. OpenGL extensions suck for the same reason X extensions suck: they are not transparent to applications. All apps should be AA enabled automatically (user-configurable, of course!) The fact they are not is an inherent weakness in the extension mechanism. Sorry to say this, but MS has the right idea. Take a look at DirectX for an API that allows old apps to automatically take advantage of new advances.
Local sockets are really fast
>>>>>>>>>>>
Umm, the BeOS messaging system can shunt 90,000 messages per second around the system (on a PII 300). Nothing on UNIX is anywhere *near* that number. Even QNX can't do above 40K.
Try TinyX. Your arguments, while true to some extend, are really not convincing enough to call X "badly designed".
>>>>>>>>>
Does TinyX have all the featues of QNX Photon? Hell, Xfree86 doesn't have all the features of Photon!
As for BeOS, you're comments are irrelevent. I mentioned it for technological comparision, not political debate. Though I too support OSS BeOS, it is not an issue in this thread. Not everything I post is a Linux-sux BeOS rocks rant.
Actually, even games are moving farther and farther from the hardware. The main reason is because today's hardware is so complex, they have to hide behind libraries and drivers (OpenGL, DirectX, OpenAL, etc) anyway, so properly protecting everything isn't a problem at all. For example, there is much talk that new graphics cards will not export straight framebuffers without a performance hit, since it messes with their internal workings. Again, its not that X is in userspace that's the problem (sometimes I don't think some/. understand the actual differences between userspace and kernel space...) but that it is poorly designed.
1) X runs on UNIX. Unicies are almost always server-oriented systems, and tend to have very short thread quantums. For example, the quantum on Linux 2.4 is 50ms (down from 100+ on 2.2). That means that if a process sends out a request near the beginning of its timeslice, it will be a minimum of 50ms before X is sheduled again. This is why renicing X has such a good effect, because it allows X to be sheduled ahead of other processes. OSs that use shorter timeslices (10ms on NT, 3ms on BeOS, 4ms on QNX) show much improved access times, even when the GUI is in a userspace server (as in BeOS or QNX)
2) It's badly designed. To tell the truth, I can't rationalize X's design. Wheras other OSes like BeOS use special-purpose messaging channels to communicate with the window server, X uses the much more general (and much slower) UNIX domain sockets. Secondly, when GUIs like Photon (on QNX) implement all the features of X plus more in less than a meg, one has to fault elements of X's design, elements that have nothing to do with either the versatility of transparent networking, nor the stability of a usermode server.
I know you're joking, but I have to point out some flaws in our information. First, DirectX isn't in the kernel. Just like most of Windows, it is contained in a userspace library. The only thing in the kernel is a channel through the HAL (on Win2K) that allows the DirectX libraries access to the hardware.
>>>> this is a multi-part message, since Slash 2.0 breaks IE 5.05 quite badly >>>>>>>>>>>
X is definately not needed, but hey, its UNIX. You nuts still use tty software and termcap databases to write to your GeForce3 Linux terminals. There are two main arguements for X
Yo, stop mistating communism. (I don't care if you're being sarcastic, either way you're misrepresenting communism.) Have you even read the Manifesto? I don't agree with some parts of it, but in reality, much of what the US is now is basically what Marx outlined in the Manifesto. Too many Americans get their ideas about communism from cold-war type idiots, and dislike the entire ideology based on Russia's basterdized version of Communism.
I'm pretty sure that both network transparency and multiple desktops were not pioneered by X. Besides, there are programs that let you do virtual desktops on Windows too. (And, let's not forget that BeOS has the best implementation of virtual desktops available, allowing you to set them to different resolutions, color depths, and referesh rates.) Also, I'm just waiting for X to start copy MS and make the damn thing fast, standardized, and well-integrated with media technologies like OpenGL and high performance audio.
99% of the time, X is used on a workstation or desktop machine. (Who installs a GUI on a server?) As such, his comments about X's bloat have apply to only 1% of the population, and have absolutely zero significance. In reality, most of couldn't use TinyX. ('cause if we could, we would already be using it!) It doesn't have a 3D infrastructure like XFree86 (plus it can't use the NVIDIA 3D drivers, the best OpenGL drivers around on Linux), and it doesn't have all the feature necessary to compete with the GUIs of Windows and other OSes. Problems with 'top' aside, there is only one thing that is important. KDE2/X/Linux swaps more than Win2K on my machine, apps start significantly slower (ex. KDevelop takes far longer to load than Visual C++), and while using the UI is lightning fast on Win2K, X is significantly slower, even using simple window managers like WindowMaker. (And that it isn't even a fair comparison, since Win2K has tons more features than WindowMaker/X). It flickers more, the mouse jerks at times (that, in particular is positively uncivilized), and windows switch noticibly slower. *That* is what matters, not some bullshit about how stripped down X can occupy very little space.
True, but the point of EPIC is to make the best use of available resources. If it is easy to make the compiler parallize everything, then why not do that and save transistors on the chip for bigger caches/more function units? The 800MHz Itanium, which outperforms the Alpha for FP (which matters a *whole* lot more than INT on a workstation) costs less than $1200. You can bet that will go down significantly when volume increases and the arch becomes more mature (Remember, EPIC is supposed to replace x86). So eventually, it will cost the same to put 10 Itaniums into a machine as it does to put 10 Athlon-6's or Pentium 5's. At that point, why not just build a better compiler and get more overall performance from the same number of transistors?
Slashdot Mirror
What's needed is less arrogance, and more understanding that Small Is Beautiful (And Bloody Fast).
>>>>>>>>>>>>>>>>
Good god. If only the Linux GUI developers would think the way the networking developers do!
BTW> This was directly inspired by the recent GNOME article...
I've done Be programming, and because of the design, it really isn't hard to keep the interactions straight. Windows probably does have a problem with threads, mainly because of the C style of the API. However, in Be, multi-threading is explicitly done in window threads. Since, the window interface is contained within a set of C++ classes, all one has to remember to do is be aware of thread interactions in any code that you put into the window subclass. Also, most threads are wrapped in Loopers (essentially message loops) so it again comes down to making sure that any code within a particular object is thread-safe. BeOS does have some problems, but instability in the apps is not one of them. (Not more than in any other OS, anyway) As for the OS itself, I can't say if Be has better programmers (though I'd like to think so ;) but I think the emphasis on keeping the design extremely simple and clean has a lot to do with the stability of the threading model. BeOS is not a feature-laden OS. It has some well-chosen luxuries that really enhance the user experience, but it doesn't try to make everyone happy.
How about getting Linux's interactive GUI performance to equal Windows? It will never happen, if only because of the disadvantages it would introduce to other types of programs. This back and forth will never lead to anything. I value desktop performance over everything, you value open systems and generalized performance. Ideally, the two stances could be reconciled in one OS, but that isn't the case in the real world, so in the end, I use what I want, and you use what you want.
Last time I checked, about .5% of the population was willing to dump their x86 boxes and switch top MacOS X/PPC (which has serious speed problems btw) just for the desktop. Unless Quartz and Aqua become open source, this isn't even a point worth considering.
How does the new x86 backend generated code perform in relation to previous compilers. I know icl (Intel C compiler) is coming out for Linux, and from the demoes of it I've used on Windows, it looks pretty damn spiff. (Stupid 30 limit...) Compile speed is fast too. If you look at the icl docs, you'll find that the optimizer on this thing is insane, it does all sorts of inter-intra function optimizations and prepiplines code and everything. I have only a vague understanding of what the hell that means, but it sure SOUNDS fast. Anyway, I'll try out the Windows version and see how it performs in relation to gcc. I'll post benchmarks when I get the chance. I'd appreciate it if someone would post Linux benchmarks as well, because as much as I like Windows, I can barely stand not having bash. (Ah... BeOS, where art thou?)
That is their problem. Perhaps they shouldn't have used licensed code? Food for though, eh?
>>>>>>>>>>
Maybe releasing high quality drivers on time was more important for them than appeasing the 1% of the market that are die hard OSS zealots? Food for thought, eh?
You do realize that drivers are hardware specific, right?
>>>>>>>
Go to www.opengl.org and look up the term ICD. OpenGL ICDs are entire implementations of OpenGL pipelines. Unlike a network driver (for example) the host OS doesn't do anything for the OpenGL subsystem (except give it access to a window) Thus, everything from glVertex3f() down to register banging is done by the ICD. If you've looked at the OpenGL standard, the upper (hardware independant) levels are the hard part. Why do you think Matrox and ATI are having so many problems with their drivers? If ATI had NVIDIA's OpenGL driver, they could easily squeeze another 10-15% out of their hardware. NVIDIA spent a lot of time developing their ICD, why should ATI get it for free?
Good god, man. Judge a company by what it does, not what it has the *potential* to do. There are so many good things about NVIDIA I don't have the time to iterate them now. NVIDIA got where they are by making good products and having good support. It is a disrespect to them to suggest they're trying to control the world, when they've given no such signs.
As for the driver thing, get your head out of your ass. It's called licensed code. (Plus the fact that they have the best OpenGL implementation available. Why should they write ATI's driver for them?)
Actually, for the longest time, everyone has been shipping integrated graphics with AGP slots. HP used to not do that, and they caught hell for it. I doubt you'll find many computers at Best Buy that have integrated graphics and no AGP slot.
One can look at it another way. The majority of developers use Win32! Why can't Linux get with the program?
If you're benchmarking an OS, you use whatever is fastest on the OS. And since most Win2K server programs WILL use whatever is fastest on Win2K, the benchmark can be valid as a real-world test (assuming all other factors are correct, of course!)
>>>>>
For the English-imparied, I'm not advocating that Linux switch to Win32. I'm simply stating that what is "normal" is in the eye of the beholder.
Any programming construct can be harmful. Pointers, explicit memory allocation, anything! However, if interfaces are clearly defined, and and the code is kept simple (ie. lack of feature creep, something that the "new" (GNOME, KDE, etc) UNIX guys don't seem to understand) threading is just as harmless as pointers. I'm not going to get theoretical here, but I'll give you an actual example: BeOS. Say what you will about it being dead or the company being stupid or whatever, it has a kick-ass threading implementation. The app_server regularly runs with 60+ threads and the damn thing only crashes on me when I'm playing with a kernel driver. The apps, too, are stable, even though they are forced into using multi-threading due to the GUI architecture. If you want to see why this is the case, take a look at the BeBook (the API). Every time there is a possible thread interaction, they warn you about it. Just as you have to keep memory ownership clear, you have to do the same thing for threads. Theoretical rules aside, an entire platform begs to differ with you.
Actually, if you look at the PE file format, there are fields for not one but two version fields (library and subsystem) and something resembling a soname. So Windows supports it, its just that Windows developers don't use it.
If there is no other process to run (with a higher priority) of course the kernel will let the current process run its full timeslice. However, any process that needs attention and has a higher priority than the current running one preempts it and gets to run (within 10-20ms).
>>>>>>>
True. However, that requires processes to have a higher priority. However, on a normal system, Linux doesn't automatically manage these priorities. While "goodness" does have some effect, the Linux sheduler doesn't use tricks like the Windows sheduler does to make sure that GUI apps get fast response times. If you look at the case study of Win2K in Tannenbaum's new book, you'll see that Win2K does all sorts of priority mucking to make sure that GUI apps have a higher ability to preempt than other apps. While this might be bad for a server, or a generalized system, it certainly does wonders for GUI response.
"run a good deal faster", and what runs a good deal faster? The BeOS UI is certainly much slower on my box these days, but I suspect that has something to do with the AMD-challenged optimizations in the Be kernel.
>>>>>>>.
BeOS doesn't properly support the mtrrs in AMD chips.
Haven't tried QNX recently.
>>>>>>
You should. Not only does it have the nicest fonts I've ever seen, but it is fast as all hell.
Point is that with properly prioritized processes you can make Linux just as responsive as for example BeOS.
>>>>>>>.
On a desktop or workstation OS, this shouldn't be necessary. The OS should manage that. Besides, I've been running X at -20 as long as I can remember, and while it improves the speed, it still doesn't work as well as Win2K or BeOS.
The advantage BeOS has is that it does this automatically for you, it's a single user OS, with no security. (I'll take multi-user Linux over it anyday though!)
>>>>>>>>
Why? On a workstation, what's the point?
t they are not transparent to applications
What do you mean, not transparent?
>>>>>>>>
For example, in DirectX, an app uses whatever features the API has available. If the features are not implemented in hardware, they are emulated. (Or, in the case of some 3D features, just not implemented. In these cases, however, you get fine-grained information about the exact capabilities of hardware, so it is quite easy to enable turning on and turning off of features.) In either case, when hardware that supports that feature becomes available, the software automatically takes advantage of it, no recompilation, no patches, no nothing. Thus, if X had this design, all apps would automatically take advantage of whatever features were available. AA text could be done without requiring application support. Different rendering back-ends could be put in without messing with apps. In general, lots of stuff that X should do automagically, but can't. While this is more of a problem for OpenGL (where features are introduced monthly) X isn't immune to it, as evidenced by the silliness of Render. While DirectX in reality has deviated somewhat from the ideal of feature transparency, it still does a hell of a better job than any extension mechanisms. This is evidenced by the fact that developers sternly told MS not to make DirectX extendible.
Where are you getting these numbers from? And what constitutes sending a message?
>>>>>>
A simple program shunting data from one app to another. The messages were various sizes, and used whatever IPC mechanism was native on the OS (ports in BeOS, send, recieve in QNX). With 32 byte messages (the size of an X packet) BeOS hit 90,000 messages per second on a PII. QNX was in the 40s. With big messages (10K and up) BeOS could move data at memcpy speeds approaching 400MB/sec.
The answer is quite easy. Simply stop making so many shared libraries! On Linux, there are at least a dozen different libraries that do the same thing the same way, and progams use all of them. If GTK+ and Qt weren't equally used by different programs, there would be a dozen libraries you could remove right off the bat. If people didn't keep releasing toolkits and wrappers as fast as they could code them, the total library bloat would greatly decrease. Say what you will about closed-source OSes, they do have one advantage. A closed source OS is usually managed as a whole (rather than having seperate projects for the kernel, GUI, etc.) Thus they are able to impose standards on developers (yes, imposing standards is a good thing, just like imposing law) who, while free to not follow the standards, do so at the risk of pissing off consumers who have grown used to uniformity.
Nintendo64 used a custom designed R4300i, not a R3400.
Yuck. Factual errors all over the place...
This is simply not true. Both your 2.2 and 2.4 numbers are dead wrong.
>>>>>>>>>>>..
I don't think so. The length of a jiffy (the timer interrupt) in Linux is 10ms. However, the quantum is 50ms. Most processes are not preempted within the 10ms jiffy.
X is in userpace.
>>>>
That's my point. QNX and BeOS both run in userspace, just like X, and run a good deal faster.
The design is about 20 years old, and still going strong.
>>>>
It's still alive... But so is Strom Thurmond.
Luckily enough they tought of X extensions. Oh wait, X extensions are bad right?
>>>>>>>>>>>>
Yes, extensions are by definition bad when they are used to implement core functionality. OpenGL extensions suck for the same reason X extensions suck: they are not transparent to applications. All apps should be AA enabled automatically (user-configurable, of course!) The fact they are not is an inherent weakness in the extension mechanism. Sorry to say this, but MS has the right idea. Take a look at DirectX for an API that allows old apps to automatically take advantage of new advances.
Local sockets are really fast
>>>>>>>>>>>
Umm, the BeOS messaging system can shunt 90,000 messages per second around the system (on a PII 300). Nothing on UNIX is anywhere *near* that number. Even QNX can't do above 40K.
Try TinyX. Your arguments, while true to some extend, are really not convincing enough to call X "badly designed".
>>>>>>>>>
Does TinyX have all the featues of QNX Photon? Hell, Xfree86 doesn't have all the features of Photon!
As for BeOS, you're comments are irrelevent. I mentioned it for technological comparision, not political debate. Though I too support OSS BeOS, it is not an issue in this thread. Not everything I post is a Linux-sux BeOS rocks rant.
Oh god. He pointed out X sucked! Blasphemer! Keep it coming, baby, got plenty of karma to spare ;)
To tell the truth, I don't want to pay for stuff I don't use. Where's the famed UNIX "choice?"
Actually, even games are moving farther and farther from the hardware. The main reason is because today's hardware is so complex, they have to hide behind libraries and drivers (OpenGL, DirectX, OpenAL, etc) anyway, so properly protecting everything isn't a problem at all. For example, there is much talk that new graphics cards will not export straight framebuffers without a performance hit, since it messes with their internal workings. Again, its not that X is in userspace that's the problem (sometimes I don't think some /. understand the actual differences between userspace and kernel space...) but that it is poorly designed.
1) X runs on UNIX. Unicies are almost always server-oriented systems, and tend to have very short thread quantums. For example, the quantum on Linux 2.4 is 50ms (down from 100+ on 2.2). That means that if a process sends out a request near the beginning of its timeslice, it will be a minimum of 50ms before X is sheduled again. This is why renicing X has such a good effect, because it allows X to be sheduled ahead of other processes. OSs that use shorter timeslices (10ms on NT, 3ms on BeOS, 4ms on QNX) show much improved access times, even when the GUI is in a userspace server (as in BeOS or QNX)
2) It's badly designed. To tell the truth, I can't rationalize X's design. Wheras other OSes like BeOS use special-purpose messaging channels to communicate with the window server, X uses the much more general (and much slower) UNIX domain sockets. Secondly, when GUIs like Photon (on QNX) implement all the features of X plus more in less than a meg, one has to fault elements of X's design, elements that have nothing to do with either the versatility of transparent networking, nor the stability of a usermode server.
I know you're joking, but I have to point out some flaws in our information. First, DirectX isn't in the kernel. Just like most of Windows, it is contained in a userspace library. The only thing in the kernel is a channel through the HAL (on Win2K) that allows the DirectX libraries access to the hardware.
>>>> this is a multi-part message, since Slash 2.0 breaks IE 5.05 quite badly >>>>>>>>>>>
X is definately not needed, but hey, its UNIX. You nuts still use tty software and termcap databases to write to your GeForce3 Linux terminals. There are two main arguements for X
Yo, stop mistating communism. (I don't care if you're being sarcastic, either way you're misrepresenting communism.) Have you even read the Manifesto? I don't agree with some parts of it, but in reality, much of what the US is now is basically what Marx outlined in the Manifesto. Too many Americans get their ideas about communism from cold-war type idiots, and dislike the entire ideology based on Russia's basterdized version of Communism.
I'm pretty sure that both network transparency and multiple desktops were not pioneered by X. Besides, there are programs that let you do virtual desktops on Windows too. (And, let's not forget that BeOS has the best implementation of virtual desktops available, allowing you to set them to different resolutions, color depths, and referesh rates.) Also, I'm just waiting for X to start copy MS and make the damn thing fast, standardized, and well-integrated with media technologies like OpenGL and high performance audio.
99% of the time, X is used on a workstation or desktop machine. (Who installs a GUI on a server?) As such, his comments about X's bloat have apply to only 1% of the population, and have absolutely zero significance. In reality, most of couldn't use TinyX. ('cause if we could, we would already be using it!) It doesn't have a 3D infrastructure like XFree86 (plus it can't use the NVIDIA 3D drivers, the best OpenGL drivers around on Linux), and it doesn't have all the feature necessary to compete with the GUIs of Windows and other OSes. Problems with 'top' aside, there is only one thing that is important. KDE2/X/Linux swaps more than Win2K on my machine, apps start significantly slower (ex. KDevelop takes far longer to load than Visual C++), and while using the UI is lightning fast on Win2K, X is significantly slower, even using simple window managers like WindowMaker. (And that it isn't even a fair comparison, since Win2K has tons more features than WindowMaker/X). It flickers more, the mouse jerks at times (that, in particular is positively uncivilized), and windows switch noticibly slower. *That* is what matters, not some bullshit about how stripped down X can occupy very little space.
True, but the point of EPIC is to make the best use of available resources. If it is easy to make the compiler parallize everything, then why not do that and save transistors on the chip for bigger caches/more function units? The 800MHz Itanium, which outperforms the Alpha for FP (which matters a *whole* lot more than INT on a workstation) costs less than $1200. You can bet that will go down significantly when volume increases and the arch becomes more mature (Remember, EPIC is supposed to replace x86). So eventually, it will cost the same to put 10 Itaniums into a machine as it does to put 10 Athlon-6's or Pentium 5's. At that point, why not just build a better compiler and get more overall performance from the same number of transistors?