5 ms·

> And IT does another cycle. People keep saying that as if it was a bad thing

pjmlp 3y ago
Usually it is great for those of us that sell consulting services, for the others not really.
lproven 3y ago
It wouldn't be a bad thing if people learned from the previous iteration. But they don't. In fact, what they generally do is layer an implementation of the stuff they forgot last time on top of the preceding iteration which lacked it. So now, we have clusters of Linux boxes, built with a ton of new tooling on top of Linux because Linux is a UNIX and traditional UNIX doesn't have networking or clustering in the design. (Go on, then, 2 PCs on a LAN, both running a bare Linux kernel and a shell for init. Call them box1 and box2. Tell me how you mount the filesystem of box2 in a folder on box1.) Plan 9 is UNIX 2.0 and can do this out of the box, but we didn't adopt Plan 9 so now we have to emulate it in a million lines of Rust or something. Now we have WASM which is kinda sorta compiling to the bare bytecode of the Javascript runtime, for universal app binaries. Only you need a vast infrastructure to run it. Inferno is UNIX 3.0 and can do this out of the box: it has the Dis VM right in the kernel, and all its components are compiled to Dis bytecode so binaries run on all supported processors. But we didn't adopt Inferno so now we have to emulate it in a million lines of C++ because Mozilla cancelled Rust.
- deleted 3y ago
  [deleted]
- worthless-trash 3y ago
  Features are backed by code. The code has to exist somewhere, in previous systems it ran as ring0. Is this where you want your privesc ?
  - lproven 3y ago
    This is missing the point. The point is that if functionality is core to what you are doing with your OS, then it ought to be a core part of that OS and not layered on top. If that would make the kernel of your OS too big and too complex then the design of your OS is wrong.
- rcarr 3y ago
  What I don't get about all of this is why one of the big players don't invest heavily in Plan9/Inferno and promoting it. Surely having the networking and clustering code baked in to the OS makes the whole thing both easier and more efficient to run which would mean they'd be able to offer a product that significantly undercut their rivals in terms of price as well as allowing the companies using it to reduce their DevOps team sizes due to the reduced complexity? Unlikely that MS would do it given that they'd prefer everyone to run Windows but I don't get why AWS or GCP aren't jumping all over it.
  - pjmlp 3y ago
    J2ME, SavageSE, microEJ and Android, are basically Inferno, at least in part, and not on general purpose computing. Inferno was actually originally started to fight against Sun's ideas regarding Java, hence why alongside Limbo, there was also Java support eventually.
  - plagiarist 3y ago
    When companies are up against that much inertia, they push the boulder towards the nearest local minimum, not a currently known "best" global minimum. Why redo everything for Plan9 and train engineers on a new OS paradigm when you can write Kubernetes at a lower LoE? IMO of course, I'm not an expert.
- rollcat 3y ago
  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).
- yjftsjthsd-h 3y ago
  > Go on, then, 2 PCs on a LAN, both running a bare Linux kernel and a shell for init. Call them box1 and box2. Tell me how you mount the filesystem of box2 in a folder on box1. Running /bin/sh on a bare kernel isn't a unix system. A unix system has daemons, at which point we get enough supporting tooling to make use of the very much built into the kernel NFS and 9P support and mounting files from one machine to another becomes easy.
  - lproven 3y ago
    > Running /bin/sh on a bare kernel isn't a unix system. That's true and you're right. However, what I was specifically discussing here is core kernel functionality versus layering it on top, and for that, I had to describe things in an artificially simplistic way, because Linux folks tend to think Linux invented everything and is everything and start to go on about in-kernel Ethernet drivers and in-kernel NFS and so on and because they get busy counting trees, they miss the fact that they are lost in the forest. I am not advocating the use of bare kernels here. I am not saying this is a rigorous or fair comparison. What I am trying to demonstrate is the fundamental difference between having networking and a networked system as core parts of your system design, as opposed to bolted on later. It's integral in Plan 9. Whereas Linux is a UNIX, and therefore must implement things later on top of a core design which assumes that all machines are standalone multiuser minicomputers with dumb text terminals. This is such a fundamental part of the design of Unix that it is everywhere and it's very hard to show to Unix users that it's there... because it's the material of the walls, the floor, the ceiling and the door and so it's hard to see.
