It'd be interesting to see this evolve into a reliable way to spin up a Linux or Windows VM with GPU passthrough. Since Haiku's GPU acceleration story is (last I checked) rather nonexistent, it seems like it'd be a good way to put an otherwise-unused GPU to use, so long as the GPU supports passthrough in the first place.
BeOS lives on. Relevant quote from Neil Stephenson’s In the Beginning was the Command Line [1], a fun commentary on early Mac, Windows, Linux, and BeOS competition.
”On the other side of the road are two competitors that have come along more recently.
One of them (Be, Inc.) is selling fully operational Batmobiles (the BeOS). They are more beautiful and stylish even than the Euro-sedans, better designed, more technologically advanced, and at least as reliable as anything else on the market--and yet cheaper than the others.
I used BeOS as my main driver for about a year and a half, back in the day.
One thing that we take for granted now was it supported low-latency concurrency, so its user interface felt really, REALLY snappy. You could launch 4-5 different videos, in different windows all playing at once, and there was absolutely no jitter and lag. Unless you grew up with the user interfaces of the mid-90's (Windows 3.1/95, MacOS 7.6), you won't appreciate just how mind-boggling this was.
The other big feature that unfortunately hasn't been broadly adopted by other operating systems was the file system. I know this one pretty well because I actually wrote my own driver for it (as a high school's hobby project mind you, so probably extremely cringe if I saw the source code again). BeOS didn't have a hierarchical file system so much as a relational database with built-in support for showing nested relationships as folders, and support for multi-megabyte blob types for the actual file data. Emails, for example, were stored with each header value as a separate column in the email table. If you opened your folder of emails, you could sort by sender, time received, subject, etc. just from the finder window. Within the BeOS API, you could write complex joins on the filesystem, e.g. between your emails and your contact list (which was also stored as metadata IIRC).
"BeOS was demonstrated to me during my senior year of college. The guy giving the talk played upwards of two dozen mp3s, a dozen or so movie trailers, the GL teapot thing, etc. simultanously. None of the apps skipped a beat. Then, he pulled out the showstopper.
"He yanked the plug on the box.
"Within 20 seconds or so of restarting, the machine was chugging away with all of its media files in the place they were when they were halted, as if nothing had happened.
From what I heard, the filesystem was very cool. You could attach arbitrary key-value pairs to files, and e.g. rather than store song metadata in ID3 tags or whatever, it was stored as filesystem metadata, making it searchable by any program without knowledge of a file's internals. As I recall reading, one could create a virtual folder that contained the results of a search, e.g. "all MP3 files where artist='Pink Floyd'" and use that as a playlist.
I have played around a bit with Haiku, but have not figured out how to do that so far.
if I recall, (and someone correct me if I'm wrong), it had deep multithreaded support/design, more so than any other desktop OS at the time, so it could run more simultaneous processes and apps w/o getting bogged down. at least I think there was a demo claiming this.
This was true at the time, but at the time Linux wasn't preemptive, had bad SMP support and no good threading implementation.
BeOS was designed for SMP hardware, was preemptive and had good threading support, but besides that there is nothing really especial about it. "pervasive multithreading" simply consisted in using threads a lot (for 90's definition of "lot"). Creating and managing the threads by hand. In 90's C++.
Modern operating systems have caught with that and gone beyond of what beos did.
I wouldn't say there was nothing special about it, given the limitations at the time. Having threads spawn quickly, and quickly move between threads so fast as to have no visible user latency was one hell of a feat on BeOS hardware--a 66MHz PowerPC dual-CPU system, IIRC.
But yeah, it's something we take for granted today.
yea it was cool dual CPU hardware:
https://en.wikipedia.org/wiki/BeBox
those two green lights on the front were CPU load per each CPU.
and the geekport reminscent of Raspberry pi
only later did they port it to x86, similar to NeXT.
Yeah, it didn't matter that it was cheap because you still had to install it and most people even today don't modify the OS their PC comes with.
I think BeOS had a restriction that they legally couldn't sell computers because of a situation with Apple similar to restriction that NeXT could only sell workstations.
I’ve never heard that they were restricted by Apple in any way (which may have been possible since Gasse and Sakoman left Apple to start Be). Do you have any reference?
The thing to know about the BeBox is that it's a cost centre. Every single Be fan who purchased a BeBox to "support the cause" drained limited cash and support from Be Inc. The idea is twofold, this demonstrates what to build, if you're making a new workstation you shouldn't care about what works well in Windows (not this) because SMP is the future, and this demonstrates how it's used, with the breakthrough applications that do not exist in 1995 on software like Windows 3.x or (Classic) MacOS.
So if you buy this and it goes in your spare bedroom because it's cool, maybe you run the demo to show a few friends, you've cost Be money and not helped them towards their goals.
What they want is a two man indie startup buys a BeBox and uses it to invent Zoom, or Blender, or at least Portal or something. Something that creates a significant demand from real users for Be's actual product, an operating system, and which is hard to replicate for the existing 1980s-style single CPU operating systems Be wants to compete with.
Ideally for JLG, this product attracts attention from Cupertino. If Be Inc. flops but Apple hire him back as new CEO, that's fine. If they buy Be Inc. and he gets to cash out and prove he was right too that's even better.
> Every single Be fan who purchased a BeBox to "support the cause" drained limited cash and support from Be Inc.
Did they sell the hardware at a loss?
> If you buy this and it goes in your spare bedroom because it's cool, maybe you run the demo to show a few friends, you've cost Be money and not helped them towards their goals.
If the hardware earns a small profit, and the enthusiast does not call the vendor for support, but creates blogs/video/media to generate user/developer/partner demand, that should be net positive for the vendor.
> What they want is a two man indie startup buys a BeBox and uses it to invent Zoom, or Blender, or at least Portal or something. Something that creates a significant demand from real users for Be's actual product, an operating system, and which is hard to replicate for the existing 1980s-style single CPU operating systems Be wants to compete with.
A variation of this text/sentiment should be included on the marketing page for every hardware "dev board", including Qualcomm SDXE dev device from ex-Apple team, that is attempting to compete with Apple Silicon and x86 PCs.
Sure, they're just examples of compelling software. I can't give real examples of software which compelled users to buy into Be's vision in huge number and made it a success, because in fact Be failed.
In practice there's always going to be a certain element of post-hoc justification as to why this or that software really mattered and how it "couldn't" have existed for other platforms.
No. I don't have any sources just vaguely remember reading (or watching?) something that mentioned that. I think it was like a non-compete agreement or something. It could all be just my imagination though.
If Jobs didn't return to Apple, that's probably what we would have got. Their exit strategy ended up being to get bought by Apple and provide BeOS as the new Mac OS X.
Dual 66MHZ 603 CPUs at first, and later dual 133MHZ 603e CPUs. For the time interesting, but hardly head and shoulders above the 200MHZ Pentium Pros of the same era.
For those who do like to modify their OS and appreciate the beauty of BeOS, there is a merge of Haiku with Genode [1]. It is pretty active and has much promise.
It's interesting that this was built to support QEMU – a lot of Haiku's tentpole applications are ports at this point (e.g. Firefox, GNU toolchain, etc.)
Why is it that this post is on the front page with no comments about the actual contents of the post and yet the first comment is about "the old BeOS days" again?
I guess that the lack of comments around this project indicates the extreme technical detail of low level operating system code which is over the heads of >90% of HN readers which I want to see such posts like this here rather than yet another copy-and-paste LLM project.
This report is nicely presented and offers a neat explanation into what was done around hardware-assisted virtualization with the goal of using the NetBSD NVVM driver in another OS to support this in QEMU.
This is a very common phenomenon, and it's especially apparent if you specialize in some area that is fashionable on HN. The right things to do are to upvote good hardcore technical specialist content, and to contribute comments in the same vein. Sometimes, with a really good story, there just isn't much to say anyways; there doesn't need to be.
