The tests would certainly help that migration.

Yes, yes, FUSE performance is nothing to write home about – but some people seem to think that io_uring might solve that. L4 is evidence that, in principle, the right microkernel design can perform about as well as monolithic kernels can

Or for container based distributions where it is basically there to provide the minimal set of services to run containers, and any other kernel would do, it is only a matter of convenience to ping back on the Linux kernel.

The monolithic kernel folks just haven't noticed it.

I know may be by sheer number of users most people use them in the cloud or for development but some of us do actually use linux on our everyday machines.

> GP: development

Probably yes?

Even foregoing development scenarios, containers can be used for everyday Linux tasks with things like toolbox/distrobox (which do support GUIs).

Then there is the whole IPC taking place across containers with much slower APIs and heavier context switch states.

The two remaining ones are worse than any micro-kernel API call in performace.

[1]: https://docs.docker.com/engine/reference/run/#ipc-settings--...

That is the beauty of hypervisors, just enough abstraction for a portable language runtime.

Right. Which means they're not microkernels. Which is my point.

AWS overwhelmingly uses Linux/KVM, not any type 1 hypervisor. There's a few leftover Xen systems, but those are legacy; you get KVM if you provision a new instance.

Not as cheap but that's the price of interfaces

Old and generally unused filesystems shouldn't be living untested in the kernel.

If we just create the filesystem using the Linux driver, and validate it using the same driver, then what is achieved exactly? For preservation we'd still need access to Xenix systems and a drive of some sort that can be moved between the old system and a more modern computer.

I suppose disk images could be used, but that still seems like only a partial solution.

besides any philosophical argument, doesn't it still crap up your whole system whenever the network flakes out? (unlike, i imagine, any FUSE driver)

What exactly do you want the client to do, when it relies on remote resources and the network isn't reliable? This fortunately is these days much less a problem than in the days of cheapernet (10BASE2).

FUSE drivers aren't exempt from hanging syscalls, I've experienced them even with local mounts let alone network ones. I don't know why people keep repeating this.

FTP and NFS are good, I'd also want ckermit / tip / tar in my toolbag...

Probably not an issue these decades, though.

A fuse implementation would be good enough today though. You're not doing actual production work on htfs today no matter how special the circumstances.

...and did anyone ever automate parsing the divvy partition table?

I confess I have never productively used either but have destructively used fsck.

Someone is, apparently. Some shop called Xinuos apparently bought part of the corpse (the not lawsuit obsessed, not fraud committing part, presumably) and is still selling SCO OpenServer and Unixware. That's some serious dead-ender computing. But hey...people still run OS/2 in production.

Divvy...haven't thought about that in not long enough.

In the (far) future, just use a past distro to see them. Removal now wipes functionality from the market very, very slowly.

xiafs sounded intriguing, but I never actually used it.

Of all the filesystems currently in the mainline Linux kernel, the most useless (surely) must be BFS (not BeFS) – https://www.kernel.org/doc/html/next/filesystems/bfs.html

The file system used isn't accessible, so issues aren't directly applicable.

https://man7.org/linux/man-pages/man7/sysvipc.7.html

Unix has a bigger range of IPC mechanisms than i think most people realise. Everyone knows about internet sockets and pipes. Most people know about shared memory, named pipes, and unix domain stream sockets. But how many people know about unix domain datagram sockets, or POSIX message queues?

One might say that the whole of POSIX IPC is simply SysV IPC with sane and "unix-like" API (ie. names instead of "IPC keys").

One of the problems with POSIX IPC is that you cannot really use it if you want to be portable, because on BSD and derived systems the implementation is best described as also existing only for completeness.

https://www.autometer.de/unix4fun/coherent/

A python wrapper for simple formats like this around a block interface (fuse mount, etc...) is a few afternoons of work for someone. I bet anything someone's already written this.

[1]: https://www.phoronix.com/news/Linux-Floppy-2021-Regression

That's a lot of work for something pretty much nobody uses. And in the end the SysV FS support might not even work anymore because of oversights during the API updates.

"can't even properly test it anymore" almost certainly means not that it is impossible for the maintainer, but more like they have better things to spend their time on.

Well... Then, if it builds, it can at least be tested with the same tools that test every other filesystem.

I could buy "It's a waste of time, nobody's using the code, we are pruning legacy code for the Rust rewrite, etc." But not that it's impossible to test. That doesn't seem truthful.