I would be very interested in a writeup that talked about the likely trajectory of Apple's OS if they had bought BeOS instead.
ndiddy 1 days ago [-]
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.
diskzero 1 days ago [-]
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.
ndiddy 1 days ago [-]
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...
lproven 18 hours ago [-]
Palm at one point was talking to Symbian about licensing the Symbian kernel for the Arm PalmOS.
I wish that had happened... it might have saved both companies.
WillAdams 1 days ago [-]
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.
ykonstant 18 hours ago [-]
Ah, Adobe, how I want you to burn in an enormous, abyssal hellfire.
tialaramex 1 days ago [-]
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.
smithbits 1 days ago [-]
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.
jasomill 9 hours ago [-]
I was amused to recall this a decade later when, as a result of Disney acquiring Pixar, Ed Catmull and John Lasseter were put in charge of Disney's animation studios and Jobs got a seat on Disney's board of directors as its single largest shareholder.
diskzero 1 days ago [-]
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.
electroly 1 days ago [-]
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.
diskzero 1 days ago [-]
For release 4, we added private impls with many many virtual declaration placeholders. I still remember the comment in every file: Mmmmmmm, stuffing!
AshamedCaptain 12 hours ago [-]
So, exactly like what Mac OS X did with IO Kit. They managed for several decades...
mike_hearn 20 hours ago [-]
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.
hobo123 20 hours ago [-]
I'm not familiar with Be API, but I did a lot of GUI dev in Java Swing back in the day. It's not that hard in principle, you launch whatever background op in whatever threads you like, and any GUI updates have to be done by sending messages back to the GUI event thread (or something like Swing.invokeLater(closure)).
mike_hearn 18 hours ago [-]
IIRC BeOS gave every window its own thread rather than have one GUI thread per app. So in effect every app was multi-threaded by default.
pjmlp 18 hours ago [-]
Yes, Be GUI is heavily multithreaded, so core dumps were kind of common, and stuff like Swing.invokeLater(closure) only came later in Swing, after existing for a while as community library, after folks having the same issues in Java GUI applications.
Note that on Android they took an hammer solution, programming patters to invoke such code on main thread, have as outcome that there are either lint compile errors, or platform killing the application, for those flows not verifiable at compile time.
bunderbunder 17 hours ago [-]
Yes, and it’s been a quarter century or so but this is how I remember BeOS doing it. Every window got a dedicated thread for handling events and GUI updates, and other code would communicate with it via message passing. The OS had a standard message passing system that was pervasive; if I remember right every thread got a mailbox by default.
But it was 90s era C++, so probably that was all just a polite agreement and the reality was that circumventing the message passing to directly call methods on objects that belong to other threads was common, and just as likely to happen by accident as on purpose.
timschmidt 1 days ago [-]
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.
lproven 20 hours ago [-]
This is not quite correct as I understand it.
32-bit Haiku can run old Be apps, but must be built with ancient GCC.
64-bit Haiku is built with modern GCC but it is not binary compatible with old BeOS.
timschmidt 1 hours ago [-]
You're right and I misremembered slightly. Still ABI magic in my book!
ErroneousBosh 19 hours ago [-]
Correct, yes. You can run BeOS apps on 32-bit gcc2 builds.
This is a surprising amount of effort to not break compatibility ;-)
hxorr 20 hours ago [-]
Gee, maybe Linux devs could learn something from them...
wmf 1 days ago [-]
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.
diskzero 1 days ago [-]
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.
diskzero 1 days ago [-]
> 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.
AshamedCaptain 1 days ago [-]
I'll note that Mac OS X used a C++ ABI in the _kernel_....
pjmlp 18 hours ago [-]
Kind of, you will note that it is based on COM, exactly to prevent ABI issues.
Which is what Windows has been doing since C++ replaced C for most of the systems programming stuff, around Vista timeframe.
AshamedCaptain 13 hours ago [-]
Not at all. IO Kit was raw, pure C++, with all the ABI consequences you must deal with (including fragile base class). Just go to see any header of any exported IOKit class to see what I am talking about.
There is no COM whatsoever, no IPC, no IDL, nothing, dunno where do you get that from.
I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.
jasomill 8 hours ago [-]
Perhaps they're thinking of the CFPlugIn architecture, which is basically COM IUnknown without everything Microsoft built on top of it.
> I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.
I think that those that use such argument tend to be on anti-C++ crowd, they forget that NeXTSTEP even had Objective-C++ as well.
JKCalhoun 1 days ago [-]
Designed in California has been a very entertaining (video podcast) watch that covers this era:
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.
tialaramex 1 days ago [-]
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.
pjmlp 1 days ago [-]
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.
diskzero 1 days ago [-]
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.
tialaramex 18 hours ago [-]
I am greatly enjoying the juxtaposition of a comment asserting that obviously BeOS was so far from POSIX that Haiku had to do loads of work to get there and your comment that BeOS was POSIX compliant.
pjmlp 8 hours ago [-]
If I remember correctly it was bit like how Windows NT did POSIX as well, supported, kind of, hence the need of books like these,
Maybe I am wrong, won't dispute being 100% certain, nor do I have the R5 CD around.
diskzero 18 hours ago [-]
Haiku is all new source, so they had to figure out how to get the binaries to run. I am not the POSIX expert, but I think it was just an API guarantee not ABI.
There were several companies that had the BeOS source and that source can be found in the wild. It is speculated that yellowTAB ZETA was based on unlicensed BeOS source code.
walrus01 1 days ago [-]
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.
diskzero 1 days ago [-]
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.
lproven 20 hours ago [-]
That is amazing to read. I never knew. I thought it was Workspace Manager, adapted to feel more Mac-like. There is even a clear line of descent:
1. The Rhapsody developer previews, which are NeXTstep with a menu bar at the top and desktop icons, and a Platinum skin.
2. Mac OS X Server 1.x which has cascading finder windows, an icon view by default, and some other things much like that.
3. Mac OS X 10.0, which I used, or tried to use, as a daily driver, with a broadly Mac-like experience with an Apple menu, but with app names next to it containing global "about" and "quit" options, and so on.
It never did acquire any of the nice stuff that came in with System 7 (e.g. drag-and-drop customisable Apple menu stored in folders in the System Folder) or MacOS 8 (e.g. folder drawers that shrink to tabs).
diskzero 18 hours ago [-]
Right. There were several interesting skins and Finder-esque modifications of Workspace Manager. You may have seen a “Beaker” build of OSX with that. The Kodiak pre-release had the C++ Finder that is still the current Finder with PowerPlant replaced by HIView and some code refactored to use AppKit. No SwiftUI though!
Yeah, a lot of those “blue” features never were adopted or came back. The whole spatial Finder concept was lost.
walrus01 21 hours ago [-]
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.
diskzero 18 hours ago [-]
I hear you. Yes, the 10.0 Finder had swaths of commented out code and missing features that were present in 9. Spring loaded folders comes to mind. They came back at some point.
hobo123 20 hours ago [-]
To me BeOS was and is still the best looking desktop OS ever, and it was so fast, it felt so good. I think in 2000ish (when it was released freely) I used it on my PC pretty much exclusively for a few months.
lproven 20 hours ago [-]
I fervently agree.
I wish that there was some edict from KDE Project management telling everyone working on the Plasma desktop to spend a week in Haiku or something.
The amount of indirect "open a dialog box, click 6 tabs down, then enter a value" stuff in KDE that is a single drag in Haiku drives me mad.
lproven 20 hours ago [-]
The counterpoint is RISC OS for GNOME.
GNOME 3 was trying to built a clean modern minimalist desktop without all the clutter inherited from the design of Windows... But all they know is, very visibly, Windows and KDE.
RISC OS is that clean legacy free desktop. It's unlike anything else, built from scratch by a team not interested in what the rest of the world was doing.
And it's still alive and still updated and works well on modern hardware. Several separate efforts are building 64-bit replacements today.
hobo123 17 hours ago [-]
Many people might not know that ARM the company behind pretty much all phone CPUs (at least historically) was founded as Acorn Risc Machines and built their own computers with their own RISC OS.
I know almost nothing about it, so I will give your links a read.
HeckFeck 19 hours ago [-]
RISC OS? That's still going! What can I run it on?/run on it?
It runs on all Raspberry Pi models up to the 4, and runs really well. As of version 5.30 it supports the Wifi chip in the Pi so it can connect to WLANs.
The owners of the IP are RISC OS Developments Ltd (ROD) and they have an enhanced version -- free on the Pi -- called RISC OS Direct, with an IPv6 stack and a modern WebKit browser:
There is another fork of the OS that is still proprietary. That's owned by 3QD. They used to sell upgrades for real Acorn-compatible kit but there's none of that that isn't vintage now, so it focuses on a software emulation that runs on modern x86 machines:
Search the Reg for "riscos" and you'll find interview with the original core team, looks at the last couple of FOSS releases, the Moonshot effort to go 64-bit and more.
sillywalk 7 hours ago [-]
> RISC OS is that clean legacy free desktop
Uh, legacy free? I'd argue the opposite - it's got tons of legacy baggage - cooperative multitasking, and a lot is written in old ARM assembly language. It's disk limitations, filetypes.
> And it's still alive and still updated and works well on modern hardware.
I am quite impressed that the bounties that are put out to improve it get funded. (to be clear, this is not sarcasm , there's tens of thousands of pounds £s donated). I've tried in on my Pi, and it's super snappy, if a little odd.
ErroneousBosh 19 hours ago [-]
> I wish that there was some edict from KDE Project management telling everyone working on the Plasma desktop to spend a week in Haiku or something.
The other thing is that it says right at the start of the BeOS Book - and this is carried across to Haiku - is that you shouldn't have a spinner or hourglass. It should do *something*, it shouldn't make you wait.
renehsz 1 days ago [-]
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?
hadlock 1 days ago [-]
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.
HeckFeck 20 hours ago [-]
Please share anything you have, if possible. I'd love to know how you're doing it. If you don't want to do it publicly, my email is in my profile.
I've a wild whim to try this with Windows 95. What's an x11 or wayland? we're going EXPLORER.EXE!
sen 17 hours ago [-]
I would absolutely love and daily drive “modern Linux with Win95 UI”.
Skins and theming only gets it so far, I want it to actually be the Win95 front end with Linux underpinnings.
ndiddy 16 hours ago [-]
I recently saw this project, where someone got the Windows XP shell running as a Linux DE using a patched version of Wine. It supports both running Windows software under Wine and running Linux software. I doubt it's production ready yet, but it's pretty neat. https://github.com/mikuta0407/win4wine
ecliptik 1 days ago [-]
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.
tomduncalf 1 days ago [-]
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
ndiddy 1 days ago [-]
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?
anthk 1 days ago [-]
Target system 7.5.3, it will run far more stuff.
TimTheTinker 17 hours ago [-]
Second this - System 7.5.3 has by far the most backward and forward compatibility of any classic era Macintosh OS.
It's also available for both 68k and PPC architectures. And the PPC version can run 68k software (it internally emulates a 68020)
ben_w 8 hours ago [-]
I thought it was the PPC chips, not the OS, which emulated a 68020?
tjakab 4 hours ago [-]
The 68k emulator was inside the Mac ROM on PPC Macs, not the processor.
reverius42 23 hours ago [-]
I was going to say, why System 6 and not 7?
mjhagen 18 hours ago [-]
Possibly because System 6 runs better on SE-era machines?
68030 on a 16-bit bus, max 10MB RAM, no expansion slots so nothing except SCSI.
So, I put 10MB in it, a bigger SCSI HDD, a SCSI Ethernet adaptor on the back, and built both OSes up from scratch.
MacOS 6.0.8 with all the extras: a menu bar clock, hierarchical Apple menu with modular Control Panel, MacTCP, etc.
And MacOS 7.6.1, which doesn't officially support the Classic II as it wants 12MB RAM minimum -- but I had RAMdoubler. OpenTalk, Netscape Navigator 3, Communicator 4, some early Internet Explorer, etc.
Honestly, there was little difference. It was usably quick on 7.6.1 and more stable. So many things that are extras on 6.0.8 are built in to 7.x that it doesn't need that much more disk or memory.
7.x did more, made it easier, and ran well.
But, as an example, on roughly 1MBs ADSL, it took about half an hour to render the top-left quarter of https://slashdot.org/.
Perfectly usable machine, could do email, FTP, Gopher, but forget it on the WWW on of the noughties (2000-2009).
ndiddy 16 hours ago [-]
Well the parent commenter said "SE era machines". That era of machines (Plus, SE, Classic) had an 8 MHz 68000 and only supported up to 4 MB of RAM. The Low End Mac page you linked says that your Classic II is 1.8x faster than an SE. On the 68000 Macs, System 7 (especially 7.1 and 7.5) feels a lot more sluggish than System 6, and will use over half the RAM just running the OS with no applications. Being able to skip the "extras" you mention that became mandatory on System 7 is useful when you have a slow machine with limited RAM. Of course I'm not sure what any of this has to do with running the OS on a Raspberry Pi.
lproven 14 hours ago [-]
Fair. It's not a vast difference though.
I would love to play with a hundreds-of-megaHertz class emulated classic 68K Mac on a Raspberry Pi! :-)
The PiStorm delivered this on a lot of classic Amigas.
... Some people told me that everyone they knew still running classic Amigas had
PiStorms in them. It is a cheap upgrade and it's apparently become ubiquitous.
As such, it's odd, but I don't know of fully-working versions for classic Atari ST or 68k Mac hardware.
There are 2 all-FOSS recreated ST OSes I know of now: AFROS, by the team behind ARANYM, and the formerly-commercial MagiX. It shouldn't be that much of an effort to make some bare-metal emulation that can run that on a Raspberry Pi.
Classic MacOS remains proprietary. Some of the comments in this thread hint at why -- that quite a bit of original Finder code at least made it into OS X. Pity. I'd hope that some day Apple might release whatever source it still has.
I'd love a community Copland to play with. :-D
jjuran 4 hours ago [-]
> Classic MacOS remains proprietary. ... Pity. I'd hope that some day Apple might release whatever source it still has.
I highly doubt this will ever happen. It seems like Apple is trying to avoid any association at all with classic Mac OS, even to the point of declining to go after folks hosting system software or ROM images, or even leaked ROM source code... on GitHub!
Even in the case of QuickDraw, whose source was published by the Computer History Museum, it's under a non-free license — so it wasn't quite released, but merely exhibited. (If you're unclear on the difference, ask any resident of a zoo.)
In the meantime, my own work-in-progress reimplementation of Mac OS is dual-licensed AGPL/commercial. The goal is to run classic Mac applications on commodity hardware.
anthk 16 hours ago [-]
Get a gopher client and join gopher://hngopher.com (r/o HN over gopher), gopher://magical.fish (huge portal, from a translator from text adventures over gopher, and even current news) and gopher://sdf.org. (blogs).
Gopher://typed-hole.org it's fine too.
lproven 14 hours ago [-]
Sadly, I gave the machine away when I moved out of the UK in 2014.
darkwater 20 hours ago [-]
Which model are you using? If Anthropic/OpenAI aren't you tripping any "cyber" blockage?
Someone 22 hours ago [-]
> 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.
ben_w 8 hours ago [-]
> It had most if not all of that.
I could have phrased this better, the "modern" is a prefix on each item in the list:
modern {memory protection, virtual memory, preemptive multitasking, and networking}.
rather than:
{modern memory protection}, {virtual memory}, {preemptive multitasking}, and {networking}.
lproven 20 hours ago [-]
You are getting your versions muddled up.
You are describing attributes of the NeXT-based OS X but calling it MacOS 9.
MacOS 9 was the final version of Classic. No preemption, weak virtual memory, weak cooperative multitasking, no virtual machines for anything.
MacOS 9 is the OS that ran inside the Blue Box on Mac OS X for backwards compatibility.
jjuran 19 hours ago [-]
> You are describing attributes of the NeXT-based OS X but calling it MacOS 9.
You're mistaken.
> MacOS 9 [had] no preemption
Classic Mac OS has had vertical retrace (VBL) interrupts since System 1.0 (which are a form of preemption). But suppose we disregard that.
>> MacOS 9 had a preemptively scheduled kernel.
The GP is correct. Applications run cooperatively within the Blue task, but the Blue task itself runs preemptively with other MP tasks (which an application can create).
I know about the nanokernel, yes. Without following the links, Gary Davidian (is that spelled right?) did amazing work.
Very very little used it. About the only classic app I ever heard of that could even use pre-emption and background execution were some demanding Photoshop filters. Enough that Daystar Digital built multiprocessor Mac clones just for that alone:
Within the MacOS kernel it is as coop as ever, and there were no different OSes inside virtual machines. No, Tenon MachTen does not count.
ndiddy 16 hours ago [-]
There was a lot of popular software that used preemptive threads, as it was the only way to make use of the second processor inside multiprocessor Macs. Some examples are Photoshop, Premiere, Final Cut Pro, After Effects, Lightwave, and Cinema 4D. See https://web.archive.org/web/20210619165728/https://www.macwo... .
jjuran 18 hours ago [-]
It's totally fair to disagree about whether Mac OS 9 meets the stated requirements. I just don't think it's reasonable to assert that GGGP (who may have made unwarranted claims about OS 9) was actually confusing OS 9 with OS X.
jjuran 19 hours ago [-]
> At this point, they could likely decompile MacOS classic and rework it to give it modern memory protection, virtual memory, preemptive multitasking, and networking.
You'd lose compatibility with the applications, though, so you'd have to decompile and rework those as well. And even if you did, you couldn't legally distribute any of it.
An alternative approach is high-level emulation. Running a separate instance per application gives you process isolation (via the host OS) for free.
> I assume booting an OS with a mere few megabytes of RAM footprint would only take milliseconds?
I haven't measured it as such, but yes.
ben_w 8 hours ago [-]
> An alternative approach is high-level emulation. Running a separate instance per application gives you process isolation (via the host OS) for free.
The AI know this too, and that is a way to rework the OS.
jjuran 6 hours ago [-]
> The AI know this too,
An AI trained on leaked Apple ROM code?
> and that is a way to rework the OS.
What you do on your own machine is your business, so have fun with that. You can't legally share it, though.
ben_w 6 hours ago [-]
> An AI trained on leaked Apple ROM code?
Nah, just one which read e.g. every Hacker News discussion like this.
> What you do on your own machine is your business, so have fun with that. You can't legally share it, though.
Unclear, as with so much else going on in this space right now.
Don't get me wrong, it feels like it ought to be against the rules to me… but then again, several highly successful businesses also felt to me like they ought to be against the rules.
alfiedotwtf 15 hours ago [-]
Funnily enough, earlier this week I switched back to WindowMaker :)
ErroneousBosh 19 hours ago [-]
> Mmm. Or improve the OSes themselves.
Haiku specifically does not accept AI-generated code.
I expect if you use AI to explain how to write it and then write it yourself that would be okay.
You need to be able to explain your work without just pasting in what Special Needs Wintermute says.
publlus_enigma 17 hours ago [-]
Haiku has been in beta for twenty years.
Haiku still doesn't boot on many modern systems.
Haiku can use all the help it can get.
ErroneousBosh 12 hours ago [-]
But no-one wants AI slop in it.
ben_w 7 hours ago [-]
Good for you. But Haiku (OS) is MIT licensed and therefore easily forked, and at this point the AI you dismiss as "Special Needs Wintermute" (much as I agree with the sentiment "You need to be able to explain your work without just pasting in what [it] says") is being used to find and resolve critical issues in OSes that actually get used outside of hobbies, and even when the AI was a lot more meh than it currently is, it has been useful for such hobby projects* when used by people capable of explaining as you demand.
* I like hobby projects, no shade here. But it is a hobby project, just like the people trying to keep RISC OS modern, or my suggestion about MacOS classic. There's no obvious reason to pick these things over "just use some flavour of linux" in the present world, unless you're a nerd like us.
Ironically, it being a hobby project might actually be a good reason to keep the AI away: the effort is the point.
ErroneousBosh 6 hours ago [-]
Then fork it, and add your own AI slop to it.
But it won't be included upstream.
publlus_enigma 1 hours ago [-]
That's fine. But I might end up with a system I can actually use. That actually boots.
If you look at Haiku, they have a handful of regular contributors. I think from memory they have one or two people working on it.
I would love to be able to sit down and port drivers by hand and contribute them. And maybe when I am retired in 20 years time, I can do that -- at which point, Haiku will be a 40 year old project.
Perfect is the enemy of good.
publlus_enigma 18 hours ago [-]
I have been supporting Haiku financially for years, but sadly, it won't boot natively on any of my computers :(
I really need to dedicate some time to understand why. I'd love to contribute with apps and drivers.
BodyCulture 18 hours ago [-]
It is such a pity that they are not implementing any kind of disk encryption.
jmspring 1 days ago [-]
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.
hadlock 1 days ago [-]
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.
HeckFeck 19 hours ago [-]
Last time I tried it on my old Thinkpad T440, it ran fairly well. Now with Firefox it's a serious contender for an internet machine.
thisislife2 18 hours ago [-]
For those who like BeOS, please check out V OS - https://v-os.dev/ - it's a Linux distro that is porting Be GUI and SDK to run on the Linux kernel. It's quite light on the resources. With enough support, it could one day be a really great alternate to Gnome and KDE on Linux.
thenewwazoo 1 days ago [-]
> 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.
:-|
hadlock 1 days ago [-]
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.
electroly 1 days ago [-]
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).
tomaskafka 11 hours ago [-]
Damn, I spent some time getting Opus 5 to do this for Mac, being proud of discovering a new UI metaphor - bringing a set of workflow related windows into one “tabbed meta-window”.
Good work everyone who made this for Haiku.
kalleboo 1 days ago [-]
> I haven't seen anything like it
I remember using the fluxbox wm like this back on the university Sun machines
hobo123 20 hours ago [-]
Yep, reeeally nice feature, used it on Linux. After that I wondered why apps bothered to implement their own tabbing when you could just stack Windows as tabs (assuming more WMs would adopt that feature).
pjmlp 1 days ago [-]
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.
multiplegeorges 1 days ago [-]
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.
somat 1 days ago [-]
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.
jmgao 1 days ago [-]
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
notduncansmith 1 days ago [-]
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 :)
presbyterian 1 days ago [-]
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
> 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.
1 days ago [-]
Singletail 1 days ago [-]
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.
diskzero 1 days ago [-]
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.
MomsAVoxell 18 hours ago [-]
Still got my BeBox, boot it up every year just to make sure its still okay. I have wondered about that paint job over the years ..
Narishma 1 days ago [-]
The closest modern thing to it is probably the Raspberry Pi GPIO header.
ndiddy 1 days ago [-]
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.
detourdog 1 days ago [-]
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.
WillAdams 1 days ago [-]
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).
MomsAVoxell 18 hours ago [-]
[flagged]
watersb 1 days ago [-]
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.
jonhohle 1 days ago [-]
Were the tabs movable like on BeOS? That’s something I cannot recall seeing in any theme.
watersb 1 days ago [-]
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.
hobo123 20 hours ago [-]
As mentioned in another thread above: you can get similar(?) tabs in Fluxbox on Linux.
tonymet 1 days ago [-]
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.
lukeparker2020 22 hours ago [-]
[flagged]
jv22222 1 days ago [-]
Why do people want to look at old os's like this and Amiga what is the fascination? Just curious.
zapzupnz 2 hours ago [-]
One never knows where to go if one doesn't know where we've been. So many mistakes in tech can be avoided by realising somebody had made that mistake before you.
I'm a computer science teacher at the high school and part of what I do is make my students use old operating systems (via InfiniteMac.org and others) and ask them to identify what's the same on those older OS, what's better, and what's worse, and why.
My hope is that they don't just waste time by keeping on reinventing the wheel, getting burnt by the most easily avoided mistakes, or reviving something we've made the mistake of leaving behind.
hobo123 20 hours ago [-]
To me it's not nostalgia, the system felt truly great to use. Haven't met anything as good since then.
And while I agree that Steve Jobs and Next were the right business (and people) choice, I still mourn the loss of a much better UI (never been a fan of the Mac UI, and it's my daily at-work system).
nickhodge 1 days ago [-]
Nostalgia is an addictive drug.
Rendered at 05:56:50 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
I wish that had happened... it might have saved both companies.
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.
Note that on Android they took an hammer solution, programming patters to invoke such code on main thread, have as outcome that there are either lint compile errors, or platform killing the application, for those flows not verifiable at compile time.
But it was 90s era C++, so probably that was all just a polite agreement and the reality was that circumventing the message passing to directly call methods on objects that belong to other threads was common, and just as likely to happen by accident as on purpose.
32-bit Haiku can run old Be apps, but must be built with ancient GCC.
64-bit Haiku is built with modern GCC but it is not binary compatible with old BeOS.
This is a surprising amount of effort to not break compatibility ;-)
We paid Cygnus(?) millions for that. The multiple virtual inheritance needed for MediaKit was a real joy to get working.
Which is what Windows has been doing since C++ replaced C for most of the systems programming stuff, around Vista timeframe.
There is no COM whatsoever, no IPC, no IDL, nothing, dunno where do you get that from.
I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.
https://developer.apple.com/library/archive/documentation/Co...
I get that from knowing my way around OS X, naturally it isn't Windows COM, rather shares many of the same ideas,
https://developer.apple.com/library/archive/documentation/De...
https://developer.apple.com/library/archive/documentation/De...
> I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.
I think that those that use such argument tend to be on anti-C++ crowd, they forget that NeXTSTEP even had Objective-C++ as well.
https://www.youtube.com/@designedinca
(Specifically they talk about Be beginning: https://youtu.be/5IFxwnXASyQ)
If not, desktop computing would be taken over by C++ as main systems programming language, and UNIX like computing relegated to servers.
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.
The amount of work done by Haiku to provide a proper POSIX userspace support proves the point.
"BeOS: Porting UNIX Applications"
https://www.amazon.com/dp/1558605320
Maybe I am wrong, won't dispute being 100% certain, nor do I have the R5 CD around.
There were several companies that had the BeOS source and that source can be found in the wild. It is speculated that yellowTAB ZETA was based on unlicensed BeOS source code.
1. The Rhapsody developer previews, which are NeXTstep with a menu bar at the top and desktop icons, and a Platinum skin.
2. Mac OS X Server 1.x which has cascading finder windows, an icon view by default, and some other things much like that.
3. Mac OS X 10.0, which I used, or tried to use, as a daily driver, with a broadly Mac-like experience with an Apple menu, but with app names next to it containing global "about" and "quit" options, and so on.
It never did acquire any of the nice stuff that came in with System 7 (e.g. drag-and-drop customisable Apple menu stored in folders in the System Folder) or MacOS 8 (e.g. folder drawers that shrink to tabs).
Yeah, a lot of those “blue” features never were adopted or came back. The whole spatial Finder concept was lost.
I wish that there was some edict from KDE Project management telling everyone working on the Plasma desktop to spend a week in Haiku or something.
The amount of indirect "open a dialog box, click 6 tabs down, then enter a value" stuff in KDE that is a single drag in Haiku drives me mad.
GNOME 3 was trying to built a clean modern minimalist desktop without all the clutter inherited from the design of Windows... But all they know is, very visibly, Windows and KDE.
RISC OS is that clean legacy free desktop. It's unlike anything else, built from scratch by a team not interested in what the rest of the world was doing.
And it's still alive and still updated and works well on modern hardware. Several separate efforts are building 64-bit replacements today.
I know almost nothing about it, so I will give your links a read.
https://www.riscosopen.org/content/
It runs on all Raspberry Pi models up to the 4, and runs really well. As of version 5.30 it supports the Wifi chip in the Pi so it can connect to WLANs.
The owners of the IP are RISC OS Developments Ltd (ROD) and they have an enhanced version -- free on the Pi -- called RISC OS Direct, with an IPv6 stack and a modern WebKit browser:
https://www.riscosdev.com/direct/
They also sell more capable hardware for it.
There is another fork of the OS that is still proprietary. That's owned by 3QD. They used to sell upgrades for real Acorn-compatible kit but there's none of that that isn't vintage now, so it focuses on a software emulation that runs on modern x86 machines:
http://www.virtualacorn.co.uk/index2.htm
https://www.theregister.com/software/2022/06/21/risc-os-is-3...
Search the Reg for "riscos" and you'll find interview with the original core team, looks at the last couple of FOSS releases, the Moonshot effort to go 64-bit and more.
Uh, legacy free? I'd argue the opposite - it's got tons of legacy baggage - cooperative multitasking, and a lot is written in old ARM assembly language. It's disk limitations, filetypes.
> And it's still alive and still updated and works well on modern hardware.
I am quite impressed that the bounties that are put out to improve it get funded. (to be clear, this is not sarcasm , there's tens of thousands of pounds £s donated). I've tried in on my Pi, and it's super snappy, if a little odd.
The other thing is that it says right at the start of the BeOS Book - and this is carried across to Haiku - is that you shouldn't have a spinner or hourglass. It should do *something*, it shouldn't make you wait.
[1]: https://www.haiku-os.org/
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
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've a wild whim to try this with Windows 95. What's an x11 or wayland? we're going EXPLORER.EXE!
Skins and theming only gets it so far, I want it to actually be the Win95 front end with Linux underpinnings.
It's also available for both 68k and PPC architectures. And the PPC version can run 68k software (it internally emulates a 68020)
It does but not all that much.
I had a Classic II, so a very limited machine.
Not a "road apple" but a "compromised Mac":
https://lowendmac.com/1991/mac-classic-ii/
68030 on a 16-bit bus, max 10MB RAM, no expansion slots so nothing except SCSI.
So, I put 10MB in it, a bigger SCSI HDD, a SCSI Ethernet adaptor on the back, and built both OSes up from scratch.
MacOS 6.0.8 with all the extras: a menu bar clock, hierarchical Apple menu with modular Control Panel, MacTCP, etc.
And MacOS 7.6.1, which doesn't officially support the Classic II as it wants 12MB RAM minimum -- but I had RAMdoubler. OpenTalk, Netscape Navigator 3, Communicator 4, some early Internet Explorer, etc.
Honestly, there was little difference. It was usably quick on 7.6.1 and more stable. So many things that are extras on 6.0.8 are built in to 7.x that it doesn't need that much more disk or memory.
7.x did more, made it easier, and ran well.
But, as an example, on roughly 1MBs ADSL, it took about half an hour to render the top-left quarter of https://slashdot.org/.
Perfectly usable machine, could do email, FTP, Gopher, but forget it on the WWW on of the noughties (2000-2009).
I would love to play with a hundreds-of-megaHertz class emulated classic 68K Mac on a Raspberry Pi! :-)
The PiStorm delivered this on a lot of classic Amigas.
https://pistorm.github.io/
After I wrote about it in 2024:
https://www.theregister.com/on-prem/2024/02/12/pistorm-turbo...
... Some people told me that everyone they knew still running classic Amigas had PiStorms in them. It is a cheap upgrade and it's apparently become ubiquitous.
As such, it's odd, but I don't know of fully-working versions for classic Atari ST or 68k Mac hardware.
There are 2 all-FOSS recreated ST OSes I know of now: AFROS, by the team behind ARANYM, and the formerly-commercial MagiX. It shouldn't be that much of an effort to make some bare-metal emulation that can run that on a Raspberry Pi.
Classic MacOS remains proprietary. Some of the comments in this thread hint at why -- that quite a bit of original Finder code at least made it into OS X. Pity. I'd hope that some day Apple might release whatever source it still has.
I'd love a community Copland to play with. :-D
I highly doubt this will ever happen. It seems like Apple is trying to avoid any association at all with classic Mac OS, even to the point of declining to go after folks hosting system software or ROM images, or even leaked ROM source code... on GitHub!
Even in the case of QuickDraw, whose source was published by the Computer History Museum, it's under a non-free license — so it wasn't quite released, but merely exhibited. (If you're unclear on the difference, ask any resident of a zoo.)
In the meantime, my own work-in-progress reimplementation of Mac OS is dual-licensed AGPL/commercial. The goal is to run classic Mac applications on commodity hardware.
Gopher://typed-hole.org it's fine too.
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 could have phrased this better, the "modern" is a prefix on each item in the list:
rather than:You are describing attributes of the NeXT-based OS X but calling it MacOS 9.
MacOS 9 was the final version of Classic. No preemption, weak virtual memory, weak cooperative multitasking, no virtual machines for anything.
MacOS 9 is the OS that ran inside the Blue Box on Mac OS X for backwards compatibility.
You're mistaken.
> MacOS 9 [had] no preemption
Classic Mac OS has had vertical retrace (VBL) interrupts since System 1.0 (which are a form of preemption). But suppose we disregard that.
>> MacOS 9 had a preemptively scheduled kernel.
The GP is correct. Applications run cooperatively within the Blue task, but the Blue task itself runs preemptively with other MP tasks (which an application can create).
https://en.wikipedia.org/wiki/Mac_OS_nanokernel
https://en.wikipedia.org/wiki/Multiprocessing_Services
Very very little used it. About the only classic app I ever heard of that could even use pre-emption and background execution were some demanding Photoshop filters. Enough that Daystar Digital built multiprocessor Mac clones just for that alone:
https://lowendmac.com/1995/daystar-genesis-mp/
Within the MacOS kernel it is as coop as ever, and there were no different OSes inside virtual machines. No, Tenon MachTen does not count.
You'd lose compatibility with the applications, though, so you'd have to decompile and rework those as well. And even if you did, you couldn't legally distribute any of it.
An alternative approach is high-level emulation. Running a separate instance per application gives you process isolation (via the host OS) for free.
> I assume booting an OS with a mere few megabytes of RAM footprint would only take milliseconds?
I haven't measured it as such, but yes.
The AI know this too, and that is a way to rework the OS.
An AI trained on leaked Apple ROM code?
> and that is a way to rework the OS.
What you do on your own machine is your business, so have fun with that. You can't legally share it, though.
Nah, just one which read e.g. every Hacker News discussion like this.
> What you do on your own machine is your business, so have fun with that. You can't legally share it, though.
Unclear, as with so much else going on in this space right now.
Don't get me wrong, it feels like it ought to be against the rules to me… but then again, several highly successful businesses also felt to me like they ought to be against the rules.
Haiku specifically does not accept AI-generated code.
I expect if you use AI to explain how to write it and then write it yourself that would be okay.
You need to be able to explain your work without just pasting in what Special Needs Wintermute says.
Haiku still doesn't boot on many modern systems.
Haiku can use all the help it can get.
* I like hobby projects, no shade here. But it is a hobby project, just like the people trying to keep RISC OS modern, or my suggestion about MacOS classic. There's no obvious reason to pick these things over "just use some flavour of linux" in the present world, unless you're a nerd like us.
Ironically, it being a hobby project might actually be a good reason to keep the AI away: the effort is the point.
But it won't be included upstream.
If you look at Haiku, they have a handful of regular contributors. I think from memory they have one or two people working on it.
I would love to be able to sit down and port drivers by hand and contribute them. And maybe when I am retired in 20 years time, I can do that -- at which point, Haiku will be a 40 year old project.
Perfect is the enemy of good.
I really need to dedicate some time to understand why. I'd love to contribute with apps and drivers.
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.
:-|
Good work everyone who made this for Haiku.
I remember using the fluxbox wm like this back on the university Sun machines
Granted it was already Windows 10, so nothing that original.
I loved the tabs on BeOS.
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.
https://github.com/RamonUnch/AltSnap
https://github.com/stefansundin/altdrag
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.
The original Nike store in NYC purchased one to do their signage media playback. It didn’t go well.
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.
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.
One of the few upgrade experiences that was a discernable improvement and completely revised experience.
I'm a computer science teacher at the high school and part of what I do is make my students use old operating systems (via InfiniteMac.org and others) and ask them to identify what's the same on those older OS, what's better, and what's worse, and why.
My hope is that they don't just waste time by keeping on reinventing the wheel, getting burnt by the most easily avoided mistakes, or reviving something we've made the mistake of leaving behind.
And while I agree that Steve Jobs and Next were the right business (and people) choice, I still mourn the loss of a much better UI (never been a fan of the Mac UI, and it's my daily at-work system).