What's an existing example of a non-'half-backed' OS?
I personally liked VMS for concurrency, but for dealing with code and coding there was no contest that Unix was far better. I think the reality is they're all half-baked since none can satisfy every need.
The Windows NT kernel is surprisingly well-designed. Everything is an 'object' to the kernel (or file descriptor). Concepts like ACLs apply to all kernel objects. I summarized about some of its capabilities previously: https://news.ycombinator.com/item?id=34914776
One concrete example of its design: exercising administrator (sudo) permissions causes a User Account Control (UAC) dialog to pop up, which takes over the screen from the current WindowStation -- making it impossible for any software to mess with approval or password entry [1].
IO Completion Ports (IOCP) also stand out as a powerful way to perform asynchronous IO that NT has had since ... I'm not sure how long, but I believe probably since the 90s. As one HN commenter wrote in 2016, "IOCP is the top item on my (short) list of things Windows simply does better. The performance boost you see from designing a server for IOCP from the ground up is jaw-dropping." [2] And it works for a variety of different IO tasks (including disk IO).
Windows gets a lot of hate, but most of the criticism you read about it online is not usually a well-considered critique of how its kernel APIs operate.
Isn't the kernel API banned from usage by userspace applications that aren't kernel32.dll (plus deliberately breaks ABI all the time) ? I can appreciate the strengths of the NT kernel, but if nobody is allowed to use it... (I suppose kernel drivers can, but that's still a very narrow range of applications)
Also, while IOCP has the advantage of being older w.r.t. availability, I wonder how io_uring competes - I haven't used IOCP myself, but from what I've seen io_uring seems to fill its role quite well and I've seen several people complain about various problems with IOCP (in particular poor documentation)
There's a quote that goes something like "the last piece of software ever written for a novel OS is the UNIX compatibility layer". kernel32.dll is essentially that, except it isn't even UNIX compatible!
Windows NT was designed by Dave Cutler who also designed VMS. And, I agree, for many things it is a very nicely designed system and doesn't deserve a lot of hate.
But, what I said about developing software stands: I'd much rather be using a unix .
I used "half-baked" in the context of UNIX history, where the legend goes that UNIX was the stop-gap solution for AT&T failing to come up with a better designed system on schedule.
Unfortunately, today, UNIX is by and large all we have. Other things are either some kind of UNIX but with a twist, or very underdeveloped.
Looking into the future, I'm very enthusiastic about OS-as-a-library approach, but I don't think we have a solid contender there yet.
I think one approach in (re)designing an OS should be to go back to fundamentals: what makes an Operating System?
I think fundamentally, there are only a few things it has to do: Allow applications to run (on the CPU/other hardware), Allow applications to communicate between themselves (establish communication standards), Allow access to disk, Manage the time given to each application well/fairly, Define permissions around resources (who can talk to whom and who can access what). Depending on who you ask, shells/desktop environments should be part of the OS too.
When I think of the minimum that can accomplish that, I think something like a simple communication standard (with authentication mechanisms) would be interesting (with possibility to support more specialized standards). A standard for defining app. share of resources (CPU/disk). Maybe hardware resources like disks, devices like cameras, etc.. could be treated as applications via a driver (or application <-> disk application <-> disk driver). Then instead of 'opening' files, you're just communicating your intentions with a disk driver, and you can do essentially anything. Maybe then instead of a Filesystem Hierarchy standard, there could simply be "OS (standard) applications" that for example list what users are in the OS, what applications are available, and so on (without a filesystem hierarchy at all, if you wish!). An FHS could be provided for legacy reasons.
I also think permissions should take a more fine grained approach than Unix/Linux does (closer to Android permission systems), I think by default applications should have minimum permissions and should be whitelisted as needed.
I personally liked VMS for concurrency, but for dealing with code and coding there was no contest that Unix was far better. I think the reality is they're all half-baked since none can satisfy every need.