All of the computers are "running" the OS. The OS is more than one service on more than one machine.
https://en.wikipedia.org/wiki/Distributed_operating_system
"Research and experimentation efforts began in earnest in the 1970s and continued through the 1990s, with focused interest peaking in the late 1980s. A number of distributed operating systems were introduced during this period; however, very few of these implementations achieved even modest commercial success."
So looks like they're trying to keep the idea going?
So 'inevitably destinated to evolve'? No..
VMWare usage is actually on the decline now with many companies switching to cloud services (which are generally running Xen). And containerisation, while not a like-for-like replacement for virtualisation, has also eaten aware at some of VMWares market share. Particularly with services like k8s. Those that are dependent on running Windows might still use VMWare but Microsoft Hyper V has also eaten away at VMWares market share too.
Also people deploying Wordpress on a VPS and using Excel are categorically NOT doing any form of distributed computing, which is what this discussion is about. So it’s correct to discount those contexts.
What I’m noticing here is a lot of people are confused about the terms “distributed” and “data centre”.
And as for Hyper-V, that’s only there for people locked into the Windows ecosystem. You rarely see much distributed computing happening in Windows. Frankly it’s silly to even mention Windows in the same conversation as Plan 9 and other distributed systems.
Saying “infrastructure needs to scale” is such a generalised truism that it doesn’t really contribute anything to the discussion. And the way how Plan 9 manages scale vastly different to how Docker, VMWare and other solutions manage scale.
I do get the general point you’re making. I honestly do. But as I said in my initial post, it’s not a new trend nor emerging trend like you claimed. It’s already been the industry norm for the lifetime of most engineers careers.
So the real crux of our disagreement isn’t about technology nor whether infrastructure at scale is even needed, it’s the timeline you suggested. You’re out by a couple of decades — so far out that entire architectural designs to solve these problems have come and gone.
This feels perhaps a bit too dismissive?
Just in the past few months the VPS vendor that I get most of my VPSes from introduced a VMware cloud offering: https://www.time4vps.com/vmware-cloud/
If you were looking for a technology that is inevitably on its way out, I'd reckon that something like OpenVZ might be a better fit for such criteria, albeit for different reasons (being pinned to an older kernel version for the most part).
> VMWare usage is actually on the decline now with many companies switching to cloud services (which are generally running Xen). And containerisation, while not a like-for-like replacement for virtualisation, has also eaten aware at some of VMWares market share. Particularly with services like k8s. Those that are dependent on running Windows might still use VMWare but Microsoft Hyper V has also eaten away at VMWares market share too.
Containers are pretty great, however I wouldn't say that they're always exclusive to virtualization - I've seen plenty of useful setups splitting up physical hardware in virtual machines per project/team for access control and hard resource limit reasons and then the team using container orchestrators inside of those for easier deployment/management of apps and further resource limits on a per-service basis (e.g. how one would otherwise use something like systemd slices).
Sure, there are benefits to running containers directly on hardware, but also some challenges associated with it, compared to the VM based setup which gives you more flexibility (including not running containers in parallel for legacy systems and/or teams where they aren't a good fit) and the benefit of a technology that has been around for a long time, as opposed to needing to worry about picking the correct rootless runtime and figuring out how to better enforce resource limits across different teams with varying quality of engineering standards (Kubernetes namespaces are helpful here, but Kubernetes is not the only orchestrator you might use, the requirements for which might also vary on a per-project basis).
I don't really have a horse in the race, I merely enjoy the benefits of the (various) virtualization solutions, container orchestrators and runtimes, as well as any number of storage abstractions (GlusterFS and Ceph come to mind) and networking solutions (WireGuard seems like a pretty cool recent one) that come to mind. More so, many of those can easily work in tandem in many cases. Building on the progress of the past few decades seems like a pretty decent idea and I don't really see VMware or other solutions as on their way out anytime soon.
None of that might be very relevant for the serverless cloud, though, or people who just run managed Kubernetes in the cloud and don't care about the actual infrastructure, but that is nowhere near anyone.
Im just posting my observations having managed on prem and data centres over the last couple of decades.
> Containers are pretty great, however I wouldn't say that they're always exclusive to virtualization
I literally said it’s not a like for like replacement. Plenty of SaaS offerings run virtualisation for security with containers on top. But in those instances the VMs aren’t used for distributed computing; they’re used as a security layer. It’s the containers that perform the distributed aspects.
And I wouldn't call "cd", "ls", "mkdir", "rm", "cat" and "echo" a query language.
Even the first navigational databases had a proper query language, although radically different from SQL.
Novell Netware was also marketed as a Network Operating System, in the sense that none of its services were confined to the local machine: its entire purpose was to combine a network of computers into a single management unit.
And I don't know what you mean by "catalogs", in the context of IBM i. Are you talking about DB2 catalog views? (Which exist in DB2 on every other platform, and most other RDBMS have something equivalent, such as the ANSI standard INFORMATION_SCHEMA)
Or are you confusing IBM i with MVS (in which the OS contains databases called "catalogs", in which you lookup a file name or file name prefix to find out which disk volume a file is stored on?)
You could _also_ architect a comparable system as user-space networking on top of a conventional OS, but that's by no means required.
Distributed OSes have been an active area of research since the 1970s at least.
But this seems to be proposing a distributed database that runs across computers, which confuses me. Anything that runs across computers seems to me to be application-level, not OS-level, by definition. What does it even mean to be running a distributed database on "microkernel services" instead of on fully-fledged OS's? And then... where is the OS-level CPU coming from? If the database is distributed among computers then fine, but which computer is "running" the OS?
Both the nomenclature and distributed aspect are really throwing me off here.