Bell Labs' Plan 9 research project looks to tomorrow (1990)

Capabilities were supposed to split up the need to having a single root account that could do everything. I'm not sure how far it has gone.

https://tbhaxor.com/understanding-linux-capabilities/

https://blog.container-solutions.com/linux-capabilities-in-p...

The number of special cases.

For example: consider how you'd write some generic code to forward all ioctls transparently across the network. Keep in mind that the data attached to the ioctls is machine dependent, driver dependent, and has no information about how it's formatted. Every ioctl for every driver is its own special case.

Meanwhile, faithfully forwarding all devices in a plan 9 system is trivial. Control messages aren't strictly formatted -- but they're done via reads and writes on file descriptors, so sending them to the devices that understand them, and relaying back the result, is trivial. It's just 9p: https://man.9front.org/5/0intro

Doing this fully, for all devices (except /srv, which is a bit magical) is implemented here, in a short shell script. This is the remote login program used by 9front, which gives you something resembling ssh or vnc, but with full access to the data and devices on your local machine, graphics, audio, mouse, keyboard, USB, network, and anything else, even if it hasn't been implemented yet. It does both client and server side:

https://git.9front.org/plan9front/plan9front/HEAD/rc/bin/rcp...

The client side sets itself as a file server, using exportfs. It exports everything in its namespace, including /dev, over to the server.

The server takes the client's namespace, and mounts it over /mnt/term. Then, it takes /mnt/term/dev/cons and binds that over /dev/cons and starts a shell. That means that every time a program is run, it opens /dev/cons to interact with the user, using the client's mouse, keyboard, and so on, forwarding all the operations transparently over the network.

The idea can go further; Instead of using network translation layers, for example, a plan 9 machine would import a different machine's network stack and mount it over itself:

    # whats my ip?
    % cat /net/ipselftab
    192.168.1.11                                 01   4u
    % hget https://api.ipify.org
    74.{home.address}

    # ok, let's import another machine's network stack and use it.
    % rimport orib.dev /net/ /net

    # what's my ip now? look ma, I'm proxying!
    % cat /net/ipselftab
    144.202.1.203                                01   4u
    % hget https://api.ipify.org
    144.202.1.203

There are no special hooks in the network stack for this. It doesn't know. This happens for free because the network stack being accessible through the filesystem API.

This kind of thing happens everywhere, because everything goes through 9p, and everything can be namespaced. There isn't any other special case to consider: If you forward 9p, you forward all operations you can do with a device. Or any other file server.

If everything is in a namespace, you don't pull the devices other programs are using out from under them, so you can put one login in one sandbox with a remote mouse and keyboard, and a different one in a different sandbox with a different network stack.

This falls apart when you have the 53,719 special cases bundled with posix. If you need a special case for each operation you through the network, or interpose in userspace, you're in for a rough time.

Plan 9 works because it's relatively simple and uniform.

> Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword.

Not sure I understand. I imagine without dynamic linking/shared libraries, most widely used shared libraries would be widely used statically linked libraries, and so a vulnerability in them would indeed be harder to fix, as you'd need to relink all the binaries using them instead of just the dynamically linked library?

(Also, memory usage seems more concerning to me than disk space. Shared libraries are called "shared" because all their non-mutable pages in memory are shared across processes. To even approximate the same with static libraries, you'd pretty much have to have deduplication of pages in memory. Link-time optimization might then spoil even that plan entirely. Of course on the other hand, dynamic linking precludes LTO for that.)

Hint: static linking predates Plan 9. Static linking even predates shared libraries. Back in the '80s there were impassioned quarrels over whether anything should be shared. Laura Creighton was static linking's most impassioned voice. The fact that a shared library may be mapped once and used by all the programs that call it carried the day, back when main memory was measured in megabytes, and GUI libraries were huge and getting bigger.

If there is anything we should thank Plan 9 for, it has to be UTF-8.

This comes up constantly and is pretty easily refuted by opening pretty much any app on an Android or iOS phone and observing just how many pages of the system shared libraries are touched by even the most trivial apps. You can do this by e.g. purging the FS cache, disabling readahead, launching an app, and then observing how many code pages are resident.

All of that code would have to be brought into app binary itself, making mobile apps even larger in code size than they already are. Dead code elimination could eliminate some of that bloat, but I doubt it'd eliminate much of it, given that we're only measuring resident pages to begin with.

Only allowing static linking might make sense on servers (it certainly makes deployment a lot easier). But it wouldn't work on mobile devices without significantly changing the way mobile apps and OSes are architected.