To anyone who hasn't already: I really recommend checking out Haiku OS [1], the FOSS successor to BeOS. It's so pleasant to use and supports a surprisingly large catalog of software.
Claude built me a meta web/notes/code search engine with IOS and MacOS apps, and for fun I asked it to make a Haiku version [1], which it did in under 20 minutes.
With AI I feel like a lot of these bygone-era OS's could see a whole new ecosystem of modern apps within a very short period of time.
At this point, they could likely decompile MacOS classic and rework it to give it modern memory protection, virtual memory, preemptive multitasking, and networking.
I assume booting an OS with a mere few megabytes of RAM footprint would only take milliseconds?
I am in the middle of doing this with apple's System 6 and adding a posix-compliant shell under the codename bluetail, and working my way up, i've got it booting with an os, busybox, openssh and stuff. Boots on a raspberry pi 3 A+ bare metal (And qemu, of course). And full usb MIDI support, because (I said so, and) there's actually an incredible catalog of early DAW software that will run on System 6. And pretty decent usb ethernet, sound, webcam etc etc. The future of hobby software is wild.
How did you implement that? Is it like a modified emulator with your enhancements added? How does the System 6 cooperatively multitasking stuff interoperate with the posix stuff?
> they could likely decompile MacOS classic and rework it to give it modern memory protection, virtual memory, preemptive multitasking, and networking.
It had most if not all of that.
It had networking from the start with AppleTalk, later Ethernet and internet with MacTCP.
MacOS 9 had a preemptively scheduled kernel.
The problem is having that and supporting the software ecosystem, which depended on cooperative scheduling without having memory protection.
MacOS 9 ‘solved’ that by running the classic OS in a single process. It had APIs for creating preemptively scheduled threads, but those threads were limited in what they could do.
I occasionally spin up VMs with this and OS2. I miss the era of operating system options. But but linux. It has it's place, I run FreeBSD, but for desktop, options dimish. I like apple hardware, I like apple hardware trackpad support. Running Linux on a MacBook is not something I would ever do. I used FreeBSD on stinkpads for years.
Haiku is actually pretty usable these days, someone has a draft nvidia driver that's not completely terrible (as of maybe a month ago? still very DIY but neat), and there's a surprising number of retro games and shareware in their package manager catalog these days.
> The distinctive tabbed window titles look neat, but they have a reduced draggable area, so I’d have to think harder every time I wanted to move a window.
Now imagine macOS progressing to the point where title bars have been replaced with toolbars, and buttons no longer have borders, so you have to guess what part of the window will drag it.
The feature those provide isn't immediately obvious in a static screenshot, the tabs are "magnetic" and you can take your "word" application and "stick" it's tab next to your email tab, and now you have a "tabbed application" with the email app tab on the left, and the word app tab on the right. You might have one "window" that is your front end dev workflow (firefox, vscode, 2-3 term windows) with 5 tabs, and then a second window that is your backend workflow of vscode + 4 terminal tabs, and a database workflow that is pgadmin + 2 terminal tabs. For example. I haven't seen anything like it, and I'm not sure how it handles windows with a smaller fixed window size, like winamp.
Haiku made them magnetic. In classic BeOS you had to manually position the windows on top of each other, then hold shift and manually drag the tab over from the left. And they wouldn't be tethered together: moving one window wouldn't move the other. It was annoying enough that I never bothered. By the end of BeOS's life I was mostly using the Mac OS 8 titlebar style (accessed by holding down all the modifier keys and pressing the Be menu).
It would just stack the windows of different sizes, so if you hit the Winamp tab the smaller Winamp tab would be at the top of the stack. Pretty simple and intuitive.
I really like the linux solution here. My windows have no titlebar/borders at all. To move a window hold the window key and drag the window from anywhere, to resize hold the window key and right-click drag.
And yes I know it's not really a linux specific thing, but that gets the point across. It is very common on linux. I could twirl my os/desktop hipster mustache and say "my obsd/spectrwm desktop handles no window chrome really well" but then I feel really pretentious instead of only slightly.
I wrote something to do this 13 years ago, someone picked it up after 6 years of inactivity (since I don't own a Mac anymore): https://github.com/justjake/metamove
Yeah I do this too, though on macOS (through Rectangle, the window manager). Control+Option drags the window under my cursor. I picked that up from the Super key drag on Linux
How funny, this is exactly the control scheme I ended up with for a window-manager-esque system I was working on recently. I love finding out I've rediscovered something proven to work well :)
> I really like the linux solution here. My windows have no titlebar/borders at all. To move a window hold the window key and drag the window from anywhere, to resize hold the window key and right-click drag.
Speaking of which. It is not a Linux solution but stock X11 twm window manager features dating back into 1988, i.e.:
– replicates the described behaviour with the pin-point precision[0].
[0] m4 stands for the Mod4 modifier, now commonly assigned to the Super/Windows key. The equivalent 1988 configuration would have used m (Meta), since the original binding syntax supported Shift, Control and Meta only.
Some former Be employees have commented here in the past saying that Apple made the right decision to buy Next and not Be from a technical perspective, as BeOS had poor code quality and was far behind NEXTSTEP in important areas like networking and printing. They also implemented the OS API directly in C++, which tied them to a specific C++ compiler (some mid-90s version of GCC) due to the ABI getting broken in newer versions. The 32-bit version of Haiku (modern BeOS reimplementation) supports BeOS software, and as a result still needs to be compiled with that mid-90s GCC release.
Beyond that, I'm not sure if buying Be would have fixed the managerial problems at Apple. Would they have been able to add the required features to BeOS to turn it into a production OS without the project turning into another Copland? Would the existing Apple management have slimmed down the massive Apple product line that had dozens of nearly identical models? Would it have gotten rid of dead-end projects like Newton and Pippin? Etc.
Best example of how far BeOs fell short was that for a very long while it lacked printer drivers of any kind --- by contrast, not only did NeXTstep essentially get printing "for free" since it used Display PostScript, the implementation of that was such that Adobe demanded a modification to the user agreement limiting the output resolution so that print shops would not be able to purchase NeXT computers and use them as RIPs for imagesetters.
Former Be person here. Excellent summary. To further elucidate the management issue, some of the Be management went to Palm and they weren’t super effective there either. A fun alternative universe would be Apple buying Be, Apple going bankrupt or eaten by the clones, NeXT powering the internet with WebObjects, Microsoft crushed by antitrust and we are all running Linux using Eazel/GNOME.
Yeah it's interesting how similar what happened with Palm OS 6 was to Copland. They had a working, but outdated OS that had been hacked onto a new platform as a stopgap, then they couldn't get the rewrite meant to take full advantage of the new hardware out the door. Palm OS 6 was at least finished, but it never got used on a shipping device. There's an interesting Reddit post going over how the OS design was fundamentally flawed when combined with the ARM processors that were available at the time: https://www.reddit.com/r/Palm/comments/1422bqy/palm_os6/jn5o...
I recall the C++ "fragile base class" problem already starting to rear its ugly head by the end. Existing base classes couldn't be reasonably extended without breaking compatibility with existing applications, and the BeOS API was routinely designed in a way that promoted subclassing. e.g. to implement a window, you'd subclass BWindow and fill it with your own subclasses of BView. It's difficult to see how they would have dug themselves out of this hole in the long term. Perhaps eventually they would have needed to ship multiple versions of their system libraries corresponding to each ABI breakage.
Pre-standard C++ is an even worse programming language than C++ 98, but also the big difference wouldn't have been the technology, it was the people. If Apple buy Be Inc they're getting JLG back whereas if they buy NeXT they get Jobs back.
Jobs is what makes or breaks Apple in that critical period. I didn't like him but that's relevant to the success of the company. JLG did not have whatever it was Jobs gave the company.
And Jobs brought an entire team of people with him. Many of the top people at Apple got replaced by people from NeXT. Avie Tevanian, Craig Federighi, Bertrand Serlet and many lesser known names came from NeXT. The joke at the time was that NeXT bought Apple for -$400M.
Yes, the reverse acquisition. Minor correction though, Craig didn’t show up until much later. He missed out on some very tough years and came on when Apple was fully revitalized and printing money. I might even suggest what I consider the decline of Apple software occurred when Avie and Bertrand left and Craig took over.
One minor correction: the Haiku developers worked some magic with GCC binary compatibility and modern Haiku builds are done with a modern GCC yet still preserve the ability to run and interoperate with software built using the old release which is important for preserving the use of commercial software built for BeOS without released source code.
It was reported that Apple offered $75M for Be and almost $500M for NeXT and in retrospect those seem like entirely fair valuations. One was a mature OS and the other was a demo of an OS.
JLG countered with a $100 million and I thought Apple offered Steve $400 million at first. There was a moment when Apple was just talking to us (Be) and Steve heard about it. Bummed.
Outside of the GUI, Be is a very thin veneer over Unix. There is, no joke, a class named "BStatable" which, if you know some Unix, is just stat, because of course what their OS kernel implements is just stat.
In the places where there's something entirely different going on, such as networking in earlier BeOS, it's trash and you'd obviously want to throw it away and do what Unix did - Be were doing so. So a hypothetical turn of the century fruit-flavour BeOS is probably much closer to "Unix with a different UI" than you're thinking. NeXT changed nothing there.
A strong BeOS selling point was that it was POSIX compliant. I guess that is what you mean by a thin veneer. But we had to write all that code; it wasn’t like we were running Linux or some SCO or other flavor of Unix. It was a written and rewritten and rewritten multiple times.
It would have been a disaster, BeOS was significantly different from a NeXT/BSD-like unix type base that made it relatively easy for software to be developed on MacOS in the 10.0 to 10.4 era. Early versions of MacOS X like 10.0 were clearly just an evolved NeXT with a cute MacOS finder like skin on top.
Well, not only former Be but former Finder developer here. The OSX Finder was certainly not a cute Finder-like skin, it was in fact huge amounts of the OS9 Finder source code including a complete copy of a modified Metrowerks PowerPlant C++ framework underneath it all. There was even elements of the old MacApp framework there. It was not a skin; it was a source code behemoth with massive amounts of legacy code.
I didn't mean that the 10.0 finder was a reskinned NeXT GUI file management application (as you point out, it clearly wasn't and was a huge thing that had a bunch of heritage code), but that the entire 10.0 GUI was a kinda-MacOS-9-like GUI on top of the NeXT bsd-heritage unix-like base. If you were to take a 10.0 system and put it side by side for comparison with the CLI environment perspective, file tree, system libraries with the last NeXTSTEP releases or rhapsody.
I loved my BeBox, but what would be the modern equivalent of the GeekPort? I've been using esp32/nRF52/etc boards for uart/spi/i2c/i2s/pwm-type work... it feels like hardware hacking on a desktop is a lost art.
Your BeBox case was lovingly spray painted in a conference room with inadequate ventilation by us at Be at corporate HQ in Menlo Park. Each one was lovingly assembled by the actual people who designed the hardware and wrote the code.
The old school way to do I/O on desktop was via the parallel port, which I imagine would still work if you get a PCIe parallel port card. For a more modern way, the FT232H chip supports UART, SPI, I2C, JTAG and raw GPIO over USB, and there are break-out boards available.
I was going to say this as well the GeekPort was a parallel port. I always thought it was marketed that way is that Macs didn’t have a parallel port. Having a parallel port would make the spec sheet seem regressive. I believe serial ports were always faster than parallel ports.
I bought a BeBox at the time.
The original Nike store in NYC purchased one to do their signage media playback. It didn’t go well.
I seem to recall that you could hold down Alt key and drag the tab horizontally. So a tab could stick up anywhere along the top of the window frame. The SPARCStations had three-button mice, and this might have been mapped to middle or right mouse button.
The tabbed interface features the ability to gather windows into tab groups. So when you are moving a window by dragging its tab, if you drag the tab next to another window's tab, the dragged window will snap to that other window's frame, the dragged window will be the selected tab and its contents displayed in the frame. Then dragging any of the tabs drags the whole set of tabs that are snapped to that frame. Click on a tab to make it the active tab displayed in the frame.
It's effectively like tabs now, but sort of inside out: tabs are managed by the windows manager and not the app. Tab groups of multiple, different apps. The app does not have to be "tab-aware" to be in a tab group, although I suppose there are events that can signal the manager to make a window the selected tab. It's just raising a window, making it frontmost. Modal dialogs can get tangled up, but it's no worse than the mess commonly accepted today.
To anyone who hasn't already: I really recommend checking out Haiku OS [1], the FOSS successor to BeOS. It's so pleasant to use and supports a surprisingly large catalog of software.
[1]: https://www.haiku-os.org/
Claude built me a meta web/notes/code search engine with IOS and MacOS apps, and for fun I asked it to make a Haiku version [1], which it did in under 20 minutes.
With AI I feel like a lot of these bygone-era OS's could see a whole new ecosystem of modern apps within a very short period of time.
1. https://github.com/machiya-kobo/shiori/tree/main#haiku
Mmm. Or improve the OSes themselves.
At this point, they could likely decompile MacOS classic and rework it to give it modern memory protection, virtual memory, preemptive multitasking, and networking.
I assume booting an OS with a mere few megabytes of RAM footprint would only take milliseconds?
I am in the middle of doing this with apple's System 6 and adding a posix-compliant shell under the codename bluetail, and working my way up, i've got it booting with an os, busybox, openssh and stuff. Boots on a raspberry pi 3 A+ bare metal (And qemu, of course). And full usb MIDI support, because (I said so, and) there's actually an incredible catalog of early DAW software that will run on System 6. And pretty decent usb ethernet, sound, webcam etc etc. The future of hobby software is wild.
I am willing to check this out. I have 512Ke and Mac Plus hardware and am always looking for ways to maximize the hardware capabilities.
How did you implement that? Is it like a modified emulator with your enhancements added? How does the System 6 cooperatively multitasking stuff interoperate with the posix stuff?
Woah I never even considered the possibly of rebooting old OS with new features. Very cool. Would love to experience that era of music tech
Target system 7.5.3, it will run far more stuff.
I was going to say, why System 6 and not 7?
> they could likely decompile MacOS classic and rework it to give it modern memory protection, virtual memory, preemptive multitasking, and networking.
It had most if not all of that.
It had networking from the start with AppleTalk, later Ethernet and internet with MacTCP.
MacOS 9 had a preemptively scheduled kernel.
The problem is having that and supporting the software ecosystem, which depended on cooperative scheduling without having memory protection.
MacOS 9 ‘solved’ that by running the classic OS in a single process. It had APIs for creating preemptively scheduled threads, but those threads were limited in what they could do.
I occasionally spin up VMs with this and OS2. I miss the era of operating system options. But but linux. It has it's place, I run FreeBSD, but for desktop, options dimish. I like apple hardware, I like apple hardware trackpad support. Running Linux on a MacBook is not something I would ever do. I used FreeBSD on stinkpads for years.
Haiku is actually pretty usable these days, someone has a draft nvidia driver that's not completely terrible (as of maybe a month ago? still very DIY but neat), and there's a surprising number of retro games and shareware in their package manager catalog these days.
> The distinctive tabbed window titles look neat, but they have a reduced draggable area, so I’d have to think harder every time I wanted to move a window.
Now imagine macOS progressing to the point where title bars have been replaced with toolbars, and buttons no longer have borders, so you have to guess what part of the window will drag it.
:-|
The feature those provide isn't immediately obvious in a static screenshot, the tabs are "magnetic" and you can take your "word" application and "stick" it's tab next to your email tab, and now you have a "tabbed application" with the email app tab on the left, and the word app tab on the right. You might have one "window" that is your front end dev workflow (firefox, vscode, 2-3 term windows) with 5 tabs, and then a second window that is your backend workflow of vscode + 4 terminal tabs, and a database workflow that is pgadmin + 2 terminal tabs. For example. I haven't seen anything like it, and I'm not sure how it handles windows with a smaller fixed window size, like winamp.
Haiku made them magnetic. In classic BeOS you had to manually position the windows on top of each other, then hold shift and manually drag the tab over from the left. And they wouldn't be tethered together: moving one window wouldn't move the other. It was annoying enough that I never bothered. By the end of BeOS's life I was mostly using the Mac OS 8 titlebar style (accessed by holding down all the modifier keys and pressing the Be menu).
> I haven't seen anything like it
I remember using the fluxbox wm like this back on the university Sun machines
Also Windows was going to have this, but never left the preview builds, there was a BUILD or Ignite session were it was demoed.
Granted it was already Windows 10, so nothing that original.
It would just stack the windows of different sizes, so if you hit the Winamp tab the smaller Winamp tab would be at the top of the stack. Pretty simple and intuitive.
I loved the tabs on BeOS.
I really like the linux solution here. My windows have no titlebar/borders at all. To move a window hold the window key and drag the window from anywhere, to resize hold the window key and right-click drag.
And yes I know it's not really a linux specific thing, but that gets the point across. It is very common on linux. I could twirl my os/desktop hipster mustache and say "my obsd/spectrwm desktop handles no window chrome really well" but then I feel really pretentious instead of only slightly.
I wrote something to do this 13 years ago, someone picked it up after 6 years of inactivity (since I don't own a Mac anymore): https://github.com/justjake/metamove
Yeah I do this too, though on macOS (through Rectangle, the window manager). Control+Option drags the window under my cursor. I picked that up from the Super key drag on Linux
How funny, this is exactly the control scheme I ended up with for a window-manager-esque system I was working on recently. I love finding out I've rediscovered something proven to work well :)
For Windows there is AltDrag or the AltSnap fork.
https://github.com/RamonUnch/AltSnap
https://github.com/stefansundin/altdrag
Also built-in to PowerToys.
> I really like the linux solution here. My windows have no titlebar/borders at all. To move a window hold the window key and drag the window from anywhere, to resize hold the window key and right-click drag.
Speaking of which. It is not a Linux solution but stock X11 twm window manager features dating back into 1988, i.e.:
– replicates the described behaviour with the pin-point precision[0].[0] m4 stands for the Mod4 modifier, now commonly assigned to the Super/Windows key. The equivalent 1988 configuration would have used m (Meta), since the original binding syntax supported Shift, Control and Meta only.
I would be very interested in a writeup that talked about the likely trajectory of Apple's OS if they had bought BeOS instead.
Some former Be employees have commented here in the past saying that Apple made the right decision to buy Next and not Be from a technical perspective, as BeOS had poor code quality and was far behind NEXTSTEP in important areas like networking and printing. They also implemented the OS API directly in C++, which tied them to a specific C++ compiler (some mid-90s version of GCC) due to the ABI getting broken in newer versions. The 32-bit version of Haiku (modern BeOS reimplementation) supports BeOS software, and as a result still needs to be compiled with that mid-90s GCC release.
Beyond that, I'm not sure if buying Be would have fixed the managerial problems at Apple. Would they have been able to add the required features to BeOS to turn it into a production OS without the project turning into another Copland? Would the existing Apple management have slimmed down the massive Apple product line that had dozens of nearly identical models? Would it have gotten rid of dead-end projects like Newton and Pippin? Etc.
Best example of how far BeOs fell short was that for a very long while it lacked printer drivers of any kind --- by contrast, not only did NeXTstep essentially get printing "for free" since it used Display PostScript, the implementation of that was such that Adobe demanded a modification to the user agreement limiting the output resolution so that print shops would not be able to purchase NeXT computers and use them as RIPs for imagesetters.
Former Be person here. Excellent summary. To further elucidate the management issue, some of the Be management went to Palm and they weren’t super effective there either. A fun alternative universe would be Apple buying Be, Apple going bankrupt or eaten by the clones, NeXT powering the internet with WebObjects, Microsoft crushed by antitrust and we are all running Linux using Eazel/GNOME.
Yeah it's interesting how similar what happened with Palm OS 6 was to Copland. They had a working, but outdated OS that had been hacked onto a new platform as a stopgap, then they couldn't get the rewrite meant to take full advantage of the new hardware out the door. Palm OS 6 was at least finished, but it never got used on a shipping device. There's an interesting Reddit post going over how the OS design was fundamentally flawed when combined with the ARM processors that were available at the time: https://www.reddit.com/r/Palm/comments/1422bqy/palm_os6/jn5o...
I recall the C++ "fragile base class" problem already starting to rear its ugly head by the end. Existing base classes couldn't be reasonably extended without breaking compatibility with existing applications, and the BeOS API was routinely designed in a way that promoted subclassing. e.g. to implement a window, you'd subclass BWindow and fill it with your own subclasses of BView. It's difficult to see how they would have dug themselves out of this hole in the long term. Perhaps eventually they would have needed to ship multiple versions of their system libraries corresponding to each ABI breakage.
There were other issues too, no? They went all in on multi-threading of the GUI which is super hard to do well, so apps were often crash prone.
For release 4, we added private impls with many many virtual declaration placeholders. I still remember the comment in every file: Mmmmmmm, stuffing!
Pre-standard C++ is an even worse programming language than C++ 98, but also the big difference wouldn't have been the technology, it was the people. If Apple buy Be Inc they're getting JLG back whereas if they buy NeXT they get Jobs back.
Jobs is what makes or breaks Apple in that critical period. I didn't like him but that's relevant to the success of the company. JLG did not have whatever it was Jobs gave the company.
And Jobs brought an entire team of people with him. Many of the top people at Apple got replaced by people from NeXT. Avie Tevanian, Craig Federighi, Bertrand Serlet and many lesser known names came from NeXT. The joke at the time was that NeXT bought Apple for -$400M.
Yes, the reverse acquisition. Minor correction though, Craig didn’t show up until much later. He missed out on some very tough years and came on when Apple was fully revitalized and printing money. I might even suggest what I consider the decline of Apple software occurred when Avie and Bertrand left and Craig took over.
One minor correction: the Haiku developers worked some magic with GCC binary compatibility and modern Haiku builds are done with a modern GCC yet still preserve the ability to run and interoperate with software built using the old release which is important for preserving the use of commercial software built for BeOS without released source code.
It was reported that Apple offered $75M for Be and almost $500M for NeXT and in retrospect those seem like entirely fair valuations. One was a mature OS and the other was a demo of an OS.
JLG countered with a $100 million and I thought Apple offered Steve $400 million at first. There was a moment when Apple was just talking to us (Be) and Steve heard about it. Bummed.
I'll note that Mac OS X used a C++ ABI in the _kernel_....
> They also implemented the OS API directly in C++, which tied them to a specific C++ compiler
We paid Cygnus(?) millions for that. The multiple virtual inheritance needed for MediaKit was a real joy to get working.
Designed in California has been a very entertaining (video podcast) watch that covers this era:
https://www.youtube.com/@designedinca
(Specifically they talk about Be beginning: https://youtu.be/5IFxwnXASyQ)
They probably would fail to recover and be another historical company by now.
If not, desktop computing would be taken over by C++ as main systems programming language, and UNIX like computing relegated to servers.
Outside of the GUI, Be is a very thin veneer over Unix. There is, no joke, a class named "BStatable" which, if you know some Unix, is just stat, because of course what their OS kernel implements is just stat.
In the places where there's something entirely different going on, such as networking in earlier BeOS, it's trash and you'd obviously want to throw it away and do what Unix did - Be were doing so. So a hypothetical turn of the century fruit-flavour BeOS is probably much closer to "Unix with a different UI" than you're thinking. NeXT changed nothing there.
It certainly wasn't on the BeOS R5 CD that was available back in the day, or the whole Kits available for BeOs programming in C++.
The amount of work done by Haiku to provide a proper POSIX userspace support proves the point.
A strong BeOS selling point was that it was POSIX compliant. I guess that is what you mean by a thin veneer. But we had to write all that code; it wasn’t like we were running Linux or some SCO or other flavor of Unix. It was a written and rewritten and rewritten multiple times.
It would have been a disaster, BeOS was significantly different from a NeXT/BSD-like unix type base that made it relatively easy for software to be developed on MacOS in the 10.0 to 10.4 era. Early versions of MacOS X like 10.0 were clearly just an evolved NeXT with a cute MacOS finder like skin on top.
Well, not only former Be but former Finder developer here. The OSX Finder was certainly not a cute Finder-like skin, it was in fact huge amounts of the OS9 Finder source code including a complete copy of a modified Metrowerks PowerPlant C++ framework underneath it all. There was even elements of the old MacApp framework there. It was not a skin; it was a source code behemoth with massive amounts of legacy code.
I didn't mean that the 10.0 finder was a reskinned NeXT GUI file management application (as you point out, it clearly wasn't and was a huge thing that had a bunch of heritage code), but that the entire 10.0 GUI was a kinda-MacOS-9-like GUI on top of the NeXT bsd-heritage unix-like base. If you were to take a 10.0 system and put it side by side for comparison with the CLI environment perspective, file tree, system libraries with the last NeXTSTEP releases or rhapsody.
I loved my BeBox, but what would be the modern equivalent of the GeekPort? I've been using esp32/nRF52/etc boards for uart/spi/i2c/i2s/pwm-type work... it feels like hardware hacking on a desktop is a lost art.
Your BeBox case was lovingly spray painted in a conference room with inadequate ventilation by us at Be at corporate HQ in Menlo Park. Each one was lovingly assembled by the actual people who designed the hardware and wrote the code.
The closest modern thing to it is probably the Raspberry Pi GPIO header.
The old school way to do I/O on desktop was via the parallel port, which I imagine would still work if you get a PCIe parallel port card. For a more modern way, the FT232H chip supports UART, SPI, I2C, JTAG and raw GPIO over USB, and there are break-out boards available.
I was going to say this as well the GeekPort was a parallel port. I always thought it was marketed that way is that Macs didn’t have a parallel port. Having a parallel port would make the spec sheet seem regressive. I believe serial ports were always faster than parallel ports. I bought a BeBox at the time.
The original Nike store in NYC purchased one to do their signage media playback. It didn’t go well.
This is still an on-going thing for the LinuxCNC project (which mostly follows Mach3 in using a Parallel port interface to drive a CNC controller).
I used a BeOS inspired GNOME extension or hack for tabbed windows, signature yellow color, about 20 years ago. Loved it.
I was installing GNOME pieces compiling from source, on top of Sun Solaris. So it was a weird configuration. But FWIW I relied on the tabs a lot.
Were the tabs movable like on BeOS? That’s something I cannot recall seeing in any theme.
I think so; it's been a while.
I seem to recall that you could hold down Alt key and drag the tab horizontally. So a tab could stick up anywhere along the top of the window frame. The SPARCStations had three-button mice, and this might have been mapped to middle or right mouse button.
The tabbed interface features the ability to gather windows into tab groups. So when you are moving a window by dragging its tab, if you drag the tab next to another window's tab, the dragged window will snap to that other window's frame, the dragged window will be the selected tab and its contents displayed in the frame. Then dragging any of the tabs drags the whole set of tabs that are snapped to that frame. Click on a tab to make it the active tab displayed in the frame.
It's effectively like tabs now, but sort of inside out: tabs are managed by the windows manager and not the app. Tab groups of multiple, different apps. The app does not have to be "tab-aware" to be in a tab group, although I suppose there are events that can signal the manager to make a window the selected tab. It's just raising a window, making it frontmost. Modal dialogs can get tangled up, but it's no worse than the mess commonly accepted today.
I ran BeOS for a bit, and it was the best OS upgrade experience I've had, besides the Windows 95 to NT 4.0 upgrade.
One of the few upgrade experiences that was a discernable improvement and completely revised experience.
Why do people want to look at old os's like this and Amiga what is the fascination? Just curious.
Nostalgia is an addictive drug.