Hacker News Reader

Comment by miga | Hacker News Reader

I disagree with the author:

1. We could gradually port Linux `ioctl` to Plan9 namespaces, if there was understanding they greatly simplify Docker.

2. Docker and virtualization are one of most important applications of Linux, but there is still not even a proof-of-concept implementation of such on Plan9.

3. We don't need a complete rebuilding of Linux to make it more like Plan9. Both Windows and Mac OS X is an example of system that underwent radical redesigns of several subsystems.

4. All features of Plan9 could be brought to Linux by adding modules for alternative system interfaces, and deprecating old ones or blocking them with security capabilities.

View on HN

The feature of plan 9 that makes it all hang together is that all features interact through a single, network transparent, universal layer.

Fixing this in Linux means removing everything that doesn't fit in this interposable, redirectable, nameable world with a uniform way to interact with all resources.

That's most of Linux.

Ioctl is a particularly egregious violation of the model.

on plan9 you can theoretically tarball a running process file, move it over the network, ubtar it and have it continue to run as it was before.

that a little above your docker usecase already...

Just a nitpick: "docker" is not a technology, its a product. What you (and the author) mean is "kernel containers".

Regarding the rest: I was an early Plan9 user and still use some of their tools. They had some good ideas and some bad ones. I don't want people to rewrite linux to make it a plan9 clone. The good parts have already been added to Linux anyway

wrt #4: No, the big thing about Plan 9 is that each process has its own view of the filesystem, and can modify it without any privileges. This would break the unix security model because unix has setuid.

Quote from https://utcc.utoronto.ca/~cks/space/blog/unix/WhyNoUserNames...:

> Imagine that Unix had this feature and still had setuid, and you would like root privileges. No problem; make a custom namespace for /etc that has a version of /etc/shadow, /etc/group, and /etc/sudoers that have known passwords and list you as authorized. Now run sudo. Done.

Reply on news.ycombinator.com