"Zero-Clause BSD" is a bit closer to public domain than MIT if you want that. It's essentially only the disclaimer of liability. It omits the requirement to include any notices with the software.

https://opensource.org/license/0bsd

I like 0BSD, except the name.

The proliferation of BSD licenses dilutes the meaning of "bsd license". There's only one MIT license, so there's no confusion.

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.

For release 4, we added private impls with many many virtual declaration placeholders. I still remember the comment in every file: Mmmmmmm, stuffing!

So, exactly like what Mac OS X did with IO Kit. They managed for several decades...

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.

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)).

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.

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.

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.

> Swing.invokeLater(closure)

Should be:

   SwingUtilities.invokeLater(closure)

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 tried this new app, but Windows Task Manager has always had the ability to pause. Hold down Ctrl and it'll pause updates. You can also set the update frequency to Paused.

> they charge self-hosted runners for using their coordination plane

They don't. Self-hosted runners are still free. They backed down from their plan to charge after receiving widespread backlash.