XP is on the order of 20-30% slower than Windows 2000. If that's isn't regressing, I don't know what is. MS is so concerned with 1% features (ie. features which only 1% of the userbase will take advantage of) that it is rebloating their OS. Win2K was unusually good for an MS product, but it seems that it was just a fluke.
As for product quality, just look at the numbers. Linux networking is faster and more stable than Windows. Almost every kernel operation is faster. The VM is more well tuned. The filesystems (XFS and ReiserFS) are faster and more stable. Basically anything in the kernel (except the server-oriented scheduler) is better. The GUI needs a lot of work, but compared to XP's, its actually snappy. The only thing Linux has left to do is to fix the toolkit mess and get X running faster (maybe twice as fast and it will compare to BeOS and Photon;)
KDE-2? KDE-1 lacks many features that Win2K has, which makes the comparison unfair. As for KDE-2, even with the obj-prelink extensions, Konqueror takes three or four times as long too start than IE. In fact, EVERY KDE-2 app takes three or four times longer than IE (or Visual Studio or even Word). And GNOME flickers a LOT more than Win2K. What kind of graphics card are you running? I'm using a RivaTNT with NVIDIA's drivers, so that's not the problem. (And yes, I've tried the renice -10 hack and the low latency patch and the HZ=1024 hack).
Oh please, the whole first sector bit is just semantics. If "boot loader" is a reserved term for that sector then his argument holds for some other term. Grub isn't an OS anymore than the OS/2 boot manager or System Commander is an OS.
>>>>>>>
And why not? Many toy OS kernels have less functionality than does GRUB.
Look at NetWare for example, where DOS is/was pretty much used exclusively as a 'bootloader' (Loads OS image, and jumps to it, then DOS is blown out of memory).
>>>>>>>>
Doesn't matter. Netware used the DOS bootloader. It might have used DOS to provide services to Netware (like reading the OS image from a filesystem), but the actual booting of the machine was done by DOS's bootloader. In that case the bootloader loaded an OS, which loaded a user program that wiped DOS out of memory and loaded another OS. In that case, there were two bootloaders, DOS's, and the user program that loaded Netware.
If you don't like the Standard Oil monopoly, stop using petroleum! If you don't like AT&T, stop using phones! If you don't like US Steel, stop using pots and trains and cars and shovels.
Are you suggesting that the of a compture requires the use of Microsoft products?
>>>>>>>>>>
Yes. And every desktop computer maker seems to agree with me.
According to Opensources.com, XFree86 is over 1.5 million lines of code. That is larger than the whole BeOS source tree. I'd say that that's pretty big, top or not. Both BeOS's GUI and QNX's GUI are less than 2MB in size, and QNX's GUI has even more functionality. I don't give a damn WHAT 'top' reports, X is too large.
Maybe if you run FVWM. But we're talking about a full desktop (GNOME or KDE) which is what you need to run if you want to compare with BeOS or Win2K that have the DE and GUI integrated. Either way, the whole shebang is slower than Windows 2000, which is just silly bad.
It depends on what you mean by support. Generally, I think of hardware support. And in that area BeOS has always lacked.
>>>>>>>>>
True.
Well, that depends on what you want to do with it in terms of media. Capture and edit video? Linux is current the best of the two with more applications and more video capture card support.
>>>>>>>
Well, supporting the most capture cards doesn't make on OS the best media platform. Right now, the best Media OS is Windows 2000, both because of its good performance and board hardware support. If Linus can keep his promise that 2.5 will fix many of the latency problems of 2.4, maybe Linux can pull ahead. After that, Linux will have to work on getting a good media environment, something it may never be able to do because of the sheer number of projects trying to do the same thing.
Unless you're talking about a CLI network application. If your lucky, you might be able to get it to compile. If your on God's good graces, you might be able to get it to run without bringing down the net server.
>>>>>>>
Yea, the net_server sucks. Acknowledged feature;)
And what shackles would that be? The shackles of anti-aliased fonts? The shackles of hardware accelerated 3D (something that BeOS has never really supported for more than the Voodoo cards through glide)?
>>>>
The shackles that make X slower and less responsive than even Win2K. The shackles that make the X codebase larger than the ENTIRE BeOS system. The shackles that make X fragmented and filled with competing, incompatible toolkits. Some people like the extra freedom. Some people are disgusted with the non-uniform waste of CPU and RAM that is the average Linux desktop. Many BeOS users happen to be the latter.
Pretenders to the throne are a good thing... It means that there's competition which, in general, leads to better products. BeoOS had great potential, and could have been the next in line, but Be Inc. dropped the ball.
>>>>>
I was being sarcastic.
MOSX really isn't in a position to challenge Linux, since the field of battle is x86, not PPC. The x86 regime is even more entrenched than Windows, Apple hardware still can't beat top-end x86 hardware, and its price/performance ratio sucks. Unless IBM and Motorola bring out some serious open PPC hardware at good prices (they won't neither company has the balls to go up against Intel) PPC will continue to be marginal.
Doubtful. MS is regressing technologicially. Linux is continually moving forwards. I am the last person to talk about Linux's success (I'm extremely critical of it even now), but undoubtedly Linux will beat Microsoft. Its starts in the server room. Sheer product quality CAN eventually defeat Microsoft, its just a very time intensive process. No closed company has the resources to follow that processes, but Linux community is big enough that it can fight MS indefintely.
I agree with you 100% The problem with BeOS was never the quality of the OS, but the development model. BeOS defintely should have been open sourced, because that is the only way an OS can survive competition with Microsoft. There were several problems with BeOS later in its development, praticularly with the VM. While Linux got a VM overhaul in a couple of months, BeOS's VM didn't improve at all over the period of a year or more. If the community had had access to the source, BeOS would probably be in a very different position today, both technologically and in terms of its userbase.
Hahaha, and how is that going to help us? Be fans LOVE to point out the "superior" technology in their beloved BeOS (I was once such a person:). However, that's probably one of the reasons BeOS is gone today. Too much arrogance, too little substance!!
>>>>>>>
All OS afectionados love to brag. At least BeOS users can brag and not lie. I've laid out several reasons why (as a Media OS) BeOS beats Linux. If you'd care to refute any of these, be my guest.
Funny, X is still around after all these years, while BeOS is going down the toilet faster than a turd spinning counterclockwise in Australia.
>>>>
So, the measure of a GUI's quality is how long its been around?
Why don't you port or rewrite the 'great' BeOS Interface Kit to X.
>>>>>>>>
Because it would then just be another stupid X toolkit.
You can get all features, including one thread per window on X today, no populair toolkit does this however.
>>>>>>>
Yes, that's because UNIX in general is loathe to enforce (or even promote) policy. Its all about huggy feely "you have the freedom to do whatever you want!" stuff. BeOS was designed to encourage highly multithreaded programs with fast GUIs. Aside from the window threading example you have so nicely pointed out, there is the fact that BeOS's API encourages developers to extensively use attributes. Again, you can do this on Linux too, but you don't see applications doing this prevasively, do you? Similarly, the messaging system encourages scriptable apps. While it is entirely possible in Linux, the system doesn't encourage that behavior, and thus you don't see a unified app scripting system in Linux. The media system is designed to encourage a modular, plug-in based approach with multiple programs sharing media streams. While this is also possible with Linux (well, on low latency patched kernels anyway) the lack of any central encouragement precludes large scale integration of media apps.
I know there is closed-source code out there that does exactly this. According to you people are probably begging for this functionality right now...So go on!
>>>>>
I don't know about closed source code, but I do know that BeOS's system isn't really possible on Linux right now. Neither Qt nor GTK+ are very thread-safe in their present states, which is why neither GNOME nor KDE use threads extensively. This should theoretically change with GTK+ 2.0 and Qt 3.0.
BTW, if you read the osnews.com forums you'll see that there are several serious issues with the BeOS pervasively mulit-threaded interface.
>>>>>>>>
Where? I looked through the entire BeOS board, couldn't find anything related to multithreading. Did searches for both "GUI" and "thread." "Thread" turned up on irrelevant hit, while "GUI" simply turned up some articles about improving the GUI. What posts are you referring to?
Your statement makes no sense. On x86 systems, a boot loader is something that resides on the first sector of a disk partition. The purpose of the bootloader is to load an OS image and jump to it. DOS isn't a boot loader. That's like saying Linux is a bootloader for X. DOS *has* a boot loader, which is a separate entity entirely. GRUB blurs the lines slightly (because it has many OS-type features such as a shell), but it's still a program that is contained in the first sector, and its sole purpose is still to load an OS image and jump to its starting location. Interestingly, it could be stated that GRUB is actually an OS, but its bootloader still retains a seperate identity.
If you want the abuse to stop, then DONT USE MICROSOFT PRODUCTS. EVER. PERIOD. END OF STORY.
>>>>>>>>
If you don't like the Standard Oil monopoly, stop using petroleum! If you don't like AT&T, stop using phones! If you don't like US Steel, stop using pots and trains and cars and shovels.
Real funny. There are parts of BeOS that aren't particularly stable (like net_server) but the guts have always been solid. Saying that it is buggy is just plain false.
Second, BeOS is probably just as well supported as Linux. There is a great user community, and I have yet to see the Linux equivilent of betips.net. Granted, commercial support on Linux is probably better, but given that BeOS runs a great deal of GNU code (like the entire CLI environment, for example) support on the application level is probably about the same.
As for taking a long time to come to market, that's false as well. BeOS had a solid journeling FS long before ReiserFS came out. BeOS had a great desktop environment (proudly based on the Mac GUI) before KDE and GNOME ever got their acts together. It had sub 3ms audio latencies when the low latency patches were just a gleam in Ingo Molnar's eye. BeOS had technology in 1997 that Linux is just getting today. In another year or two, one will be able to say that Linux is the greatest media OS on the planet. At its current pace of development, there is no doubt about that. However, that level of development will only compare to what BeOS was in 1998.
Enough with the focus shift BS. There have been two focus shifts in Be's history. First, they switched from IAs to desktops. Then, 8 years later, they switched back to IAs. It was a last ditch effort to save the company, and it gave people hope for a few more months. The focus shift was just a symptom of the fact that Be was on its way out, not a cause.
Yes, Be had a lack of applications. That's the problem that any alternative OS that doesn't use X must endure. OSS-types talk about freedom, but what about those who want to be free of the shackles of X?
Linux types always get mean about BeOS. My theory is that BeOS is the only thing out there that could possibly challenge Linux for technological supremacy. The BSD folks have already settled for the server market, and if WinXP is any indication of the future, it looks like MS won't be any competition. No, BeOS was the only thing that could have foiled Linux on the desktop. Well, the cornoation can preceed as scheduled. There are no more troublesome pretenders to the OS throne...
I just hope that acceleration arrives in a usable form. Most graphics cards have tons of 2D acceleration, but they are so tied to the GDI that other environments have a hard time making full use of them. In other words, instead of seeing "Aqua accelerators," I'd rather see "DPDF accelerators," or better yet, even more general "vector graphics accelerators."
1) Mach 3.0
2) Mach 3.0
3) Mach 3.0
4) HFS+: read my other post on why this minor update to the 20 year old HFS isn't very good at all.
5) Aqua: Sure its pretty. Sure its powerful. But it makes X seem snappy!
6) FreeBSD 3.2: Its a nice system, but all of the cool stuff is being done in the 4.0/5.0 branch. VM, SMP, security, etc.
7) Environment: OS-X is a mish-mash of OS9 programs running in a (large) compatibility layer, poor Wintel ports (IE 5), and a dearth of Carbonized apps. Meanwhile, Linux seems positively unified: running a KDE program in GNOME doesn't incur nearly as much of a system drain as running an OS9 program in OS-X. Plus, Linux is pure preemptive 32-bit apps all the way through, while many important OS-X apps still run in the cooperative kinda 32bit OS9 environment.
PS> If I seem down on Mach 3.0 that's because that kernel single handedly have microkernels a bad name...
It's interesting how much baggage OS-X carries with it. HFS+ is a lot worse than many people thought it was. Instead of having inodes, HFS+ uses a catalog file and an extent overflow file. The end result is that the fs is EXTREMELY single threaded, as every write access to either file has to lock it. As a result, the dual G4-800s seem a lot slower than they should be, especially if you're running disk-limited programs, which is true for the vast majority of home users.
Actually, I think people get the impression that the PDF rendering is slow because IIRC, Display Postscript renderers would generate a ps file then send it to a ps rasterizer. The resulting system was less than speedy. I don't know if Apple does it the same way, but I'd rather think that the GUI is slow because of a slow model rather than just plain crappy programming. As for OS-X, its slow largely because of Mach. The dated version of FreeBSD (3.2) doesn't help things, but the Mach 3.0 kernel is an absolute dog. Every so often a disscussion pops up on the HURD list about porting it to something better, but apparently they're quite stuck with it.
You mean like/etc?
>>>>>>>
Yes, UNIX is a normal OS./etc is a fine config structure. However, if you'd care to show me a *complete* list of config files in/etc that will let me configure *any* Linux distro, I'd be damn surprised. In theory/etc is great. In practice, it works out less well in non-propriatory *NIXs, simply by virtue of the fact that Open system types are loathe to enforce standards.
My Computer-> Manage->{pick one}, Network->properties->Local Area Network->properties->TCP/IP->properties, Taskbar->properties, etc, etc. Like a normal OS.
>>>>>>>>>>
Huh? The only stuff that's not configured via Control Panel (in Win2K at least) are object-specific things like the Taskbar properties. And for the sake of usability, object-specific config SHOULD be object-specific. The Windows convention is that things that you can't directly see on the screen are configured via the control panel, while everything else is configured by right-clicking on it an hitting properties. Might not be the most efficient thing concievable, but it works quite well in practice. Certainly a hell of a lot better than the mish-mash Linux has in place. For example, say I want to turn off anti-aliasing in Windows. I can just go to Control Panel -> Display -> Effects. In Linux I have to break out the Xterm, go hunt for a HOWTO on the net, then edit a xftconfig, a config file whose structure is different from every other config file on the system.
PS> And don't point me to some nifty KDE utility that does that for me. The user has to FIND these things, remember?
Because not everyone is a techno bigot. A hair is thin. Something that is 100,000 times thinner than a hair is REALLY thin. Very easy for us human types to understand.
I love the part where he kicks himself for taking 3 hours to figure out how to configure his TrackPad. The funny part is, that it would take ANYONE 3 hours to figure it out. That's because all normal OSs put all that configuration stuff in one place (be it a GUI panal or a tree of config files). Of course, all Linux distros have to be "special" so they all have different ways of configuring things. Still wondering why Linux hasn't taken over the world yet?
I don't know how much of a problem FBC is. GCC changes the C++ ABI often enough to make FBC a non-issue...
BeOS uses something of a hack, (and I presume AtheOS does something similar). There are some virtual functions that are left unused and all objects have some padding in them. Thus the structure of the object can change a little bit without breaking compatibility. There is an article on the Be solution that's pretty informative: here.
Slashdot Mirror
No, from the Anandtech articles.
XP is on the order of 20-30% slower than Windows 2000. If that's isn't regressing, I don't know what is. MS is so concerned with 1% features (ie. features which only 1% of the userbase will take advantage of) that it is rebloating their OS. Win2K was unusually good for an MS product, but it seems that it was just a fluke.
;)
As for product quality, just look at the numbers. Linux networking is faster and more stable than Windows. Almost every kernel operation is faster. The VM is more well tuned. The filesystems (XFS and ReiserFS) are faster and more stable. Basically anything in the kernel (except the server-oriented scheduler) is better. The GUI needs a lot of work, but compared to XP's, its actually snappy. The only thing Linux has left to do is to fix the toolkit mess and get X running faster (maybe twice as fast and it will compare to BeOS and Photon
KDE-2? KDE-1 lacks many features that Win2K has, which makes the comparison unfair. As for KDE-2, even with the obj-prelink extensions, Konqueror takes three or four times as long too start than IE. In fact, EVERY KDE-2 app takes three or four times longer than IE (or Visual Studio or even Word). And GNOME flickers a LOT more than Win2K. What kind of graphics card are you running? I'm using a RivaTNT with NVIDIA's drivers, so that's not the problem. (And yes, I've tried the renice -10 hack and the low latency patch and the HZ=1024 hack).
Oh please, the whole first sector bit is just semantics. If "boot loader" is a reserved term for that sector then his argument holds for some other term. Grub isn't an OS anymore than the OS/2 boot manager or System Commander is an OS.
>>>>>>>
And why not? Many toy OS kernels have less functionality than does GRUB.
Look at NetWare for example, where DOS is/was pretty much used exclusively as a 'bootloader' (Loads OS image, and jumps to it, then DOS is blown out of memory).
>>>>>>>>
Doesn't matter. Netware used the DOS bootloader. It might have used DOS to provide services to Netware (like reading the OS image from a filesystem), but the actual booting of the machine was done by DOS's bootloader. In that case the bootloader loaded an OS, which loaded a user program that wiped DOS out of memory and loaded another OS. In that case, there were two bootloaders, DOS's, and the user program that loaded Netware.
If you don't like the Standard Oil monopoly, stop using petroleum! If you don't like AT&T, stop using phones! If you don't like US Steel, stop using pots and trains and cars and shovels.
Are you suggesting that the of a compture requires the use of Microsoft products?
>>>>>>>>>>
Yes. And every desktop computer maker seems to agree with me.
According to Opensources.com, XFree86 is over 1.5 million lines of code. That is larger than the whole BeOS source tree. I'd say that that's pretty big, top or not. Both BeOS's GUI and QNX's GUI are less than 2MB in size, and QNX's GUI has even more functionality. I don't give a damn WHAT 'top' reports, X is too large.
Maybe if you run FVWM. But we're talking about a full desktop (GNOME or KDE) which is what you need to run if you want to compare with BeOS or Win2K that have the DE and GUI integrated. Either way, the whole shebang is slower than Windows 2000, which is just silly bad.
It depends on what you mean by support. Generally, I think of hardware support. And in that area BeOS has always lacked.
;)
>>>>>>>>>
True.
Well, that depends on what you want to do with it in terms of media. Capture and edit video? Linux is current the best of the two with more applications and more video capture card support.
>>>>>>>
Well, supporting the most capture cards doesn't make on OS the best media platform. Right now, the best Media OS is Windows 2000, both because of its good performance and board hardware support. If Linus can keep his promise that 2.5 will fix many of the latency problems of 2.4, maybe Linux can pull ahead. After that, Linux will have to work on getting a good media environment, something it may never be able to do because of the sheer number of projects trying to do the same thing.
Unless you're talking about a CLI network application. If your lucky, you might be able to get it to compile. If your on God's good graces, you might be able to get it to run without bringing down the net server.
>>>>>>>
Yea, the net_server sucks. Acknowledged feature
And what shackles would that be? The shackles of anti-aliased fonts? The shackles of hardware accelerated 3D (something that BeOS has never really supported for more than the Voodoo cards through glide)?
>>>>
The shackles that make X slower and less responsive than even Win2K. The shackles that make the X codebase larger than the ENTIRE BeOS system. The shackles that make X fragmented and filled with competing, incompatible toolkits. Some people like the extra freedom. Some people are disgusted with the non-uniform waste of CPU and RAM that is the average Linux desktop. Many BeOS users happen to be the latter.
Pretenders to the throne are a good thing... It means that there's competition which, in general, leads to better products. BeoOS had great potential, and could have been the next in line, but Be Inc. dropped the ball.
>>>>>
I was being sarcastic.
MOSX really isn't in a position to challenge Linux, since the field of battle is x86, not PPC. The x86 regime is even more entrenched than Windows, Apple hardware still can't beat top-end x86 hardware, and its price/performance ratio sucks. Unless IBM and Motorola bring out some serious open PPC hardware at good prices (they won't neither company has the balls to go up against Intel) PPC will continue to be marginal.
Doubtful. MS is regressing technologicially. Linux is continually moving forwards. I am the last person to talk about Linux's success (I'm extremely critical of it even now), but undoubtedly Linux will beat Microsoft. Its starts in the server room. Sheer product quality CAN eventually defeat Microsoft, its just a very time intensive process. No closed company has the resources to follow that processes, but Linux community is big enough that it can fight MS indefintely.
I agree with you 100% The problem with BeOS was never the quality of the OS, but the development model. BeOS defintely should have been open sourced, because that is the only way an OS can survive competition with Microsoft. There were several problems with BeOS later in its development, praticularly with the VM. While Linux got a VM overhaul in a couple of months, BeOS's VM didn't improve at all over the period of a year or more. If the community had had access to the source, BeOS would probably be in a very different position today, both technologically and in terms of its userbase.
Hahaha, and how is that going to help us? Be fans LOVE to point out the "superior" technology in their beloved BeOS (I was once such a person :). However, that's probably one of the reasons BeOS is gone today. Too much arrogance, too little substance!!
>>>>>>>
All OS afectionados love to brag. At least BeOS users can brag and not lie. I've laid out several reasons why (as a Media OS) BeOS beats Linux. If you'd care to refute any of these, be my guest.
Funny, X is still around after all these years, while BeOS is going down the toilet faster than a turd spinning counterclockwise in Australia.
>>>>
So, the measure of a GUI's quality is how long its been around?
Why don't you port or rewrite the 'great' BeOS Interface Kit to X.
>>>>>>>>
Because it would then just be another stupid X toolkit.
You can get all features, including one thread per window on X today, no populair toolkit does this however.
>>>>>>>
Yes, that's because UNIX in general is loathe to enforce (or even promote) policy. Its all about huggy feely "you have the freedom to do whatever you want!" stuff. BeOS was designed to encourage highly multithreaded programs with fast GUIs. Aside from the window threading example you have so nicely pointed out, there is the fact that BeOS's API encourages developers to extensively use attributes. Again, you can do this on Linux too, but you don't see applications doing this prevasively, do you? Similarly, the messaging system encourages scriptable apps. While it is entirely possible in Linux, the system doesn't encourage that behavior, and thus you don't see a unified app scripting system in Linux. The media system is designed to encourage a modular, plug-in based approach with multiple programs sharing media streams. While this is also possible with Linux (well, on low latency patched kernels anyway) the lack of any central encouragement precludes large scale integration of media apps.
I know there is closed-source code out there that does exactly this. According to you people are probably begging for this functionality right now...So go on!
>>>>>
I don't know about closed source code, but I do know that BeOS's system isn't really possible on Linux right now. Neither Qt nor GTK+ are very thread-safe in their present states, which is why neither GNOME nor KDE use threads extensively. This should theoretically change with GTK+ 2.0 and Qt 3.0.
BTW, if you read the osnews.com forums you'll see that there are several serious issues with the BeOS pervasively mulit-threaded interface.
>>>>>>>>
Where? I looked through the entire BeOS board, couldn't find anything related to multithreading. Did searches for both "GUI" and "thread." "Thread" turned up on irrelevant hit, while "GUI" simply turned up some articles about improving the GUI. What posts are you referring to?
Your statement makes no sense. On x86 systems, a boot loader is something that resides on the first sector of a disk partition. The purpose of the bootloader is to load an OS image and jump to it. DOS isn't a boot loader. That's like saying Linux is a bootloader for X. DOS *has* a boot loader, which is a separate entity entirely. GRUB blurs the lines slightly (because it has many OS-type features such as a shell), but it's still a program that is contained in the first sector, and its sole purpose is still to load an OS image and jump to its starting location. Interestingly, it could be stated that GRUB is actually an OS, but its bootloader still retains a seperate identity.
News flash.
If you want the abuse to stop, then DONT USE MICROSOFT PRODUCTS. EVER. PERIOD. END OF STORY.
>>>>>>>>
If you don't like the Standard Oil monopoly, stop using petroleum! If you don't like AT&T, stop using phones! If you don't like US Steel, stop using pots and trains and cars and shovels.
Real funny. There are parts of BeOS that aren't particularly stable (like net_server) but the guts have always been solid. Saying that it is buggy is just plain false.
Second, BeOS is probably just as well supported as Linux. There is a great user community, and I have yet to see the Linux equivilent of betips.net. Granted, commercial support on Linux is probably better, but given that BeOS runs a great deal of GNU code (like the entire CLI environment, for example) support on the application level is probably about the same.
As for taking a long time to come to market, that's false as well. BeOS had a solid journeling FS long before ReiserFS came out. BeOS had a great desktop environment (proudly based on the Mac GUI) before KDE and GNOME ever got their acts together. It had sub 3ms audio latencies when the low latency patches were just a gleam in Ingo Molnar's eye. BeOS had technology in 1997 that Linux is just getting today. In another year or two, one will be able to say that Linux is the greatest media OS on the planet. At its current pace of development, there is no doubt about that. However, that level of development will only compare to what BeOS was in 1998.
Enough with the focus shift BS. There have been two focus shifts in Be's history. First, they switched from IAs to desktops. Then, 8 years later, they switched back to IAs. It was a last ditch effort to save the company, and it gave people hope for a few more months. The focus shift was just a symptom of the fact that Be was on its way out, not a cause.
Yes, Be had a lack of applications. That's the problem that any alternative OS that doesn't use X must endure. OSS-types talk about freedom, but what about those who want to be free of the shackles of X?
Linux types always get mean about BeOS. My theory is that BeOS is the only thing out there that could possibly challenge Linux for technological supremacy. The BSD folks have already settled for the server market, and if WinXP is any indication of the future, it looks like MS won't be any competition. No, BeOS was the only thing that could have foiled Linux on the desktop. Well, the cornoation can preceed as scheduled. There are no more troublesome pretenders to the OS throne...
If its got a Mach kernel, the standard BSD filesystems should be available. Maybe FFS with softupdates?
I just hope that acceleration arrives in a usable form. Most graphics cards have tons of 2D acceleration, but they are so tied to the GDI that other environments have a hard time making full use of them. In other words, instead of seeing "Aqua accelerators," I'd rather see "DPDF accelerators," or better yet, even more general "vector graphics accelerators."
1) Mach 3.0
2) Mach 3.0
3) Mach 3.0
4) HFS+: read my other post on why this minor update to the 20 year old HFS isn't very good at all.
5) Aqua: Sure its pretty. Sure its powerful. But it makes X seem snappy!
6) FreeBSD 3.2: Its a nice system, but all of the cool stuff is being done in the 4.0/5.0 branch. VM, SMP, security, etc.
7) Environment: OS-X is a mish-mash of OS9 programs running in a (large) compatibility layer, poor Wintel ports (IE 5), and a dearth of Carbonized apps. Meanwhile, Linux seems positively unified: running a KDE program in GNOME doesn't incur nearly as much of a system drain as running an OS9 program in OS-X. Plus, Linux is pure preemptive 32-bit apps all the way through, while many important OS-X apps still run in the cooperative kinda 32bit OS9 environment.
PS> If I seem down on Mach 3.0 that's because that kernel single handedly have microkernels a bad name...
It's interesting how much baggage OS-X carries with it. HFS+ is a lot worse than many people thought it was. Instead of having inodes, HFS+ uses a catalog file and an extent overflow file. The end result is that the fs is EXTREMELY single threaded, as every write access to either file has to lock it. As a result, the dual G4-800s seem a lot slower than they should be, especially if you're running disk-limited programs, which is true for the vast majority of home users.
Actually, I think people get the impression that the PDF rendering is slow because IIRC, Display Postscript renderers would generate a ps file then send it to a ps rasterizer. The resulting system was less than speedy. I don't know if Apple does it the same way, but I'd rather think that the GUI is slow because of a slow model rather than just plain crappy programming. As for OS-X, its slow largely because of Mach. The dated version of FreeBSD (3.2) doesn't help things, but the Mach 3.0 kernel is an absolute dog. Every so often a disscussion pops up on the HURD list about porting it to something better, but apparently they're quite stuck with it.
Its just like GNU/BeOS, GNU/Win2K, GNU/OpenUNIX, GNU/Solaris, GNU/Tru64, and GNU/OSX!
You mean like /etc?
/etc is a fine config structure. However, if you'd care to show me a *complete* list of config files in /etc that will let me configure *any* Linux distro, I'd be damn surprised. In theory /etc is great. In practice, it works out less well in non-propriatory *NIXs, simply by virtue of the fact that Open system types are loathe to enforce standards.
>>>>>>>
Yes, UNIX is a normal OS.
My Computer-> Manage->{pick one}, Network->properties->Local Area Network->properties->TCP/IP->properties, Taskbar->properties, etc, etc. Like a normal OS.
>>>>>>>>>>
Huh? The only stuff that's not configured via Control Panel (in Win2K at least) are object-specific things like the Taskbar properties. And for the sake of usability, object-specific config SHOULD be object-specific. The Windows convention is that things that you can't directly see on the screen are configured via the control panel, while everything else is configured by right-clicking on it an hitting properties. Might not be the most efficient thing concievable, but it works quite well in practice. Certainly a hell of a lot better than the mish-mash Linux has in place. For example, say I want to turn off anti-aliasing in Windows. I can just go to Control Panel -> Display -> Effects. In Linux I have to break out the Xterm, go hunt for a HOWTO on the net, then edit a xftconfig, a config file whose structure is different from every other config file on the system.
PS> And don't point me to some nifty KDE utility that does that for me. The user has to FIND these things, remember?
Because not everyone is a techno bigot. A hair is thin. Something that is 100,000 times thinner than a hair is REALLY thin. Very easy for us human types to understand.
I love the part where he kicks himself for taking 3 hours to figure out how to configure his TrackPad. The funny part is, that it would take ANYONE 3 hours to figure it out. That's because all normal OSs put all that configuration stuff in one place (be it a GUI panal or a tree of config files). Of course, all Linux distros have to be "special" so they all have different ways of configuring things. Still wondering why Linux hasn't taken over the world yet?
I don't know how much of a problem FBC is. GCC changes the C++ ABI often enough to make FBC a non-issue...
BeOS uses something of a hack, (and I presume AtheOS does something similar). There are some virtual functions that are left unused and all objects have some padding in them. Thus the structure of the object can change a little bit without breaking compatibility. There is an article on the Be solution that's pretty informative: here.