I think I’d rather go the other way, implement a Plan 9-like userspace, virtual filesystem and all, on top of the Linux kernel. The interesting parts of Plan 9 are the userspace abstractions over the hardware, and the (mostly) interesting parts of Linux are the hardware and industry support. You can already run blink by jart on any POSIX compliant system (which Plan 9 is, with compatibility layers), so I’m not sure what you gain from microVMs here.
I am more interested in the potential for modernising and updating what was effectively UNIX 2.0 than in continuing a vast monolith that was obsolete in 1991, even if it’s really capable today.
I don’t see how the argument against monolithic kernels applies to Plan 9, which is also monolithic. plan9ports is sort of what I’m talking about, but instead of having it sit on top of Linux userspace APIs, I’d rather have it replace them.
I think the key word was “vast” rather than “monolith”. :-)
I mean, yes, it is, but a lot of the stuff that’s in-kernel on Linux, or in user space communicating by some fancy IPC mechanism on the HURD or L4 or whatever, is in user space communicating via the filesystem in Plan 9. AIUI, anyway.
Fair enough. Linux really sorely lacks a proper message-passing subsystem. I’m always in favor of more Plan 9, at least to toy with the concepts, but am simultaneously skeptical that it’s designs implementations are sound in modern distributed systems.
That’s a good point, but OTOH, there’s only one way to find out. Well, OK, no, there isn’t, but OTOH it does seem to me that a lot of what Kubernetes does, for instance, is right there in the basic design of Plan 9.
In an ideal world I’d prefer the UI of Inferno, back-ported, but I suppose it’s written in Limbo and so that would be a significant undertaking.
One of the interesting efforts to modernise Plan 9 was Harvey, but that’s ended now.
I don’t think Plan 9 does half of what Kubernetes does. Kubernetes handles things like graceful failover, replica sets, dynamic rebalancing, etc., which Plan 9 doesn’t really have robust support for, to my understanding at least.
To better articulate why I don’t think Plan 9 actually works is:
It stops short of actually defining a consistent interface, instead leaves it at “text over a virtual system” which is wildly open to interpretation and also horribly inefficient for a huge class of problems
The abstraction over where (as in what host) a resource is stored on is really not what you want for serious distributed systems. You typically care deeply about predictable latency and consistent throughput which requires knowing precise information about what you’re talking to
Error handling is sorta just, shoved under the rug. It emphasizes human readability, which is quite frankly not what you want for a operating system interface
Plan 9 was never really meant for serious “production” usage. It didn’t even have support for any sort of authentication over the network until it’s last official release.
I don’t think Plan 9 does half of what Kubernetes does.
I am sure you’re right. Frankly I’d be astonished if it did anything near as much as that. The question is, though, does it do enough to do something, anything, useful in this space?
Plan 9 was never really meant for serious “production” usage.
It’s true, it wasn’t. But then neither was Linux. And Linux is a clone of Unix, and neither was Unix by its inventors.
The actual professionally-designed systems, implemented by experts to do complex jobs, are almost all long extinct now. A handful cling on in tiny niches: OpenVMS, a few mainframe OSes mostly running on emulated hardware, a few dozen exceptionally determined OpenGenera users, and so on.
We all use lashed-together stuff made from leftover junk, because it’s cheaper.
I am merely speculating if there are any easier, simpler bits of leftover junk that we could use instead.
Interesting. I tried Plan 9 (specifically, 9front) recently and was tempted to switch, but for the lack of a few key Unix apps like Firefox.
The main thing that springs to mind is how many Unix toolchains depend upon 3D acceleration that’s just not supported by Plan 9. I ran into a milder version of this with Electron apps on FreeBSD’s Linux compatibility layer.
I had a bit of a sad about it until I realised that - in principle - it’s okay. Sort of the FPU of 2023.
The issue isn’t so much 3D acceleration per se, but that the space is a wretched hive of scum and villainy; proprietary drivers and binary blobs abound.
Outside of the green company (and that’s in progress), pretty much all the GPUs are well supported by Mesa. For Intel and AMD, open drivers are the default and only (*) option on open operating systems.
(*) Almost: AMD still has some “Pro” driver package but idk anyone that uses it.
The issue isn’t so much 3D acceleration per se, but that the space is a wretched hive of scum and villainy; proprietary drivers and binary blobs abound.
Yes indeed. I’ve largely ignored that stuff for precisely this reason. And I’ve survived, career-wise, although it seems like a risky decision in hindsight. But the landscape of drivers and whatnot is an existential threat to FOSS, imho, and needs addressing somehow.
Does VNC have any conception of hardware 3D? It’s not even a native Unix tool originally; it was developed for the Olivetti VideoTile, an ATM-based smart display-cum-IO device which didn’t even speak TCP/IP.
I don’t think so. In theory, I guess you could teach applications to render to an off-screen buffer and hand that to the VNC server, but I don’t think anything does, at least not with Tigervnc. glxinfo reports that I’m using llvmpipe, which is software rendering.
tempted to switch, but for the lack of a few key Unix apps like Firefox.
That is exactly the sort of experience I was thinking about, yes. :-)
many Unix toolchains depend upon 3D acceleration
Good grief! Really? That’s one I didn’t expect.
Electron apps on FreeBSD’s Linux compatibility layer
Urgh. Not tried. I am dabbling in xBSD recently and some bits are lovely and some are just horribly arcane and give me bad flashbacks to SCO Xenix in the 1980s. Amazingly small, yes. Amazingly efficient, yes. Amazingly hard to use and to configure, though.
Me neither. It blocked me using Electron apps until the port landed.
Amazingly hard to use and to configure, though.
Matches my experience. I stuck with it though and use FreeBSD 13.2 as a daily driver. Check out https://git.sr.ht/~duncan-bayne/freebsd-setup but a great big “works on my machine” disclaimer applies :)
I have radically different needs, though. I am a writer, of English not code. I want a couple of rich web browsers, ideally with different engines behind them, some chat accounts, a good Markdown editor and a robust VM for testing OSes & distros in.
It should be perfectly doable, and yet, the road there looks very steep and rocky… :-/
Okay so you could do most or all of that with my setup as a starting point - largely depending upon whether you consider Emacs a “good Markdown editor” or a curse :)
I use VirtualBox myself for running Windows (9x, XP), Linux and FreeBSD VMs, including testing my own setup scripts against upcoming versions of FreeBSD. I use QEMU for running 9front.
A curse, I’m afraid. I mainly use Panwriter which I like so much I’ve written about it, to the apparently bafflement of many a geekier type in the comments.
Can VirtualBox run on FreeBSD? I found an attempted port from many years ago, but no update mentioned since FreeBSD 9.
With the caveat that I’m probably suffering from an extreme case of Stockholm Syndrome, given that I check my news feeds and manage my email in Emacs, Markdown editing in Emacs is pretty good these days, even has live preview.
I spend my days on a 2015 MacBook Pro and occasionally write light OpenGL or Metal code for visualizing things that are tough to visualize using existing software packages. When I run Instruments to try to figure out what I’m doing to make my code slow, more often than not Spotify shows up high in the list of processes that are causing GPU contention (via Electron).
The thing is, what makes plan 9 hang together is the removal of the special cases and API quirks that Linux apps expect in order to work.
So, agreed with this article: it’s easier to emulate the machine, rather than the large and growing syscall layer. Microsoft learned this with WSL, the same as plan 9 learned it with linuxemu.
The bulk of the code is there. Someone just needs to sit down and work on polishing the pieces.
The main difference I’d propose is just keeping the Linux around and providing a cmd(3) (http://man.9front.org/3/cmd) file server that you’d mount over 9p, using virtio-serial. Virtio-serial, in spite of the name, can function as a dumb pipe, so patching vmx to be able to post virtio-serial fds into /srv would allow easy integration.
I’d also suggest that the graphics side of things run on Linux, but output to a virtio-mounted devdraw instead of to a framebuffer. Mainly because that would minimize the diff against the compostior or X server.
But regardless, many of the hard bits exist at least to the point of a proof of concept, and the concept has been discussed regularly on #cat-v, as well as other places 9front developers congregate.
Someone just needs to find time to sit down and type.
I think I’d rather go the other way, implement a Plan 9-like userspace, virtual filesystem and all, on top of the Linux kernel. The interesting parts of Plan 9 are the userspace abstractions over the hardware, and the (mostly) interesting parts of Linux are the hardware and industry support. You can already run
blinkby jart on any POSIX compliant system (which Plan 9 is, with compatibility layers), so I’m not sure what you gain from microVMs here.That has been done, years ago.
It even has its own Wikipedia entry.
I am more interested in the potential for modernising and updating what was effectively UNIX 2.0 than in continuing a vast monolith that was obsolete in 1991, even if it’s really capable today.
I don’t see how the argument against monolithic kernels applies to Plan 9, which is also monolithic. plan9ports is sort of what I’m talking about, but instead of having it sit on top of Linux userspace APIs, I’d rather have it replace them.
I think the key word was “vast” rather than “monolith”. :-)
I mean, yes, it is, but a lot of the stuff that’s in-kernel on Linux, or in user space communicating by some fancy IPC mechanism on the HURD or L4 or whatever, is in user space communicating via the filesystem in Plan 9. AIUI, anyway.
Fair enough. Linux really sorely lacks a proper message-passing subsystem. I’m always in favor of more Plan 9, at least to toy with the concepts, but am simultaneously skeptical that it’s
designsimplementations are sound in modern distributed systems.That’s a good point, but OTOH, there’s only one way to find out. Well, OK, no, there isn’t, but OTOH it does seem to me that a lot of what Kubernetes does, for instance, is right there in the basic design of Plan 9.
In an ideal world I’d prefer the UI of Inferno, back-ported, but I suppose it’s written in Limbo and so that would be a significant undertaking.
One of the interesting efforts to modernise Plan 9 was Harvey, but that’s ended now.
OTOH what they’re working on instead also sounds interesting: https://github.com/r9os/r9
I don’t think Plan 9 does half of what Kubernetes does. Kubernetes handles things like graceful failover, replica sets, dynamic rebalancing, etc., which Plan 9 doesn’t really have robust support for, to my understanding at least.
To better articulate why I don’t think Plan 9 actually works is:
Plan 9 was never really meant for serious “production” usage. It didn’t even have support for any sort of authentication over the network until it’s last official release.
Those projects look cool!
Very interesting response… thank you!
I am sure you’re right. Frankly I’d be astonished if it did anything near as much as that. The question is, though, does it do enough to do something, anything, useful in this space?
It’s true, it wasn’t. But then neither was Linux. And Linux is a clone of Unix, and neither was Unix by its inventors.
The actual professionally-designed systems, implemented by experts to do complex jobs, are almost all long extinct now. A handful cling on in tiny niches: OpenVMS, a few mainframe OSes mostly running on emulated hardware, a few dozen exceptionally determined OpenGenera users, and so on.
We all use lashed-together stuff made from leftover junk, because it’s cheaper.
I am merely speculating if there are any easier, simpler bits of leftover junk that we could use instead.
What doesn’t dbus satisfy in regards to message-passing? I thought it was the go-to Linux messaging subsystem.
Interesting. I tried Plan 9 (specifically, 9front) recently and was tempted to switch, but for the lack of a few key Unix apps like Firefox.
The main thing that springs to mind is how many Unix toolchains depend upon 3D acceleration that’s just not supported by Plan 9. I ran into a milder version of this with Electron apps on FreeBSD’s Linux compatibility layer.
Maybe a passthrough approach would work here.
That’s a really interesting - and to me chilling - observation.
I had a bit of a sad about it until I realised that - in principle - it’s okay. Sort of the FPU of 2023.
The issue isn’t so much 3D acceleration per se, but that the space is a wretched hive of scum and villainy; proprietary drivers and binary blobs abound.
Outside of the green company (and that’s in progress), pretty much all the GPUs are well supported by Mesa. For Intel and AMD, open drivers are the default and only (*) option on open operating systems.
(*) Almost: AMD still has some “Pro” driver package but idk anyone that uses it.
Yes indeed. I’ve largely ignored that stuff for precisely this reason. And I’ve survived, career-wise, although it seems like a risky decision in hindsight. But the landscape of drivers and whatnot is an existential threat to FOSS, imho, and needs addressing somehow.
I find that slightly surprising, given that I tend to use vnc fairly heavy, and haven’t noticed a problem.
Does VNC have any conception of hardware 3D? It’s not even a native Unix tool originally; it was developed for the Olivetti VideoTile, an ATM-based smart display-cum-IO device which didn’t even speak TCP/IP.
https://marrow.cam-orl.co.uk/tile.html
I don’t think so. In theory, I guess you could teach applications to render to an off-screen buffer and hand that to the VNC server, but I don’t think anything does, at least not with Tigervnc.
glxinforeports that I’m using llvmpipe, which is software rendering.That is exactly the sort of experience I was thinking about, yes. :-)
Good grief! Really? That’s one I didn’t expect.
Urgh. Not tried. I am dabbling in xBSD recently and some bits are lovely and some are just horribly arcane and give me bad flashbacks to SCO Xenix in the 1980s. Amazingly small, yes. Amazingly efficient, yes. Amazingly hard to use and to configure, though.
Me neither. It blocked me using Electron apps until the port landed.
Matches my experience. I stuck with it though and use FreeBSD 13.2 as a daily driver. Check out https://git.sr.ht/~duncan-bayne/freebsd-setup but a great big “works on my machine” disclaimer applies :)
Interesting. Thanks for that.
I have radically different needs, though. I am a writer, of English not code. I want a couple of rich web browsers, ideally with different engines behind them, some chat accounts, a good Markdown editor and a robust VM for testing OSes & distros in.
It should be perfectly doable, and yet, the road there looks very steep and rocky… :-/
Okay so you could do most or all of that with my setup as a starting point - largely depending upon whether you consider Emacs a “good Markdown editor” or a curse :)
I use VirtualBox myself for running Windows (9x, XP), Linux and FreeBSD VMs, including testing my own setup scripts against upcoming versions of FreeBSD. I use QEMU for running 9front.
A curse, I’m afraid. I mainly use Panwriter which I like so much I’ve written about it, to the apparently bafflement of many a geekier type in the comments.
Can VirtualBox run on FreeBSD? I found an attempted port from many years ago, but no update mentioned since FreeBSD 9.
Yep :)
https://i.postimg.cc/3rzjmbKq/virtualbox-freebsd.png
With the caveat that I’m probably suffering from an extreme case of Stockholm Syndrome, given that I check my news feeds and manage my email in Emacs, Markdown editing in Emacs is pretty good these days, even has live preview.
Very interesting. Thanks for that! I must try this.
I spend my days on a 2015 MacBook Pro and occasionally write light OpenGL or Metal code for visualizing things that are tough to visualize using existing software packages. When I run Instruments to try to figure out what I’m doing to make my code slow, more often than not Spotify shows up high in the list of processes that are causing GPU contention (via Electron).
Full Linux emulation has been tried. https://9p.io/wiki/plan9/Linux_emulation/index.html
The thing is, what makes plan 9 hang together is the removal of the special cases and API quirks that Linux apps expect in order to work.
So, agreed with this article: it’s easier to emulate the machine, rather than the large and growing syscall layer. Microsoft learned this with WSL, the same as plan 9 learned it with linuxemu.
The bulk of the code is there. Someone just needs to sit down and work on polishing the pieces.
Um. This was my core argument, about microVMs. You did read that bit, right?
The main difference I’d propose is just keeping the Linux around and providing a cmd(3) (http://man.9front.org/3/cmd) file server that you’d mount over 9p, using virtio-serial. Virtio-serial, in spite of the name, can function as a dumb pipe, so patching vmx to be able to post virtio-serial fds into /srv would allow easy integration.
I’d also suggest that the graphics side of things run on Linux, but output to a virtio-mounted devdraw instead of to a framebuffer. Mainly because that would minimize the diff against the compostior or X server.
But regardless, many of the hard bits exist at least to the point of a proof of concept, and the concept has been discussed regularly on #cat-v, as well as other places 9front developers congregate.
Someone just needs to find time to sit down and type.
Typing is somewhere on my todo list.
Oh, OK, cool. Thank you. :-)
https://news.ycombinator.com/item?id=28771886
You’re saying that the comments there apply to my idea?
Sheesh… harsh… :-(