[TUHS] Macs and future unix derivatives

[Andrew Warkentin]

On 2/8/21, Will Senn <will.senn at gmail.com> wrote:
>
> My thought for the day and question for the group is... It seems that
> the options for a free operating system (free as in freedom) are
> becoming ever more limited - Microsoft, this week, announced that their
> Edge update will remove Edge Legacy and IE while doing the update -
> nuts; Mac's desktop is turning into IOS - ew, ick; and Linux is wild
> west meets dictatorship and major corporations are moving in to set
> their direction (Microsoft, Oracle, IBM, etc.). FreeBSD we've beat to
> death over the last couple of weeks, so I'll leave it out of the mix for
> now. What in our unix past speaks to the current circumstance and what
> do those of you who lived those events see as possibilities for the next
> revolution - and, will unix be part of it?
>

Yes, those are almost exactly my thoughts on the current state of
OSes. I'm hoping that I can change it by writing my own OS
<https://gitlab.com/uxrt/>, because I don't see anyone else making
anything that I consider to be a particularly good effort to solve
those issues. However, it's still anyone's guess as to whether I will
succeed. I'm trying to give it every chance of success that I can
though by using existing code wherever possible and focusing on
compatibility with Linux (or at least I will be once I get to that
point).

BTW, I welcome any contributions to UX/RT. I currently am still only
working on the allocation subsystem (it's a bit trickier under seL4
than it would be on bare metal due to having to manage capabilities as
well as memory), but I think I am pretty close to being able to move
on.

>
> And a bonus question, why, oh why, can't we have a contained kernel that
> provides minimal functionality (dare I say microkernel), that is
> securable, and layers above it that other stuff (everything else) can
> run on with auditing and suchlike for traceability?
>

A lot of people still seem to believe that microkernels are inherently
slow, even though fast microkernels (specifically QNX) predate the
slow ones by several years. Also, it seems as if much of the academic
microkernel community thinks that there's a need to abandon Unix-like
architecture entirely and relegate Unix programs to some kind of
"penalty box" compatibility layer, but I don't see any reason why that
is the case. Certainly there are a lot of old Unix features that could
be either reimplemented in terms of something more modern or just
dropped entirely where doing so wouldn't break compatibility, but I
still think it's possible to write a modern microkernel-native
Unix-like OS that does most of what the various proposed or existing
incompatible OSes do.

>
> I can answer the microkernel question I think.  It's discipline.
> The only microkernel I ever liked was QNX and I liked it because it was
> a MICROkernel.  The entire kernel easily fit in a 4K instruction cache.
>
> The only way that worked was discipline.  There were 3 guys who could
> touch the kernel, one of them, Dan Hildebrandt, was sort of a friend
> of mine, we could, and did, have conversations about the benefits of a
> monokernel vs a microkernel.  He agreed with me that QNX only worked
> because those 3 guys were really careful about what went into the
> kernel.  There was none of this "Oh, I measured performance and it is
> only 1.5% slower now" nonsense, that's death by a hundred paper cuts.
> Instead, every change came with before and after cache miss counts
> under a benchmark.  Stuff that increased the cache misses was heavily
> frowned upon.
>
> Most teams don't have that sort of discipline.  They say they do,
> they think they do, but when marketing says we have to do $WHATEVER,
> it goes in.
>

I still don't get why QNX hasn't had more influence on anything else
even though it's been fairly successful commercially. If i am
successful, UX/RT will only be the second usable non-QNX OS with
significant QNX influence that I am aware of (after VSTa; there have
been a couple other attempts at free QNX-like systems that I am aware
of but they haven't really produced anything that could be considered
complete).

seL4 is fairly similar to QNX's kernel both in terms of architecture
and design philosophy. That's why I'm using it in UX/RT. I may end up
having to fork it at some point, but I am still going to keep to a
strict policy of not adding something to the kernel unless there is no
other way to reasonably implement it. For the sake of extensibility
and security I'm also going to have a strict policy against adding
non-file-based primitives of any kind, which is something that QNX
hasn't done (no other OS has AFAICT, not even Plan 9, since it has
anonymous memory, whereas UX/RT will use memory-mapped files in a
tmpfs instead).

On 2/8/21, Dan Stromberg <drsalists at gmail.com> wrote:
>
> But I also have high hopes for Redox OS, and may switch someday:
> https://en.wikipedia.org/wiki/Redox_(operating_system)
> https://www.theregister.com/2019/11/29/after_four_years_rusty_os_nearly_selfhosting/
>

The biggest problem I see with Redox is that they insist on writing
everything from scratch, whereas with UX/RT I am going to use existing
code wherever it is reasonable (this includes using the LKL project to
get access to basically the full range of Linux device drivers,
filesystems, and network protocols). Also, their VFS architecture is a
bit questionable IMO. Otherwise I might have been inclined to just
contribute to Redox (UX/RT will use quite a bit of Rust, but it won't
try to be a "Rust OS" like Redox is). I may end up incorporating more
code from Redox though (I'm already going to use their heap allocator
but will enhance it with dynamic resizing of the heap).

In addition they claim it to be a microkernel when it is actually a
Plan 9-style hybrid, since the kernel includes a bunch of Unix system
calls as primitives, disqualifying it from being a microkernel. This
is unlike QNX where the process server that implements the core of the
Unix API is built into the kernel but accessed entirely through IPC
and not through its own system calls (the UX/RT process server will be
similar in scope to that of QNX and will similarly lack any kind of
multi-personality infrastructure and be built alongside the kernel,
but will be a separate binary).