3 ms·

As much as I love Plan 9 and Inferno, the reason why they never were a commercial success is because they deliberately broke backwards compatibility with UNIX.

As much as I love Plan 9 and Inferno, the reason why they never were a commercial success is because they deliberately broke backwards compatibility with UNIX. (Which was an excellent choice for Plan 9 as a research OS, but perhaps should've been reconsidered for a commercial offering.) They did however accomplish pushing the "UNIX 1.0" into at least 1.1: as awkward as Linux's /proc is, it's still objectively better than sysctl; 9P is a practical choice for sharing files with a VM guest; and let's not forget everything Go brought to the table. In retrospect, considering which technologies contemporary to Plan 9/Inferno have "won", I'm also grateful that we don't need to deal with an in-kernel JVM.

craftkiller 3y ago
> Linux's /proc is [...] still objectively better than sysctl Is it though? AFAIK there is no way to get an atomic snapshot of the contents of /proc so any attempt to traverse the tree will be met with "No such file or directory" errors as processes end. You can reproduce this with a simple: doas find /proc -name pid -exec cat {} \; Whereas sysctl returns a consistent snapshot of the data requested.
- rollcat 3y ago
  My point is about the elegance of using open/read/write/close (the mantra of Plan 9) versus going through a complex interface full of constants defined in a C header file. A bunch of shell commands stitched together is the wrong level of abstraction for taking atomic snapshots of anything. Even "ls | xargs cat" suffers from the same problem: ls might output the name of a file that gets deleted or renamed before cat can open it. You'd need to mount a filesystem read-only, or take a snapshot (on e.g. ZFS). You can however use openat(2), which should in theory at least guarantee that if dirfd=open("/proc/123", ...) succeeds, then openat(dirfd, "pid", ...) will not race against another process reusing the same pid. PIDs being racey by nature is why Linux introduced pidfd_open(2) and friends.
  - craftkiller 3y ago
    > My point is about the elegance of using open/read/write/close I certainly agree with you that they are more pleasant to use, and I think procfs could one day solve the atomic snapshot issue. For example, there could be a /proc/snapshot directory. Running mkdir inside there could take a snapshot that the calling process would then be free to traverse at its leisure. It could be tied to the process group that called mkdir to make sure the snapshot gets automatically cleaned up when the calling process terminates. I think this would work a lot better with Plan 9's per-process namespaces but it could be hacked onto Linux. At that point, the only argument I would have against procfs would be that we'd be paying for hundreds to thousands of syscalls compared to sysctl costing us only one syscall (or rather, two syscalls if I'm reading the FreeBSD source for kinfo_getallproc correctly).
pjmlp 3y ago
Except that Android, WebOS and ChromeOS are closer to Inferno than UNIX, and quite successful. IBM i and IBM z, have done quite alright for OSes with an in-kernel JIT. It turns out when a company really has the budget, and the necessary management support, to push a technology no matter what, it happens.

craftkiller 3y ago

> Linux's /proc is [...] still objectively better than sysctl Is it though? AFAIK there is no way to get an atomic snapshot of the contents of /proc so any attempt to traverse the tree will be met with "No such file or directory" errors as processes end. You can reproduce this with a simple: doas find /proc -name pid -exec cat {} \; Whereas sysctl returns a consistent snapshot of the data requested.

rollcat 3y ago
My point is about the elegance of using open/read/write/close (the mantra of Plan 9) versus going through a complex interface full of constants defined in a C header file. A bunch of shell commands stitched together is the wrong level of abstraction for taking atomic snapshots of anything. Even "ls | xargs cat" suffers from the same problem: ls might output the name of a file that gets deleted or renamed before cat can open it. You'd need to mount a filesystem read-only, or take a snapshot (on e.g. ZFS). You can however use openat(2), which should in theory at least guarantee that if dirfd=open("/proc/123", ...) succeeds, then openat(dirfd, "pid", ...) will not race against another process reusing the same pid. PIDs being racey by nature is why Linux introduced pidfd_open(2) and friends.
- craftkiller 3y ago
  > My point is about the elegance of using open/read/write/close I certainly agree with you that they are more pleasant to use, and I think procfs could one day solve the atomic snapshot issue. For example, there could be a /proc/snapshot directory. Running mkdir inside there could take a snapshot that the calling process would then be free to traverse at its leisure. It could be tied to the process group that called mkdir to make sure the snapshot gets automatically cleaned up when the calling process terminates. I think this would work a lot better with Plan 9's per-process namespaces but it could be hacked onto Linux. At that point, the only argument I would have against procfs would be that we'd be paying for hundreds to thousands of syscalls compared to sysctl costing us only one syscall (or rather, two syscalls if I'm reading the FreeBSD source for kinfo_getallproc correctly).

pjmlp 3y ago

Except that Android, WebOS and ChromeOS are closer to Inferno than UNIX, and quite successful. IBM i and IBM z, have done quite alright for OSes with an in-kernel JIT. It turns out when a company really has the budget, and the necessary management support, to push a technology no matter what, it happens.