BeOS was my primary operating system for a couple of years (I even bought the Professional Edition…I might still have the box somewhere). Did my research and built a box that only had supported hardware - dual Celeron processors, 17” monitor at 1024x768, and some relatively large disk for the time.
I remember downloading it and playing around with it (maybe it was small enough to boot from a floppy?) but I couldn’t do anything useful with it. Was a bit too young as well, I guess today I could make do better with unfamiliar stuff.
It was my daily driver. 99% of my work at the time involved being connected to a remote device (routers and firewalls mostly), and BeOS could do that just fine.
It was a great system. There hasn’t been a better one since.
I had triple boot machine - Windows/Linux/BeOS that time. I used BeOS mainly to learn C++ programming. Their GUI toolkit was at that time quite nice - much nicer than MFC :)
Ah, my bad. I don’t remember the motherboard; this was 20 years ago. Sadly, I haven’t built my own since…probably 2002? I’m so out of the loop it’s not even funny.
(Unless you count putting a Raspberry Pi in a little plastic case as “building your own machine”. If so, then…it’s still been a few years.)
oh that’s quite OK. The BP-6 was quite famous in that era for allowing SMP with celerons that were built to disallow it. It was quite a popular choice for x86 BeOS at the time.
I used BeOS as my primary OS for a year or so, eventually dual-booting with Linux and then dropping it altogether.
Many things about BeOS were sort of incredible. Booted in a couple seconds on the machines of the era, easily 5-10x more quickly than Linux. One of the “demos” was playing multiple MP3 files backwards simultaneously, a feat that nothing else could really do at the time, or multiple OpenGL applications in windows next to each other. The kernel really did multiprocessing in a highly responsive, very smooth way that made you feel like your machine was greased lightning, much faster than it felt under other OSes. This led to BeOS being used for radio stations, because nothing you were doing in the foreground stood a chance of screwing up the media playback.
BeOS had a little productivity suite, Gobe Productive. It had an interesting component embedding scheme, I guess similar to what COM was trying to be, so you just made a “document” and then fortified it with word processing sections or spreadsheet sections.
There were a lot of “funny” things about BeOS that were almost great. Applications could be “replicants,” and you could drag the app out of the window frame and directly onto your desktop. Realistically, there were only a couple for which this would be useful, like the clock, but it was sort of like what “widgets” would become in a few years with Windows and Mac OS X.
The filesystem was famous for being very fast and for having the ability to add arbitrary metadata to it. The mail client was really just a mail message viewer; the list of messages was just a Tracker window (like Finder) showing attributes for To, From, Subject, etc. Similarly, the media player was just able to play one file, if you wanted a playlist, you just used Tracker; the filetype, Title, Artist, Album, etc. were just attributes on the file. I’m not entirely sure how it parsed them out, probably through a plugin or something. You could do what we now call “smart searches” on Mac OS X by saving a search. These worked just like folders for all the apps.
The POSIX compatibility was only OK. I remember it being a little troublesome to get ports of Unix/Linux software of the era going. At the time, using a shittier browser than everyone else wasn’t really a major impediment to getting anything done, so usually I used NetPositive. There was a port of Mozilla, but it was a lot slower, and anyway, NetPositive gave you haiku if something went wrong.
There were not a huge number of applications for BeOS. I think partly it was a very obscure thing to program for. There were not a lot of great compatibility libraries you could use to easily make a cross-platform app with BeOS as a target. I wasn’t very skilled at C++ (still am not) but found trying to do a graphical app with BeOS and its libraries a pretty huge amount of work. Probably it was half or less the work of doing it in Windows, but you had to have separate threads for the app and the display and send messages between them, and it was a whole thing. Did not increase my love for C++.
All in all, it was a great OS for the time. So much of my life now is spent in Emacs, Firefox and IntelliJ that if I had those three on there I could use it today, but it was such an idiosyncratic platform I imagine it would have been quite difficult to get graphical Emacs on there, let alone the others. But perhaps it’s happening with Haiku.
the filetype, Title, Artist, Album, etc. were just attributes on the file. I’m not entirely sure how it parsed them out, probably through a plugin or something.
Querying was built into the filesystem. There was a command-line query, too. So many applications became so much simpler with that level of support for queries, it was great.
you had to have separate threads for the app and the display and send messages between them, and it was a whole thing
Yeah, that was a downside, but it was very forward-thinking at the time.
So much of my life now is spent in Emacs, Firefox and IntelliJ that if I had those three on there I could use it today
Well, you’re almost in luck. Emacs is available – a recent version, too!
IntelliJ is there, too, but 1- only the community edition, and 2- it’s a bit further behind in versions.
Unfortunately, Firefox doesn’t have a Haiku port at this time. Rust has been ported, but there are still a boatload of dependencies that haven’t been. The included browser, WebPositive, is based on a (iirc, recent) version of webkit, fwiw, so it’s not antiquated.
the problem with relying on additional file metadata for functionality in a networked world is that you have to find a way to preserve the metadata across network transfers. I also used BeOS for several years for daily everything. Networking in BeOS was practically an afterthought.
Sure, and you need to be able to populate metadata for untagged files from the network.
Fortunately, most modern file types have metadata in them, so discarding the fields outgoing doesn’t hurt, and populating them incoming isn’t too hard. IIRC, that sort of thing was generally part of the application. So, e.g., the IMAP sync app would populate your email files with metadata from the email header fields, the music player app would populate metadata from the mp3 or ogg info headers, etc.
but then this becomes a schema problem. next-gen ideas like tagging files pervasively with identical metadata regardless of type for relating and ordering dies as soon as you tar it up and pass it through a system that doesn’t know about your attributes - unless you have abitrary in-band metadata support, and then it becomes a discoverability and a taxonomy problem, and if you have it in multiple places you have to keep it synchronised and stable with regards to shallow copies like links. You can still have the support for it as a second layer of metadata, of course, and the ability to index and query otherwise extant metadata out of band is useful as an optimisation, but once you extend the idea of the file namespace to include foreign data, you lose out on ‘smart metadata’ as a first class foundation. A similar thing happened with multi-fork files for MacOS.
A similar thing happened with multi-fork files for MacOS.
Sure, but it’s still so useful that when Apple rewrote their filesystem a couple years ago, they included support for resource forks. NTFS supports them, too, as does (iirc) the SMB protocol.
Apple standard practice has moved to bundle directories for fork-requiring executables, sure, and that reduces those interop problems a little bit.
I guess what I’m saying is: file forks are still widely supported, regardless of difficulty integrating with un*x filesystems. Since they’re still incredibly useful ways of interacting with file systems, I don’t see why we should avoid them.
I’ve been following Haiku OS development, and it’s been exciting to see all the progress it’s made. I’m really hoping it becomes a viable alternative to Linux one day.
I somehow came into possession of one of Scot Hacker’s BeOS books in the late 90s and had quite a bit of fun playing with it. I really liked it quite a lot. I don’t think the overall ecosystem would’ve ended up in a better spot had Apple bought Be instead of NeXT.
Be is a fine example of technical brilliance but marketing incompetence. Gasse never really had a clear market idea for the machine or the OS, which is sad because there were SO many great ideas there.
Kind of misleading history. Jean-Louis Gassée got into a row with Apple over the sale and Apple walked.
“ Jean-Louis Gassée. In many respects, Gassée was responsible for the ultimate success of the Macintosh platform as he drove (and hid its existence from Steve Jobs until after he left the company) the development of the Macintosh II, an “open” system that rejected many of Jobs’ original design mandates but sold extremely well. After yet another Apple power struggle, Gassée left the company in 1990 and founded Be, Inc. Be’s principal product was the BeOS, which was powerful and ahead of its time. Gassée was in the happy position of being first in line to sell his company and the OS to Apple in the 1996 timeframe as the company was in desperate need of an upgrade to the Mac OS and had proven incapable of developing one internally. Unfortunately, Gassée could not stop himself from being French and annoying and the deal broke down, to the happiness of Steve Jobs and NeXT, who swooped in and took advantage of the opportunity.”
Selling Steve Jobs’ Liver: A Story of Startups, Innovation, and Connectivity in the Clouds
There’s a quote of him describing himself that’s not terribly far off, so I don’t think it’s too dishonest. I’d have to dig through his twitter again to find it.
BeOS was my primary operating system for a couple of years (I even bought the Professional Edition…I might still have the box somewhere). Did my research and built a box that only had supported hardware - dual Celeron processors, 17” monitor at 1024x768, and some relatively large disk for the time.
It was great.
It was - Very fast, very fun.
Out of interest, what did you use it for?
I remember downloading it and playing around with it (maybe it was small enough to boot from a floppy?) but I couldn’t do anything useful with it. Was a bit too young as well, I guess today I could make do better with unfamiliar stuff.
It was my daily driver. 99% of my work at the time involved being connected to a remote device (routers and firewalls mostly), and BeOS could do that just fine.
It was a great system. There hasn’t been a better one since.
I had triple boot machine - Windows/Linux/BeOS that time. I used BeOS mainly to learn C++ programming. Their GUI toolkit was at that time quite nice - much nicer than MFC :)
was it the Abit BP-6? I had two of those as well, for BeOS. Loved them almost as much as I loved a real bebox. Way faster too :-)
Nah, all self-built, back when building your own machine could actually be significantly cheaper than buying a prebuilt one.
the bp-6 is a motherboard. I hope that counts as self-built :-)
Ah, my bad. I don’t remember the motherboard; this was 20 years ago. Sadly, I haven’t built my own since…probably 2002? I’m so out of the loop it’s not even funny.
(Unless you count putting a Raspberry Pi in a little plastic case as “building your own machine”. If so, then…it’s still been a few years.)
oh that’s quite OK. The BP-6 was quite famous in that era for allowing SMP with celerons that were built to disallow it. It was quite a popular choice for x86 BeOS at the time.
I used BeOS as my primary OS for a year or so, eventually dual-booting with Linux and then dropping it altogether.
Many things about BeOS were sort of incredible. Booted in a couple seconds on the machines of the era, easily 5-10x more quickly than Linux. One of the “demos” was playing multiple MP3 files backwards simultaneously, a feat that nothing else could really do at the time, or multiple OpenGL applications in windows next to each other. The kernel really did multiprocessing in a highly responsive, very smooth way that made you feel like your machine was greased lightning, much faster than it felt under other OSes. This led to BeOS being used for radio stations, because nothing you were doing in the foreground stood a chance of screwing up the media playback.
BeOS had a little productivity suite, Gobe Productive. It had an interesting component embedding scheme, I guess similar to what COM was trying to be, so you just made a “document” and then fortified it with word processing sections or spreadsheet sections.
There were a lot of “funny” things about BeOS that were almost great. Applications could be “replicants,” and you could drag the app out of the window frame and directly onto your desktop. Realistically, there were only a couple for which this would be useful, like the clock, but it was sort of like what “widgets” would become in a few years with Windows and Mac OS X.
The filesystem was famous for being very fast and for having the ability to add arbitrary metadata to it. The mail client was really just a mail message viewer; the list of messages was just a Tracker window (like Finder) showing attributes for To, From, Subject, etc. Similarly, the media player was just able to play one file, if you wanted a playlist, you just used Tracker; the filetype, Title, Artist, Album, etc. were just attributes on the file. I’m not entirely sure how it parsed them out, probably through a plugin or something. You could do what we now call “smart searches” on Mac OS X by saving a search. These worked just like folders for all the apps.
The POSIX compatibility was only OK. I remember it being a little troublesome to get ports of Unix/Linux software of the era going. At the time, using a shittier browser than everyone else wasn’t really a major impediment to getting anything done, so usually I used NetPositive. There was a port of Mozilla, but it was a lot slower, and anyway, NetPositive gave you haiku if something went wrong.
There were not a huge number of applications for BeOS. I think partly it was a very obscure thing to program for. There were not a lot of great compatibility libraries you could use to easily make a cross-platform app with BeOS as a target. I wasn’t very skilled at C++ (still am not) but found trying to do a graphical app with BeOS and its libraries a pretty huge amount of work. Probably it was half or less the work of doing it in Windows, but you had to have separate threads for the app and the display and send messages between them, and it was a whole thing. Did not increase my love for C++.
All in all, it was a great OS for the time. So much of my life now is spent in Emacs, Firefox and IntelliJ that if I had those three on there I could use it today, but it was such an idiosyncratic platform I imagine it would have been quite difficult to get graphical Emacs on there, let alone the others. But perhaps it’s happening with Haiku.
Querying was built into the filesystem. There was a command-line query, too. So many applications became so much simpler with that level of support for queries, it was great.
Yeah, that was a downside, but it was very forward-thinking at the time.
Well, you’re almost in luck. Emacs is available – a recent version, too!
IntelliJ is there, too, but 1- only the community edition, and 2- it’s a bit further behind in versions.
Unfortunately, Firefox doesn’t have a Haiku port at this time. Rust has been ported, but there are still a boatload of dependencies that haven’t been. The included browser, WebPositive, is based on a (iirc, recent) version of webkit, fwiw, so it’s not antiquated.
the problem with relying on additional file metadata for functionality in a networked world is that you have to find a way to preserve the metadata across network transfers. I also used BeOS for several years for daily everything. Networking in BeOS was practically an afterthought.
Sure, and you need to be able to populate metadata for untagged files from the network.
Fortunately, most modern file types have metadata in them, so discarding the fields outgoing doesn’t hurt, and populating them incoming isn’t too hard. IIRC, that sort of thing was generally part of the application. So, e.g., the IMAP sync app would populate your email files with metadata from the email header fields, the music player app would populate metadata from the mp3 or ogg info headers, etc.
but then this becomes a schema problem. next-gen ideas like tagging files pervasively with identical metadata regardless of type for relating and ordering dies as soon as you tar it up and pass it through a system that doesn’t know about your attributes - unless you have abitrary in-band metadata support, and then it becomes a discoverability and a taxonomy problem, and if you have it in multiple places you have to keep it synchronised and stable with regards to shallow copies like links. You can still have the support for it as a second layer of metadata, of course, and the ability to index and query otherwise extant metadata out of band is useful as an optimisation, but once you extend the idea of the file namespace to include foreign data, you lose out on ‘smart metadata’ as a first class foundation. A similar thing happened with multi-fork files for MacOS.
Sure, but it’s still so useful that when Apple rewrote their filesystem a couple years ago, they included support for resource forks. NTFS supports them, too, as does (iirc) the SMB protocol.
Apple standard practice has moved to bundle directories for fork-requiring executables, sure, and that reduces those interop problems a little bit.
I guess what I’m saying is: file forks are still widely supported, regardless of difficulty integrating with un*x filesystems. Since they’re still incredibly useful ways of interacting with file systems, I don’t see why we should avoid them.
I’ve been following Haiku OS development, and it’s been exciting to see all the progress it’s made. I’m really hoping it becomes a viable alternative to Linux one day.
For many people, it already is, if you don’t need GPU acceleration…
Or want to watch Netflix etc.
I somehow came into possession of one of Scot Hacker’s BeOS books in the late 90s and had quite a bit of fun playing with it. I really liked it quite a lot. I don’t think the overall ecosystem would’ve ended up in a better spot had Apple bought Be instead of NeXT.
Be is a fine example of technical brilliance but marketing incompetence. Gasse never really had a clear market idea for the machine or the OS, which is sad because there were SO many great ideas there.
Kind of misleading history. Jean-Louis Gassée got into a row with Apple over the sale and Apple walked.
‘French and annoying’? Yeah, that sounds totally unbiased. /s
There’s a quote of him describing himself that’s not terribly far off, so I don’t think it’s too dishonest. I’d have to dig through his twitter again to find it.
It would make sense if it were in quotes and referring to Gassée himself saying it (or similar).
You haven’t lived until you’ve run BeOS on an actual BeBox. Love those blinkenlights.
I have been reviving mine over the holidays, so I was quite surprised to see this story surface at around the same time. https://www.reddit.com/r/vintagecomputing/comments/eku19u/dusted_off_one_of_my_old_beboxes/
The dude has three, one being a Hobbit?! My jelly runneth over. Took me ages to find the one 133MHz I own.
that dude is me, the username is the clue :-)
I had bought BeOS. I have the manuals somewhere still. But I never really managed to use it.