Hacker News Reader

Comment by happymellon | Hacker News Reader

Yes, but something like this should be moved to FUSE.

The tests would certainly help that migration.

Maybe one of these days all filesystems will be moved to FUSE, and Linux will have evolved from a monolithic kernel into a microkernel

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

Ironically with cloud workloads it already kind of is, specially when it doesn't run bare metal, and has a type 1 hypervisor underneath it.

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.

>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.

With docker?

> docker?

> 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).

So playing microkernels anyway, with worse performance due to the extra monolithic layers.

How are namespaces similar to microkernels? I see them a lot more as glorified chroot; it's not like there's a modprobe namespace or anything.

Namespaces are a tiny part of what means a complete container infrastructure, across all OS layers.

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

Containers on Linux don't have slower APIs or IPC, and don't have heavier context switches. Are you sure you're not thinking about VMs?

How do containers communicate with each other?

Sockets, shared memory, or the network, just like any Linux process.

Shared memory across containers, across isolation layers, that is a good one.

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

It's explicit, just like all the other mapping/mounting options[1], and containers aren't exclusively for secure isolation anyway. Many examples exist where security isn't desirable, such as the afformentioned toolbox/distrobox.

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

Hypervisors and microkernels are meaningfully different, both in terms of history and technology: Microkernels implement one OS by running different userspace components on a minimal kernel, whereas hypervisors run multiple OSes, each with their own kernel, on a minimal hardware multiplexer which ideally provides no abstractions, as opposed to a kernel, which provides many abstractions. Conflating them is both historically wrong and confusing.

"An operating system is a collection of things that don't fit into a language. There shouldn't be one." – Dan Ingalls

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

> 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.

What do you call seL4?

> Ironically with cloud workloads it already kind of is, specially when it doesn't run bare metal, and has a type 1 hypervisor underneath it.

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.

FUSE works well enough for Gluster to benefit from RDMA over TCP, it's already pretty good imo

Not as cheap but that's the price of interfaces

Well yes and no, SystemV FS support isn't there for performance.

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

Reply on news.ycombinator.com