Re: Compatibility of microkernel systems with legacy OSes; was L4Re with GCC 9; Repositories and Roadmaps

On 1/29/20, Paul Boddie <[email protected]> wrote:
>
> Nor do the BSDs, but it is the reliance on Linux-specific features that ends
>
> up hurting Free Software. We only need look at the Free Software desktops
> and
> their reliance on software which demands an increasingly monolithic and
> "opinionated" stack of Linux-specific software. Things like Debian GNU/Hurd
>
> and kFreeBSD, whatever their merits, suffer from this creeping monoculture.
>

Yes, that's a problem I've come across more and more. That's exactly
the reason why Linux compatibility will be a priority for UX/RT. I'm
hoping I can make Linux world domination work for me rather than
against me.


> It depends on what your ambitions are for interoperability. From what I
> recall, the BSDs and maybe various proprietary Unix products sought to
> support
> ABI compatibility with Linux, meaning that you could run Linux executables -
>
> presumably Intel x86 flavoured - on those operating systems. (I think Spring
>
> also sought to support Solaris binaries in such a fashion, by the way.)
>
> But I imagine that you're looking for source code compatibility. However, I
>
> don't think that portability should be too much of a concern for well-
> engineered software projects: we all lived with multiple Unix flavours and
> autotools for years and things went pretty well. And some projects deal with
>
> even more esoteric things like Mac OS X, Windows NT (and successors), and
> sometimes even their predecessors.
>

Yes, well-designed applications should usually be portable, but as you
said it is becoming increasingly common for programs to depend on
Linuxisms.

>
> I thought a bit more about libraries after writing my last message, and I do
>
> think that there would be benefits in describing component interfaces, if
> only
> to have productive discussions about how functionality might be arranged in
>
> such systems. I would say that such elaboration of interfaces has been
> rather
> de-emphasised in things like L4Re, with libraries being used to hide away
> such
> details, but just as various modelling diagrams can help to understand
> software, so we might expect interface descriptions to help us reason a bit
>
> better about the systems we want to develop.
>

If you're talking about RPC interfaces, components that require them
would be something I would consider an unnecessary burden in many
cases. UX/RT will limit its use of traditional dynamic RPC except
where it is actually the best way to implement something (like a lot
of desktop/GUI-related things; the process server will use a limited
form of RPC that is purely static).