Yep, you heard right. RAMBUS RAM is crappy. Sure it runs a 800 MHz, but at what cost? It only has a 16 bit data bus, which greatly affects latency. As Tom has pointed out before on TomsHardware.com, high power 3D apps (read: games) use comparitivly little bandwidth, but need low latency. Even one of the most demanding of these apps (read: Quake) uses only about a few hundred megs of bandwidth. As such, DDR-SDRAM is a much better choice, because A) It provides much lower latency. B) It is much cheaper. C) It has just as much bandwidth. There is a reason the latest GeForce cards aren't using RDRAM. (Aside from the cost.) DDR-SDRAM is a much better memory technology. The only real reason that RDRAM has made it even this far is that Intel wants a little piece of the memory game.
This is yet another move from a major UNIX vendor that shows support of the Open Source movement. (As an aside, I am surprised people think that it shows support for Linux. They make no mention of the type of license that Tru64 will be under, and thus, there will be probably no way for the Linux people to steal parts of Tru64.) Many people could say that it is just Compaq jumping on the OSS bandwagon, but Compaq's other software efforts show that this is not so. They have ported many of their development tools to Linux, and have shown a general support of Linux on the Alpha architecture. Its move to abandon WinNT for Alpha plus its moves to support Linux show a general trend in the PC-class high end workstation market. In general, companies are trying to move away from WinNT on their workstations. SGI is doing this in conjunction with nVidia, and now Compaq is doing this. I believe it is because Linux offers much more freedom to the OEM about how they want their machines configured, and it also bridges the gap between the lower end PC-class workstations and the high end UNIX servers. I can predict that IBM will be making an announcement soon to run some of its workstations on Linux, as it has already done so much to beef up its support. SGI too, is probably not that far away from announcing a Linux based workstation with nVidia Quadro graphics and XFS support to replace the Visual Workstation line.
1) Every compiler is going to have special cases in terms of performance. It is unreasonable to expect MS to make sure that its compiler has the same special cases as gcc. 2) There are a lot of people who want some of the special features present in compilers (like #pragma once) and know enough that that code won't work on another compiler. These features are not a standard part of the C or C++ spec, but are in demand anyway so vendors have to come up with their own method of doing it. Visual has a couple of nice ways of doing things like exporting library functions, and inline asm, that are just plain nicer than the way gcc or Watcom does it. Since there is no real standard for these things, MS can't be blamed for not making their compiler like everyone elses. As in any compiler (even gcc) you have to write standard code. The price you pay for portability is losing some of the neat, but proprietory, features present in all compilers.
And they do the same job. What a coincidence! >>>>>>>>>> Yes, quite a coincidence. Its incredible how Linux zealots complain about Window's bloat, UNTIL, Linux gets just as bloated. BeOS (and a number of other OSs) do the same job, yet are much slimmer. >>>>>>>>>>>>>>> I guess by "crap" you mean "applications"? Seriously, Linux and Gnome could be a lot smaller if they ditched support for existing Unix/X applications and standards, but then nobody except you would use them. Unfortunately a lot of computer users want to do useful work with their computers rather than spending their time measuring each other's kernels. >>>>>>> No, I don't mean apps. I was talking about system size. The crap (crap in the sense of legacy code, not bad systems!) I mean isn't support for POSIX either. I am talking about the huge amount of redundancy present in a desktop Linux system. You have libraries crawling up the walls. Is there a reason I have to have curses on my system? Or if I don't have that, I have to have TK? Would it kill the kernel developers to make a X based config tool (Native, not dependant on TK)? Redundancy is the #1 problem in Linux. It isn't like Linux has that much legacy app support over BeOS, it's just that the BeOS ones are immature. Already, BeOS has a decent X server, nearly full POSIX complience, a nearly finished NATIVE GTK+ implementation, and a BeWine project that is progressing quite nicely. Yet, still, the average BeOS system (even loaded with these goodies) is hugly less memory intensive than a Linux system. I don't measure the kernel for no reason. I measure the amount of resident memory each takes, and I measure swap activity, and I measure system responsiveness. If these are trivial, well, we have different priorities.
You said it. Why would anyone run KDE and Gnome when they do the same job? And by the way, it's CORBA, not COBRA. >>>>>>>>> Sorry, I've always thought it was COBRA. Sounds much less cooler now. Anway, I see that you are someone who doesn't like GNOME, yet love the KDE apps. Currently, I use GNOME with Sawmill because it looks so much nicer, and the environment is much better. I do, however, like KDevelop. Thus, I have to install both GNOME and KDE.
It's CORBA you monkey! >>>>>>>>>>>>> You settle for trivial responses, but think about it. Why NOT a system-wide CORBA implementation. What's there to lose? There is a lot to gain!
Oh, it's just architecture differences? Well then, they're basically the same, aren't they? Just like Windows and Linux are basically just two operating systems that provide some services to applications. Monkey. >>>>>>> You are so shallow. Do you even think before you post? If you ever read the DirectX docs, you should realize that architecture is independant of interface IN A WELL DESIGNED SYSTEM. It is very possible (using a COM-like object system) to design a DE whose backend architecture can be seperated from the middle-ware, and still stay compatible with any GUI the user wishes to use. Take the CORBA implementaiton. CORBA has a set API, no? Why not make an object (or a library or whatever) to allow an app to access CORBA. Now, you can use whatever damn CORBA implementation you chose, as long as it responds in a given way to a given input. Thats why apps designed for DirectX 1.0 still work perfectly on DirectX 8.0 AND take advantage of the speed of the new implementation. As long as a higher level GUI uses only these objects to access services, the backend architecture can be changed without having to keep around two complete implementations. Think about it, no more keeping around two different widget sets that do the same thing, but only differ in HOW they do them.
They did. It's calle Xlib. Xlib is good for what it is, but it is feature poor and NOT IMPLEMENTATION INDEPENDANT. It relys too heavily on X providing the backend services. Plus, it does none of the things the new DEs have set out to do.
I write straight C++. I don't even know of the efficiant cases for Visual, I just use good algorithms and let the optimizer do its magic. I have ported a great deal of code between (including a drawing library which is pretty performance critical code) and it works just fine under BeIDE/GCC. I don't use any of the auto-code generation, but that code is inportable anyway, so it doesn't matter. Code portability is also not that terribly a big deal to me, since I find that the APIs are a far bigger hinderance to me than anything else (Probably my fault, but I find POSIX ugly as all hell and thus refuse to touch it with a ten foot pole.). The point is that you have to be smart. As long as you don't use stuff like #pragma (once) and pay attention to how your vendor inlines asm code, you're fine.
Yo, not everyone is hooked to a T1. Plus, it takes a lot of config to switch a system from 2.0 to 2.2. In addition, a lot of packages need some extra config time in vastly newer versions. This config is not done automatically. It is their job to maintain the distro, not mine. If they don't do it, what the hell is wrong with not using it?
Damn you Linux zealots are idiots. What is wrong with expecting a NEW distro to come with up to date software? Its not that hard, but unlike you, normal people actually have work to do. They can't spend their entire weekend updating their Linux distro. Does expecting the people who's responsibility it is to maintain the distro to actually maintain it make you less 31337 (Or however it's spelled.)
Actually, even C++ (which is a pretty lightweight resource-wise) OO language needs significant runtime resources. Even in BeOS (Where C++ is modus oparendi in user level stuff) C++ is discouraged for kernel-level stuff (namely drivers and modules)
It's true. Linux is becoming increasingly more bloated. In terms of memory use, its true. GNOME +X +Linux take as much memory as Windows. I find it incredible how much bloat is left in Linux in general. Sure, it is much better at managing it than most other OSs, but a clean kernel does not a clean system make. The Linux kernel has around 2 million lines of code and takes 10 minutes to compile (on my PII300.) It takes 90 minutes to compile X, so lets be conservative and say that X is 10 million lines of code. That is 12 million lines right there. GNOME takes almost as long as X to compile, so lets estimate another 8 million lines there. (I'm hugely low balling it.) That is around 20 million lines of code. With QT/KDE (which is almost required for the GNOME-faithfull to run cool apps like KDevelop), that climbs to 25-30 million lines. That is nearly as much as Windows 2K (only 3-5 million lines less). In comparison, BeOS is a sevelte 1.5 million lines for the entire OS. Don't belive me, root around the/boot/beos/system directory some time. The kernel is about 700K, the servers about 3.5 meg, the drivers are less than 500K(it loads drivers dynamically) and deskbar and tracker are about 2.5 meg. In total, the entire/boot/beos/system directory is 36 meg which incluldes all libraries, codecs, kernel add ones, unused drivers, etc. It is easy to see why. BeOS doesn't have nearly as much crap in it as Linux does. Take the whole KDE/GNOME/X thing. If someone runs KDE 2 and GNOME 2, they will have a total of two large cobra implementations, three drag and drop protocols, three print servers, three+ widget sets, dozons of critical libraries, and an ass-load of duplicated functionality. Choice is good, bloat is bad. This is why Linux cries out for standardization. Why cannot a Linux-wide COBRA implementation be used? Is the one time loss of a little bit of programming flexibility (face it, GNOME and KDE do the same thing. For the programmer, it is just an API preference.) worth the extra 30 meg loss in memory? Is it really necessary to have a seperate GNOME print architecture, or for Qt and GTK+ not to be binary compatible? How exactly is GNOME different from KDE aside from ascthetics(namely that until 2.0 the KDE people had none)? Sure there are some architecture differences, but to the app, they provide basically the same services with the same features. I don't begrudge people flexibility. I just think that Linux is becoming increasingly bloated, and people aren't taking any steps to curb it. It would be really nice if someone would define a standard set system of objects, (or function calls, no-one cares) that could be implemented by and DE and widget set of the users choice. Now THERE is smart flexibility.
PS: I know flamers won't read this far before responding, but I'll try anyway. Don't say that Linux is so flexible you can leave these things out. If you want a modern feature-rich desktop OS, at the moment, KDE and GNOME are the only players. Until KDE 2.0 becomes stable, the situation is even worse, because GNOME has a better environment, while KDE has better apps.
Why are OpenSource development tools the RightWay? Don't you people care about funtionality? I get Visual C++ for an absurdly low student discount, and I greatly prefer it to using KDevelop, because frankly, VisualC++ is much better. I also prefer the MS compiler to gcc because it optimizes my code better! If you like the OpenSource ideal above all else, then an open compiler is the RightWay (TM) for YOU. If you like speed and functionality above all else, and the most funtional at the moment is a closes source app, then that app is the RightWay(TM) for you. I frankly don't like Linux, for example. It has a nice community, a nice development model, but it just rubs me the wrong way. I do, however, see why lots of people like it. I agree that the RightWay(TM) is whatever works for them. Linux, BSD, BeOS, whatever, they are all the RightWay(TM) if they work the RightWay(TM) for you.
Re:A wake-up call for Linux zealots
on
AtheOS
·
· Score: 2
I meant "can't" and I know it!
Re:A wake-up call for Linux zealots
on
AtheOS
·
· Score: 2
The whole "it's OpenSource it can be anything" spiel is a little trite. You can really change Linux to be a new type of OS without having to start from scratch. Linux is a UNIX and always will be, no matter how much jiggering people do with it. At best, the OSS license will allow people to cannibalize parts of it for the new OS.
I know DCOM isn't that great. I, personally, think distributed interfaces are retarded in this day and age of huge bandwidth networks and massive local storage, but hey, to each his own, right? I do concede that COBRA is better for distributed objects, but I dislike that fact that it has so much bloody overhead.
You haven't used DirectX have you. It is direct access to hardware in a HARDWARE INDEPENDANT WAY. You can write perfectly portable software (between hardware, OSs, CPUs, and what-not) using an API that allows direct access to hardware.
Excuse me? Full easier than 3D video? Maybe in Linux, where the extent of 3D sound is multiple channels, but in windows you have cards that do occulsion, reflections, reverb, etc. For some parts of A3D 2.0, you even have to feed it your vertex data so it can calculate oculsions and what-not.
I wasn't talking about the actual test. I was talking about the line where they say there will be a battle between Linux and windows over which is the best gaming experiance.
Quake 3 uses direct X for everything except 3D. Thus, Quake never actually makes very many Windows calls, most of its calls are to DirecX. Thus the game is actually running on DirectX, rather than Windows, which merely provides some window and process management code. This specific test may have sound turned off, but the battle between Linux and Windows definatly won't. (You play your games with sound off?) They talk of Linux becoming as good of a gaming experiance as Windows. Unless it gets something like DirectX, it won't. PS: Repeat after me, SDL is not a full-fledged media system. It is merely a wrapper API for native high-performance APIs. Also, DirectX does not preclude OpenGL. It merely keeps you from using DirectDraw. In addition, SDL graphics functions don't work with OpenGL either. This is a big difference compared to D3D where you can render into a hardware buffer, directly write in it with DirectDraw, and use the whole thing as a source texture for some 3D object.
I knew about DGA, but it doesn't hold a candle to DDraw in terms of features. The big problem is that it is a bunch of disparate APIs, so extending it to include this nifty features is difficult. Take for example, the cool trick of rendering directly into a texture surface, drawing on it through a pointer to memory, than mapping it to a 3D object. Without a lot of reworking between DRI, DGA, and OpenGL, this will be impossible under Linux.
Slashdot Mirror
Yep, you heard right. RAMBUS RAM is crappy. Sure it runs a 800 MHz, but at what cost? It only has a 16 bit data bus, which greatly affects latency. As Tom has pointed out before on TomsHardware.com, high power 3D apps (read: games) use comparitivly little bandwidth, but need low latency. Even one of the most demanding of these apps (read: Quake) uses only about a few hundred megs of bandwidth. As such, DDR-SDRAM is a much better choice, because
A) It provides much lower latency.
B) It is much cheaper.
C) It has just as much bandwidth.
There is a reason the latest GeForce cards aren't using RDRAM. (Aside from the cost.) DDR-SDRAM is a much better memory technology. The only real reason that RDRAM has made it even this far is that Intel wants a little piece of the memory game.
This is yet another move from a major UNIX vendor that shows support of the Open Source movement. (As an aside, I am surprised people think that it shows support for Linux. They make no mention of the type of license that Tru64 will be under, and thus, there will be probably no way for the Linux people to steal parts of Tru64.) Many people could say that it is just Compaq jumping on the OSS bandwagon, but Compaq's other software efforts show that this is not so. They have ported many of their development tools to Linux, and have shown a general support of Linux on the Alpha architecture. Its move to abandon WinNT for Alpha plus its moves to support Linux show a general trend in the PC-class high end workstation market. In general, companies are trying to move away from WinNT on their workstations. SGI is doing this in conjunction with nVidia, and now Compaq is doing this. I believe it is because Linux offers much more freedom to the OEM about how they want their machines configured, and it also bridges the gap between the lower end PC-class workstations and the high end UNIX servers. I can predict that IBM will be making an announcement soon to run some of its workstations on Linux, as it has already done so much to beef up its support. SGI too, is probably not that far away from announcing a Linux based workstation with nVidia Quadro graphics and XFS support to replace the Visual Workstation line.
About your sig. BeOS boots up in 12 seconds, so sucks to MS.
1) Every compiler is going to have special cases in terms of performance. It is unreasonable to expect MS to make sure that its compiler has the same special cases as gcc.
2) There are a lot of people who want some of the special features present in compilers (like #pragma once) and know enough that that code won't work on another compiler. These features are not a standard part of the C or C++ spec, but are in demand anyway so vendors have to come up with their own method of doing it. Visual has a couple of nice ways of doing things like exporting library functions, and inline asm, that are just plain nicer than the way gcc or Watcom does it. Since there is no real standard for these things, MS can't be blamed for not making their compiler like everyone elses. As in any compiler (even gcc) you have to write standard code. The price you pay for portability is losing some of the neat, but proprietory, features present in all compilers.
And they do the same job. What a coincidence!
>>>>>>>>>>
Yes, quite a coincidence. Its incredible how Linux zealots complain about Window's bloat, UNTIL, Linux gets just as bloated. BeOS (and a number of other OSs) do the same job, yet are much slimmer.
>>>>>>>>>>>>>>>
I guess by "crap" you mean "applications"? Seriously, Linux and Gnome could be a lot
smaller if they ditched support for existing Unix/X applications and standards, but then
nobody except you would use them. Unfortunately a lot of computer users want to do
useful work with their computers rather than spending their time measuring each other's
kernels.
>>>>>>>
No, I don't mean apps. I was talking about system size. The crap (crap in the sense of legacy code, not bad systems!) I mean isn't support for POSIX either. I am talking about the huge amount of redundancy present in a desktop Linux system. You have libraries crawling up the walls. Is there a reason I have to have curses on my system? Or if I don't have that, I have to have TK? Would it kill the kernel developers to make a X based config tool (Native, not dependant on TK)? Redundancy is the #1 problem in Linux. It isn't like Linux has that much legacy app support over BeOS, it's just that the BeOS ones are immature. Already, BeOS has a decent X server, nearly full POSIX complience, a nearly finished NATIVE GTK+ implementation, and a BeWine project that is progressing quite nicely. Yet, still, the average BeOS system (even loaded with these goodies) is hugly less memory intensive than a Linux system. I don't measure the kernel for no reason. I measure the amount of resident memory each takes, and I measure swap activity, and I measure system responsiveness. If these are trivial, well, we have different priorities.
You said it. Why would anyone run KDE and Gnome when they do the same job? And
by the way, it's CORBA, not COBRA.
>>>>>>>>>
Sorry, I've always thought it was COBRA. Sounds much less cooler now. Anway, I see that you are someone who doesn't like GNOME, yet love the KDE apps. Currently, I use GNOME with Sawmill because it looks so much nicer, and the environment is much better. I do, however, like KDevelop. Thus, I have to install both GNOME and KDE.
It's CORBA you monkey!
>>>>>>>>>>>>>
You settle for trivial responses, but think about it. Why NOT a system-wide CORBA implementation. What's there to lose? There is a lot to gain!
Oh, it's just architecture differences? Well then, they're basically the same, aren't they?
Just like Windows and Linux are basically just two operating systems that provide some
services to applications. Monkey.
>>>>>>>
You are so shallow. Do you even think before you post? If you ever read the DirectX docs, you should realize that architecture is independant of interface IN A WELL DESIGNED SYSTEM. It is very possible (using a COM-like object system) to design a DE whose backend architecture can be seperated from the middle-ware, and still stay compatible with any GUI the user wishes to use. Take the CORBA implementaiton. CORBA has a set API, no? Why not make an object (or a library or whatever) to allow an app to access CORBA. Now, you can use whatever damn CORBA implementation you chose, as long as it responds in a given way to a given input. Thats why apps designed for DirectX 1.0 still work perfectly on DirectX 8.0 AND take advantage of the speed of the new implementation. As long as a higher level GUI uses only these objects to access services, the backend architecture can be changed without having to keep around two complete implementations. Think about it, no more keeping around two different widget sets that do the same thing, but only differ in HOW they do them.
They did. It's calle Xlib.
Xlib is good for what it is, but it is feature poor and NOT IMPLEMENTATION INDEPENDANT. It relys too heavily on X providing the backend services. Plus, it does none of the things the new DEs have set out to do.
Well good for you. In this case (since you need to develop palm apps) gcc is the RightWay(TM) for you, now isn't it?
I write straight C++. I don't even know of the efficiant cases for Visual, I just use good algorithms and let the optimizer do its magic. I have ported a great deal of code between (including a drawing library which is pretty performance critical code) and it works just fine under BeIDE/GCC. I don't use any of the auto-code generation, but that code is inportable anyway, so it doesn't matter. Code portability is also not that terribly a big deal to me, since I find that the APIs are a far bigger hinderance to me than anything else (Probably my fault, but I find POSIX ugly as all hell and thus refuse to touch it with a ten foot pole.). The point is that you have to be smart. As long as you don't use stuff like #pragma (once) and pay attention to how your vendor inlines asm code, you're fine.
I've gotten a 4: Flamebait before, so I feel for yo9u man!
Yo, not everyone is hooked to a T1. Plus, it takes a lot of config to switch a system from 2.0 to 2.2. In addition, a lot of packages need some extra config time in vastly newer versions. This config is not done automatically. It is their job to maintain the distro, not mine. If they don't do it, what the hell is wrong with not using it?
Damn you Linux zealots are idiots. What is wrong with expecting a NEW distro to come with up to date software? Its not that hard, but unlike you, normal people actually have work to do. They can't spend their entire weekend updating their Linux distro. Does expecting the people who's responsibility it is to maintain the distro to actually maintain it make you less 31337 (Or however it's spelled.)
Hello, Linux is mainly a non-Java bytecode CPU. (Yes, I'm being sarcastic, Linux doesn't run on any Java bytecode CPUs.)
Actually, even C++ (which is a pretty lightweight resource-wise) OO language needs significant runtime resources. Even in BeOS (Where C++ is modus oparendi in user level stuff) C++ is discouraged for kernel-level stuff (namely drivers and modules)
Whoa, this is a genuinly funny post. What exactly makes it off-topic? Humor is never off topic.
It's true. Linux is becoming increasingly more bloated. In terms of memory use, its true. GNOME +X +Linux take as much memory as Windows. I find it incredible how much bloat is left in Linux in general. Sure, it is much better at managing it than most other OSs, but a clean kernel does not a clean system make. The Linux kernel has around 2 million lines of code and takes 10 minutes to compile (on my PII300.) It takes 90 minutes to compile X, so lets be conservative and say that X is 10 million lines of code. That is 12 million lines right there. GNOME takes almost as long as X to compile, so lets estimate another 8 million lines there. (I'm hugely low balling it.) That is around 20 million lines of code. With QT/KDE (which is almost required for the GNOME-faithfull to run cool apps like KDevelop), that climbs to 25-30 million lines. That is nearly as much as Windows 2K (only 3-5 million lines less). In comparison, BeOS is a sevelte 1.5 million lines for the entire OS. Don't belive me, root around the /boot/beos/system directory some time. The kernel is about 700K, the servers about 3.5 meg, the drivers are less than 500K(it loads drivers dynamically) and deskbar and tracker are about 2.5 meg. In total, the entire /boot/beos/system directory is 36 meg which incluldes all libraries, codecs, kernel add ones, unused drivers, etc. It is easy to see why. BeOS doesn't have nearly as much crap in it as Linux does. Take the whole KDE/GNOME/X thing. If someone runs KDE 2 and GNOME 2, they will have a total of two large cobra implementations, three drag and drop protocols, three print servers, three+ widget sets, dozons of critical libraries, and an ass-load of duplicated functionality. Choice is good, bloat is bad. This is why Linux cries out for standardization. Why cannot a Linux-wide COBRA implementation be used? Is the one time loss of a little bit of programming flexibility (face it, GNOME and KDE do the same thing. For the programmer, it is just an API preference.) worth the extra 30 meg loss in memory? Is it really necessary to have a seperate GNOME print architecture, or for Qt and GTK+ not to be binary compatible? How exactly is GNOME different from KDE aside from ascthetics(namely that until 2.0 the KDE people had none)? Sure there are some architecture differences, but to the app, they provide basically the same services with the same features. I don't begrudge people flexibility. I just think that Linux is becoming increasingly bloated, and people aren't taking any steps to curb it. It would be really nice if someone would define a standard set system of objects, (or function calls, no-one cares) that could be implemented by and DE and widget set of the users choice. Now THERE is smart flexibility.
PS: I know flamers won't read this far before responding, but I'll try anyway. Don't say that Linux is so flexible you can leave these things out. If you want a modern feature-rich desktop OS, at the moment, KDE and GNOME are the only players. Until KDE 2.0 becomes stable, the situation is even worse, because GNOME has a better environment, while KDE has better apps.
Why are OpenSource development tools the RightWay? Don't you people care about funtionality? I get Visual C++ for an absurdly low student discount, and I greatly prefer it to using KDevelop, because frankly, VisualC++ is much better. I also prefer the MS compiler to gcc because it optimizes my code better! If you like the OpenSource ideal above all else, then an open compiler is the RightWay (TM) for YOU. If you like speed and functionality above all else, and the most funtional at the moment is a closes source app, then that app is the RightWay(TM) for you. I frankly don't like Linux, for example. It has a nice community, a nice development model, but it just rubs me the wrong way. I do, however, see why lots of people like it. I agree that the RightWay(TM) is whatever works for them. Linux, BSD, BeOS, whatever, they are all the RightWay(TM) if they work the RightWay(TM) for you.
I meant "can't" and I know it!
The whole "it's OpenSource it can be anything" spiel is a little trite. You can really change Linux to be a new type of OS without having to start from scratch. Linux is a UNIX and always will be, no matter how much jiggering people do with it. At best, the OSS license will allow people to cannibalize parts of it for the new OS.
Tracker is Open Source is under a BSD-style license. Go write a FM for that!
I know DCOM isn't that great. I, personally, think distributed interfaces are retarded in this day and age of huge bandwidth networks and massive local storage, but hey, to each his own, right? I do concede that COBRA is better for distributed objects, but I dislike that fact that it has so much bloody overhead.
You haven't used DirectX have you. It is direct access to hardware in a HARDWARE INDEPENDANT WAY. You can write perfectly portable software (between hardware, OSs, CPUs, and what-not) using an API that allows direct access to hardware.
Excuse me? Full easier than 3D video? Maybe in Linux, where the extent of 3D sound is multiple channels, but in windows you have cards that do occulsion, reflections, reverb, etc. For some parts of A3D 2.0, you even have to feed it your vertex data so it can calculate oculsions and what-not.
I wasn't talking about the actual test. I was talking about the line where they say there will be a battle between Linux and windows over which is the best gaming experiance.
Quake 3 uses direct X for everything except 3D. Thus, Quake never actually makes very many Windows calls, most of its calls are to DirecX. Thus the game is actually running on DirectX, rather than Windows, which merely provides some window and process management code. This specific test may have sound turned off, but the battle between Linux and Windows definatly won't. (You play your games with sound off?) They talk of Linux becoming as good of a gaming experiance as Windows. Unless it gets something like DirectX, it won't.
PS: Repeat after me, SDL is not a full-fledged media system. It is merely a wrapper API for native high-performance APIs. Also, DirectX does not preclude OpenGL. It merely keeps you from using DirectDraw. In addition, SDL graphics functions don't work with OpenGL either. This is a big difference compared to D3D where you can render into a hardware buffer, directly write in it with DirectDraw, and use the whole thing as a source texture for some 3D object.
Linux allows you to open /dev/dsp, but that precludes using advanced features present in saw ALSA or OpenAL or whatever.
I knew about DGA, but it doesn't hold a candle to DDraw in terms of features. The big problem is that it is a bunch of disparate APIs, so extending it to include this nifty features is difficult. Take for example, the cool trick of rendering directly into a texture surface, drawing on it through a pointer to memory, than mapping it to a 3D object. Without a lot of reworking between DRI, DGA, and OpenGL, this will be impossible under Linux.