- otabdeveloper4 3y ago
  > mount the filesystem of box2 in a folder on box1. This is not possible due to the CAP theorem. (You will need to severely rethink your concept of "file" at the very least.)
  - lproven 3y ago
    And yet, that's how Plan 9 boxes talk to one another. I think maybe you are misinterpreting my post as saying "mount the entire disk used by box1 on box2 simultaneously". Although when it comes to that, I would also note that DEC's AdvFS did more or less that, 20+ years ago, and it's FOSS now: https://en.wikipedia.org/wiki/AdvFS https://en.wikipedia.org/wiki/AdvFS And it's also what the DragonflyBSD team are attempting to make happen in HAMMER2. https://www.dragonflybsd.org/hammer/ https://www.dragonflybsd.org/hammer/
    - icedchai 3y ago
      Wasn't DEC doing that with VAX/VMS 40 years ago with VAXclusters? See https://en.wikipedia.org/wiki/VMScluster https://en.wikipedia.org/wiki/VMScluster
      - lproven 3y ago
        I believe I specifically mentioned VMS and VAXclusters in the article, didn't I?
        icedchai 3y ago
        You did, sorry! I did not read your article originally. That's great. So few people these days even know about anything outside of Linux/Unix or Windows...
  - icedchai 3y ago
    DEC did it 40 years ago.
    - 3y ago
- solardev 3y ago
  > Tell me how you mount the filesystem of box2 in a folder on box1 It's not that hard. Just install Ubuntu, then VMware, then Windows, then WSL, then Docker, then a microcloud inside a container, then you can easily run a headless Dropbox client to sync that folder.
  - SoftTalker 3y ago
    I get the sarcasm, but seriously -- did we just forget about NFS? Also, sshfs will do the job at least up to a point.
    - solardev 3y ago
      We try to support YCombinator companies where we can :)

Usually it is great for those of us that sell consulting services, for the others not really.

It wouldn't be a bad thing if people learned from the previous iteration. But they don't. In fact, what they generally do is layer an implementation of the stuff they forgot last time on top of the preceding iteration which lacked it. So now, we have clusters of Linux boxes, built with a ton of new tooling on top of Linux because Linux is a UNIX and traditional UNIX doesn't have networking or clustering in the design. (Go on, then, 2 PCs on a LAN, both running a bare Linux kernel and a shell for init. Call them box1 and box2. Tell me how you mount the filesystem of box2 in a folder on box1.) Plan 9 is UNIX 2.0 and can do this out of the box, but we didn't adopt Plan 9 so now we have to emulate it in a million lines of Rust or something. Now we have WASM which is kinda sorta compiling to the bare bytecode of the Javascript runtime, for universal app binaries. Only you need a vast infrastructure to run it. Inferno is UNIX 3.0 and can do this out of the box: it has the Dis VM right in the kernel, and all its components are compiled to Dis bytecode so binaries run on all supported processors. But we didn't adopt Inferno so now we have to emulate it in a million lines of C++ because Mozilla cancelled Rust.

deleted 3y ago
[deleted]
worthless-trash 3y ago
Features are backed by code. The code has to exist somewhere, in previous systems it ran as ring0. Is this where you want your privesc ?
- lproven 3y ago
  This is missing the point. The point is that if functionality is core to what you are doing with your OS, then it ought to be a core part of that OS and not layered on top. If that would make the kernel of your OS too big and too complex then the design of your OS is wrong.
