Anyone else think the idea of microkernels sounds more compliant with the Unix philosophy? The whole "Do one thing...

Anyone else think the idea of microkernels sounds more compliant with the Unix philosophy? The whole "Do one thing, and do it well"?
I mean with a monolithic one, all of the kernel-type stuff is in one big process that does all of it, whereas with a microkernel, it gets split up into separate servers that each handle one type of component.
I'm not the only one who sees this am I?

No Mr Stallman. I'm sure Hurd will be great.

I don't know how you can argue for two conflicting concepts at once.
Either you want to do one thing well, or do everything.
Anyway, the biggest inefficiencies are swapping between modes/contexts. Washing and putting away the spoon when you want to use the fork.

I wasn't talking about HURD though. I'm talking about the concept in general.
Do you know how to read?

One thing actually works as demonstrated daily by billions of devices in all sizes and form factors on and above earth.

The other is hot (academic) garbage like L4 and HURD.

They do follow the UNIX philosophy more closely. The main problem is that there’s not much of a practical benefit.
Everything gets pulled out into seperate “servers” and all that happens is it gets slower but more resilient. Most users don’t benefit from that directly because user facing software is still unstable.

The problem with microkernels is that they don't allow processes to directly contact each other, which decreases performance as they first have to go through the IPC. This is especially a problem with things like device drivers where as little latency as possible is key.

There is no practical loss of flexibility in monolithic kernels. If you need less or more in your kernel you simply compile or obtain a new kernel with less or more modules in it and install it. Just because it's monolithic doesn't mean it's not flexible at all; it's just no flexible while the system is still in a state we call running.

One of the only real advantages microkernels have is you can easily make them as large or as small as you want on the fly. The problem is almost no one requires an OS that can do that because hardware tends to be pretty static and the performance hit isn't negligible.

In essence we basically do this with cloud computing, though at a higher level with hypervisors and such. Maybe one day we will see a need to break down into even lower levels and require a faster, always up, and flexible system that can perform quickly and adapt as needed but that day is not today.

the minix microkernel is in every single Intel CPU

>monolithic kernels have success and microkernels don't
>not much practical benefit, resilient, but way slower
>maybe one day we'll see a need, but not today
Well we'll have to see how some recent developments such as Fuchsia and Redox work out. It seems like this idea could become more feasible in the near future.

Microkernels are not inherently slower if they are designed properly.

>The L4 11 μ-kernel was implemented at the TU Dresden by
the Systems Architecture Group in cooperation with the
IBM Watson research center. It belongs to the second-
generation of μ-kernels. It prooved together with the QNX
neutrino kernel, that μ-kernels cn be as fast as their mono-
lithic counterparts allowing easy extensibility.

From Monolithic Kernel vs Microkernel by Benjamin Roch

>Anyone else think the idea of microkernels sounds more compliant with the Unix philosophy?
Only if you don't know how Unix and software works.

Software modularity is more than just process boundaries.

>which decreases performance as they first have to go through the IPC

Not true post the first gen of microkernels.

>There is no practical loss of flexibility in monolithic kernels

Not true as you cannot change things "on the fly". There is an inherent lack of flexibility with the concept of compiling or recompiling or replacing the entire kernel. Having one thing that can be added on to to do it all is more flexible than making 20 different things for each use case. Modules of course were very helpful in expanding the flexibility of mono kernels.

>One of the only real advantages microkernels have is you can easily make them as large or as small as you want on the fly.

This is a huge advantage when it comes to security and stability. If you have a component of the kernel which is not in user space fail it takes down the whole kernel, as opposed to a microkernel where you could just disable that part and repair it. Consider a brain injury: if your frontal lobe is damaged, your brain doesn't fail as a whole, and you can live without it (Take the classic case study Phineas Gage as an example of this). That's a massive benefit.

And I'll agree it isn't essential today that we use microkernels but it would be a massive benefit to OS programming at large if we made the switch.

>it would be a massive benefit to OS programming at large if we made the switch.
Well if the projects in go somewhere, that might actually happen.

I know, I'm very excited about Redox. Particularly because it (made, I haven't looked at it in about 5 or 6 months) a huge amount of progress in a relatively short period of time.

Reminder that Linux Is Not UniX

I tried it out in a VM recently. It's definitely rough, but for something so new, this is an impressive amount of progress. They even have some kinda GNOME-lookin desktop interface.

more process context change = shit performance

Sure sounds like a good idea and maybe one day we will have a better kernel but for now linux is ahead of everything else.

>Anyone else think the idea of microkernels sounds more compliant with the Unix philosophy?
Not really. The unix philosophy is about separable components, not processes; processes are a convenient abstraction point, but by no means always the most convenient unit of "separate component". You can have very unix-y components that are kernel modules, rather than processes.

>I mean with a monolithic one, all of the kernel-type stuff is in one big process that does all of it
Not sure whether this is nitpicking or a genuine misunderstanding, but the kernel is not a process.

There are advantages and disadvantages about microkernels, but I don't think it has any real bearing on the unix philosophy.

The problem is that the little blobs will spend more time formatting messages than doing work.

of course, but it's a unix-like

true microkernels have never been tried

You still have to undergo inter-process communication. Explain how this would otherwise be achievable when all your drivers are running in userspace. Just because now microkernels are much faster (~10% slower than Linux in file server call speed), does not guarantee that the worst case or even general performance will be acceptable in mainstream use. Additionally, to my knowledge Redox and seL4 are single server so the security advantage of the microkernel is severely diminished and would virtually result in the same code size when loaded.

>There is an inherent lack of flexibility with the concept of compiling or recompiling or replacing the entire kernel.
Modules, DKMS. You have to recompile processes and servers as well. They aren't even particularly small when each process is accumulated.

>If you have a component of the kernel which is not in user space fail it takes down the whole kernel
This is something great about a microkernel, but the first objective should be to write code that doesn't crash, or have undefined behavior in the first place. Granted kernels are extremely complex, but one of the deficiencies of Linux is in particular the grueling amount of poor documentation on antiquated code, and that's what I think next-gen operating systems should target first, without necessarily falling back to a microkernel, though with a modular kernel it is much easier to document it (see seL4).

I've been seeing a lot of microkernel shilling on here lately.

Is this some attempt by googleshills to push Fuchsia?

No but exokernel is

You probably use L4 daily, it's the kernel for a lot of baseband processors.

I dunno about the rest, but for me it's more a general autistic interest in the success of a microkernel unix or unix-like OS.
As for fuchsia shilling, the only reason I consider that is because aside from redox, there doesn't appear to be a microkernel OS project that is actually going anywhere. Ideally, I wish GNU HURD was more successful/developed, but that doesn't exactly look like it's gonna happen anytime soon.

>microkernel
Please no. We don't need another Node.js on our hand.

Modules, yes. Microkernels, no.

What the fuck does microkernel have to do with Node? Isn't that a Javascript thing?

Maybe microkernel has a different meaning to webdevs, but this is about an operating system Kernel. Think the Microsoft NT kernel, the Linux Kernel, the BSD kernel, etc.

*BSD kernels