So.. we’re back to self-hosting your own services?
And IT does another cycle.
And IT does another cycle.
I work with an enterprisey on-prem product, which we of-course tried to replace with a cloud offer. And in all fairness, it's generally gone well - but because we manage the platform, it sits in the cloud we chose. And that's never going to be the right choice for everyone.
So we have some customers who are concerned about national boundaries. We have some customers who offer their own clouds, and aren't hugely enthusiastic about using the competition's. And then the whole mess with the govt having isolated regions within otherwise-public cloud offers.
Between these, it quickly became apparent that replacing our traditional offer with *aaS would leave a lot of money on the table. It's a minority of customers, but it turns out to be a very valuable minority.
Within that context at least, "private clouds" start to feel like they have legs - bringing most of the benefits of the cloud, to places that 'public' can't reach.
I've been saying this for years. The Ubuntu vision here is appealing: storage and live migration as first class things, because many high value services are never going to be "cloud native," easily scheduled, stateless, ephemeral container apps: the stuff k8s et al. was designed for.
So they have the right model. Now it's down to execution.
The big gain from clouds is the flexible infrastructure, especially in the microservices world we are now. In the past, one needed to procure, provision, etc a new server to run a service (times X per environment). With a cloud, regardless if it's public or private, provisioning a VM (or container) to run a new service is a few clicks away.
There might be a quiet betting pool on just how much more.
Been through the fad cycle three times now and worked out where to make money :)
People keep saying that as if it was a bad thing
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.
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.
Inferno was actually originally started to fight against Sun's ideas regarding Java, hence why alongside Limbo, there was also Java support eventually.
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.
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 {} \;
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.
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).
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.
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.
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.
This is not possible due to the CAP theorem.
(You will need to severely rethink your concept of "file" at the very least.)
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
And it's also what the DragonflyBSD team are attempting to make happen in HAMMER2.
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.
Also, sshfs will do the job at least up to a point.
It never stopped: plenty of places have on-site VMware and Hyper-V, both of which provide (IIRC) APIs to automated VM creation. If you're more open source, there's OpenStack (which VMware has a API-compat layer for).
Medical, we do everything in-house to make life easier.
Low value servers, in-house.
High uptime + scalable? You are not doing that in-house.