rcarr 3y ago
What I don't get about all of this is why one of the big players don't invest heavily in Plan9/Inferno and promoting it. Surely having the networking and clustering code baked in to the OS makes the whole thing both easier and more efficient to run which would mean they'd be able to offer a product that significantly undercut their rivals in terms of price as well as allowing the companies using it to reduce their DevOps team sizes due to the reduced complexity? Unlikely that MS would do it given that they'd prefer everyone to run Windows but I don't get why AWS or GCP aren't jumping all over it.
- pjmlp 3y ago
  J2ME, SavageSE, microEJ and Android, are basically Inferno, at least in part, and not on general purpose computing. Inferno was actually originally started to fight against Sun's ideas regarding Java, hence why alongside Limbo, there was also Java support eventually.
- plagiarist 3y ago
  When companies are up against that much inertia, they push the boulder towards the nearest local minimum, not a currently known "best" global minimum. Why redo everything for Plan9 and train engineers on a new OS paradigm when you can write Kubernetes at a lower LoE? IMO of course, I'm not an expert.
rollcat 3y ago
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).
yjftsjthsd-h 3y ago
> Go on, then, 2 PCs on a LAN, both running a bare Linux kernel and a shell for init. Call them box1 and box2. Tell me how you mount the filesystem of box2 in a folder on box1. Running /bin/sh on a bare kernel isn't a unix system. A unix system has daemons, at which point we get enough supporting tooling to make use of the very much built into the kernel NFS and 9P support and mounting files from one machine to another becomes easy.
- lproven 3y ago
  > Running /bin/sh on a bare kernel isn't a unix system. That's true and you're right. However, what I was specifically discussing here is core kernel functionality versus layering it on top, and for that, I had to describe things in an artificially simplistic way, because Linux folks tend to think Linux invented everything and is everything and start to go on about in-kernel Ethernet drivers and in-kernel NFS and so on and because they get busy counting trees, they miss the fact that they are lost in the forest. I am not advocating the use of bare kernels here. I am not saying this is a rigorous or fair comparison. What I am trying to demonstrate is the fundamental difference between having networking and a networked system as core parts of your system design, as opposed to bolted on later. It's integral in Plan 9. Whereas Linux is a UNIX, and therefore must implement things later on top of a core design which assumes that all machines are standalone multiuser minicomputers with dumb text terminals. This is such a fundamental part of the design of Unix that it is everywhere and it's very hard to show to Unix users that it's there... because it's the material of the walls, the floor, the ceiling and the door and so it's hard to see.
otabdeveloper4 3y ago
> mount the filesystem of box2 in a folder on box1. This is not possible due to the CAP theorem. (You will need to severely rethink your concept of "file" at the very least.)
- lproven 3y ago
  And yet, that's how Plan 9 boxes talk to one another. I think maybe you are misinterpreting my post as saying "mount the entire disk used by box1 on box2 simultaneously". Although when it comes to that, I would also note that DEC's AdvFS did more or less that, 20+ years ago, and it's FOSS now: https://en.wikipedia.org/wiki/AdvFS https://en.wikipedia.org/wiki/AdvFS And it's also what the DragonflyBSD team are attempting to make happen in HAMMER2. https://www.dragonflybsd.org/hammer/ https://www.dragonflybsd.org/hammer/
  - icedchai 3y ago
    Wasn't DEC doing that with VAX/VMS 40 years ago with VAXclusters? See https://en.wikipedia.org/wiki/VMScluster https://en.wikipedia.org/wiki/VMScluster
    - lproven 3y ago
      I believe I specifically mentioned VMS and VAXclusters in the article, didn't I?
      - icedchai 3y ago
        You did, sorry! I did not read your article originally. That's great. So few people these days even know about anything outside of Linux/Unix or Windows...
- icedchai 3y ago
  DEC did it 40 years ago.
  - 3y ago
solardev 3y ago
> Tell me how you mount the filesystem of box2 in a folder on box1 It's not that hard. Just install Ubuntu, then VMware, then Windows, then WSL, then Docker, then a microcloud inside a container, then you can easily run a headless Dropbox client to sync that folder.
- SoftTalker 3y ago
  I get the sarcasm, but seriously -- did we just forget about NFS? Also, sshfs will do the job at least up to a point.
  - solardev 3y ago
    We try to support YCombinator companies where we can :)