Note to you: Don't complain that you can't use mainstream hardware on a non-mainstream OS. NVIDIA is being very nice just by supporting Linux, and it is not feasible for them to support every niche OS on the planet. Oh my GOD! They're thinking about business feasibility! They must be *evil* like Osama bin Laden!
The high level OpenGL code that comes from SGI isn't terribly well optimized. It is a reference implementation meant to be feature complete and correct, not fast. NVIDIA license the code from SGI and has spent the last several years hacking on it, ever since the original ICD came out with the Riva TNT-1. In that time, the code has probably changed a huge amount. Also, the high level code can have a lot of influence on how a card peforms. The OpenGL ICD driver is basically the entire OpenGL library. How it handles and optimizes the various calls made by the application to the driver makes a big difference in speed. For example, if the application calls for a certain set of rendering parameters, is the driver smart enough to take certain shortcuts based on those parameters to make rendering faster? A lot of this stuff is hardware independant, and the optimizations in the high level layer would help any 3D card.
Yes. This is exactly why NVIDIA's drivers are rock solid and run everything blazingly fast? If they use hacks to do that, then kudos to them! All I know is that everything from Quake to 3D Studio runs awesome on their drivers. Don't be stupid. The reason NVIDIA's drivers are so great are because they have been working on the same codebase for years (since halfway through the original Riva TNT's life cycle) and they had help from SGI on their OpenGL.
XFS historically has very bad delete performance. I don't think its the fault of the journal, since other things involving the journal (growing or creating files) aren't slow (though, ReiserFS does seem to have the best journaling code). I don't know what the official take on this is, but here's my theory. Most filesystems use a bitmap to keep track of free blocks. XFS, on the other hand, uses a pair of B+ trees to mange extents of free areas. This allows it to find better (more contiguous) blocks more quickly when an allocation has to be done. A bitmap, on the other hand, has to do a scan through the bits and can't afford to spend a lot of time looking in different places for the "best" place to allocate. However, when deleting a file, the bitmap approach already has all the addresses of the blocks, so its just a matter of clearing some bits. XFS, on the other hand, has to go ahead an reinsert the blocks back into the B+ tree, which takes many more disk access and much more time. Normally, this is an okay tradeoff, since you usually grow files more often than you delete (ie. you grow it many times while writing it out to 2GB, but delete the thing in one go). On systems like Squid server, on the other hand, you create and delete files like mad, so Reiser is often faster in that case.
Actually, the best filesystem on Linux right now for most uses is probably XFS. Its a little slow on deletes, and not as fast as Reiser for extremely small files, but from the stuff I've done with both (compiling, tar/untar, moving around directories, general workstation stuff) XFS is just as fast as Reiser for normal sized files, and much faster for large files. JFS is the dark horse here, though. I've seen some benchmarks showing it to have as good large file performance as XFS, but much better metadata (creating, deleting, growing, etc) performance. But there's not much info on it yet, and its not rock solid entirely.
Actually, the new journaling filesystems (ReiserFS, XFS, and JFS) are all *faster* than ext2. Also, journaling itself can cost very little these days because modern JFSs use large buffers and coalesce writes. For example, BFS achieves metadata performance nearly as high as ext2 on a heavily loaded system. So if all you're doing all day is creating/deleting/growing/shrinking files, the filesystem is only slightly slower. When you factor in all the performance improvements, it end up being faster.
To all you OSS zealots out there, *this* is why NVIDIA's drivers are closed source. You can bet ATI would love to put this whole driver fiasco behind them and just steal the high level OpenGL code (an OpenGL driver has to implement the whole GL API, not just hardware interfacing) from NVIDIA's ICD.
Actually, that's *not* what they did. Carmack make's their hack quite clear. Like all applications, Quake only uses a limited amount of the OpenGL API. Because of that, the graphics driver can make certain assumptions that would normally break certain features, but really don't hurt anything since Quake doesn't use them. Thus, the program can run faster. Still, its pretty devious nonetheless. If they came up with some nifty hacks to make Quake 3 faster on their (cruddy) drivers, then they should have released this as a feature, not hidden it. The fact that it is hidden is what makes people think it is just there to cheat on benchmarks.
Intel doesn't make drivers for a CPU, and thus can't cheat on the drivers. And not even Intel is not messed up enough to design an entire instruction set just to cheat on a couple of Photoshop filters. The real reason that only certain Photoshop features were helped is because MMX is a very limited instruction set and only a few Photoshop filters could really take advantage of it.
Here it is, 2001, and we're still typing text in flat ascii files, remembering all of the arcane syntax and rules of the compiler, then submitting our attempts to it, awaiting its response.
>>>>>>>>>>>
Actually, a good many people now type text in flat unicode files.
I guess that shows how different hardware can be. On my machine, anyway (300MHz PII, 256MB, GeForce2 MX) the speed order of the widgets is: (slowest) Qt, Win98, GTK+, Win2K (fastest).
Re:X-box and PS2 virtually the same?
on
XBox Released
·
· Score: 2
What's wrong with HDTV? At the high end, it carries a price premium of less than $1000. You can get a good Sony HDTV 53" for $2500 while a comparable Sony non-HDTV runs around $1800. Not a bad deal, considering a TV easily lasts you five or six years. Plus, there is a lot more programming these days, and (with new DVD players) DVDs look really good on HDTV.
Actually, GNOME is kinda weird. GNOME applications are fast, as long as you don't run the GNOME environment itself. Its amazing, the minute gnome-session starts, all GNOME apps seem to go into slow mo. If you use GNOME apps with a regular window manager, (like IceWM), its speedy. KDE, on the other hand, is always slow. Widgets just feel like they're moving through tar. Almost everything rubber-bands when resized. I think this might have a lot to do with Qt on Linux. While Qt on Windows performs well, it doesn't seem to on Linux. Most GTK+ apps can almost touch Windows in speed, but even simple KDE apps are far behind even complex Windows apps (ie. kmail is slower at most UI stuff than Word.
Re:SMB (Samba) kioslave in Konqueror yet?
on
KDE 3.0 Screenshots
·
· Score: 2
Also, Komba2 has the functionality of the Win2K browse service and more!
g++ 3.1 (because the minor release of g++ will break BC again).
>>>>>>>>>>>
Really? I thought 3.0 was supposed to have the set in stone, perfect C++ ABI?
Re:X-box and PS2 virtually the same?
on
XBox Released
·
· Score: 2
But the XBox has a VGA output (and can interface to HDTV) so you CAN have hi-res console gaming!
You're looking at the developer level, not the user level.
>>>>>>>
And ultimately, that's what matters. One can't build a cathedral on the foundation of a wooden shack.
The graphics system features true transparency
>>>>>>>>
So does Win2K (good transparency too, you can play a video through a transparent window without any flicker), and its still an utterly useless feature. A nifty effect, yes. Worth the huge memory and performance problems in OS-X? No.
and full font antialiasing, something the X11-folks can only dream about.
>>>>>>>>>>
XFree86 4.X has incredible font support, with full antialiasing. The TrueType renderer (given a good font like MS WebFonts) is easily comparable to FontFusion (the best font renderer in existance, IMO), except maybe with respect to anti-aliasing medium-sized fonts (its a little blurrier than I'd like, but since most people don't antialias between 8 and 15 point anyway, it doesn't really matter).
but 10.1 is usable on my G3/300M, and next year, when the G5/2.4G will be released, accelerated OpenGL will be unnecessary.
>>>>>>>
It doesn't matter. For the forseeable future, graphics hardware will continue to outpace (by FAR) CPUs in imaging operations. Even if Quartz on a G5 2.4 GHz is bearable, you'll be able to do much more complex operations more quickly on even an entry level OpenGL card. Since OpenGL can accelerate most (all, given the right hardware) of the features present in Aqua, and almost all modern computers have 3D acceleration, it is a no-brainer to base a future imaging system on OpenGL.
But isn't it a valid choice to reject choices? I mean, shouldn't there be a distro that standardizes everything, for users who don't want to deal with all the options? One man's choice is another man's chaos.
Not really. Even if you have an L4 HURD that is complete and stable, do you really have anything more than a stable, secure UNIX system? Those are a dime a dozen these days! The microkernel will not make it super-stable or super-secure, and competing OSs (which have the maturity of code that marks a stable/secure system) will be ahead of it in these respect for at least a decade or more. There is nothing in the HURD to justify its existance; it provides nothing to the world that doesn't already exist. Maybe that's fine for a research project, but IIRC, research projects are supposed to try new things!
How is HURD that different? What benifet does it provide the user that hasn't been seen elsewhere? HURD is, at best, a research OS. It has neither the mindshare nor the technological advances to become mainstream. If you compare it with other research OSs, its not very interesting even then. Sure everyone has a right to work on what they think is interesting, but people also have the right to call a particular project pointless and redundant.
Even I am not deluded enough that think that BeOS might yet stage a comeback. (I'd be ecstatic if it did, but it won't.) Yet, the passing of BeOS has left a hole in the OS world. There is, at the moment, no lightweight, powerful, fast desktop GUI OS. Windows is bloated and buggier than the rest (though XP is remarkably stable for a Windows OS), Linux (specifically the GNOME and KDE desktop environments) still have major speed and bloat issues, and MacOS-X can't even be considered because the majority of the world runs x86 (and will continue to do so for the forseeable future). There are several projects that are attempting to recreate BeOS and fill its niche (desktop OS, one hell of a niche!)
1) BeUnited. Trying to get Palm to license the BeOS source code. Probably won't work, but if they can do it, might be nice. Still, it won't be Open Source, and thus probably will not have the longevity to compete with Linux and Windows.
2) OpenBeOS. Trying to reimplement BeOS from scratch. Never going to happen, what kind of crack are they on? Good luck to them anyway.
3) BlueOS: A replacement for BeOS using X and the Linux kernel. So far, this seems to be the most promising. After all, Linux is a very nice kernel (after XFS and the low-latency patches are applied) and X is reasonably fast and has good 3D support. The main problem on Linux are the fragmented, slow as molases desktop environments, and that's the part they're concentrating on. If they are successful, it would be useful for all Linux (and beyond!) users, not just BeOS users.
Slashdot Mirror
Note to you: Don't complain that you can't use mainstream hardware on a non-mainstream OS. NVIDIA is being very nice just by supporting Linux, and it is not feasible for them to support every niche OS on the planet. Oh my GOD! They're thinking about business feasibility! They must be *evil* like Osama bin Laden!
The high level OpenGL code that comes from SGI isn't terribly well optimized. It is a reference implementation meant to be feature complete and correct, not fast. NVIDIA license the code from SGI and has spent the last several years hacking on it, ever since the original ICD came out with the Riva TNT-1. In that time, the code has probably changed a huge amount. Also, the high level code can have a lot of influence on how a card peforms. The OpenGL ICD driver is basically the entire OpenGL library. How it handles and optimizes the various calls made by the application to the driver makes a big difference in speed. For example, if the application calls for a certain set of rendering parameters, is the driver smart enough to take certain shortcuts based on those parameters to make rendering faster? A lot of this stuff is hardware independant, and the optimizations in the high level layer would help any 3D card.
Yes. This is exactly why NVIDIA's drivers are rock solid and run everything blazingly fast? If they use hacks to do that, then kudos to them! All I know is that everything from Quake to 3D Studio runs awesome on their drivers. Don't be stupid. The reason NVIDIA's drivers are so great are because they have been working on the same codebase for years (since halfway through the original Riva TNT's life cycle) and they had help from SGI on their OpenGL.
XFS historically has very bad delete performance. I don't think its the fault of the journal, since other things involving the journal (growing or creating files) aren't slow (though, ReiserFS does seem to have the best journaling code). I don't know what the official take on this is, but here's my theory. Most filesystems use a bitmap to keep track of free blocks. XFS, on the other hand, uses a pair of B+ trees to mange extents of free areas. This allows it to find better (more contiguous) blocks more quickly when an allocation has to be done. A bitmap, on the other hand, has to do a scan through the bits and can't afford to spend a lot of time looking in different places for the "best" place to allocate. However, when deleting a file, the bitmap approach already has all the addresses of the blocks, so its just a matter of clearing some bits. XFS, on the other hand, has to go ahead an reinsert the blocks back into the B+ tree, which takes many more disk access and much more time. Normally, this is an okay tradeoff, since you usually grow files more often than you delete (ie. you grow it many times while writing it out to 2GB, but delete the thing in one go). On systems like Squid server, on the other hand, you create and delete files like mad, so Reiser is often faster in that case.
Actually, the best filesystem on Linux right now for most uses is probably XFS. Its a little slow on deletes, and not as fast as Reiser for extremely small files, but from the stuff I've done with both (compiling, tar/untar, moving around directories, general workstation stuff) XFS is just as fast as Reiser for normal sized files, and much faster for large files. JFS is the dark horse here, though. I've seen some benchmarks showing it to have as good large file performance as XFS, but much better metadata (creating, deleting, growing, etc) performance. But there's not much info on it yet, and its not rock solid entirely.
Actually, the new journaling filesystems (ReiserFS, XFS, and JFS) are all *faster* than ext2. Also, journaling itself can cost very little these days because modern JFSs use large buffers and coalesce writes. For example, BFS achieves metadata performance nearly as high as ext2 on a heavily loaded system. So if all you're doing all day is creating/deleting/growing/shrinking files, the filesystem is only slightly slower. When you factor in all the performance improvements, it end up being faster.
Its really nifty. Its got attributes and ACLs and you can grow it without even rebooting!
I was kidding. The point was that we do the same things we've always done, except we use nifty new stuff to do it.
To all you OSS zealots out there, *this* is why NVIDIA's drivers are closed source. You can bet ATI would love to put this whole driver fiasco behind them and just steal the high level OpenGL code (an OpenGL driver has to implement the whole GL API, not just hardware interfacing) from NVIDIA's ICD.
Actually, that's *not* what they did. Carmack make's their hack quite clear. Like all applications, Quake only uses a limited amount of the OpenGL API. Because of that, the graphics driver can make certain assumptions that would normally break certain features, but really don't hurt anything since Quake doesn't use them. Thus, the program can run faster. Still, its pretty devious nonetheless. If they came up with some nifty hacks to make Quake 3 faster on their (cruddy) drivers, then they should have released this as a feature, not hidden it. The fact that it is hidden is what makes people think it is just there to cheat on benchmarks.
Intel doesn't make drivers for a CPU, and thus can't cheat on the drivers. And not even Intel is not messed up enough to design an entire instruction set just to cheat on a couple of Photoshop filters. The real reason that only certain Photoshop features were helped is because MMX is a very limited instruction set and only a few Photoshop filters could really take advantage of it.
Here it is, 2001, and we're still typing text in flat ascii files, remembering all of the arcane syntax and rules of the compiler, then submitting our attempts to it, awaiting its response.
>>>>>>>>>>>
Actually, a good many people now type text in flat unicode files.
I guess that shows how different hardware can be. On my machine, anyway (300MHz PII, 256MB, GeForce2 MX) the speed order of the widgets is: (slowest) Qt, Win98, GTK+, Win2K (fastest).
What's wrong with HDTV? At the high end, it carries a price premium of less than $1000. You can get a good Sony HDTV 53" for $2500 while a comparable Sony non-HDTV runs around $1800. Not a bad deal, considering a TV easily lasts you five or six years. Plus, there is a lot more programming these days, and (with new DVD players) DVDs look really good on HDTV.
Actually, GNOME is kinda weird. GNOME applications are fast, as long as you don't run the GNOME environment itself. Its amazing, the minute gnome-session starts, all GNOME apps seem to go into slow mo. If you use GNOME apps with a regular window manager, (like IceWM), its speedy. KDE, on the other hand, is always slow. Widgets just feel like they're moving through tar. Almost everything rubber-bands when resized. I think this might have a lot to do with Qt on Linux. While Qt on Windows performs well, it doesn't seem to on Linux. Most GTK+ apps can almost touch Windows in speed, but even simple KDE apps are far behind even complex Windows apps (ie. kmail is slower at most UI stuff than Word.
Also, Komba2 has the functionality of the Win2K browse service and more!
g++ 3.1 (because the minor release of g++ will break BC again).
>>>>>>>>>>>
Really? I thought 3.0 was supposed to have the set in stone, perfect C++ ABI?
But the XBox has a VGA output (and can interface to HDTV) so you CAN have hi-res console gaming!
You're looking at the developer level, not the user level.
>>>>>>>
And ultimately, that's what matters. One can't build a cathedral on the foundation of a wooden shack.
The graphics system features true transparency
>>>>>>>>
So does Win2K (good transparency too, you can play a video through a transparent window without any flicker), and its still an utterly useless feature. A nifty effect, yes. Worth the huge memory and performance problems in OS-X? No.
and full font antialiasing, something the X11-folks can only dream about.
>>>>>>>>>>
XFree86 4.X has incredible font support, with full antialiasing. The TrueType renderer (given a good font like MS WebFonts) is easily comparable to FontFusion (the best font renderer in existance, IMO), except maybe with respect to anti-aliasing medium-sized fonts (its a little blurrier than I'd like, but since most people don't antialias between 8 and 15 point anyway, it doesn't really matter).
but 10.1 is usable on my G3/300M, and next year, when the G5/2.4G will be released, accelerated OpenGL will be unnecessary.
>>>>>>>
It doesn't matter. For the forseeable future, graphics hardware will continue to outpace (by FAR) CPUs in imaging operations. Even if Quartz on a G5 2.4 GHz is bearable, you'll be able to do much more complex operations more quickly on even an entry level OpenGL card. Since OpenGL can accelerate most (all, given the right hardware) of the features present in Aqua, and almost all modern computers have 3D acceleration, it is a no-brainer to base a future imaging system on OpenGL.
That's probably the greatest post I've ever seen. You, sir, are a god among men...
Then, of course, there is urpmi which, despite its problems (like an extremely rigid idea of package servers), is one cool piece of software.
But isn't it a valid choice to reject choices? I mean, shouldn't there be a distro that standardizes everything, for users who don't want to deal with all the options? One man's choice is another man's chaos.
Not really. Even if you have an L4 HURD that is complete and stable, do you really have anything more than a stable, secure UNIX system? Those are a dime a dozen these days! The microkernel will not make it super-stable or super-secure, and competing OSs (which have the maturity of code that marks a stable/secure system) will be ahead of it in these respect for at least a decade or more. There is nothing in the HURD to justify its existance; it provides nothing to the world that doesn't already exist. Maybe that's fine for a research project, but IIRC, research projects are supposed to try new things!
How is HURD that different? What benifet does it provide the user that hasn't been seen elsewhere? HURD is, at best, a research OS. It has neither the mindshare nor the technological advances to become mainstream. If you compare it with other research OSs, its not very interesting even then. Sure everyone has a right to work on what they think is interesting, but people also have the right to call a particular project pointless and redundant.
Even I am not deluded enough that think that BeOS might yet stage a comeback. (I'd be ecstatic if it did, but it won't.) Yet, the passing of BeOS has left a hole in the OS world. There is, at the moment, no lightweight, powerful, fast desktop GUI OS. Windows is bloated and buggier than the rest (though XP is remarkably stable for a Windows OS), Linux (specifically the GNOME and KDE desktop environments) still have major speed and bloat issues, and MacOS-X can't even be considered because the majority of the world runs x86 (and will continue to do so for the forseeable future). There are several projects that are attempting to recreate BeOS and fill its niche (desktop OS, one hell of a niche!)
1) BeUnited. Trying to get Palm to license the BeOS source code. Probably won't work, but if they can do it, might be nice. Still, it won't be Open Source, and thus probably will not have the longevity to compete with Linux and Windows.
2) OpenBeOS. Trying to reimplement BeOS from scratch. Never going to happen, what kind of crack are they on? Good luck to them anyway.
3) BlueOS: A replacement for BeOS using X and the Linux kernel. So far, this seems to be the most promising. After all, Linux is a very nice kernel (after XFS and the low-latency patches are applied) and X is reasonably fast and has good 3D support. The main problem on Linux are the fragmented, slow as molases desktop environments, and that's the part they're concentrating on. If they are successful, it would be useful for all Linux (and beyond!) users, not just BeOS users.