Haiku still exists, and is actually really good now. I was running it for a while.
That's tautologically true, but something like the RT preemption kernel patch is still a basic requirement for a truly responsive system. Once that's merged, you then have buy-in for that use case and can start fixing all the things that are broken in user-space, as well.
Additionally, there's a lot that can be fixed by simple tuning. There's no excuse for UI input locking up when a system is low on RAM, for example. Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority, so that (1) they're always responsive, no matter what, and (2) when the system starts thrashing, they can still grab enough of whatever system resources are available (RAM, CPU, device I/O), so that the user can survey the situation and kill the offending process. Linux distributors are dropping the ball here - this sort of system-wide tuning is their job!
> Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority
This approach is prone to priority-inversion and it doesn't help with the underlying problem that programmers have written tons of synchronous I/O all over the place and the call chains are often highly non-obvious. For example, most Linux desktop environments will freeze if you use an authentication provider which isn't instantly responsive and that prevents things like interacting with menus, closing windows, etc. because various low-level libraries do things like check settings which at some point does something like getting your list of groups, which is normally very fast because it's cached. I got some patches into pam_ldap years ago to set socket-level timeouts so it would recover from something like a single socket error but the better solution would be fewer dependencies and interfaces which don't have tons of different things happening on a single thread.
Priority inversion is one of the main things that are addressed by the PREEMPT_RT patchset - without a fix to the priority inversion problem, you don't really have a RT system. Aside from that, I agree that we should move towards having async interfaces as the default whenever slow I/O is a realistic possibility. I'm not sure how many people actually use something like PAM-LDAP, though.
Setting the bar kinda low aren't we?
Not something where each computer is a special snowflake with a developer fragmented experience about which libraries are even available on the system, and lack of integrated tooling, forcing the trend of just bundling a web browser with the application.
Note that I included "desktop oriented OSes" on the same group as Be.
As for systemd, the very fact that Linux is late to the party of commercial UNIXes init replacements says it all, in terms of being a need that a large majority actually wants.
AIUI, these days you can just develop for Flatpack (if you're making a proprietary application) and declare your dependencies as needed. But do note that Flatpack is not a kitchen-sink "framework" or "platform": it's just something that addresses a number of fairly well-understood issues with the prevailing, mostly FLOSS-oriented, development model. (One reason that the issues are well-understood by now is that other "solutions" have been tried before, such as the LSB effort-- and found wanting.) This is key to decreasing complexity and making the system as a whole more comprehensible and surveyable. The commercial UNIXes you point to are far closer to your view of "each platform being a special snowflake", and big frameworks make this issue worse; they don't ameliorate it.
It can be hard to find the time to get productive in a new programming language. But if you have some spare time, this project could provide the motivation!
If that isn't "Near Death", then what is?
Source?