Actually, XFS is faster than BFS, and has more features to boot. BFS is great because the system on top of it used its capabilities so well. Nothing prevents Linux desktops from using XFS the same way.
Honestly, the Linux kernel one-ups the BeOS kernel in several ways these days. BeOS development has stood still for several years, and in that timespan Linux has gotten better latencies (preempt patches), a killer filesystem (XFS), and improved graphics (XFree86 4.1/w NVIDIA drivers). The only things really left to improve are audio (integrate ALSA, ditch the stupid software mixers like esound and aRts) and the applications (compare ROX and GMC and you'll find out how crappily programmed most Linux GUI apps are).
BeOS simply [ab]uses threads more; using them where they are unnecessary and in too large a quantity...
>>>>>>>>>>>>&g t;
Only for developers too stupid to learn to do proper locking... Kernel developers deal with multithread issues on a regular basis (a SMP kernel behaves very similarly to a highly multithreaded application) and there seem to be no major stability problems in Solaris or Linux. Also, they abuse threads where it makes sense (the GUI). If you're doing much more in a GUI thread than drawing some pre-generated data, you're application design is wrong.
NT got destabilized because MS put the entire GUI in kernel space. Nobody is suggesting Linux do the same, they're suggesting that the graphics driver (which is much smaller and simpler) be put in kernel space. To tell the truth, BeOS did graphics best. The low level driver code was put in the kernel, while higher level acceleration was put in a userspace module. This meant that the graphics driver had the control over the hardware it needed (thanks to being in kernel space) and graphics calls were very fast (since most of the code was in userspace and thus no system calls were needed). NVIDIA adopts almost exactly the same architecture on XFree86. There is a kernel "resource manager" driver module to bang interrupts and such, while the majority of the rendering code is in module loaded into the X server.
Dude, why can't Linux people get their paradigms straight?
There is nothing wrong with lots of different filesystems. They all use the same API, so one can use whichever is best suited for one's task. XFS sacrifices metadate performance for awesome large file performance. ReiserFS sacrifices large file performance for small file performance. ext2 sacrifices saftey for update performance. Yet, you can use whichever suites you best, because, thanks to the VFS, they all look the same to user programs.
PS> I never understood why people complain about this, but not about the fact that there are so many toolkits, which unlike filesystems, have different APIs (and thus incompatible application bases). Maybe its time for a VTK (virtual toolkit) layer in X?
The thing is, Linux is also unstable for many people. For example, if I switch virtual terminals while starting a big GNOME program, I can crash the machine around half the time. I think that Linux is just in a rut. KDE people are too busy adding features to be bothered with stability, GNOME people don't have the caffine IV drips the KDE people got, so they have to work really hard just to keep up, and Linus has finally lost it and the kernel is worse for it. And GCC-3 is just plain broken. Maybe kernel 2.6, GCC-4.0, and KDE-3 will finally be the golden era of Linux. (I've been saying something similar since kernel 2.2, KDE 1.1.2, and GCC 2.95.x...)
I have a question. I've heard about enabling the hinter code, but how do you do it? Do you recompile XFree86, since it provides its own Freetype module?
Of course XP has nothing to do with 95, the point is that Microsoft has been singing the "more reliable, more stable" song since 95 was released.
>>>>>>>>>>>>&g t;
The delivered it with NT4.
They've yet to deliver on that promise fully, though you could make a case for NT/2000 in a server environment I suppose.
>>>>>>>>>>>>
Nobody in their right mind uses Windows on a server. Windows is for desktop machines, UNIX is for server machines. They are both improving on each other's areas, but Windows is still a stronger desktop machine that *NIX.
You have to fiddle around a little bit with the X setup (changing the display variable from 0 to 1), but in general you just have to log in as a different user and startx from the bash prompt.
The thing with BeOS threads is that they force you to seperate display logic from the actual program. This allows windows to redraw quickly without waiting for the application to catch up to it. This is a problem in many Linux GUI apps. Also, by seperating the display logic out, it takes away many of the pains of multithreading. The windowing thread shouldn't be doing anything super-complex, just displaying precomputed data. As such, multithreading shouldn't really make designing programs that much harder.
The problem with the 'daemon' idea is that it is out of the 1980s. Almost all sound hardware these days has hardware level mixing, so multiple apps (given proper drivers like ALSA) can open/dev/dsp at the same time. That ability makes aRts useless. However, you can't remove it, otherwise you'd lose all the cool media capabilities. So you're stuck with either crappy software mixed audio, or no media framework.
Sorry, but I have yet to see a GUI better than the Linux GUI. With the range of window managers, customisability and functionality, nothing comes close. With Windows or BeOS etc, you're limited to what they want to give you. With Linux, you can do whatever you want.
>>>>>>>>
A) Linux GUI's are slower than Windows GUI. Having used both extensively (IceWM and Win2K BTW) there is no arguement on that one.
B) Linux GUI's are less unifed that the Windows GUI. I think the whole "range of WMs" thing is perfectly fine. Different WMs interoperate nicely and give the user freedom. The problem is that you have several toolkit APIs that do the EXACT SAME THING (and usually do a mediocre job of it) and just take up lots of disk and memory. Note, there is nothing wrong with multiple toolkits, it fosters competition for better implementations. The original X people were perfectly right in making the WMs configurable. HOWVER, all the WMs run all programs equaly. That's not true of toolkits. You have GTK+ apps and Qt apps and GNOME apps, ad nauseum. There should be only X apps. The present situation in X does nothing more than give developers lots of freedom, not users.
How can you take seriously a hierarchy where every single program has its own directory? Imagine the $PATH for that one!
>>>>>>>
Only GUI apps get their own directory. Command line apps are all put in the same directory because they are usually self-contained. The best of both worlds, if you ask me.
Real OSes have each type of file (config file, binary, user files) in seperate directories, or even partitions if necessary. With Linux, to back up the setting, I merely have to back up/etc. And for user settings, I merely back up/home/$USER
>>>>>>>
What if you want to remove an application? Upgrade an application? Install/remove a library? The braindead UNIX FHS (for a GUI system anyway, its fine for a CLI system), is why we have all this RPM shit. (Which doesn't even work. RPM always leaves app droppings littering my system.)
On Windows, if I wanted to do that, I'd be there all day, hunting down things in the registry, in c:\windows and various subdirectories, in various c:\Progra~1 directories etc. So illogical, so disorganised, such a mess. And to think they charge so much money for that!
>>>>>>
Or you could just back up the registry! What a concept!
One nifty thing about 64bit memory addressing that is often missed is that it makes OS design tons easier. First, you can just contiguously map all of physical RAM permanantly instead of dynamically mapping in needed regions (like Linux high-mem). Even on many desktop machines, people are coming up to Linux's 1GB kernel-space address limit and having to use the more complex highmem code. Also, the 4GB address space of 32bit procs can become exteremly limiting when you have to deal with memory mapping large files and such. Lastly, library management becomes tons easier. Usually, libraries on 32 bit systems have to be relocated because the bases of their compiled images can conflict with those of another library. On a 64-bit arch, it is feasible to assign each library a unique base address and never have to relocate after the first time.
Geez, stop complaining about threads! There is nothing wrong with pervasive multi-threading. Given the crappy responsiveness of the Linux GUIs, Linux people are in no position to talk. A lossy messaging system (as in BeOS) is an implementation problem, not something wrong with threading. Just learn how to do proper locking and everything will be rosey. The kernel people have to deal with it all the time (SMP locks), its not that HARD.
You said C++ wasn't appropriate for a kernel, I pointed out that the kernel was in C. Second, there are hacks in other (C) OSs too. For example, paremeter passing to the kernel is always kinda ugly. Hacks are just a part of life in the kernel. Also, the C++ issues exist in Linux too. KDE/Qt gets around the FBC problem by breaking binary compatibility every major release. Given the smaller BeOS software base, the reserved function "hack" really isn't that bad.
Re:kernel pre-emption patch
on
Linux 2.4.13
·
· Score: 2
1) You're a moron.
2) C++ is just as useful as C in many kernel applications. For example, Linux has many implementations of lists, trees, etc. Using templating, you can get 99% of the advantages of having specialized lists for each datatype without the hassle of actually maintaining specialized lists. Also, Linux has a lot of structures filled with pointers to functions. ABC's fill that role much more cleanly. Operator overloading (like overriding 'new') also come in handy. Plus, its not like anyone is suggesting writing the kernel using STL or somesuch nonsense!
3) The BeOS kernel is written in 'C'.
Actually, there are lots of things that BeOS didn't do so well. VM and I/O was the major one. X also isn't that bad these days (especially on good hardware like NVIDIA's). There are actually few real technical problems Linux has left, most of them are organizational. For example
1) Sound is brain-dead. aRts on KDE has a great media framework, but doesn't support much of the hardware acceleration provided by APIs like ALSA. Since both KDE and GNOME are moving to aRts, this is a major step backwards for Linux in the multimedia department.
2) GUI is brain-dead. There is nothing wrong with having multiple WMs and desktops, but couldn't they have the courtesy to use the same API so I would only have to have the one I want on my machine?
3) FHS is brain-dead. The UNIX filesystem hierarchy is so 1970's. Real OSs put all applications in seperate directories along with their necessary libraries. OS-X's app bundle along with its XML config files is the greatest thing ever.
I'm a desktop user. I have no need for security beyond what my BSD firewall provides me with. And that's only because I have a DSL connection. Why exactly is security such a big concern on a desktop OS? Certainly, security (which *NIX does well) is much less of a concern than performance (which *NIX doesn't do so well...)
Actually, Windows 2000 is VERY suitable for games. Why? I thought you'd never ask:
1) Kernel tuning: The Win2K Pro kernel isn't a server kernel gussied up for the desktop. It shamelessly gives heavy preference to the foreground application (screw UNIXy ideals of "fairness") and gives boosts to media-oriented processes over other types of processes. For example, reading for a sound device gives you thread an 8 point temporary boost in priority while reading from disk gives you a 2 point boost.
2) DirectX: Still unmatched by any other multimedia API on the planet. Maybe OpenGL 2.0 + OpenML + OpenAL could kick its ass, but I have yet to see such a combo in use. What really sucks about Linux multimedia is the situation with audio. ALSA is great, but nothing really uses it that much. Then you have the brain-dead aRts and esound scheme which take a trip down memory lane to software mixing...
3) Hardware. Not only does Windows support more hardware, but it supports it better. More acceleration gets used and more features are implemented.
4) Simplicity: Packages don't work for gaming systems. While packages are nice in theory, RPM (I don't have much experience with Debian, but it isn't a player in this market anyway) sucks monkey balls when it comes to keep track of applications. I have yet to go through DLL-hell in Windows, but everytime I want to upgrade something, RPM puts me through a giant dependency chase/conflict resolution. urpmi is shaping up to be pretty great, but its still not there yet. For example, it often installs cruft that are supposedly dependencies for an app, but the app doesn't actually *require* them (the package maker thought they'd be nice to have).
Of course, Linux technically has a lot of advantages too. Its got a killer VM/IO system, and new memory hungry games can use that. It has great latency (with the new patches) which is good for audio. With a few tweeks (and a lot of changes to developer methodology) Linux could become more suitable for games than Windows. But it isn't right now.
That theory would be great if it were true. Because Win98 sucks, Win2k/XP is actually faster in many games these days. In terms of application performance, its faster there too. Direct'ness is out. Todays hardware is very abstracted to begin with, so Win98 DOS'ness really doesn't help. The better VM and I/O management of real 32 bit OSs outweigh any administrative costs.
Slashdot Mirror
Because X will always remain the fastest GUI on Linux, if only for the sole reason that that's what NVIDIA writes their drivers for.
Actually, XFS is faster than BFS, and has more features to boot. BFS is great because the system on top of it used its capabilities so well. Nothing prevents Linux desktops from using XFS the same way.
Honestly, the Linux kernel one-ups the BeOS kernel in several ways these days. BeOS development has stood still for several years, and in that timespan Linux has gotten better latencies (preempt patches), a killer filesystem (XFS), and improved graphics (XFree86 4.1 /w NVIDIA drivers). The only things really left to improve are audio (integrate ALSA, ditch the stupid software mixers like esound and aRts) and the applications (compare ROX and GMC and you'll find out how crappily programmed most Linux GUI apps are).
BeOS simply [ab]uses threads more; using them where they are unnecessary and in too large a quantity...
>>>>>>>>>>>>&g t;
Only for developers too stupid to learn to do proper locking... Kernel developers deal with multithread issues on a regular basis (a SMP kernel behaves very similarly to a highly multithreaded application) and there seem to be no major stability problems in Solaris or Linux. Also, they abuse threads where it makes sense (the GUI). If you're doing much more in a GUI thread than drawing some pre-generated data, you're application design is wrong.
NT got destabilized because MS put the entire GUI in kernel space. Nobody is suggesting Linux do the same, they're suggesting that the graphics driver (which is much smaller and simpler) be put in kernel space. To tell the truth, BeOS did graphics best. The low level driver code was put in the kernel, while higher level acceleration was put in a userspace module. This meant that the graphics driver had the control over the hardware it needed (thanks to being in kernel space) and graphics calls were very fast (since most of the code was in userspace and thus no system calls were needed). NVIDIA adopts almost exactly the same architecture on XFree86. There is a kernel "resource manager" driver module to bang interrupts and such, while the majority of the rendering code is in module loaded into the X server.
Dude, why can't Linux people get their paradigms straight?
There is nothing wrong with lots of different filesystems. They all use the same API, so one can use whichever is best suited for one's task. XFS sacrifices metadate performance for awesome large file performance. ReiserFS sacrifices large file performance for small file performance. ext2 sacrifices saftey for update performance. Yet, you can use whichever suites you best, because, thanks to the VFS, they all look the same to user programs.
PS> I never understood why people complain about this, but not about the fact that there are so many toolkits, which unlike filesystems, have different APIs (and thus incompatible application bases). Maybe its time for a VTK (virtual toolkit) layer in X?
The thing is, Linux is also unstable for many people. For example, if I switch virtual terminals while starting a big GNOME program, I can crash the machine around half the time. I think that Linux is just in a rut. KDE people are too busy adding features to be bothered with stability, GNOME people don't have the caffine IV drips the KDE people got, so they have to work really hard just to keep up, and Linus has finally lost it and the kernel is worse for it. And GCC-3 is just plain broken. Maybe kernel 2.6, GCC-4.0, and KDE-3 will finally be the golden era of Linux. (I've been saying something similar since kernel 2.2, KDE 1.1.2, and GCC 2.95.x...)
I have a question. I've heard about enabling the hinter code, but how do you do it? Do you recompile XFree86, since it provides its own Freetype module?
Of course XP has nothing to do with 95, the point is that Microsoft has been singing the "more reliable, more stable" song since 95 was released.
>>>>>>>>>>>>&g t;
The delivered it with NT4.
They've yet to deliver on that promise fully, though you could make a case for NT/2000 in a server environment I suppose.
>>>>>>>>>>>>
Nobody in their right mind uses Windows on a server. Windows is for desktop machines, UNIX is for server machines. They are both improving on each other's areas, but Windows is still a stronger desktop machine that *NIX.
You have to fiddle around a little bit with the X setup (changing the display variable from 0 to 1), but in general you just have to log in as a different user and startx from the bash prompt.
The thing with BeOS threads is that they force you to seperate display logic from the actual program. This allows windows to redraw quickly without waiting for the application to catch up to it. This is a problem in many Linux GUI apps. Also, by seperating the display logic out, it takes away many of the pains of multithreading. The windowing thread shouldn't be doing anything super-complex, just displaying precomputed data. As such, multithreading shouldn't really make designing programs that much harder.
The problem with the 'daemon' idea is that it is out of the 1980s. Almost all sound hardware these days has hardware level mixing, so multiple apps (given proper drivers like ALSA) can open /dev/dsp at the same time. That ability makes aRts useless. However, you can't remove it, otherwise you'd lose all the cool media capabilities. So you're stuck with either crappy software mixed audio, or no media framework.
Sorry, but I have yet to see a GUI better than the Linux GUI. With the range of window managers, customisability and functionality, nothing comes close. With Windows or BeOS etc, you're limited to what they want to give you. With Linux, you can do whatever you want.
/etc. And for user settings, I merely back up /home/$USER
>>>>>>>>
A) Linux GUI's are slower than Windows GUI. Having used both extensively (IceWM and Win2K BTW) there is no arguement on that one.
B) Linux GUI's are less unifed that the Windows GUI. I think the whole "range of WMs" thing is perfectly fine. Different WMs interoperate nicely and give the user freedom. The problem is that you have several toolkit APIs that do the EXACT SAME THING (and usually do a mediocre job of it) and just take up lots of disk and memory. Note, there is nothing wrong with multiple toolkits, it fosters competition for better implementations. The original X people were perfectly right in making the WMs configurable. HOWVER, all the WMs run all programs equaly. That's not true of toolkits. You have GTK+ apps and Qt apps and GNOME apps, ad nauseum. There should be only X apps. The present situation in X does nothing more than give developers lots of freedom, not users.
How can you take seriously a hierarchy where every single program has its own directory? Imagine the $PATH for that one!
>>>>>>>
Only GUI apps get their own directory. Command line apps are all put in the same directory because they are usually self-contained. The best of both worlds, if you ask me.
Real OSes have each type of file (config file, binary, user files) in seperate directories, or even partitions if necessary. With Linux, to back up the setting, I merely have to back up
>>>>>>>
What if you want to remove an application? Upgrade an application? Install/remove a library? The braindead UNIX FHS (for a GUI system anyway, its fine for a CLI system), is why we have all this RPM shit. (Which doesn't even work. RPM always leaves app droppings littering my system.)
On Windows, if I wanted to do that, I'd be there all day, hunting down things in the registry, in c:\windows and various subdirectories, in various c:\Progra~1 directories etc. So illogical, so disorganised, such a mess. And to think they charge so much money for that!
>>>>>>
Or you could just back up the registry! What a concept!
One nifty thing about 64bit memory addressing that is often missed is that it makes OS design tons easier. First, you can just contiguously map all of physical RAM permanantly instead of dynamically mapping in needed regions (like Linux high-mem). Even on many desktop machines, people are coming up to Linux's 1GB kernel-space address limit and having to use the more complex highmem code. Also, the 4GB address space of 32bit procs can become exteremly limiting when you have to deal with memory mapping large files and such. Lastly, library management becomes tons easier. Usually, libraries on 32 bit systems have to be relocated because the bases of their compiled images can conflict with those of another library. On a 64-bit arch, it is feasible to assign each library a unique base address and never have to relocate after the first time.
Geez, stop complaining about threads! There is nothing wrong with pervasive multi-threading. Given the crappy responsiveness of the Linux GUIs, Linux people are in no position to talk. A lossy messaging system (as in BeOS) is an implementation problem, not something wrong with threading. Just learn how to do proper locking and everything will be rosey. The kernel people have to deal with it all the time (SMP locks), its not that HARD.
You said C++ wasn't appropriate for a kernel, I pointed out that the kernel was in C. Second, there are hacks in other (C) OSs too. For example, paremeter passing to the kernel is always kinda ugly. Hacks are just a part of life in the kernel. Also, the C++ issues exist in Linux too. KDE/Qt gets around the FBC problem by breaking binary compatibility every major release. Given the smaller BeOS software base, the reserved function "hack" really isn't that bad.
Does it help?
1) You're a moron.
2) C++ is just as useful as C in many kernel applications. For example, Linux has many implementations of lists, trees, etc. Using templating, you can get 99% of the advantages of having specialized lists for each datatype without the hassle of actually maintaining specialized lists. Also, Linux has a lot of structures filled with pointers to functions. ABC's fill that role much more cleanly. Operator overloading (like overriding 'new') also come in handy. Plus, its not like anyone is suggesting writing the kernel using STL or somesuch nonsense!
3) The BeOS kernel is written in 'C'.
Because GNOME/KDE have the features over speed/elegance mentality that everyone hates MS for.
Actually, there are lots of things that BeOS didn't do so well. VM and I/O was the major one. X also isn't that bad these days (especially on good hardware like NVIDIA's). There are actually few real technical problems Linux has left, most of them are organizational. For example
1) Sound is brain-dead. aRts on KDE has a great media framework, but doesn't support much of the hardware acceleration provided by APIs like ALSA. Since both KDE and GNOME are moving to aRts, this is a major step backwards for Linux in the multimedia department.
2) GUI is brain-dead. There is nothing wrong with having multiple WMs and desktops, but couldn't they have the courtesy to use the same API so I would only have to have the one I want on my machine?
3) FHS is brain-dead. The UNIX filesystem hierarchy is so 1970's. Real OSs put all applications in seperate directories along with their necessary libraries. OS-X's app bundle along with its XML config files is the greatest thing ever.
I'm a desktop user. I have no need for security beyond what my BSD firewall provides me with. And that's only because I have a DSL connection. Why exactly is security such a big concern on a desktop OS? Certainly, security (which *NIX does well) is much less of a concern than performance (which *NIX doesn't do so well...)
Actually 1T-SRAM has been around for awhile. The GameCube uses some for main memory. See the /. article
Yea, I gagged a little myself the first time I read it. Until I remembered that HP was the one who put 1.5 MB caches on chips in the PII era.
Actually, Windows 2000 is VERY suitable for games. Why? I thought you'd never ask:
1) Kernel tuning: The Win2K Pro kernel isn't a server kernel gussied up for the desktop. It shamelessly gives heavy preference to the foreground application (screw UNIXy ideals of "fairness") and gives boosts to media-oriented processes over other types of processes. For example, reading for a sound device gives you thread an 8 point temporary boost in priority while reading from disk gives you a 2 point boost.
2) DirectX: Still unmatched by any other multimedia API on the planet. Maybe OpenGL 2.0 + OpenML + OpenAL could kick its ass, but I have yet to see such a combo in use. What really sucks about Linux multimedia is the situation with audio. ALSA is great, but nothing really uses it that much. Then you have the brain-dead aRts and esound scheme which take a trip down memory lane to software mixing...
3) Hardware. Not only does Windows support more hardware, but it supports it better. More acceleration gets used and more features are implemented.
4) Simplicity: Packages don't work for gaming systems. While packages are nice in theory, RPM (I don't have much experience with Debian, but it isn't a player in this market anyway) sucks monkey balls when it comes to keep track of applications. I have yet to go through DLL-hell in Windows, but everytime I want to upgrade something, RPM puts me through a giant dependency chase/conflict resolution. urpmi is shaping up to be pretty great, but its still not there yet. For example, it often installs cruft that are supposedly dependencies for an app, but the app doesn't actually *require* them (the package maker thought they'd be nice to have).
Of course, Linux technically has a lot of advantages too. Its got a killer VM/IO system, and new memory hungry games can use that. It has great latency (with the new patches) which is good for audio. With a few tweeks (and a lot of changes to developer methodology) Linux could become more suitable for games than Windows. But it isn't right now.
That theory would be great if it were true. Because Win98 sucks, Win2k/XP is actually faster in many games these days. In terms of application performance, its faster there too. Direct'ness is out. Todays hardware is very abstracted to begin with, so Win98 DOS'ness really doesn't help. The better VM and I/O management of real 32 bit OSs outweigh any administrative costs.