Um, the guy on their team doesn't write the drivers. First, the driver core is fully portable, so maintaining more than one platform is very easy. Second, the Linux port has commercial importance, because SGI uses NVIDIA GPUs in their Linux-based machines. It's only the FreeBSD port that seems to be a community job. As for ATI, I couldn't care less about ATI. NVIDIA has a track record (back from the Riva128 days) of being community-friendly. They also have a track record of having very good drivers, and improving the drivers even for existing hardware, not just their latest stuff. ATI has a history of crappy drivers, and their open source OpenGL ones barely work at all. NVIDIA's Linux drivers in comparison, are just as fast and stable (for most people, anyway) as their Windows drivers.
I stand in awe of all the uber-nerds on this board. I'm nowhere comparable to some of the people on this board (I've only got 6 computers at home) but I'd just like to add my two bits. I seem to accumulate hardware in any available drawer. I have drawers full of Riva 128s, Voodoo 2's, SB 16's, cables, etc. I've got a Celeron 366 motherboard + cpu combo sitting in the chest of drawers behind me (right next to a blanket and a couple of table cloths) and I've got RAM in random nooks and corners around the room. I've only been in my dorm room for about two months now, and I've already got a PIII-850, a PIII-667, and two 10,000 RPM Cheetahs sitting in the drawer next to me.
Except NVIDIA. ATI is quickly catching up on the hardware front. But their drivers suck, which is why NVIDIA still rules. Why should they give up a lead like that? Remember, an OpenGL driver is an entire OpenGL implementation (everything from glVertex3f() down to register banging). That's a huge amount of code to open up, not to mention that some of its probably licensed.
The kernel portability layer is already open. The FreeBSD-nvidia project even got some initial results porting the Linux version. However, there are some issues in the binary part that held up the port. Given that they've most likely cleaned up the issues in the binary part for the FreeBSD port (why bother maintaining two different nearly identical binary modules?) a port to NetBSD should be fairly easy.
The reason seems to be the FreeBSD-NVIDIA project. They did some driver porting, and were really hitting the wall, so their contacts at NVIDIA decided to just do a release. It's not that hard at all to port the NVIDIA driver to another OS. The X11 part is OS independent (like all X11 graphics drivers) and the kernel part is wrapped in a small portability layer. Most likely, they're just doing it because the effort in porting is small compared to the good faith it gets in the community, and the fact that it allows vendors using a BSD to also consider NVIDIA products.
Well, the NVIDIA drivers are generally quite friendly to hacking. The main issue is in the portability layer, where sometimes interfaces will get changed in development versions. But some tweeking is all that it needs. For example, I'm using the nvidia drivers under 2.5.44 right now. In fact, my distro (Gentoo) patches the drivers for development kernels automagically...
Look, FreeBSD support isn't a huge deal at NVIDIA. It's a few coders in their driver development group that are doing this with company approval. No doubt, these pages didn't go through the official "gods of marketing" over at NVIDIA. As such, give it a little time. What most likely happened was that they were pressed for time in releasing these drivers, and so they just made some hastly pages to put it up. What matters is the actual code, and once that's working nicely, I'm sure the page will get polished.
Actually, Linux is rather new code. The important parts (VM, block I/O, scheduler, memory allocators, threading code, you name it) have nearly been rewritten in the past five years, many of them in just the last two. Improvements have been made to XNU I'm sure, but I doubt Apple had enough time to make drastic overhauls to the core code. Many things in Darwin just smack of that haste. The use of Mach 3.x instead of Mach 4.x, the use of 4.4 BSD instead of FreeBSD, the rather contrived layering of BSD and Mach, you name it. Apple has been very busy working on the other parts of OS X, like Aqua, Quartz, etc. Ideally for Apple, they would have just ported the OpenStep APIs (which are portable to begin with...) to a modern BSD. OS X would have immediatly started life with catagory-leading performance instead of catagory-trailing performance. The Apple developers would have an instant community of developers. But clearly, they didn't have the time to do that and develop Aqua at the same time, so how much work could they really have done in the kernel? For example, they added a unified VM/buffer-cache to XNU. But apparently, OS X has some bad behavior where a large amount of file I/O will cause process pages to be thrown out of RAM. Such a problem is traditionally an issue with unified VMs, but fixes for that behavior were published by Sun (among others) years ago. Given the importance of media professionals to Apple's business, you'd think they would have splurged $50 for a copy of Solaris Internals to find out about the fix. Of course they would have, but they most likely didn't have the time to.
You're right. I was mistaken. The Mach version is 3.0. But I was right about the BSD. It's 4.4 BSD Lite2. IIRC, NeXT used 4.3 BSD. Either way, both are still old code. They don't have the benifet of the nearly one decade of advancements that have happened in kernel design since they were written. Take a look at the papers published by Sun and the Net/FreeBSD VM guys in the last few years. Modern free kernels have implemented these features, XNU hasn't. Is Darwin 6.x better than 4.4 BSD lite-2? Undoubtedly. But has Apple had the time or resources to make up for the long period of non-development? The benchmarks would indicate that they have not.
I don't follow the Darwin mailing lists, so would you care to sum up the improvements that make 10.2 twice as fast as 10.1.5 in lmbench? Cuz that's what it's losing by to Linux and the BSDs. I don't see much in the ChangeLog that'd do that.
I never said that moving the BSD part of the kernel into the same address space doesn't increase performance. I said it's not as fast as a normal monolithic kernel that doesn't have the additional layering. In OS X, low level work is abstracted by Mach for the BSD layer to use. This was probably the time-effective solution, to keep the general structure of NeXT in place, but the additional layer of abstraction does incur a performance hit.
That said, I'm not a Darwin kernel developer. Someone asked why Darwin was slower in lmbench and this is my explanation. If you have some actual evidence to contradict me (instead of apparently just misreading the statements I made) or can point me to the relevent code that contridicts anything I've said, feel free to do so.
It isn't old code. >>>>>>>> Yes it is old code. Mach 2.x, mostly 4.4 BSD. How much improvement do you think the Apple engineers could have improved on that code base given Apple's situation before OS X was released? Of course, code doesn't rot like wood, but machine performance characteristics are very different now than they were when the code powering OS X was designed. Take a look at the Linux kernel code. There are all sorts of optimizations that depend on the general performance characteristics of the machine. These have changed, and as a result the OS X code isn't optimal for modern systems. Beyond that, there is the fact that huge improvements in VM design and microkernel performance have been introduced since Mach was designed. OS X largely lacks the advantage of those improvements. The fact that OS X is slower isn't in question here. The benchmarks are nice and simple. What I'm doing here is explaining *why* the benchmarks as are they are.
Second the BSD kernel is in the same address space as Mach and is compiled into the same file. >>>>>>>> Doesn't change the fact that the layering involves a layer of redundency and abstraction that hurts performance.
Further, what version of xnu you were you guys testing with? xnu has gone through a massive amount of development. >>>>>>>>>> 10.1.5. Not 10.2, as mac-heads say when I point it out, but if you'd read the changelogs, you'd realize that the GUI was the focus of 10.2 development, not the kernel. You can find numbers here http://clustermonkey.org/~laz/pbook/
Dude, why can't people spend 2 seconds in Google before being stupid. The lineage of the alphabet traces directly from Phoenician, Latin was only one of the languages in that line. The numerals are Indian, they're just called Arabic numerals because the west was introduced to it through Arab traders who had travelled from India.
Um, as I remember it, Americans use several times more engergy per capita than any other group of people on the planet. When you're trying to stop something prevalent, it's too complicated to go after everyone. You go after the big abusers. It's like the MP3 situation. You don't bust the guy 100 MB of country, you bust the guy hosting 100 GB of Top 40 music. The US reps had a problem with Thailand getting off too easy. Thailand! That's complete and utter bullshit. The rest of the world will start picking up on their end when Americans stop buying 13 mpg SUVs.
It's just old code. It hasn't really been adapted to modern machine architectures, it hasn't had the benifet of all the new algorithms and developed in modern kernels. Also, Mach was never a great microkernel to begin with and the whole BSD/Mach layering saps some performance.
Problematically, the G4's FSB is still 167 MHz SDR = 1.3 GB/sec. So the 2.7 GB/sec of DDR bandwidth does absolutely no good. The 2MB of L3 cache helps, but in the case where AltiVec really matters (hint: they call it 'streaming' SIMD for a reason) the data sets totally blow the 2MB of cache. Besides, the 4.2 GB/sec of main memory bandwidth on the P4 is almost as fast as the L3 cache bandwidth on the G4. If you don't believe me, just look at the new benchmarks. The DDR memory makes no difference at all.
In all reality, microkernels are all BS these days. Monolithic kernels have gotten to the point where they can be utterly stable (I have only crashed Linux a few times, and that was in the process of using development kernels) and totally modular (almost everything in Linux can be compiled as a module, and these days, Linux can dynamically detect USB mice or video cams just as easily as any microkernel). Microkernels still have their advantages, but that's in the massively parallel NUMA market or the distributed processing market, and isn't relavent to consumers.
1) Given the prices of PC1066, RDRAM not common, but it's hardly "largely unavailable." Plenty of vendors carry it these days. It used to be rare, but it isn't anymore.
2) DDR-433 (PC 3500) RAM performs just as well as PC800 RDRAM. DDR-333 RAM performs just as well as PC-800. Both are very stable in current P4 motherboards.
3) If heat is an issue (and it shouldn't be, given the excellent choices in super-quiet fans available today) then just use DDR instead. A well made PC can run just as cool as any Apple machine. It takes premium fans and power supplies, but what do you think Apple uses?
You're comments about the P4 might have been true a year ago, but the situation is very different today, now that the P4 platform has matured.
Partially correct. You could use PC1066 RDRAM, which is only about 50% more than PC2100 DDR RAM, or PC3500 DDR RAM, which is only about 30% more than PC2100 DDR RAM. Now, the G4 can use DDR RAM too, but it's limited by the 167 MHz SDR bus of the G4 (which is why DDR makes no difference in the benchmarks). The 133 QDR bus of the P4 doesn't limit the memory banwidth.
Re:Moshe Bar compares OS X to Linux
on
Is Mac OS X Slow?
·
· Score: 1, Flamebait
Typical mac-head response. 10.2 didn't really change anything in the programs he was testing. He tested network and I/O, while Jaguar improved the GUI (read the ChangeLogs for Darwin). And the GUI shouldn't take up many cycles at all if he isn't using it. Compiling a big app in the back ground takes the same amount of time with the GUI on as with it off. And it's obvious Linux has a better I/O and network subsystem. The Linux subsystems have been continuously tweeked for the last several years. The extent of the tweeking in the OS X kernel is whatever a few Apple engineers could do to 4.4 BSD and Mach 2.x in a couple of years.
We're at a very interesting time in OSs now. While Windows is still getting slower everyday (XP killed all the nice things that started with Win2K) the other two big OSs, Linux and OS X are getting faster everyday. KDE 3.x is faster than KDE 2.x to the point where it's even usable for me, and it has tons more features. OS X 10.2 has a lot more features than OS X 10.0, but is a lot faster. The only time I've ever seen this before was with BeOS. And honestly, it makes sense. Adding new features, generally, needn't have any effect on performance other than on memory usage. Adding a better file search, for example, shouldn't effect how long it takes to display my emails, not if the program is well designed. Hopefully, this trend continues. Hopefully, KDE 4.x on my 2GHz, 640MB P4 will finally match BeOS 4.5 on my 300 MHz 64MB P2...
Um, human response time is 1/3 of a second. Over a second isn't "soon as the icon was clicked" it's "agonizingly, painfully long after the icon was clicked." If you take a full second to do a mouse click, you need to get your reflexes checked...
I can even watch a normal-sized (~320x240) DivX movie full-screen with very few dropped frames.
>>>>>>>>>>>. On a 500 MHz G3! I could play full screen DivXs on my P2-300 while playing a couple of MP3s in the background! And that was on Windows! Don't even get me started on BeOS!
When rewriting, it's a lot of easier to just change the important stuff (UI GOODIES!!!) and leave the unimportant stuff (kernel) as unchanged as possible. >>>>>>>>> That's the real reason *real* NIX grognards will never use OS X. To them, the kernel is important, and the UI isn't. Different strokes for different folks, I guess. I still don't like the proselytizing attitude Mac-heads have gotten lately.
Actually, the kernel is slow. In lmbench (which measures the speed of basic UNIX kernel operations) OS X is half the speed of Linux. And the Velocity engine would be great...if the G4 had enough front side bus bandwidth to actually feed it. The AltiVec units themselves are very high quality, but because the average P4 has 3x the memory bandwidth (and streaming SIMD operations are *very* memory bandwidth dependent) it can't shine in the current G4.
Actually, MacOS X renders very little through OpenGL. Quartz 2D software renders onto textures, and those textures are drawn using OpenGL. OpenGL is thus relegated to nothing more than supporting fancy window effects like transparency, shadow, and genie. And the PDF thing has major downsides. I'm guessing the fact that Quartz is tied to PDF is one of the major reasons why they couldn't use OpenGL to accelerate actual drawing.
If one were to go around chanting anti-american remarks and burning the flag, by the Constitutional law.. they have every right to do that, but our government will see it as a threat and most likely arrest the individual. >>>>>>>>>>> If I recall correctly, you can't arrest someone if they have the right to do something. And last I remembered, making anti-american remarks and burning the flag was still Constitutional.
Slashdot Mirror
Um, the guy on their team doesn't write the drivers. First, the driver core is fully portable, so maintaining more than one platform is very easy. Second, the Linux port has commercial importance, because SGI uses NVIDIA GPUs in their Linux-based machines. It's only the FreeBSD port that seems to be a community job. As for ATI, I couldn't care less about ATI. NVIDIA has a track record (back from the Riva128 days) of being community-friendly. They also have a track record of having very good drivers, and improving the drivers even for existing hardware, not just their latest stuff. ATI has a history of crappy drivers, and their open source OpenGL ones barely work at all. NVIDIA's Linux drivers in comparison, are just as fast and stable (for most people, anyway) as their Windows drivers.
I stand in awe of all the uber-nerds on this board. I'm nowhere comparable to some of the people on this board (I've only got 6 computers at home) but I'd just like to add my two bits. I seem to accumulate hardware in any available drawer. I have drawers full of Riva 128s, Voodoo 2's, SB 16's, cables, etc. I've got a Celeron 366 motherboard + cpu combo sitting in the chest of drawers behind me (right next to a blanket and a couple of table cloths) and I've got RAM in random nooks and corners around the room. I've only been in my dorm room for about two months now, and I've already got a PIII-850, a PIII-667, and two 10,000 RPM Cheetahs sitting in the drawer next to me.
Except NVIDIA. ATI is quickly catching up on the hardware front. But their drivers suck, which is why NVIDIA still rules. Why should they give up a lead like that? Remember, an OpenGL driver is an entire OpenGL implementation (everything from glVertex3f() down to register banging). That's a huge amount of code to open up, not to mention that some of its probably licensed.
The kernel portability layer is already open. The FreeBSD-nvidia project even got some initial results porting the Linux version. However, there are some issues in the binary part that held up the port. Given that they've most likely cleaned up the issues in the binary part for the FreeBSD port (why bother maintaining two different nearly identical binary modules?) a port to NetBSD should be fairly easy.
The reason seems to be the FreeBSD-NVIDIA project. They did some driver porting, and were really hitting the wall, so their contacts at NVIDIA decided to just do a release. It's not that hard at all to port the NVIDIA driver to another OS. The X11 part is OS independent (like all X11 graphics drivers) and the kernel part is wrapped in a small portability layer. Most likely, they're just doing it because the effort in porting is small compared to the good faith it gets in the community, and the fact that it allows vendors using a BSD to also consider NVIDIA products.
Well, the NVIDIA drivers are generally quite friendly to hacking. The main issue is in the portability layer, where sometimes interfaces will get changed in development versions. But some tweeking is all that it needs. For example, I'm using the nvidia drivers under 2.5.44 right now. In fact, my distro (Gentoo) patches the drivers for development kernels automagically...
Look, FreeBSD support isn't a huge deal at NVIDIA. It's a few coders in their driver development group that are doing this with company approval. No doubt, these pages didn't go through the official "gods of marketing" over at NVIDIA. As such, give it a little time. What most likely happened was that they were pressed for time in releasing these drivers, and so they just made some hastly pages to put it up. What matters is the actual code, and once that's working nicely, I'm sure the page will get polished.
Actually, Linux is rather new code. The important parts (VM, block I/O, scheduler, memory allocators, threading code, you name it) have nearly been rewritten in the past five years, many of them in just the last two. Improvements have been made to XNU I'm sure, but I doubt Apple had enough time to make drastic overhauls to the core code. Many things in Darwin just smack of that haste. The use of Mach 3.x instead of Mach 4.x, the use of 4.4 BSD instead of FreeBSD, the rather contrived layering of BSD and Mach, you name it. Apple has been very busy working on the other parts of OS X, like Aqua, Quartz, etc. Ideally for Apple, they would have just ported the OpenStep APIs (which are portable to begin with...) to a modern BSD. OS X would have immediatly started life with catagory-leading performance instead of catagory-trailing performance. The Apple developers would have an instant community of developers. But clearly, they didn't have the time to do that and develop Aqua at the same time, so how much work could they really have done in the kernel? For example, they added a unified VM/buffer-cache to XNU. But apparently, OS X has some bad behavior where a large amount of file I/O will cause process pages to be thrown out of RAM. Such a problem is traditionally an issue with unified VMs, but fixes for that behavior were published by Sun (among others) years ago. Given the importance of media professionals to Apple's business, you'd think they would have splurged $50 for a copy of Solaris Internals to find out about the fix. Of course they would have, but they most likely didn't have the time to.
You're right. I was mistaken. The Mach version is 3.0. But I was right about the BSD. It's 4.4 BSD Lite2. IIRC, NeXT used 4.3 BSD. Either way, both are still old code. They don't have the benifet of the nearly one decade of advancements that have happened in kernel design since they were written. Take a look at the papers published by Sun and the Net/FreeBSD VM guys in the last few years. Modern free kernels have implemented these features, XNU hasn't. Is Darwin 6.x better than 4.4 BSD lite-2? Undoubtedly. But has Apple had the time or resources to make up for the long period of non-development? The benchmarks would indicate that they have not.
I don't follow the Darwin mailing lists, so would you care to sum up the improvements that make 10.2 twice as fast as 10.1.5 in lmbench? Cuz that's what it's losing by to Linux and the BSDs. I don't see much in the ChangeLog that'd do that.
I never said that moving the BSD part of the kernel into the same address space doesn't increase performance. I said it's not as fast as a normal monolithic kernel that doesn't have the additional layering. In OS X, low level work is abstracted by Mach for the BSD layer to use. This was probably the time-effective solution, to keep the general structure of NeXT in place, but the additional layer of abstraction does incur a performance hit.
That said, I'm not a Darwin kernel developer. Someone asked why Darwin was slower in lmbench and this is my explanation. If you have some actual evidence to contradict me (instead of apparently just misreading the statements I made) or can point me to the relevent code that contridicts anything I've said, feel free to do so.
It isn't old code.
>>>>>>>>
Yes it is old code. Mach 2.x, mostly 4.4 BSD. How much improvement do you think the Apple engineers could have improved on that code base given Apple's situation before OS X was released? Of course, code doesn't rot like wood, but machine performance characteristics are very different now than they were when the code powering OS X was designed. Take a look at the Linux kernel code. There are all sorts of optimizations that depend on the general performance characteristics of the machine. These have changed, and as a result the OS X code isn't optimal for modern systems. Beyond that, there is the fact that huge improvements in VM design and microkernel performance have been introduced since Mach was designed. OS X largely lacks the advantage of those improvements. The fact that OS X is slower isn't in question here. The benchmarks are nice and simple. What I'm doing here is explaining *why* the benchmarks as are they are.
Second the BSD kernel is in the same address space as Mach and is compiled into the same file.
>>>>>>>>
Doesn't change the fact that the layering involves a layer of redundency and abstraction that hurts performance.
Further, what version of xnu you were you guys testing with? xnu has gone through a massive amount of development.
>>>>>>>>>>
10.1.5. Not 10.2, as mac-heads say when I point it out, but if you'd read the changelogs, you'd realize that the GUI was the focus of 10.2 development, not the kernel.
You can find numbers here
http://clustermonkey.org/~laz/pbook/
Dude, why can't people spend 2 seconds in Google before being stupid. The lineage of the alphabet traces directly from Phoenician, Latin was only one of the languages in that line. The numerals are Indian, they're just called Arabic numerals because the west was introduced to it through Arab traders who had travelled from India.
Um, as I remember it, Americans use several times more engergy per capita than any other group of people on the planet. When you're trying to stop something prevalent, it's too complicated to go after everyone. You go after the big abusers. It's like the MP3 situation. You don't bust the guy 100 MB of country, you bust the guy hosting 100 GB of Top 40 music. The US reps had a problem with Thailand getting off too easy. Thailand! That's complete and utter bullshit. The rest of the world will start picking up on their end when Americans stop buying 13 mpg SUVs.
It's just old code. It hasn't really been adapted to modern machine architectures, it hasn't had the benifet of all the new algorithms and developed in modern kernels. Also, Mach was never a great microkernel to begin with and the whole BSD/Mach layering saps some performance.
Problematically, the G4's FSB is still 167 MHz SDR = 1.3 GB/sec. So the 2.7 GB/sec of DDR bandwidth does absolutely no good. The 2MB of L3 cache helps, but in the case where AltiVec really matters (hint: they call it 'streaming' SIMD for a reason) the data sets totally blow the 2MB of cache. Besides, the 4.2 GB/sec of main memory bandwidth on the P4 is almost as fast as the L3 cache bandwidth on the G4. If you don't believe me, just look at the new benchmarks. The DDR memory makes no difference at all.
In all reality, microkernels are all BS these days. Monolithic kernels have gotten to the point where they can be utterly stable (I have only crashed Linux a few times, and that was in the process of using development kernels) and totally modular (almost everything in Linux can be compiled as a module, and these days, Linux can dynamically detect USB mice or video cams just as easily as any microkernel). Microkernels still have their advantages, but that's in the massively parallel NUMA market or the distributed processing market, and isn't relavent to consumers.
1) Given the prices of PC1066, RDRAM not common, but it's hardly "largely unavailable." Plenty of vendors carry it these days. It used to be rare, but it isn't anymore.
2) DDR-433 (PC 3500) RAM performs just as well as PC800 RDRAM. DDR-333 RAM performs just as well as PC-800. Both are very stable in current P4 motherboards.
3) If heat is an issue (and it shouldn't be, given the excellent choices in super-quiet fans available today) then just use DDR instead. A well made PC can run just as cool as any Apple machine. It takes premium fans and power supplies, but what do you think Apple uses?
You're comments about the P4 might have been true a year ago, but the situation is very different today, now that the P4 platform has matured.
Partially correct. You could use PC1066 RDRAM, which is only about 50% more than PC2100 DDR RAM, or PC3500 DDR RAM, which is only about 30% more than PC2100 DDR RAM. Now, the G4 can use DDR RAM too, but it's limited by the 167 MHz SDR bus of the G4 (which is why DDR makes no difference in the benchmarks). The 133 QDR bus of the P4 doesn't limit the memory banwidth.
Typical mac-head response. 10.2 didn't really change anything in the programs he was testing. He tested network and I/O, while Jaguar improved the GUI (read the ChangeLogs for Darwin). And the GUI shouldn't take up many cycles at all if he isn't using it. Compiling a big app in the back ground takes the same amount of time with the GUI on as with it off. And it's obvious Linux has a better I/O and network subsystem. The Linux subsystems have been continuously tweeked for the last several years. The extent of the tweeking in the OS X kernel is whatever a few Apple engineers could do to 4.4 BSD and Mach 2.x in a couple of years.
We're at a very interesting time in OSs now. While Windows is still getting slower everyday (XP killed all the nice things that started with Win2K) the other two big OSs, Linux and OS X are getting faster everyday. KDE 3.x is faster than KDE 2.x to the point where it's even usable for me, and it has tons more features. OS X 10.2 has a lot more features than OS X 10.0, but is a lot faster. The only time I've ever seen this before was with BeOS. And honestly, it makes sense. Adding new features, generally, needn't have any effect on performance other than on memory usage. Adding a better file search, for example, shouldn't effect how long it takes to display my emails, not if the program is well designed. Hopefully, this trend continues. Hopefully, KDE 4.x on my 2GHz, 640MB P4 will finally match BeOS 4.5 on my 300 MHz 64MB P2...
Um, human response time is 1/3 of a second. Over a second isn't "soon as the icon was clicked" it's "agonizingly, painfully long after the icon was clicked." If you take a full second to do a mouse click, you need to get your reflexes checked...
I can even watch a normal-sized (~320x240) DivX movie full-screen with very few dropped frames.
>>>>>>>>>>>.
On a 500 MHz G3! I could play full screen DivXs on my P2-300 while playing a couple of MP3s in the background! And that was on Windows! Don't even get me started on BeOS!
When rewriting, it's a lot of easier to just change the important stuff (UI GOODIES!!!) and leave the unimportant stuff (kernel) as unchanged as possible.
>>>>>>>>>
That's the real reason *real* NIX grognards will never use OS X. To them, the kernel is important, and the UI isn't. Different strokes for different folks, I guess. I still don't like the proselytizing attitude Mac-heads have gotten lately.
Actually, the kernel is slow. In lmbench (which measures the speed of basic UNIX kernel operations) OS X is half the speed of Linux. And the Velocity engine would be great...if the G4 had enough front side bus bandwidth to actually feed it. The AltiVec units themselves are very high quality, but because the average P4 has 3x the memory bandwidth (and streaming SIMD operations are *very* memory bandwidth dependent) it can't shine in the current G4.
Actually, MacOS X renders very little through OpenGL. Quartz 2D software renders onto textures, and those textures are drawn using OpenGL. OpenGL is thus relegated to nothing more than supporting fancy window effects like transparency, shadow, and genie. And the PDF thing has major downsides. I'm guessing the fact that Quartz is tied to PDF is one of the major reasons why they couldn't use OpenGL to accelerate actual drawing.
If one were to go around chanting anti-american remarks and burning the flag, by the Constitutional law.. they have every right to do that, but our government will see it as a threat and most likely arrest the individual.
>>>>>>>>>>>
If I recall correctly, you can't arrest someone if they have the right to do something. And last I remembered, making anti-american remarks and burning the flag was still Constitutional.