On 1/29/20, Paul Boddie <p...@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). _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
