Former Be employee here who ended up at Apple eventually. BeOS was way, way behind NeXTStep in so many ways. We also had fragile base class problems and had a lot of kernel issues. BeFS was cool but Dominic ended up at Apple (and is still there) so I feel Apple got generations of BeFS evolution. Jean Louis wanted an unrealistic price and Apple spent the smartest 400 million dollars that I can think of by buying NeXT. Apple got Steve, Avie, Bertrand and so many others. Many Be people ended up on board after journeys with Eazel and others. Some never made it to Apple due to their Danger/Android/Google paths. This saddens me even to this day.
Yeah, BeOS was nice in some ways but seriously overrated in these discussions.
The "database file system" was just a regular file system with a somewhat crude indexing system for xattrs. By crude I mean it was up to apps to manage indexes, i.e. it wasn't really useful as a cooperative scheme to help apps work together. Files that had an xattr before an index was created wouldn't be incorporated into a newly created index, so in practice it was only useful to help an app find its own data quicker assuming it stored each data item only in individual files. If you connected a storage device and labelled a file with an xattr, it just wouldn't show up in indexes at all unless an app had created an index on that device first. People hear "database file system" and assume it had similar features to an RDBMS but it didn't. And of course it suffered the conceptual problems that kill off most attempts to extend the FS into a DB; users don't want to interact with their data via a one-size-fits-all file explorer filled with confusing things like tree widgets, and devs don't want to end up exposing a pseudo-API to other apps for technical or business reasons.
The BeOS API had wider design issues too. C++ was one, as you note. Microsoft invented COM and NeXT invented Objective-C to dodge that. But the heavy use of multi-threading was another. People can't handle that even today, and they were doing this in 1995! It led to slick demoware but, as an HN commenter said last time, you could "deadlock the entire system". That was a Win3.1/MacOS Classic level design issue, but BeOS was targeting NT level hardware. When Be engineers went to Android and built a Be-inspired API, the first thing they did was tone down the multithreading and dump C++. The OS was less responsive but more stable and easier to program.
> When Be engineers went to Android and built a Be-inspired API, the first thing they did was tone down the multithreading and dump C++. The OS was less responsive but more stable and easier to program.
Yeah, Android sucked in responsiveness (gap still there but closer) compared to iOS. I guess it didn't matter given the ecosystem dynamics but it was frustrating to see the jankiness of the OS compared to the buttery smooth behavior on iOS.
To add a little detail, Objective C was created by Brad Cox and Tom Love who formed PPI/Stepstone, with NeXT becoming a customer when Steve Naroff left Stepstone for NeXT to add support in GCC
> Haiku OS, the open source project trying to recreate BeOS, was (and still is) proof that some dreams are too beautiful to die. It will never be the same as the original, but at least it tries. It’s like listening to a Beatles cover band: not the same thing, but it warms your heart.
I'm not an expert on Haiku but I feel like this is needlessly dismissive of a lot of hard work from some smart and passionate people. 25 years later and the hardware is different and more varied, the things people do with their computers is wildly different, and concerns around things like security and compatibility are very different.
Making an analogy that suggests it's a janky BeOS is just wrong. It's not worse, it's different. It might not be the original nostalgic vision the author wants, but that's what two decades does.
I was a Mac fan when it looked like BeOS was going to be the next Mac OS - some Mac magazines even sent bootable BeOS CD-ROMS. I remember booting my Performa to BeOS and being amazed how different the same hardware felt.
After OS X, I worked on a backend team for AT&T. Their entire mobile network at the time - billing, backend, customer service notes... ALL of it was in NeXTStep being streamed from centralized servers out to basic PCs running Citrix.
It was wild to know NeXT had made inroads so many places. I imagine that is why Steve had any sort of relationship with AT&T when he pitched the iPhone and got them to do it. They already saw he could deliver for them on a B&W NeXT-based product used well into the 2000s.
While M1 - M4 are fast. I still think macOS is relatively slow in terms of responsiveness / latency compared to BeOS even with M series. This probably go back to Early Windows or DOS where everything feels instantaneous.
Windows, instantaneous? Haha. I never used anything older than 3.0 but unless you mean those older versions indeed, nope - it never felt anything even close to “instantaneous”. (Unless you’re talking about how frequently it crashes).
Loading was slow indeed, even with DMA bound IDE drivers. But once they were in RAM, the latency from a PS2 input was almost nil, as if you were using a kitchen appliance.
The enraging thing is NeXTstep ran acceptably on a 25MHz 68040 (and okay on the 68030 --- the lucky folks had 33MHz "Turbo" '040 boards) --- the performance Rhapsody promised was amazing, but Adobe reneged on a free license of Display PostScript, and Apple spent 10 years recreating that as Quartz (née Display PDF) --- the transparency and drop shadows are nice, but I'd rather have the performance.
At that time, I was using similar performance hardware running Windows (a ThinkPad 755c), Mac OS (a Mac w/ a 68040 processor at my workplace --- can't recall which, I was eventually upgraded to a 9500/180MP), and my NeXT Cube (68040 25MHz) --- the Cube was the most reliable and nicest of them all.
> After OS X, I worked on a backend team for AT&T. Their entire mobile network at the time - billing, backend, customer service notes... ALL of it was in NeXTStep being streamed from centralized servers out to basic PCs running Citrix.
Oh, I would absolutely love to know more details about this. I'm fascinated by the history of telecoms. Would you consider writing a blog post about it? (Or if you prefer, my email is in my profile!)
Unrelated to my other comment, who owns the rights to BeOS these days? Palm seems to have sold it off to a company called ACCESS? But they don't seem to have any intention of doing anything with it, and I can't imagine the source is worth much to them. How reasonable is it for a company to push a two decade old project into the public (after taking the basic steps of deleting any licensed code and employee details)?
Extracting the licensed 3rd party code and doing the other cleanup needed to do a release would be a chore. I have done this for other code bases and it always ends up being a lot of work that involves lawyers.
The BeOS code wasn’t huge (I remember the tarball being 98mb) but there was licensed code in the codecs, drivers, compilers, dev tools, possibly in NetPositive and more.
It is cool to look at from a historical perspective, which would be the main reason to release it. I wouldn’t advise using the code as a foundation for any future project.
I think it would be interesting to involve the Computer History Museum. I suspect a lot of people would be passionate about helping to archive the project properly. There's a lot of educational value in it, I think.
I did use BeOS on a PC of that era. I was impressed, but it was a bit under-cooked.
In more recent times, I boot up Haiku-OS every time a new alpha version comes out. It certainly continues the tradition. But to my eyes it hasn't materially improved upon the decades old promise and fails to sufficiently take advantage of current hardware.
With due respect to the Haiku-OS developers, I think that too much valuable effort is expended on trying to port all and sundry apps to Haiku. I would have thought that making a decision to port a single product and doing it well would be far more effective. It isn't that hard to learn a different product. For example, I have with minimal effort made the transition from MS Office, to Apple Page, etc to LibreOffice. As long as I can do what I require, I'm willing to adopt whatever is the standard.
that would certainly explain this extremely bizarre excerpt:
>As a former Be employee recounted in the thread (one of those lucky ones who lived the dream from the inside): “You could deadlock the entire system, but I’ll be damned if your CD was going to stop playing perfectly. Not even a skip.” This, ladies and gentlemen, is poetry applied to computer science.
Tbh, today I'm kinda glad that BeOS hadn't "won". Using C++ for operating system APIs wasn't a great idea in hindsight, and even though BeOS' usage of C++ is quite sane it is unclear whether they would have resisted the pressure to move to 'modern' C++ with all its design warts.
Or in an alternative universe, maybe if Apple had bought BeOS, C++ might have developed into a different direction and look very different from the modern C++ in our universe.
>No decades-old Unix cruft, no Mach kernel heavy as an elephant, but an operating system born for multimedia, elegant as a Lamborghini and fast as… well, as a Lamborghini.
>Windows still with that thirty-year-old architecture dressed up as modern? Check. macOS accumulating cruft since Bush Sr. was president? Check.
said the man nostalgizing about a decade-old HN thread about a then-17-year-old operating system demo.
I love that BeOS/Haiku is still doing its thing, but I don't know what its thing is.
The only "killer app/feature" I know of for Be/Haiku is https://www.tunetrackersystems.com/status.html a radio station automation program, and it's in a weird state where they can't provide hardware that works reliably.
There are many features of BeOS I loved, but for some funny reason the one that just thoroughly won me over from day one was the three-second boot time on my crusty Mac. Might've been a bit of a cheat. You'd never know it. It was just glorious performance for the impatient.
Of course, that version of the OS didn't do a whole lot. By the time R5 rolled around, the boot time had grown quite a bit. It was still damn fast though.
The one which got me was the time I had music playing, a large C++ build going, and transferring video from a FireWire card with a tiny buffer simultaneously … and everything not only worked but the UI responsiveness didn’t change at all.
For reference, on that same PC I installed Win98 to play Baldur’s Gate. It bluescreened when I plugged in a Microsoft USB mouse. This was a representative experience.
Some seem to remember 95/98(SE) fondly but what I remember is them being unstable messes even on good hardware, an effect which was multiplied on the crappy bargain bin machines sold at Staples and the like.
Mac OS of the same vintage wasn’t a paragon of stability exactly, but its stability seemed have more rhyme/reason - there were programs and activities that had a tendency to make your system more crashy while others had little to no impact. You could kinda plan around it, and rebooting after doing the instability-causing thing would clear things up. 95/98(SE)’s instability felt a lot more random which for me made it more day-ruining.
Windows didn’t feel appreciably more stable than the competition until they finally ditched that crappy 9x kernel with Windows 2000, but that release wasn’t intended for general users, which is a shame because it was just as stable as the post-SP1 XP was, maybe more. Consumers got cheated with Windows ME.
Yeah, macOS 7-9 had known weaknesses (e.g. burning CD coasters or skipping audio if you held down the mouse button, keeping it in an interrupt handler) but they were more deterministic and people could avoid them.
The DOS-based Windows versions were just plain bad, and only Microsoft’s illegal product tying kept competitors off of the market. Windows NT 3 was at least stable, but they made it worse moving drivers into the kernel for performance in 4, and it took decades to repair the security damage that caused.
Back then booting and rebooting was something you did so many times (or at least when you “wanted to use the computer”) - my first experience with Linux was colored by “how fast did it boot”?
I solved that problem by compiling my own kernel. The speedup was dramatic. Of course, that was back in the days when an interested hobbiest could compile a lean kernel without fear of breaking dozens of things.
That was Gentoo for me - it took forever to build but then the realization that all this autoprobes and other self-configuring things were taking an awful long time.
I remember years of avoiding DHCP because if the client daemon didn’t get a response boot would hang waiting for it to time out …
The irony is that I started recompiling the kernel because it wouldn't detect a SCSI card unless parameters were passed to the kernel ... then I learned how long autoprobing was taking for hardware that I didn't even have!
Did Gentoo provide much of a performance bump back then? I never really bothered with it since I was stuck with a 486 for the longest time, and by the time I did upgrade distributions were starting to offer "i586" builds (or something to that effect).
The real performance gains were just about the -i386 to pentium jump; a bunch of distros only shipped the most compatible code and didn’t use the newer instructions.
I always found that optimizing for size and using the exact march/mcpu worked nicely.
But the biggest part I liked was being able to turn off features I didn’t need (like mpg123 in a headless server NOT pulling in X).
I fondly remember running beos5 PE on a computer with a amd k6 processor and ati tv wonder card. I think it was 400Mhz, maybe 600 and 192MB ram. Watched in awe as it purrr'd editing DVs from firewire and the turner. It was a glorious multimedia OS. BeDepot was awesome too! The ports for winamp (BeAmp), zsnes and genecyst/dgens were top notch. the hw support was great too. never had an issue with MS Sidewinder gamepad (gameport and usb versions).
Taligent (a failed Apple/IBM joint OS), Amiga, and I'm not sure what UUS is. It's also funny to give Copland the Linux logo since those are completely unrelated.
This is an obvious AI SEO spam site. Kinda interesting how AI has "innovated" here by making it viable to make SEO spam sites about extremely niche topics because generating the slop articles/pictures costs pennies.
for the windows and mac users the lack of preinstalls and lack of apps might have been what killed beos, but for the linux users who might have been tempted to experiment (i was one!) it was the lack of drivers that delivered the death blow. i was perfectly happy to install the os myself and use it for whatever i could, but it did not support my network card and that was that.
Almost every post has a comment along these lines. I think at this point everyone on this site knows to keep an eye out for AI-assisted or AI-written articles, but do we need to comment on every post?
After all, AI sounds like people. So it's pretty unremarkable when something sounds like AI, which sounds like writers.
So much great tech has been lost to aggressive business practices of entrenched companies it would have disrupted.
The theme has been repeated... repeatedly: VHS vs Beta being maybe the typically cited archetype of business model vs technical specs.
To me the dominant example in the world today though, is that s/w engineers continue to use windows 8-(
C:? Does anyone ever stop to think about the abstraction of a file system directory hierarchy? The whole point is to remove the specifics of the h/w implementing it, and provide a logical abstraction of nested "directories". Explicitly specifying drive "letters", is the opposite of that. The only reason it ever existed was because the primordial DOS didn't have the horsepower to manage something like a unix mount. But why do we still have it in 2025?
Business triumphs over technology.
One aspect of the article that didn't track my experience was the description of linux in 2015. By that point I had long ago settled onto the fluxbox window manager, because I didn't like the constant churn of "desktop environments". It all just seemed too much like windows.
In 2025 I'm still using it, and it's still exactly the same, which to me is one of it's greatest features. Personally, I don't want the latest brainchild of some UI engineer at Canonical disrupting my workflow.
This veto power of equity over technical possibility is the story of modern tech development. Cory Doctorow cites this 2014 article in his post today:
tl;dr US political policy making is 100% controlled by large financial equity stake holders. The support, for or against, a policy by the overwhelming majority of the population has a 0% effect.
This is also true of corporate decisions. "Innovation" is pursued if and only if it benefits equity, regardless of potential advantages to users, or the progress of the tech itself.
Windows NT had the ability do away with drive letters since maybe the beginning; I was certainly running NT 4 and Windows 2000 like this. The problem I think is that every legacy app would instantly break if they couldn’t use drive letters and Microsoft doesn’t care enough to prioritize migrating away from drive letters. This, I believe, is a great example of MS having no taste (as Steve Jobs pointed out).
There were reasons for drive letters. It was common to have floppy-only systems back in the day, so you were switching out floppies for everything from running software to accessing your data. The drive letter was the most meaningful way to identify where you were looking for that data.
Later on, when hard drives were common, people still used things like floppies and optical media. Drive letters were still more meaningful in that context. Drive letters started losing their relevance with USB mass storage (especially when the media was the device), and are minimally relevant today (when external storage is far more likely to be on the network).
The lack of proper abstraction sucks when you have multiple hard drives, but I'm pretty sure that Windows has taken care of that from several angles. Those features simply aren't used often. (And, since I'm not a Windows user, take that bit with a grain of salt.)
No way. AmigaDOS in 1985 referred to all disks either by device name (like DH0: for Disk, Hard, number 0 or DF1: for Disk, Floppy, number 1) or label (like "Workbench:" or "Work:" or "Defender of the Crown 2:"). If a program tried to open "Some App 2:datafile", the OS would prompt you to insert the disk named "Some App 2".
Drive letters were a poor alternative even way back then.
It was also very handy that you could arbitrarily assign names to folders and have them be treated across the system as a volume name. Got some non-copyprotected software that expects to run from the volume name of the floppy? Copy the contents of the disk into a folder, assign the volume name of the floppy to that folder, and it will most likely just work. If it's a self-booting disk you may also need to copy the contents of some system folders into your actual system folders (c, libs, devs, etc) but other than that, with regards to the filesystem, volume assigns were very powerful (and in OS 2.0 and up you could also chain these assigns across different folders)
Beta wasn't better than VHS. It was better at a given tape speed, but the cassettes were smaller, so you'd have to use a lower speed to get the same recording time.
The "database file system" was just a regular file system with a somewhat crude indexing system for xattrs. By crude I mean it was up to apps to manage indexes, i.e. it wasn't really useful as a cooperative scheme to help apps work together. Files that had an xattr before an index was created wouldn't be incorporated into a newly created index, so in practice it was only useful to help an app find its own data quicker assuming it stored each data item only in individual files. If you connected a storage device and labelled a file with an xattr, it just wouldn't show up in indexes at all unless an app had created an index on that device first. People hear "database file system" and assume it had similar features to an RDBMS but it didn't. And of course it suffered the conceptual problems that kill off most attempts to extend the FS into a DB; users don't want to interact with their data via a one-size-fits-all file explorer filled with confusing things like tree widgets, and devs don't want to end up exposing a pseudo-API to other apps for technical or business reasons.
The BeOS API had wider design issues too. C++ was one, as you note. Microsoft invented COM and NeXT invented Objective-C to dodge that. But the heavy use of multi-threading was another. People can't handle that even today, and they were doing this in 1995! It led to slick demoware but, as an HN commenter said last time, you could "deadlock the entire system". That was a Win3.1/MacOS Classic level design issue, but BeOS was targeting NT level hardware. When Be engineers went to Android and built a Be-inspired API, the first thing they did was tone down the multithreading and dump C++. The OS was less responsive but more stable and easier to program.
Yeah, Android sucked in responsiveness (gap still there but closer) compared to iOS. I guess it didn't matter given the ecosystem dynamics but it was frustrating to see the jankiness of the OS compared to the buttery smooth behavior on iOS.
I'm not an expert on Haiku but I feel like this is needlessly dismissive of a lot of hard work from some smart and passionate people. 25 years later and the hardware is different and more varied, the things people do with their computers is wildly different, and concerns around things like security and compatibility are very different.
Making an analogy that suggests it's a janky BeOS is just wrong. It's not worse, it's different. It might not be the original nostalgic vision the author wants, but that's what two decades does.
After OS X, I worked on a backend team for AT&T. Their entire mobile network at the time - billing, backend, customer service notes... ALL of it was in NeXTStep being streamed from centralized servers out to basic PCs running Citrix.
It was wild to know NeXT had made inroads so many places. I imagine that is why Steve had any sort of relationship with AT&T when he pitched the iPhone and got them to do it. They already saw he could deliver for them on a B&W NeXT-based product used well into the 2000s.
No kidding. It took until the M1 to make macOS feel anything close to the responsiveness of BeOS on a 150MHz PowerPC.
Nothing else is as fast, I don't get slowed down by it
Even cursor movement on modern macOS is slow
Windows would chug from all sorts of issues, but some things did feel instantaneous.
I had a B&W '030 NeXTStation and it took 5+ minutes to boot and a long time to launch apps, I wish I'd had a turbo!
Oh, I would absolutely love to know more details about this. I'm fascinated by the history of telecoms. Would you consider writing a blog post about it? (Or if you prefer, my email is in my profile!)
Well iPhone was launched with Cingular, which wasn't AT&T at the time.
New AT&T Wireless bought Cingular later
The BeOS code wasn’t huge (I remember the tarball being 98mb) but there was licensed code in the codecs, drivers, compilers, dev tools, possibly in NetPositive and more.
It is cool to look at from a historical perspective, which would be the main reason to release it. I wouldn’t advise using the code as a foundation for any future project.
In more recent times, I boot up Haiku-OS every time a new alpha version comes out. It certainly continues the tradition. But to my eyes it hasn't materially improved upon the decades old promise and fails to sufficiently take advantage of current hardware.
With due respect to the Haiku-OS developers, I think that too much valuable effort is expended on trying to port all and sundry apps to Haiku. I would have thought that making a decision to port a single product and doing it well would be far more effective. It isn't that hard to learn a different product. For example, I have with minimal effort made the transition from MS Office, to Apple Page, etc to LibreOffice. As long as I can do what I require, I'm willing to adopt whatever is the standard.
>As a former Be employee recounted in the thread (one of those lucky ones who lived the dream from the inside): “You could deadlock the entire system, but I’ll be damned if your CD was going to stop playing perfectly. Not even a skip.” This, ladies and gentlemen, is poetry applied to computer science.
Or in an alternative universe, maybe if Apple had bought BeOS, C++ might have developed into a different direction and look very different from the modern C++ in our universe.
>Windows still with that thirty-year-old architecture dressed up as modern? Check. macOS accumulating cruft since Bush Sr. was president? Check.
said the man nostalgizing about a decade-old HN thread about a then-17-year-old operating system demo.
NT continues to do many things correctly. Linux continues to do many things correctly. macOS continues to exist. Etc.
The only "killer app/feature" I know of for Be/Haiku is https://www.tunetrackersystems.com/status.html a radio station automation program, and it's in a weird state where they can't provide hardware that works reliably.
Of course, that version of the OS didn't do a whole lot. By the time R5 rolled around, the boot time had grown quite a bit. It was still damn fast though.
For reference, on that same PC I installed Win98 to play Baldur’s Gate. It bluescreened when I plugged in a Microsoft USB mouse. This was a representative experience.
Mac OS of the same vintage wasn’t a paragon of stability exactly, but its stability seemed have more rhyme/reason - there were programs and activities that had a tendency to make your system more crashy while others had little to no impact. You could kinda plan around it, and rebooting after doing the instability-causing thing would clear things up. 95/98(SE)’s instability felt a lot more random which for me made it more day-ruining.
Windows didn’t feel appreciably more stable than the competition until they finally ditched that crappy 9x kernel with Windows 2000, but that release wasn’t intended for general users, which is a shame because it was just as stable as the post-SP1 XP was, maybe more. Consumers got cheated with Windows ME.
The DOS-based Windows versions were just plain bad, and only Microsoft’s illegal product tying kept competitors off of the market. Windows NT 3 was at least stable, but they made it worse moving drivers into the kernel for performance in 4, and it took decades to repair the security damage that caused.
I remember years of avoiding DHCP because if the client daemon didn’t get a response boot would hang waiting for it to time out …
Did Gentoo provide much of a performance bump back then? I never really bothered with it since I was stuck with a 486 for the longest time, and by the time I did upgrade distributions were starting to offer "i586" builds (or something to that effect).
I always found that optimizing for size and using the exact march/mcpu worked nicely.
But the biggest part I liked was being able to turn off features I didn’t need (like mpg123 in a headless server NOT pulling in X).
And what are the tombstones of TALIGN1, Amigo, and UUS?
After a couple demos showing the CPU leds, it just sat there for years, doing nothing but consuming power.
But nothing about the recently mentioned https://cosmoe.org ?
Or their former port to run it atop of Linux, like hosted AROS, or plan 9 from userspace?
After all, AI sounds like people. So it's pretty unremarkable when something sounds like AI, which sounds like writers.
So much great tech has been lost to aggressive business practices of entrenched companies it would have disrupted.
The theme has been repeated... repeatedly: VHS vs Beta being maybe the typically cited archetype of business model vs technical specs.
To me the dominant example in the world today though, is that s/w engineers continue to use windows 8-(
C:? Does anyone ever stop to think about the abstraction of a file system directory hierarchy? The whole point is to remove the specifics of the h/w implementing it, and provide a logical abstraction of nested "directories". Explicitly specifying drive "letters", is the opposite of that. The only reason it ever existed was because the primordial DOS didn't have the horsepower to manage something like a unix mount. But why do we still have it in 2025?
Business triumphs over technology.
One aspect of the article that didn't track my experience was the description of linux in 2015. By that point I had long ago settled onto the fluxbox window manager, because I didn't like the constant churn of "desktop environments". It all just seemed too much like windows.
In 2025 I'm still using it, and it's still exactly the same, which to me is one of it's greatest features. Personally, I don't want the latest brainchild of some UI engineer at Canonical disrupting my workflow.
This veto power of equity over technical possibility is the story of modern tech development. Cory Doctorow cites this 2014 article in his post today:
https://www.cambridge.org/core/journals/perspectives-on-poli...
tl;dr US political policy making is 100% controlled by large financial equity stake holders. The support, for or against, a policy by the overwhelming majority of the population has a 0% effect.
This is also true of corporate decisions. "Innovation" is pursued if and only if it benefits equity, regardless of potential advantages to users, or the progress of the tech itself.
Later on, when hard drives were common, people still used things like floppies and optical media. Drive letters were still more meaningful in that context. Drive letters started losing their relevance with USB mass storage (especially when the media was the device), and are minimally relevant today (when external storage is far more likely to be on the network).
The lack of proper abstraction sucks when you have multiple hard drives, but I'm pretty sure that Windows has taken care of that from several angles. Those features simply aren't used often. (And, since I'm not a Windows user, take that bit with a grain of salt.)
Drive letters were a poor alternative even way back then.
https://learn.microsoft.com/en-us/windows/win32/fileio/namin...
And of course, NT can do mount points.