Linux Namespaces Are a Poor Man's Plan 9 Namespaces

Note that most terminal applications still use virtual terminals (`/dev/pty*`), and it is important to provide standard interface here.

Also, terminal makes it easier to debug failing UI, and host headless OS.

You forget that _all_ modern OS transcend the desktop: they support phones, tablets, and headless devices.

You don't get one object == one file node, you get one object == a subdirectory with lots of file nodes that you have to open and close independently. That should tell you that your pattern doesn't work. (With enough effort, you can of course always shoehorn everything into an ill-conceived concept (and you did), but if you have to bend over backwards to make it fit, you should just admit it doesn't fit.)

It works for /dev, but definitely not for the mess that is /sys and /proc.

"Reading and writing structs" is the most natural thing to do when you're forced to serialize your data. You then design wrappers around that serialization that expose a sane, type-safe API on each end.

> pretty much every compiler since the 90s has support for `#pragma once`

I asked for examples.

Specifically I am asking for examples that are not C compilers, do not compile languages derived from or related to C, and which do not run on Unix-like OSes, because what we are talking about here is what came after Unix. Plan 9 is effectively Unix 2.0: it is what the people who designed and built Unix did next.

Inferno is Unix 3.0. It's what they did after Plan 9.

Tweaks to the project that they had moved on from (or clones thereof, e.g. Linux) are not particularly interesting or relevant in this context, IMHO.

> You want me to cite compilers that don't compile C that support a C extension ?

No.

There are, hmm, I am not sure, at least 2, probably 3, and I suspect more than 3 assumptions in here.

#0, general context:

The bigger picture here is that there is a whole world of OS and language development which is completely outside the world of Unix, C, and things that derive, directly or indirectly from it.

However, the Unix+C world is so big, so commercially successful, that a lot of people in it can't see that there is anything else. To quote Gaiman and Pratchett, it's the same as the reason that "people in Trafalgar Square can't see England".

I wrote about this recently: https://www.theregister.com/2022/03/29/non_c_operating_syste...

#1. Plan 9 is not a Unix. It's what came after Unix. As such, I would say it's fair to say that Plan 9 C is not plain ol' Unix C. While the Unix flavour of C has continued on its own path, it's a very conservative path: it's terrified of breaking backwards compatibility. The developers of Plan 9 were not scared like this, and quite cheerfully made big sweeping changes.

#2. So, yes, I would consider that carefully implementing and adding what you yourself call an extension to an existing compiler (or set or family of compilers, it doesn't really matter) is not the same thing as redefining the semantics of a language to say "you are not allowed recursive includes".

One is a big sweeping change; the other is a minor tweak.

#4. The core, important point here is that Plan 9 made significant changes which in places have big ramifications — for instance, performance improvements on the order of several orders of magnitude — simply by tightening up the rules around an existing, well known language. IMHO, adding a new compiler directive is not comparable to this.

Adding a new directive is patching a hole, while changing the rules of how the languages compiled is fixing the design. What I was enquiring about was other designs that fix this problem in the core design of traditional compilers, in other words UNIX C and its descendants.

> And you want the language it compiles to be completely unrelated to C ?

Well, yes! Why not? There are lots of them!

> Frankly, I'd already be quite hard-pressed to even cite a compiler that compiles a language that is completely unrelated to C in the first place and doesn't run on any Unix-like OSes

Really? OK then, let me see how many I can name of the top of my head without googling: Pascal, Lisp, APL, Fortran, Cobol, Algol, BCPL, Forth, Ada, Prolog, Bliss... Okay I'm starting to struggle a little bit now, but I think the point is made.

I wasn't asking for languages that don't run on UNIX. I was asking for languages that weren't built out of UNIX tools. There are legions of languages today that were built pretty much entirely from the existing UNIX toolchain, from Python to JavaScript. My point is that there are dozens to hundreds of languages which are outside of that family.

Plan 9 is, I would argue, outside of that family because it's what came after that family.

Operating systems from outside of the UNIX family? Classic MacOS, AmigaOS, CP/M, MS-DOS, Atari ST TOS, Concurrent CP/M, Concurrent DOS, DR FlexOS, Novell Netware, OS/2 and all of its descendants, GEOS, Palm OS, Newton OS, Microware OS9, Interlisp/Medley, OpenVMS, OpenGenera.

And of course basically all mainframe operating systems... Tools that are still worth billions of dollars today, whose daily use affect everyone who uses a bank account or everyone who ever travels on an aeroplane.

So, yeah, a pretty significant technological and economic market segment… and one that UNIX people often totally forget exists at all. As it seems you did.

That sure is quite a useful precision to make - personally I found what you were asking for confounding given I can't really think of much of any language that doesn't run on UNIX, save for particularly obscure, often long-defunct ones (i.e. languages that basically don't run on anything at all or on stuff I couldn't possibly check out myself anyway). The fact you've also implicitly added the stipulation that only languages that derive from C and not all those that are related to it are excluded is also quite useful - I was excluding languages like BCPL or Algol on that basis (and I was quite iffy on Fortran/Pascal and a few others too, though since most ran on UNIX I wasn't even considering most of them anyway).

Also, while I broadly agree with your point about most people not even thinking stuff outside of Windows/UNIX exists and indeed find it quite acutely accurate in many cases, I'd say I'd hope I wouldn't be counted in it - I could have named most of the OSes and languages you did, save for a few like Microware OS9 or Bliss, simply I did not name the languages when prompted to because I'm not really aware of any that can't run on UNIX-like OSes, which I had then thought you were excluding before you clarified things.

Anyway, I'm aware of my ignorance of many of the details that are involved, but more importantly for what we were discussing, I would find it remarkably unlikely that any of these languages has a dependency handling system quite alike to that which is involved in Plan 9.

Are you actually telling me that you know of many examples of languages and/or compilers that handle dependencies like in Plan 9 ? That want you to manually specify all the dependencies of all the libraries you want to use before you can use that library, and which consider this sane in any way ?

If any actually exist, then I'd expect there's either: 1. Tooling around them specifically made to work around this exact issue by automatically specifying the dependencies when needed without having to spell them out manually 2. Preferred alternatives that don't have this problem in the first place

Meanwhile, the `#pragma once`-style model (i.e. make it so that imported libraries can use a separate library without ending up with asinine "double definition lol" errors if the program that uses the first library also separately uses the second one) seems like the evident standard that all the other languages use, such as:

- Ada

- Fortran

- Pascal

- APL

- Cobol

- Algol

- Prolog

within which I've found no examples of needing to do something like `import definitions_every_single_library_or_module_relies_on` and `import definitions_from_the_library_almost_every_single_other_library_or_module_uses` at the top of almost every file.