OS-X fonts look good to some people because, in general, Quartz renders the desktop quite softly. In reality, OS-X's font subsystem is rather low tech, it lacks hinting, gamma correction, etc. You can read all about it on the XRender mailing list. Personally, I don't like OS-X's fonts, but that's just me.
Linux fonts are great! If you take the high quality TrueType fonts from your Windows partition, Freetype2 renders the text extremely sharply. The only renderer I've seen that is better than FT2 is BitStream's FontFusion (found in QNX RtP) and the only reason I like it better is because it is less heavy-handed with the anti-aliasing. Certainly, FT2 blows away Windows' font rendering. Compare Arial in FT2 to Arial in XP, and you'll notice that FT2 renders the text visibly more clearly.
A) No ntoskrnl.exe, true, but as for the C compiler, there's always GCC.
B) I switched from Windows to Linux, even though Linux's GUI sucks more, just because I dispise Microsoft and don't mind Linux. Yet, I don't for one minute doubt that Windows is just as capable a developer machine as anything based on Linux. Xp is rock-solid stable, fast (compared to GNOME or KDE!), and thanks to GNU and Cygwin, has all the CLI tools you could possibly want. There are a lot of reasons to like Linux, but pretending there is something (desktop, not server) you can do in Linux that you can't in Windows is just dumb.
You "play for gameplay" yet you play UT? Wow. And besides, support for older machines is no excuse. First, UT doesn't run well on old machines anyway. Yet, Quake III, with all its curved-surface niceness runs fine on my PII-300. Second, LOD mesh technology has been around for years. Messiah, for example, could vary the polygon count of the scenes depending on what the machine could handle at a given point in the game. That way slow machines would get reduced graphics, while fast machines would get great graphics.
Honestly, these graphics are SO 1998! Maybe I'm spoiled by the PS2, but you'd think with all the GeForce 3 power they have at their disposal, they'd use some curved surfaces in the levels. The maps (especially the Egypt one in the screenshots) look like they were drawn by a six-year old with a demo version of 3D Studio that was limited to 100 polygons.
A) Itanium isn't RISC. Its a VLIW chip.
B) x86 chips are really hybrid RISC/CISC. Almost all modern x86 processors translate x86 operations into RISC micro-operations.
C) x86 maybe be stuck in the 1980s, but a 2GHz P4 comes within spitting distance of a 1GHz Alpha in most benchmarks, and its tons cheaper. The Alpha's a great architecture (really, really clean!) but GHz is GHz.
A little bit of history. The reason, in fact, that it is called QNX (instead of Qunix, which it used to be called) was because they didn't have a license for the word UNIX. Thus, its debatable whether QNX could be not called a UNIX. If QNX isn't a UNIX because it doesn't have the trademark, then neither Linux nor BSD are UNIX. If QNX isn't a UNIX because its a microkernel, than OS-X isn't a UNIX.
PS> QNX isn't GUI-only. Photon runs as a seperate process.
While that's true, its not a bad ballpark figure. I can feel the difference between a 5400RPM drive and a 7200RPM drive just sitting at a computer and using it. In general, drives with faster RPM tend to have higher-bit densities anyway (they're newer), so it gives a rough indicator that's easy to understand.
There's no point. C# is a good language, and just because Microsoft made it doesn't make it bad. What's wrong with using an already-developed standard to create an open, free implementation?
Actually, with modem connections, smaller files are a pain in the ass. The thing is that most of the packages are *required* dependencies. Instead of just starting a big transfer and leaving it on overnight, you have to deal with starting many different file transfers, which is quite a risk on many modem connections.
XFS is not the best example of Linux's modularity. In order to make Linux suitable for massive filesystem needs, it has to touch a lot of the core VFS code that filesystems don't usually touch. Even in a microkernel, something like XFS would conflict with the core semantics of the fileserver (equivilant to the VFS) and the problem would still be there, just in a different place. A better example of modular filesystems is JFS, which is just a drop-in install in Linux.
I would have to disagree. The kernel could easily provide services that would provide memory mapping to the driver. I don't see why not. In fact, with proper protection mechanisms in place there's no reason why any user app should not be able to figure out real memory addresses. I don't think that would be ugly.
>>>>
It would be quite ugly. There are several problems that crop up. First, each driver would have to dynamically map pieces of process address space into its own space during execution (paltry 4GB address space on x86). To do that, you not only have to make a round-trip to the kernel, but you have to mess with the process address space (which involves an AVL-tree lookup and attempts to merge regions). The kernel doesn't have to do this, because whenever a system call is invoked, the current process's address space is already mapped. Then there is the fact that it becomes a pain to manage all those shared mappings. There can easily be hundreds of processes in the system, and multiple drivers processes would have to map each one. Managing that many shared mappings quickly becomes very messy (and very dangerous, due to the extensive sharing of memory).
Dude. 120GB HDs are only $200 on Pricewatch. Given the 8 IDE channels you can have on a standard PC (anything with IDE-RAID) a terabyte machine is less than $1600 away! Given the dirt cheap price of other components, you can put that together that machine for less than $4000!
Dude, I know that. I also know that most OSs for x86 set the segments up once and then leave them alone forever after that. Changing the segment registers is expensive.
>>>>>
I know. And a modern x86 OS has to do it on every system call and every interrupt. That's why syscalls are so dreadfully slow on x86.
Context switches are expensive enough as it is; changing the segment setup during context switch would make them even more expensive.
>>>>
Linux has to do it anyway. When the timer interrupt occurs, the chip loads CS with the kernel code selector and the timer code loads DS with the kernel data selector.
On the one hand, we have Linux, a monokernel that works. On the other hand, there are microkernels that work (and HURD will work someday I am sure). Your proposal is somewhere in the middle, and it would work too. I shouldn't like to guess in what ways it would be better or worse. Maybe you can find some students in University to do a project using your design and see how it goes.
>>>>>>>
See, the problem is that I don't know of any existing hardware that does this. There are projects out there that try this with x86 segmentation, but they are limited by the fact that selector switches are slow. I don't know of anything (which was why I was asking) that meshes multiple protection levels with a paging-based mechanism.
True, but entirely beside the point. I wasn't saying that we should go back to segmentation. I was pointing out that segments have a nice property that the privlege level of the code is based on the address of the code, and that property would be useful (even in a paging based mechanism) in getting a better protection system.
Re:microkernels may be the way out
on
Hurd: H2 CD Images
·
· Score: 1, Redundant
Of course it would. But the different parts of it (drivers, file systems, personalities, distributed shared memory, clustering, video support, VM strategies, etc.) could be developed and tested by different developers, independently. With the Linux architecture, almost everything goes through the bottleneck of the Linux kernel developers, and it just isn't working in practice: important functionality takes years to make it into the kernel. It's not for lack of effort or dedication, it's the architecture and lack of modularity.
>>>>>>>>
Umm, read kernel traffic sometime. The "Linux kernel developers" are a very large and diverse group of people. They're not some committe that rules the kernel by fiat. That's Linus's job, as well it should be. He ultimately gets to decide what goes into the kernel, and making it a microkernel (say, moving the VM to a seperate process) would not make things any different. Instead of people posting VM patches (as they do today) people would just post VM processes.
Of course, compiling is "complicated". It a process that involves many steps and is completely alien to many users. It also takes forever. And minor configuration problems result in complete failure. And if the module you want isn't part of the kernel distribution, things only get worse.
>>>>>>>>>>..
I never said that compiling wasn't complicated. I'm just saying that it could easily be hidden behind a GUI tool. The configuration is the complicated part, make bzImage && make modules && make modules_install could easily be done by a nice KDE app.
With a microkernel, module installation could be as easy as installing a new command line program. You can still make configuration mistakes, but a lot of the time and effort can be eliminated. And with a really good microkernel architecture, you can also automate the process much more than it currently is.
>>>>>>>
In a proper modular design, installing a new module *is* just a matter of putting a file in the correct directory. BeOS, for example, did this very well. (It wasn't a proper microkernel, drivers were dynamic modules).
It functions well. It doesn't "work well" in the sense of being easy to install, configure, or extend.
>>>>>>>
Take a look at BeOS sometime. Its a work of art, and really not much less monolithic than a standard Linux install, except that networking is in userspace. (app_server == X server, media_server == aRts, etc).
The x86 segmentation mechanism is unavoidable. Every single memory access (even on a P4) goes through the GDT. Anyway, I wasn't talking about using the segmentation mechanism as a whole, just the nifty property that the privlege level of a task is decided by the privlege of its segment (or page, if you ditch segmentation). From what I can see, it should incur no more of a performance impact than the user/kernel checking the processor already does.
BeOS was a multimedia demon, and could support multi-terabyte partitions years before any free *NIX.
HURD has no sound and a 1GB partition limit.
Say what?
Alternative to microkernel
on
Hurd: H2 CD Images
·
· Score: 5, Interesting
The only reason microkernels exist is limitations in existing protection mechanisms. There are only two levels, kernel and user, and each must be protected from the other. My question is this: what about something like the x86 segmentation mechanism? x86 segments have the cool property that a piece of code has the privelege level of the segment containing it. The nifty thing about that is that there are 4 privlege levels, so that you can have the kernel at the lowest level, less important stuff like the GUI at a higher level, and the app at the highest level. That way nothing can crash a more important component. I was wondering why this scheme hasn't been extend to paging. On every memory reference, the processor could check the privelege level of the page containing the currently executing code, and make sure that the target memory has an appropriate privlege level. This makes things even faster than a mono-kernel, since the only thing that is necessary to do a system call is a simple jump to the appropriate code (which would be dozens of times faster than a standard system call on x86). This shouldn't be any slower than the current way of doing things. The privlege of the current code would only have to be read whenever a page boundry was crossed, and would only reference memory during a TLB fault (which would have to reference memory anyway). The proc already does a protection check on the kernel/user bit on the page table entry anyway, so that scheme could be extended to multiple privlege levels without a slowdown. Am I missing something, or does an existing processor already do this?
Usually. The problem is that x86 just wasn't designed for microkernels (or operating systems in general, it seems). A system call (which is essentially nothing more than a jmp) takes 40 times longer than a regular function call (on my PII 300 anyway). That's the performance hit for a monolithic kernel like Linux. A context switch (which microkernels do tons of) takes two user/kernel transitions, plus one save of register state (~100 bytes on x86) and one restore of register state. In computer time, a context switch is glacially slow. Now, microkernels circumvent a lot of the slowdown through tricks like buffering commands (batches commands and sends them together in one message), but it still has more overhead than the monolithic kernel method. Of course, given that people think that KDE2 is a usable piece of software (speedwise), it seems that people don't notice speed differences anyway, so the point may be moot.
Re:microkernels may be the way out
on
Hurd: H2 CD Images
·
· Score: 4, Insightful
I think this may be the way out for the current problems with the Linux kernel. The 2.4.17 Linux kernel distribution is almost 30Mbytes of sources, gzipped.
>>>>>>>
A microkernel-based OS would be just as big. Unlike Microsoft, the Linux developers need to develop (and distribute) all of their own drivers.
Getting the right ACPI or APM options requires endless recompiling and rebooting.
>>>>>
That's not the fault of the monolithic design. AtheOS, for example uses a modular monolithic kernel, and it can dynamically update kernel components.
A bug in any one kernel module will usually take down the whole system.
>>>>>
But Linux is generally as stable as any microkernel, and monolithic kernels like FreeBSD are more stable than any existing microkernel (except maybe QNX).
None of the major Linux distributions has placed reconfiguration of the kernel within reach of the average user, and even for the experienced user it's kind of a pain.
>>>>>>>>
And it would be the same on a microkernel. The compiling process isn't complicated, the configuring is. That configuring would still be present on a microkernel system, its just that less compiling would be necessary. Since compiling can be hidden behind a GUI tool, and the kernel only takes a few minutes to compile on modern hardware, this doesn't gain much.
microkernel may be the best compromise for achieving a modular, extensible kernel in the real world.
>>>>>>>>
Experience has shown that a moduler monolithic kernel seems to be working quite well.
Compiling is not hard, and most people who use linux quickly find it easy as a Windows user's step-by-step installs with an InstallShield application. Very little difference
>>>>>>>>>>>>&g t;
Only because most people who use Linux are nerds. Honestly, can you say that typing./configure, looking all over the net for all the dependencies you're missing, typing make, looking all over the net for dependencies./configure didn't catch, and make install, and looking all over the system to see where the hell the binaries got put, is easier than clicking a few times and putting in the install path?
Actually, according to SGI's own docs The VPro cards are just rebranded Quadros, which, in fact, *ARE* vanilla GeForce cards with some special features enabled in the hardware (like line-AA). All it takes is a change to one resistor to turn a "vanilla" GeForce into an SGI "VPro"
Slashdot Mirror
OS-X fonts look good to some people because, in general, Quartz renders the desktop quite softly. In reality, OS-X's font subsystem is rather low tech, it lacks hinting, gamma correction, etc. You can read all about it on the XRender mailing list. Personally, I don't like OS-X's fonts, but that's just me.
Linux fonts are great! If you take the high quality TrueType fonts from your Windows partition, Freetype2 renders the text extremely sharply. The only renderer I've seen that is better than FT2 is BitStream's FontFusion (found in QNX RtP) and the only reason I like it better is because it is less heavy-handed with the anti-aliasing. Certainly, FT2 blows away Windows' font rendering. Compare Arial in FT2 to Arial in XP, and you'll notice that FT2 renders the text visibly more clearly.
A) No ntoskrnl.exe, true, but as for the C compiler, there's always GCC.
B) I switched from Windows to Linux, even though Linux's GUI sucks more, just because I dispise Microsoft and don't mind Linux. Yet, I don't for one minute doubt that Windows is just as capable a developer machine as anything based on Linux. Xp is rock-solid stable, fast (compared to GNOME or KDE!), and thanks to GNU and Cygwin, has all the CLI tools you could possibly want. There are a lot of reasons to like Linux, but pretending there is something (desktop, not server) you can do in Linux that you can't in Windows is just dumb.
Given how often the XFS guys synch up (within hours, usually) I can't tell that I'm not using a stock kernel.
You "play for gameplay" yet you play UT? Wow. And besides, support for older machines is no excuse. First, UT doesn't run well on old machines anyway. Yet, Quake III, with all its curved-surface niceness runs fine on my PII-300. Second, LOD mesh technology has been around for years. Messiah, for example, could vary the polygon count of the scenes depending on what the machine could handle at a given point in the game. That way slow machines would get reduced graphics, while fast machines would get great graphics.
Honestly, these graphics are SO 1998! Maybe I'm spoiled by the PS2, but you'd think with all the GeForce 3 power they have at their disposal, they'd use some curved surfaces in the levels. The maps (especially the Egypt one in the screenshots) look like they were drawn by a six-year old with a demo version of 3D Studio that was limited to 100 polygons.
A) Itanium isn't RISC. Its a VLIW chip.
B) x86 chips are really hybrid RISC/CISC. Almost all modern x86 processors translate x86 operations into RISC micro-operations.
C) x86 maybe be stuck in the 1980s, but a 2GHz P4 comes within spitting distance of a 1GHz Alpha in most benchmarks, and its tons cheaper. The Alpha's a great architecture (really, really clean!) but GHz is GHz.
A little bit of history. The reason, in fact, that it is called QNX (instead of Qunix, which it used to be called) was because they didn't have a license for the word UNIX. Thus, its debatable whether QNX could be not called a UNIX. If QNX isn't a UNIX because it doesn't have the trademark, then neither Linux nor BSD are UNIX. If QNX isn't a UNIX because its a microkernel, than OS-X isn't a UNIX.
PS> QNX isn't GUI-only. Photon runs as a seperate process.
While that's true, its not a bad ballpark figure. I can feel the difference between a 5400RPM drive and a 7200RPM drive just sitting at a computer and using it. In general, drives with faster RPM tend to have higher-bit densities anyway (they're newer), so it gives a rough indicator that's easy to understand.
BeOS redux?
PS> Great. But will it run UT?
There's no point. C# is a good language, and just because Microsoft made it doesn't make it bad. What's wrong with using an already-developed standard to create an open, free implementation?
Actually, with modem connections, smaller files are a pain in the ass. The thing is that most of the packages are *required* dependencies. Instead of just starting a big transfer and leaving it on overnight, you have to deal with starting many different file transfers, which is quite a risk on many modem connections.
Doh. BeOS made its first public release one year later. Sorry 'bout that.
XFS is not the best example of Linux's modularity. In order to make Linux suitable for massive filesystem needs, it has to touch a lot of the core VFS code that filesystems don't usually touch. Even in a microkernel, something like XFS would conflict with the core semantics of the fileserver (equivilant to the VFS) and the problem would still be there, just in a different place. A better example of modular filesystems is JFS, which is just a drop-in install in Linux.
I would have to disagree. The kernel could easily provide services that would provide memory mapping to the driver. I don't see why not. In fact, with proper protection mechanisms in place there's no reason why any user app should not be able to figure out real memory addresses. I don't think that would be ugly.
>>>>
It would be quite ugly. There are several problems that crop up. First, each driver would have to dynamically map pieces of process address space into its own space during execution (paltry 4GB address space on x86). To do that, you not only have to make a round-trip to the kernel, but you have to mess with the process address space (which involves an AVL-tree lookup and attempts to merge regions). The kernel doesn't have to do this, because whenever a system call is invoked, the current process's address space is already mapped. Then there is the fact that it becomes a pain to manage all those shared mappings. There can easily be hundreds of processes in the system, and multiple drivers processes would have to map each one. Managing that many shared mappings quickly becomes very messy (and very dangerous, due to the extensive sharing of memory).
Dude. 120GB HDs are only $200 on Pricewatch. Given the 8 IDE channels you can have on a standard PC (anything with IDE-RAID) a terabyte machine is less than $1600 away! Given the dirt cheap price of other components, you can put that together that machine for less than $4000!
Dude, I know that. I also know that most OSs for x86 set the segments up once and then leave them alone forever after that. Changing the segment registers is expensive.
>>>>>
I know. And a modern x86 OS has to do it on every system call and every interrupt. That's why syscalls are so dreadfully slow on x86.
Context switches are expensive enough as it is; changing the segment setup during context switch would make them even more expensive.
>>>>
Linux has to do it anyway. When the timer interrupt occurs, the chip loads CS with the kernel code selector and the timer code loads DS with the kernel data selector.
On the one hand, we have Linux, a monokernel that works. On the other hand, there are microkernels that work (and HURD will work someday I am sure). Your proposal is somewhere in the middle, and it would work too. I shouldn't like to guess in what ways it would be better or worse. Maybe you can find some students in University to do a project using your design and see how it goes.
>>>>>>>
See, the problem is that I don't know of any existing hardware that does this. There are projects out there that try this with x86 segmentation, but they are limited by the fact that selector switches are slow. I don't know of anything (which was why I was asking) that meshes multiple protection levels with a paging-based mechanism.
True, but entirely beside the point. I wasn't saying that we should go back to segmentation. I was pointing out that segments have a nice property that the privlege level of the code is based on the address of the code, and that property would be useful (even in a paging based mechanism) in getting a better protection system.
Of course it would. But the different parts of it (drivers, file systems, personalities, distributed shared memory, clustering, video support, VM strategies, etc.) could be developed and tested by different developers, independently. With the Linux architecture, almost everything goes through the bottleneck of the Linux kernel developers, and it just isn't working in practice: important functionality takes years to make it into the kernel. It's not for lack of effort or dedication, it's the architecture and lack of modularity.
>>>>>>>>
Umm, read kernel traffic sometime. The "Linux kernel developers" are a very large and diverse group of people. They're not some committe that rules the kernel by fiat. That's Linus's job, as well it should be. He ultimately gets to decide what goes into the kernel, and making it a microkernel (say, moving the VM to a seperate process) would not make things any different. Instead of people posting VM patches (as they do today) people would just post VM processes.
Of course, compiling is "complicated". It a process that involves many steps and is completely alien to many users. It also takes forever. And minor configuration problems result in complete failure. And if the module you want isn't part of the kernel distribution, things only get worse.
>>>>>>>>>>..
I never said that compiling wasn't complicated. I'm just saying that it could easily be hidden behind a GUI tool. The configuration is the complicated part, make bzImage && make modules && make modules_install could easily be done by a nice KDE app.
With a microkernel, module installation could be as easy as installing a new command line program. You can still make configuration mistakes, but a lot of the time and effort can be eliminated. And with a really good microkernel architecture, you can also automate the process much more than it currently is.
>>>>>>>
In a proper modular design, installing a new module *is* just a matter of putting a file in the correct directory. BeOS, for example, did this very well. (It wasn't a proper microkernel, drivers were dynamic modules).
It functions well. It doesn't "work well" in the sense of being easy to install, configure, or extend.
>>>>>>>
Take a look at BeOS sometime. Its a work of art, and really not much less monolithic than a standard Linux install, except that networking is in userspace. (app_server == X server, media_server == aRts, etc).
The x86 segmentation mechanism is unavoidable. Every single memory access (even on a P4) goes through the GDT. Anyway, I wasn't talking about using the segmentation mechanism as a whole, just the nifty property that the privlege level of a task is decided by the privlege of its segment (or page, if you ditch segmentation). From what I can see, it should incur no more of a performance impact than the user/kernel checking the processor already does.
BeOS was a multimedia demon, and could support multi-terabyte partitions years before any free *NIX.
HURD has no sound and a 1GB partition limit.
Say what?
The only reason microkernels exist is limitations in existing protection mechanisms. There are only two levels, kernel and user, and each must be protected from the other. My question is this: what about something like the x86 segmentation mechanism? x86 segments have the cool property that a piece of code has the privelege level of the segment containing it. The nifty thing about that is that there are 4 privlege levels, so that you can have the kernel at the lowest level, less important stuff like the GUI at a higher level, and the app at the highest level. That way nothing can crash a more important component. I was wondering why this scheme hasn't been extend to paging. On every memory reference, the processor could check the privelege level of the page containing the currently executing code, and make sure that the target memory has an appropriate privlege level. This makes things even faster than a mono-kernel, since the only thing that is necessary to do a system call is a simple jump to the appropriate code (which would be dozens of times faster than a standard system call on x86). This shouldn't be any slower than the current way of doing things. The privlege of the current code would only have to be read whenever a page boundry was crossed, and would only reference memory during a TLB fault (which would have to reference memory anyway). The proc already does a protection check on the kernel/user bit on the page table entry anyway, so that scheme could be extended to multiple privlege levels without a slowdown. Am I missing something, or does an existing processor already do this?
Usually. The problem is that x86 just wasn't designed for microkernels (or operating systems in general, it seems). A system call (which is essentially nothing more than a jmp) takes 40 times longer than a regular function call (on my PII 300 anyway). That's the performance hit for a monolithic kernel like Linux. A context switch (which microkernels do tons of) takes two user/kernel transitions, plus one save of register state (~100 bytes on x86) and one restore of register state. In computer time, a context switch is glacially slow. Now, microkernels circumvent a lot of the slowdown through tricks like buffering commands (batches commands and sends them together in one message), but it still has more overhead than the monolithic kernel method. Of course, given that people think that KDE2 is a usable piece of software (speedwise), it seems that people don't notice speed differences anyway, so the point may be moot.
I think this may be the way out for the current problems with the Linux kernel. The 2.4.17 Linux kernel distribution is almost 30Mbytes of sources, gzipped.
>>>>>>>
A microkernel-based OS would be just as big. Unlike Microsoft, the Linux developers need to develop (and distribute) all of their own drivers.
Getting the right ACPI or APM options requires endless recompiling and rebooting.
>>>>>
That's not the fault of the monolithic design. AtheOS, for example uses a modular monolithic kernel, and it can dynamically update kernel components.
A bug in any one kernel module will usually take down the whole system.
>>>>>
But Linux is generally as stable as any microkernel, and monolithic kernels like FreeBSD are more stable than any existing microkernel (except maybe QNX).
None of the major Linux distributions has placed reconfiguration of the kernel within reach of the average user, and even for the experienced user it's kind of a pain.
>>>>>>>>
And it would be the same on a microkernel. The compiling process isn't complicated, the configuring is. That configuring would still be present on a microkernel system, its just that less compiling would be necessary. Since compiling can be hidden behind a GUI tool, and the kernel only takes a few minutes to compile on modern hardware, this doesn't gain much.
microkernel may be the best compromise for achieving a modular, extensible kernel in the real world.
>>>>>>>>
Experience has shown that a moduler monolithic kernel seems to be working quite well.
Compiling is not hard, and most people who use linux quickly find it easy as a Windows user's step-by-step installs with an InstallShield application. Very little difference ./configure, looking all over the net for all the dependencies you're missing, typing make, looking all over the net for dependencies ./configure didn't catch, and make install, and looking all over the system to see where the hell the binaries got put, is easier than clicking a few times and putting in the install path?
>>>>>>>>>>>>&g t;
Only because most people who use Linux are nerds. Honestly, can you say that typing
Actually, according to SGI's own docs The VPro cards are just rebranded Quadros, which, in fact, *ARE* vanilla GeForce cards with some special features enabled in the hardware (like line-AA). All it takes is a change to one resistor to turn a "vanilla" GeForce into an SGI "VPro"