Face it, procs are going to use more heat. Why NOT run your proc at 1.3 GHz. A fan costs maybe $10-$15, and I'd pay that for the extra 350MHz. As long as there are no stability concerns (and there don't seem to be any) what's the problem? Also, as far as I can tell, the Athlon uses significantly more power and makes a lot more heat than a PIII. The increased heat and power usage of CPUs are a unilateral trend. Witness those Alphas that take nearly 90 watts of power! I doubt a UltraSparc takes less current than a PIII. In fact, in power/heat department Intel isn't the worst.
Actually, ATX has done a lot to help cool off the CPU. (It turns the thing so that the CPU is closer to the power supply fan.) Also, due to the reorganization, ATX boards usually can fit more PCI slots than baby-AT boards.
No, I understand that the driver didn't work for you. I understand why you don't use it, why would anybody want to use something with a VESA driver? My point was that you justified BeOS being difficult to use due to the whole "8 zillion menus" to copy the file. I was just saying you can do it through the CLI as well. If you had spent a little more time with BeOS, you'd also realize that almost any CLI thing you can do with Linux you can with BeOS, that includes a lot of configuration stuff.
As for the modules.conf bit, installing most drivers under Linux require editing modules.conf (including the NVIDIA driver.) I realize graphics drivers don't usually require editing modules.conf, I was speaking more about drivers in general.
Slashdot seems to have anti-Intel mania! Let's see, how may chips HAVEN'T required new cases? Upgrading from socket7 -> Slot 1 usually took a new power supply, 486-> Pentium did too (AT -> ATX) and for my Dell 300MHz, upgrading to an Athlon is going to require a new case and power supply as well. (Dell makes very small power supplies.) Seriously, though, it's not Intel's fault. You're complaining that a 1.5GHz chip takes more power. Well, duh! Most Athlon upgrades take more power too. As for the extra power connecters, at 1.5+GHz, there are probably too many electrical concerns to not put them in. The screws probably can't be helped either. This sucker is going to make a lot of heat, and I don't think Intel wants another Slot1 fiasco (chips flopping out of the slot.) AMD's new Athlons aren't going to be any better, in fact, at.15micron (compared to.13 micron) they're going to make even more heat (Athlon's do anyway) and use more current than the P4.
Well, hardware support is always a problem on an alternate OS. The reason that stuff in X (even if it's not supported directly) is often accelerated is because it often uses the same or compatible chip as another card. For example, the NVIDIA drivers for X will work on my Creative TNT because it uses the same chip. Similarly, a Riva128ZX will work even though it's not explicitly support. However, you have to remember one thing. BeOS doesn't have nearly the community that Linux does. Linux developers have had 5 or 7 years to work on driver for X. BeOS Intel in the form we know it has only been out for maybe 3. It also has a much smaller userbase. Who cranks out the drivers for X? The X user community? Who makes drivers for BeOS? Though there are several drivers made by the community, most people depend on Be. The BeOS driver API is open, stable, and pretty easy. There's tons of sample code. So the best way to get a driver on BeOS is the same as it is on X. Go and code it. Go gather a team to write those drivers.
I really don't know what everyone is complaining about. True, I've only been programming DirectX for two or three years, and I've done nothing on as large as commercial game, but to me, it's really not that bad. The fact that it was the first major API I learned helps, but I don't see how that would help much. I have a good feeling that a lot of programming comments are aimed at the early versions of DirectX and Direct3D in particular. Back when execute buffers were the only way, and when it was crap (before version 6.) I, however, don't find programming DirectDraw much hardware than BDirectWindow, and DirectSound is easy compared to ALSA. I don't do any Direct3D programming, prefering OpenGL all the way (mainly because I can use it on BeOS), but what little I've done wasn't too hard. Maybe it's just the mindset. As far as I can recall, Andre LaMothe recommends syncing frame-rate based on a timer (in his Guru book), so I don't know if he is terribly "in tune" with the latest games. Maybe it's just mindset. I find Linux maddening to program, so maybe it's whatever you learned first.
Windows rarely has problems with load. A can almost guarentee you that a DirectX exclusive mode program will have fewer load problems under Windows simply because it gets Windows out of the way. I think Alex St. John said that about 80% of the code in DirectX is devoted to shoving Windows out of the way. The resultant "OS" isn't very powerful, but fast as hell.
There are several reasons why Linux is very far away from the gaming/consumer arena.
1) It's still hard. No matter what people try to tell you, nothing in Linux is yet easier than doing nothing while BeOS automatically configures your hardware, or putting in a disk when Windows queries your hardware. Sure there are special cases when everything "just works," but Linux plug & play is easily years behind Windows. Case in point: Mandrake (a quite standard newbie Linux distro) doesn't detect my graphics card correctly (a RivaTNT, a quite common card), and makes me supply irq's and DMAs for my AWE64 (again a quite common card.) Then there is installation of new hardware. One point everyone seems to miss is that most new hardware is not supported by the stock kernel. Right now, USB is poorly supported as is Firewire, and for devices that ARE supported, the driver installation is ridiculous. For good modular driver installation, take a cue from BeOS. Drag the driver into the appropriate directory, and it's used automatically. In Linux, the same process is significantly harder. Wheras my ALSA driver install should simply consist of dragging driver to the appropriate place, it instead consists of editing modules.conf with a dozen (poorly documented) commands and supplying IRQs and DMAs. Not acceptable. Then there is the issue of binary drivers. As long as there is no standard driver API, you'll never get driver disks that you can just plug in and have work. Sure OSS is great, but encouraging binary driver is a GOOD thing. The thing most people forget is that OSS drivers have to be COMPILED. A lack of a binary API does more than encourage OSS driver, it makes it impossible to distribute binary drivers (with available source to make you OSS-zealots happy.) Again, unnacceptable.
2) The desktop still isn't up to par. It isn't yet as easy to use as Windows, much less MacOS. People say, "well, GNOME is CLOSE to Windows!" Since when does being as good as Windows count for anything?
3) It isn't as cutting edge. Think about this one. The entire Linux community as an annoying habit of staying with old technologies. Take XFree 4.0. You can't say that Linux has an easy to install graphical system and good 3D hardware acceelration in the same breath. It has the former (XFree86 3.3.6) and it has the latter (XFree86 4.0) but the two are mutually exclusive. Any new and cool technology (DVD, 3D, ALSA, journaling fs) is most often NOT in the standard distro. Thus, you can say that Linux has these technologies, and you can say it's easy to install, but not in the same sentence. By the time the standard distros get on the ball, newer technologies are out.
4) It is light on the gaming features deparment. Face it, people rarely use Linux just for the hell of using a non-MS OS. People use it because it's better. In the gaming arena, it is not better. It's still slower, it's still harder to use (installing Quake is nowhere near as easy on Linux as it is on Windows) and it still doesn't have all the features that have been standard for awhile on Windows. It doesn't have 3D sound, it doesn't have force feedback, it has limited support for 3D cards, and it doesn't have many of the nifty features present in DirectX. It doesn't even have autoplay!
5) It doesn't have DirectX. DirectX is often underestimated by the/. crowd. The base their opinion of it on it's closed nature, it's speed in version 3, it's difficulty of programming in version 1. I'm here to tell you that DirectX is fast, stable, easy, and incredibly flexible. Given the flexibility of UNIX, a technology like DirectX should be a shoe-in for something to implement on Linux. Besides Direct3D (btw, which has several advantages over OpenGL, read my rant on OSOpinion.com entited "Is OpenGL in trouble?") there are many cool things in DirectX. Take DirectInput. It is a very flexible mechanism that supports everything from 4 button joypads to cybersex body suits. The whole point behind it is to support controllers of all types in a uniform and easy manner. Or take DirectPlay. It's a mechanism that allows games to communicate without paying attention to the underlying protocol. For someone who has been often frustrated by games that support only IPX and your network is TCP, or vice versa, it is a very cool technology. This is the kind of thinking behind UNIX that is should be as flexible and useful as possible. That's the whole reason UNIX treats everything as a file or why pipes and I/O redirection works so well. Take DirectSound and DSound3D. Currently, not even ALSA offers as much control over the sound process as these two APIs. Then take Direct Music. For a big fan of MIDI (my midi collection is in the hundreds of megs) it's very cool. It allows you to dynamically compose musical scores depending on the situation in the game. Pipe that through DirectSound3D and you've got aureal heaven. Sure DirectX is a little complex to program (not any more so than X, the paradigm is just different), and you can get yourself in trouble if you don't know what your doing (as you can in UNIX as well) but used correctly it really improves the gaming experiance. Linux nor any other OS as anything like it. BeOS and UNIX come close in the graphics department, and BeOS has something similar in the network deparment (though it only supports TCP/IP at the moment) but nothing (without specialized libraries of course) comes close in the input and sound department. Those who think SDL cuts it totally don't get it.
Linux will undoubtedly improve. However, from a pragmatic standpoint, Windows is a better gaming OS. Gamers reboot their machines every thing, and don't need the raw stability of Linux. For those who have used Windows NT or Win2K, stability isn't even an issue. A ten or twenty day uptime may be ridiculous for a sever, but for a workstation or desktop use it's fine. Windows will continue to be a better gaming OS for quite some time as well. So far, OpenAL is nowhere near completion. OpenGL doesn't have a new version in sight, and D3D 8 already beats it in features. There are no planned overhauls of the X input API. Undoubtedly they will come, but I've got a feeling it will be years until I can set up a Linux partition and get a better gaming experiance that I do in Windows.
Before you try to hang HP for this, think about why they might do this. The Linux in the hardware is a known quantity. They can support it without problems, it doesn't change, etc. Windows is also a known quantity. Windows NT Service Pack 6a is a certain set of libraries and executables. There may be other software issues, but the majority of stuff is standard. However, Linux is NOT a known quantity. It's would be hell for a general purpose support staff to support. Which distro, which kernel, which patches, which glibc, which utilities? The fact that the kernel upgrade notes list a dozen and a half required versions of certain software is indicitive of this. For Windows, a support person (or a piece of software like Internet Explorer) can say, okay, make sure you have Service Pack 6a installed to use this. In the Linux arena, they either have to support a specific distribution (the stock version of RedHat 6.1) or else deal with a support nightmare of trying to make sure everybody is on the same page. It makes a lot of sense for HP to not support Linux as a client under these circumstances.
If you look at the benchmarks, GTS's FSAA is faster than V5's FSAA. However, quality is subjective so I won't go there. If you want to see really cool FSAA in action, get yourself an N64. The thing has a measly single 60MHz graphics proc but has been pumping out full-screen anti-aliased images for the last 5 years.
Aqua isn't just pretty. Aqua/Quartz is a full-fledged DPDF engine with all it's attendant benifets. I'm guessing that Aqua didn't take very long (for a window manager.) The meat of the time was developing Darwin and Quartz. OS X should not have shipped without Quartz, and thankfully it didn't. Besides, as far as I can tell, the core stuff (Darwin, Quartz) were ready long before Aqua was put into place.
Actually, it seems that Linux software ports over real quick. Photon seems to have a layer that allows X apps to use Photon. I do know that GTK was ported over very quickly, and since it's POSIX complient, most apps should compile out of box. Not to mention the fact that it's going to get a port of lxrun.
Binary Standard: The BeOS driver API has changed a couple of times. Apparently the only place where there are "hacks" to load drivers with older versions are in the module loader.
Modules.conf: Nearly everything can be figured out. BeOS configures my soundcard totally without my help. Linux doesn't. BeOS detects my two network cards and just asks me for IPs. Linux (Slackware 7.1) will only detect one card and I've got to edit modules.conf by hand. To install ALSA I even have to tell modules.conf how many cards to support! That's ridiculous.
Detection: Again, installers can't do everything. A lot of people DO install their own hardware. And those people aren't necessarily all UNIX gurues. The problem is that under Windows, it's plug it in, insert driver disk. (90% of the time.) Under Linux, it's plug it in, then do all sorts of hardware dependant (installing a vid card is different from installing a sound card) stuff to get it running.
Okay, show me how to configure X windows automatically on Mandrake 7.1. (On my TNT, a damn common card, it don't work.) Show me how I can configure my soundcard in RedHat 6.2 without looking up my IRQs and DMAs (I've got an AWE64, again, a very common card.) Show me how Slackware 7.1 can install my two network cards (something that doesn't work on Mandrake either, they only detect one) without me editing modules.conf.
Okay, fine. If you're one of the 3 people still playing Glide games, then okay, you'd be an idiot not to by a V5. Otherwise, if whether or you run Linux or Windows, use D3D or OpenGL, then NVIDIA is the better choice.
Huh? Not according to Anandtech. Supposedly V5 FSAA is slightly better, but it doesn't "blow it away." (Look at the screens for yourself.) And it certainly doesn't blow it away in performance. In fact, GeForce2 GTS's 4x HI quality performance is close to V5's 2x performance. The article is here
http://www.anandtech.com/showdoc.html?i=1288.
You know, they really don't give a fuck what the OSS contingent thinks. Most people don't give a fuck what the OSS contingent thinks. They won't miss the money of the few hundred (or even thousand) OSS zealots who want OSS everything. Not when Dell, Compaq, HP and other are using NVIDIA cards in their systems. Not when NVIDIA cards are the most popluar and highest performing. The mainstream consumers won't care, they'll just buy what they want. That leaves the OSS-zealots without any support and with crappy graphics cards.
Slashdot Mirror
Most LX boards are ATX. In fact, I can remember ATX boards being common for the later socket 7 boards.
Face it, procs are going to use more heat. Why NOT run your proc at 1.3 GHz. A fan costs maybe $10-$15, and I'd pay that for the extra 350MHz. As long as there are no stability concerns (and there don't seem to be any) what's the problem? Also, as far as I can tell, the Athlon uses significantly more power and makes a lot more heat than a PIII. The increased heat and power usage of CPUs are a unilateral trend. Witness those Alphas that take nearly 90 watts of power! I doubt a UltraSparc takes less current than a PIII. In fact, in power/heat department Intel isn't the worst.
Actually, ATX has done a lot to help cool off the CPU. (It turns the thing so that the CPU is closer to the power supply fan.) Also, due to the reorganization, ATX boards usually can fit more PCI slots than baby-AT boards.
No, I understand that the driver didn't work for you. I understand why you don't use it, why would anybody want to use something with a VESA driver? My point was that you justified BeOS being difficult to use due to the whole "8 zillion menus" to copy the file. I was just saying you can do it through the CLI as well. If you had spent a little more time with BeOS, you'd also realize that almost any CLI thing you can do with Linux you can with BeOS, that includes a lot of configuration stuff.
As for the modules.conf bit, installing most drivers under Linux require editing modules.conf (including the NVIDIA driver.) I realize graphics drivers don't usually require editing modules.conf, I was speaking more about drivers in general.
It was metaphorical.
cp savage_driver.so /boot/home/config/add-ons/accelerants.
Wow, that was so much harder than configuring modules.conf!
Slashdot seems to have anti-Intel mania! Let's see, how may chips HAVEN'T required new cases? Upgrading from socket7 -> Slot 1 usually took a new power supply, 486-> Pentium did too (AT -> ATX) and for my Dell 300MHz, upgrading to an Athlon is going to require a new case and power supply as well. (Dell makes very small power supplies.) Seriously, though, it's not Intel's fault. You're complaining that a 1.5GHz chip takes more power. Well, duh! Most Athlon upgrades take more power too. As for the extra power connecters, at 1.5+GHz, there are probably too many electrical concerns to not put them in. The screws probably can't be helped either. This sucker is going to make a lot of heat, and I don't think Intel wants another Slot1 fiasco (chips flopping out of the slot.) AMD's new Athlons aren't going to be any better, in fact, at .15micron (compared to .13 micron) they're going to make even more heat (Athlon's do anyway) and use more current than the P4.
Well, hardware support is always a problem on an alternate OS. The reason that stuff in X (even if it's not supported directly) is often accelerated is because it often uses the same or compatible chip as another card. For example, the NVIDIA drivers for X will work on my Creative TNT because it uses the same chip. Similarly, a Riva128ZX will work even though it's not explicitly support. However, you have to remember one thing. BeOS doesn't have nearly the community that Linux does. Linux developers have had 5 or 7 years to work on driver for X. BeOS Intel in the form we know it has only been out for maybe 3. It also has a much smaller userbase. Who cranks out the drivers for X? The X user community? Who makes drivers for BeOS? Though there are several drivers made by the community, most people depend on Be. The BeOS driver API is open, stable, and pretty easy. There's tons of sample code. So the best way to get a driver on BeOS is the same as it is on X. Go and code it. Go gather a team to write those drivers.
PS> BeOS hard to use? What planet are you from?
What directory did you install it to, and what version of BeOS are you using. On 5.0, you have to install it to a different directory than in 4.5
It's here
I really don't know what everyone is complaining about. True, I've only been programming DirectX for two or three years, and I've done nothing on as large as commercial game, but to me, it's really not that bad. The fact that it was the first major API I learned helps, but I don't see how that would help much. I have a good feeling that a lot of programming comments are aimed at the early versions of DirectX and Direct3D in particular. Back when execute buffers were the only way, and when it was crap (before version 6.) I, however, don't find programming DirectDraw much hardware than BDirectWindow, and DirectSound is easy compared to ALSA. I don't do any Direct3D programming, prefering OpenGL all the way (mainly because I can use it on BeOS), but what little I've done wasn't too hard. Maybe it's just the mindset. As far as I can recall, Andre LaMothe recommends syncing frame-rate based on a timer (in his Guru book), so I don't know if he is terribly "in tune" with the latest games. Maybe it's just mindset. I find Linux maddening to program, so maybe it's whatever you learned first.
Windows rarely has problems with load. A can almost guarentee you that a DirectX exclusive mode program will have fewer load problems under Windows simply because it gets Windows out of the way. I think Alex St. John said that about 80% of the code in DirectX is devoted to shoving Windows out of the way. The resultant "OS" isn't very powerful, but fast as hell.
Of course this didn't get on Slashdot. There is an article on 3D Action Planet regarding BeOS as a gaming platform. You can find it here
There are several reasons why Linux is very far away from the gaming/consumer arena.
/. crowd. The base their opinion of it on it's closed nature, it's speed in version 3, it's difficulty of programming in version 1. I'm here to tell you that DirectX is fast, stable, easy, and incredibly flexible. Given the flexibility of UNIX, a technology like DirectX should be a shoe-in for something to implement on Linux. Besides Direct3D (btw, which has several advantages over OpenGL, read my rant on OSOpinion.com entited "Is OpenGL in trouble?") there are many cool things in DirectX. Take DirectInput. It is a very flexible mechanism that supports everything from 4 button joypads to cybersex body suits. The whole point behind it is to support controllers of all types in a uniform and easy manner. Or take DirectPlay. It's a mechanism that allows games to communicate without paying attention to the underlying protocol. For someone who has been often frustrated by games that support only IPX and your network is TCP, or vice versa, it is a very cool technology. This is the kind of thinking behind UNIX that is should be as flexible and useful as possible. That's the whole reason UNIX treats everything as a file or why pipes and I/O redirection works so well. Take DirectSound and DSound3D. Currently, not even ALSA offers as much control over the sound process as these two APIs. Then take Direct Music. For a big fan of MIDI (my midi collection is in the hundreds of megs) it's very cool. It allows you to dynamically compose musical scores depending on the situation in the game. Pipe that through DirectSound3D and you've got aureal heaven. Sure DirectX is a little complex to program (not any more so than X, the paradigm is just different), and you can get yourself in trouble if you don't know what your doing (as you can in UNIX as well) but used correctly it really improves the gaming experiance. Linux nor any other OS as anything like it. BeOS and UNIX come close in the graphics department, and BeOS has something similar in the network deparment (though it only supports TCP/IP at the moment) but nothing (without specialized libraries of course) comes close in the input and sound department. Those who think SDL cuts it totally don't get it.
1) It's still hard. No matter what people try to tell you, nothing in Linux is yet easier than doing nothing while BeOS automatically configures your hardware, or putting in a disk when Windows queries your hardware. Sure there are special cases when everything "just works," but Linux plug & play is easily years behind Windows. Case in point: Mandrake (a quite standard newbie Linux distro) doesn't detect my graphics card correctly (a RivaTNT, a quite common card), and makes me supply irq's and DMAs for my AWE64 (again a quite common card.) Then there is installation of new hardware. One point everyone seems to miss is that most new hardware is not supported by the stock kernel. Right now, USB is poorly supported as is Firewire, and for devices that ARE supported, the driver installation is ridiculous. For good modular driver installation, take a cue from BeOS. Drag the driver into the appropriate directory, and it's used automatically. In Linux, the same process is significantly harder. Wheras my ALSA driver install should simply consist of dragging driver to the appropriate place, it instead consists of editing modules.conf with a dozen (poorly documented) commands and supplying IRQs and DMAs. Not acceptable. Then there is the issue of binary drivers. As long as there is no standard driver API, you'll never get driver disks that you can just plug in and have work. Sure OSS is great, but encouraging binary driver is a GOOD thing. The thing most people forget is that OSS drivers have to be COMPILED. A lack of a binary API does more than encourage OSS driver, it makes it impossible to distribute binary drivers (with available source to make you OSS-zealots happy.) Again, unnacceptable.
2) The desktop still isn't up to par. It isn't yet as easy to use as Windows, much less MacOS. People say, "well, GNOME is CLOSE to Windows!" Since when does being as good as Windows count for anything?
3) It isn't as cutting edge. Think about this one. The entire Linux community as an annoying habit of staying with old technologies. Take XFree 4.0. You can't say that Linux has an easy to install graphical system and good 3D hardware acceelration in the same breath. It has the former (XFree86 3.3.6) and it has the latter (XFree86 4.0) but the two are mutually exclusive. Any new and cool technology (DVD, 3D, ALSA, journaling fs) is most often NOT in the standard distro. Thus, you can say that Linux has these technologies, and you can say it's easy to install, but not in the same sentence. By the time the standard distros get on the ball, newer technologies are out.
4) It is light on the gaming features deparment. Face it, people rarely use Linux just for the hell of using a non-MS OS. People use it because it's better. In the gaming arena, it is not better. It's still slower, it's still harder to use (installing Quake is nowhere near as easy on Linux as it is on Windows) and it still doesn't have all the features that have been standard for awhile on Windows. It doesn't have 3D sound, it doesn't have force feedback, it has limited support for 3D cards, and it doesn't have many of the nifty features present in DirectX. It doesn't even have autoplay!
5) It doesn't have DirectX. DirectX is often underestimated by the
Linux will undoubtedly improve. However, from a pragmatic standpoint, Windows is a better gaming OS. Gamers reboot their machines every thing, and don't need the raw stability of Linux. For those who have used Windows NT or Win2K, stability isn't even an issue. A ten or twenty day uptime may be ridiculous for a sever, but for a workstation or desktop use it's fine. Windows will continue to be a better gaming OS for quite some time as well. So far, OpenAL is nowhere near completion. OpenGL doesn't have a new version in sight, and D3D 8 already beats it in features. There are no planned overhauls of the X input API. Undoubtedly they will come, but I've got a feeling it will be years until I can set up a Linux partition and get a better gaming experiance that I do in Windows.
Before you try to hang HP for this, think about why they might do this. The Linux in the hardware is a known quantity. They can support it without problems, it doesn't change, etc. Windows is also a known quantity. Windows NT Service Pack 6a is a certain set of libraries and executables. There may be other software issues, but the majority of stuff is standard. However, Linux is NOT a known quantity. It's would be hell for a general purpose support staff to support. Which distro, which kernel, which patches, which glibc, which utilities? The fact that the kernel upgrade notes list a dozen and a half required versions of certain software is indicitive of this. For Windows, a support person (or a piece of software like Internet Explorer) can say, okay, make sure you have Service Pack 6a installed to use this. In the Linux arena, they either have to support a specific distribution (the stock version of RedHat 6.1) or else deal with a support nightmare of trying to make sure everybody is on the same page. It makes a lot of sense for HP to not support Linux as a client under these circumstances.
If you look at the benchmarks, GTS's FSAA is faster than V5's FSAA. However, quality is subjective so I won't go there. If you want to see really cool FSAA in action, get yourself an N64. The thing has a measly single 60MHz graphics proc but has been pumping out full-screen anti-aliased images for the last 5 years.
Aqua isn't just pretty. Aqua/Quartz is a full-fledged DPDF engine with all it's attendant benifets. I'm guessing that Aqua didn't take very long (for a window manager.) The meat of the time was developing Darwin and Quartz. OS X should not have shipped without Quartz, and thankfully it didn't. Besides, as far as I can tell, the core stuff (Darwin, Quartz) were ready long before Aqua was put into place.
Or why not just memorize which button does what? I haven't looked at the button's shapes since, oh, 5 minutes after installing Windows 3.1
Actually, stuff like Photoshop can use the second proc. MacOS isn't single processor, it just doesn't use them very well.
Actually, it seems that Linux software ports over real quick. Photon seems to have a layer that allows X apps to use Photon. I do know that GTK was ported over very quickly, and since it's POSIX complient, most apps should compile out of box. Not to mention the fact that it's going to get a port of lxrun.
Binary Standard: The BeOS driver API has changed a couple of times. Apparently the only place where there are "hacks" to load drivers with older versions are in the module loader.
Modules.conf: Nearly everything can be figured out. BeOS configures my soundcard totally without my help. Linux doesn't. BeOS detects my two network cards and just asks me for IPs. Linux (Slackware 7.1) will only detect one card and I've got to edit modules.conf by hand. To install ALSA I even have to tell modules.conf how many cards to support! That's ridiculous.
Detection: Again, installers can't do everything. A lot of people DO install their own hardware. And those people aren't necessarily all UNIX gurues. The problem is that under Windows, it's plug it in, insert driver disk. (90% of the time.) Under Linux, it's plug it in, then do all sorts of hardware dependant (installing a vid card is different from installing a sound card) stuff to get it running.
Okay, show me how to configure X windows automatically on Mandrake 7.1. (On my TNT, a damn common card, it don't work.) Show me how I can configure my soundcard in RedHat 6.2 without looking up my IRQs and DMAs (I've got an AWE64, again, a very common card.) Show me how Slackware 7.1 can install my two network cards (something that doesn't work on Mandrake either, they only detect one) without me editing modules.conf.
Okay, fine. If you're one of the 3 people still playing Glide games, then okay, you'd be an idiot not to by a V5. Otherwise, if whether or you run Linux or Windows, use D3D or OpenGL, then NVIDIA is the better choice.
Okay, 40MB of effective RAM at highest res!
Huh? Not according to Anandtech. Supposedly V5 FSAA is slightly better, but it doesn't "blow it away." (Look at the screens for yourself.) And it certainly doesn't blow it away in performance. In fact, GeForce2 GTS's 4x HI quality performance is close to V5's 2x performance. The article is here
http://www.anandtech.com/showdoc.html?i=1288.
You know, they really don't give a fuck what the OSS contingent thinks. Most people don't give a fuck what the OSS contingent thinks. They won't miss the money of the few hundred (or even thousand) OSS zealots who want OSS everything. Not when Dell, Compaq, HP and other are using NVIDIA cards in their systems. Not when NVIDIA cards are the most popluar and highest performing. The mainstream consumers won't care, they'll just buy what they want. That leaves the OSS-zealots without any support and with crappy graphics cards.