7 ms·
No. “Multiserver” (a term from the microkernel literature) means that the conventional basic OS services are split into several “server” processes with distinc
by mananaysiempre 4y ago
No.
“Multiserver” (a term from the microkernel literature) means that the conventional basic OS services are split into several “server” processes with distinct responsibilities (a mounted filesystem, a network card, perhaps a hardware bus, etc.). This is the original conception of a microkernel- (as opposed to e.g. an exokernel-) style system and its architectural promise, although it’s not made necessary by the mere fact of being built on top of a microkernel: AFAIK L4Linux is a single server so the L4 microkernel basically acts as a simple VMM / HAL without further architectural benefits. (For other monolithic but userspace OS servers, look at wineserver in Linux, CSRSS and LXSS in Windows NT, etc. For multiserver systems of varying purity, look at QNX and Minix.)
What you’re thinking of is a “distributed OS”, although those academic efforts look terribly naïve from today’s distributed consensus standpoint. Good points of entry may be Barrelfish and Plan 9.
- als0 4y agoAmoeba is a famous example of a distributed OS https://en.wikipedia.org/wiki/Amoeba_(operating_system) https://en.wikipedia.org/wiki/Amoeba_(operating_system)
- api 4y agoIt’s too bad this research didn’t continue. Instead we got a giant tower of kludges including containers, Kubernetes, service meshes, endless API design problems, endless reinventing of data serialization and protocols, and so on.
- deleted 4y ago[deleted]
- johnisgood 4y agoOr something like https://en.wikipedia.org/wiki/Sprite_(operating_system) https://en.wikipedia.org/wiki/Sprite_(operating_system) but with a microkernel!
- mananaysiempre 4y agoThe academic environment where that research was the thing to do if you wanted to do systems is the academic environment that produced Pike’s “Systems Software Research Is Irrelevant”[1]. It seems to have succumbed to two relatively common afflictions, though I don’t know of another case of both simultaneously: - Inbreeding of ideas: researchers inventing and solving problems noöne actually has, without observing the discipline necessary to remain interesting and avoid emotional attachments (as is done in maths, with varying success). In the distributed OS case, the model in people’s heads (including Pike’s with Plan 9!) seems to have been a closed campus network, which is close to some of the areas people care now, but still isn’t quite any of them. The social problem of the system not being able to take over the world, thus necessitating explicitly specified protocols and loose coupling, also does not seem to have received much consideration. (Except for Microsoft, who has tried—deliberately or accidentally—to weaponize the homogeneity requirements of some of that research in building Windows domain networking.) Some of the kludges aren’t—they are solving social problems. - Being before its time: sounds glorious and heroic, in reality makes people cold, lonely, and more often than not broke. The most commonly known instances of this are for individuals (or other actors capable of having a coherent volition, such as companies), but the distributed OS story feels like this happened to the community as a whole. [1] http://doc.cat-v.org/bell_labs/utah2000/utah2000.html http://doc.cat-v.org/bell_labs/utah2000/utah2000.html
- mike_hearn 4y agoGreat document, thanks for the link. I think the main issue is actually more related to the trend in academia in which the 'least publishable unit' is ever more important. Pike's essay touches on this. Coming up with an interesting new OS design is hard, and implementing one is worse, so people don't try because it'd take too long and there wouldn't be enough papers in it for anyone. Companies still do OS research (see Singularity and Midori by Microsoft, Fuschia by Google) but don't publish much about it. The problem is to become sustainable you need users, and to get users you really have to be above the core OS these days because that's where you can focus on concepts instead of getting distracted by kernel and driver writing (not much interesting to do there). If you want to experiment with microkernels, do it as a collection of processes in the Linux userland and if you want to extend that to get users, make it run on Windows too. Chrome is in effect a kind of microkernel-ish operating system, seen from this perspective. It consists of a pile of sandboxed components connected by a sophisticated IPC system called Mojo. It also handles properly cases that microkernel research sometimes ignores or punts to the user, like how to gracefully handle if the other end of a connection crashes. I feel strongly that there's still lots of interesting research to do in the operating systems space but if I were to do it, I would not start by writing an actual OS. I'd start by exploring the ideas as an set of ordinary programs that could run on a regular OS. Maximize the window and start gradually eliminating dependencies on high level APIs provided by the host, if you really want to. Then you can explore concepts like single address space OS's, ultra-fine-grained microkernels, better shells, polyglot programming, distributed computing etc, without getting bogged down by irrelevant detail.
- startupsfail 4y agoApparently Python was developed for Amoeba. So in a way some strands of that research continued.
- 1MachineElf 4y agoI wish there was a way to run Ameboa and early Python together on QEMU, but the HTTP download links on the Ameboa site are down.
- mananaysiempre 4y agoTry the FTP archive at https://archive.org/details/2014.11.ftp.cs.vu.nl https://archive.org/details/2014.11.ftp.cs.vu.nl maybe, it seems to have the Amoeba files (unlike mirrorservice.org, which only has the Minix ones). The ArchiveOS page at https://archiveos.org/amoeba/ https://archiveos.org/amoeba/ linked from the Wikipedia page also has some.
- _448 4y agoApache Mesos, though not a ground up OS, it does have the aim of sharing resources across clusters.
- zasdffaa 4y agoApache Mesos is an OS??
- nix23 4y agohttps://mesos.apache.org/ https://mesos.apache.org/ >Apache Mesos abstracts CPU, memory, storage, and other compute resources away from machines
- still_grokking 4y agoIt's still not an OS in the classical sense. It's a regular user-mode executable. The idea is that it provides a kind of "virtual OS" to the applications build against it. But Mesos needs a regular OS as runtime on the nodes of the cluster.
- skissane 4y ago> It's a regular user-mode executable. I don't think that necessarily excludes something from being an OS. Historically, a number of Unix ports ran as applications on top of a non-Unix. AT&T's early 1980s port of Unix to IBM S/370 mainframes, ran Unix as an application on top of IBM's TSS/370 operating system. [0] The Interdata 7/32 port done at Wollongong University in Australia, initially ran under Interdata's OS/32 operating system, although once the port had advanced sufficiently to run on bare metal, OS/32 was ripped out from under it. [1] The first versions of Cray's UNIX port, UNICOS, supported running as a guest under their earlier COS operating system (which was a batch processing operating system, modelled after that of CDC mainframes.) I still don't think Mesos counts though. Applications running under Mesos access resources by calling the Linux APIs; Mesos configures the Linux environment the application runs under, but at runtime it steps out of the way. If, hypothetically, Mesos had exposed its own API to applications running under it – separate from the Linux API, even if ultimately implemented using it – and forced them to use that rather than call the host OS APIs directly – then I would count it as an OS. But, that would be a rather different thing from what Mesos actually is. (And all those points apply to Kubernetes too.) With talk about WebAssembly as a container format – if you had something like Mesos/Auroroa/K8S/etc which ran WebAssembly containers only, so that applications running under it could only access WASI and other WebAssembly-based APIs – that would be closer to a true OS, even if it happened to run on top of the Linux kernel. You could swap out the Linux kernel for another – BSD, Windows, Illumos, XNU, GNU Hurd, L4, Fuschia, z/OS, whatever – and the apps shouldn't be able to tell the difference. [0] https://ieeexplore.ieee.org/document/6771917 https://ieeexplore.ieee.org/document/6771917 [1] http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
- forgotpwd16 4y agoMoreover it is also microkernel-based.
- mycall 4y agoHow would you classify Genode wrt being a multiserver?
- mananaysiempre 4y agoI haven’t found the time to examine it closely for several years now, but after finally skimming a couple of chapters of the Foundations book (thanks!) it looks like a classic multiserver to me.