On 1/29/20, Paul Boddie paul@boddie.org.uk 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).