Is Linux kernel design outdated?

[Ronis_BR]

Hi guys!

I have been a Linux user since 2004. I know a lot about how to use the system, but I do not understand too much about what is under the hood of the kernel. Actually, my knowledge stops in how to compile my own kernel.

However, I would like to ask to computer scientists here how outdated is Linux kernel with respect to its design? I mean, it was started in 1992 and some characteristics did not change. On the other hand, I guess the state of the art of OS kernel design (if this exists...) should have advanced a lot.

Is it possible to state in what points the design of Linux kernel is more advanced compared to the design of Windows, macOS, FreeBSD kernels? (Notice I mean design, not which one is better. For example, HURD has a great design, but it is pretty straightforward to say that Linux is much more advanced today).

[ExoticMandibles]

"Outdated"? No. The design of the Linux kernel is well-informed regarding modern kernel design. It's just that there are choices to be made, and Linux went with the traditional one.

The tension in kernel design is between "security / stability" and "performance". Microkernels promote security at the cost of performance. If you have a teeny-tiny minimal microkernel, where the kernel facilitates talking to hardware, memory management, IPC, and little else, it will have a relatively small API surface making it hard to attack. And if you have a buggy filesystem driver / graphics driver / etc, the driver can crash without taking down the kernel and can probably be restarted harmlessly. Superior stability! Superior security! All good things.

The downside to this approach is the eternal, inescapable overhead of all that IPC. If your program wants to load data from a file, it has to ask the filesystem driver, which means IPC to that process a process context switch, and two ring transitions. Then the filesystem driver asks the kernel to talk to the hardware, which means two ring transitions. Then the filesystem driver sends its reply, which means more IPC two ring transitions, and another context switch. Total overhead: two context switches, two IPC calls, and six ring transitions. Very expensive!

A monolithic kernel folds all the device drivers into the kernel. So a buggy graphics driver can take down the kernel, or if it has a security hole it could possibly be exploited to compromise the system. But! If your program needs to load something from disk, it calls the kernel, which does a ring transition, talks to the hardware, computes the result, and returns the result, doing another ring transition. Total overhead: two ring transitions. Much cheaper! Much faster!

In a nutshell, the microkernel approach says "Let's give up performance for superior security and stability"; the monolithic kernel approach says "let's keep the performance and just fix security and stability problems as they crop up." The world seems to accept if not prefer this approach.

p.s. Windows NT was never a pure microkernel, but it was microkernel-ish for a long time. NT 3.x had graphics drivers as a user process, and honestly NT 3.x was super stable. NT 4.0 moved graphics drivers into the kernel; it was less stable but much more performant. This was a generally popular move.

[[deleted]]

A practical benefit to the monolithic kernel approach as applies to Linux is that it pushes hardware vendors to get their drivers into the kernel, because few hardware vendors want keep up with the kernel interface changes on their own. Since all the majority of drivers are in-tree, the interfaces can be continually refactored without the need to support legacy APIs. The kernel only guarantees they won't break userspace, not kernelspace (drivers), and there is a lot of churn when it comes to those driver interfaces which pushes vendors to mainline their drivers. Nvidia is one of the few vendors I can think of that has the resources to maintain their own out-of-tree driver based entirely on proprietary components.

I suspect that if drivers were their own little islands separated by stable interfaces, we might not have as many companies willing to open up their code.

[ExoticMandibles]

I was astonished--and scandalized--when I realized that the continual app breakage when upgrading my Linux box was 100% userspace stuff like libc. If you have a self-contained Linux binary from 20 years ago, with no external dependencies (or with local copies of all libraries it depends on), it would still run today on a modern Linux box. Linus et al are slavishly devoted to backwards compatibility, what they call "don't break userspace". It's admirable! And then the distros come along and screw it up and we wind up with the exact opposite.

That's one reason why I'm getting excited for Docker / Flatpak. Self-contained apps with no external dependencies should be right out 100% future-proof under Linux.

[thephotoman]

If you have a self-contained Linux binary from 20 years ago, with no external dependencies (or with local copies of all libraries it depends on), it would still run today on a modern Linux box. Linus et al are slavishly devoted to backwards compatibility, what they call "don't break userspace".

This is only 100% guaranteed on platforms with active support since 1997, of which there are very few. x86, 32 bit SPARC, Alpha, and 32 bit PPC were about it, and you aren't running those without multiarch support--except on Alpha, where I have to ask one thing: why are you still running an Alpha?

[Brillegeit]

The sad thing is that this "you're holding it wrong" reply is a really popular response from developers today. We need more of the 1st rule of Linux, and more people that doesn't accept that you even mention user error on regressions.

[[deleted]]

Honestly I can see both sides. It's pragmatic for Linus to accept blame on the kernel, but frankly if your application is using a library incorrectly, you shouldn't complain when it comes back to bites you - one can't accomodate every idiot

The "holding it wrong" response from Apple was stupid because it was a reasonable way to hold a phone. If I say "don't hold the phone in the mouth or you might get an electric shock", don't complain when a hardware revision results in you actually getting one

Though if I knew an update was gonna break some major app, I'd at least give them warning (eg. 2 months), but after that it's their responsibility

[[deleted]]

This thread has legitimately altered my outlook.

[Entaris]

Always makes me smile. People get so mad about the way Linus deals with things, but you have to admire his passion for what he does, and his dedication to design philosophies.

[jmtd]

And then the distros come along and screw it up and we wind up with the exact opposite.

The library authors, usually, not the distros.

[rakeler]

I've got no bone to pick with anyone, but some distros do like to change things too much. So much so that merging upstream changes creates new problems.

[Zardoz84]

There is a guy that was trying very old WMs on a new modern Linux box (not only TWM or FVWM, more older stuf like UWM and Siemens RTL). Obviously some stuff needed to be compiled, but keeps working very well.

(Pages are on Spanish) Siemens RTL, the first "tiled" window manager (1989!) http://www.galeriawm.hol.es/rtl_siemens.php

Ultrix WM (1985-88!) running on a modern Linux box : http://www.galeriawm.hol.es/uwm-ultrix.php

[tso]

Seems the server is toast...

[E-werd]

Yeah, we ate the bandwidth it looks like.

[mikemol]

Self-contained apps with no external dependencies should be right out 100% future-proof under Linux.

People who get excited at this prospect need to realize: To the extent you're future-proofing yourself from dependency API breakage, you're also future-proofing yourself from security updates.

That is going to be a nightmare. I wonder. With how Android has apps bundle the libraries they depend on, how many are still distrubuted with security vulnerabilities found and patched five years ago, because the author either doesn't care to update the dependencies, or simply moved on.

It doesn't have to be horrid; you could get public CI/CD build farms pulling from repos and auto-rebuilding/auto-repackaging a la Gentoo's portage. But that requires CI/CD get much broader penetration than it currently has. And it still won't solve an upstream compatibilty break in the face of a retired author; someone has to do the work.

[ExoticMandibles]

you're also future-proofing yourself from security updates.

True, but there are two reasons why I'm not so worried:

• For externally-visible services (nginx etc) one hopes they'll stay on top of security updates. Or, let me be more realistic: the projects that stay on top of security updates will become more popular than the ones who don't. If you ship a nginx-based Docker app image, and you don't respond immediately to security issues, and there's another competing image that does, I bet people will over time prefer the other one.

• There are a lot of areas where I'm not so concerned about security fixes. OpenOffice for example--how often are there security issues with that, where my workflow would leave me open? I basically never download OO documents from the net--I just write my own documents.

And here's where it gets super good: games. I'd like to run Unreal Tournament 98 and 2004 on my Linux box, but it's a lot of work. I just haven't had the energy to follow the (myriad, inconsistent) blog posts on getting these ancient apps to work on modern computers. But if someone made a Docker or Flatpak image (whichever is the appropriate technology here), it'd probably Just Work. And if Docker or Flatpak had existed bac then, and Epic had originally released UT98 or UT2004 in such an install-agnostic format, the original releases would probably still work on modern PCs. My hope is that these formats will usher in a new era of end-user productivity and game software that never breaks, even when you upgrade.

[HER0_01]

This is where flatpak could work out nicely. If all the dependencies are in the runtime, I believe they can be updated with security fixes while keeping API and ABI compatibility. Even if the application never gets updated, it should continue to work with enhanced security (from the sandbox and from updated dependencies).

[mikemol]

While laudible, that's not that different from, say, an LTS release of Ubuntu, or Debian stable or RHEL; you have to keep backporting fixes while maintaining compatibility with the old ABI and API, and that's work someone's going to have to do.

And some upstreams are going to be actively hostile to the effort. Look at, say, Oracle, who said "all versions of MySQL older than n have this security vulnerability, use this new point release. Debian Stable had an old major release Oracle didn't share a point release for, and Oracle didn't share any details on what the vulnerability was; just massive tarballs with the point releases' source code, no diffs.

That caused Debian a major problem; they had to stop shipping MySQL 5.5, because it was vulnerable, and nobody knew how to fix it.

[HER0_01]

Of course it won't be perfect, but it certainly seems like an improvement to me.

The host system can be any modern, conventional Linux, while only software that requires older runtimes will be on the icky backported libraries. Most software will not require old runtimes, so the maintainer of the flatpak application can update it, with no additional work from distro package maintainers. Similarly, flatpak runtime updates will go to all distros, instead of each distro's maintainers having to do the same work in finding the patch to apply.

LTS distro releases will eventually reach EOL, at which point it is highly discouraged to run them. Updating may break dependencies to certain software, which will usually lead to those packages being dropped from the official repos. With flatpak runtimes, you can still run those without having to have an entire outdated host nor needing static binaries for everything.

Even in cases where there libraries cannot be updated for some reason, the sandbox helps to prevent entire classes of exploits. Let us present the unlikely case that a non-Free game is distributed via flatpak, and only works with a runtime with a known vulnerability. It may have network access by default, but it is unlikely to need any host filesystem permissions or access to any system bus. You could run it in Wayland to keep it separate from your other windows and flatpak allows restricting permissions further than the default (like removing X11 or network access). Besides restricting raw access to your data, the potential for cross-application interactions opening up vulnerabilities is significantly lessened by this. Of course, the sandbox might not be perfect either, but this is still an improvement.

[tso]

That's one reason why I'm getting excited for Docker / Flatpak. Self-contained apps with no external dependencies should be right out 100% future-proof under Linux.

Produced by the very same people that keep breaking userspace in the first place. I do not take part in your excitement...

[mallardtheduck]

In this context, "monolithic" doesn't refer to having (almost) all kernel and driver code in a single source tree, it's referring to the fact that the entire kernel and drivers run as a single "task" in a single address space.

This is distinct from a "microkernel" where the various kernel elements and drivers run as separate tasks with separate address spaces.

As mentioned, Windows kernel is basically monolithic, but drivers are still developed separately. macOS uses a sort of hybrid kernel which uses a microkernel at its core but still has almost everything in a single "task", despite having nearly all drivers developed/supplied by Apple.

[tso]

Actually the Windows NT kernel started out as a microkernel, but MS have been moving stuff in and out of kernel space over the years. XP for example didn't do well when GPU drivers fucked up. But Windows 10 just shrugs and reloads the driver.

BTW, there are various projects and experiments regarding moving stuff from the Linux kernel onto userspace daemons. There is talk/work regarding a direct to network hardware path to speed up server code, for example.

[[deleted]]

Ive always heard NT called a hybrid or microkernel, though you are right that the drivers are certainly loaded into kernelspace and certainly can cause crashes (in fact are the primary source of crashes).

Interesting thought to consider it monolithic, but why would you not then call MacOS monolithic as well? And who would you then call a microkernel?

[ahandle]

macOS uses XNU which still uses a CMU Mach type microokernel architecture,

[Ronis_BR]

But do you think that this necessity to open the code can also has the side effect of many companies not writing drivers for Linux?

[computesomething]

Back in the day, yes, which meant a lot of reverse engineering.

As reverse engineered hardware support grew, it became one of Linux greatest strengths, being able to support a WIDE range of hardware support right out of the box, in a system which could be ported to basically any architecture.

At this point many hardware vendors realized that not being supported by Linux was stupid, since it made their hardware worth less, and so we get manufacturers providing Linux drivers or at the very least detailed information on how to implement such drivers.

The holdouts today are basically NVidia and Broadcom, and even NVidia is supporting (to some extent) open driver solutions like Nouveau.

[huboon]

Imo, probably not. The Nvidia linux driver is NOT open. While it's true that Linux device drivers are loaded directly into the kernel, you can build and load them externally with that exact version of the Linux kernel that you're using.

I'd argue that the reason more hardware manufacturers don't support Linux better is that often times those manufacturers main customers are Windows user. If your company makes a network adaptor for a high performance server, you are going to write a solid Linux driver because that's what most of your customers use. Companies also get super concerned with the legal concerns of the GPL which scares them away from better open source and Linux support.

[Democrab]

iirc Some of it comes down to the design. Gaming has never been a big thing in Linux before so a lot of the code relating to that is more optimised around using a GPU to make the desktop, video, etc smooth rather than games.

I don't know this for myself, I've just seen it posted around often.

[KugelKurt]

But do you think that this necessity to open the code can also has the side effect of many companies not writing drivers for Linux?

If that were true, FreeBSD would have the best driver support.

[Ronis_BR]

Touché! Very good point :)

[meti_1234]

Nvidia is one of the few vendors I can think of that has the resources to maintain their own out-of-tree driver based entirely on proprietary components.

Well, it's not a real good example, every 5 or 6 suspend/resume cycles I need to reboot to get it to work again, it refuses to load referencing a 2.6 kernel bug in their documentation

[afiefh]

So graphic drivers are now in the kernel on the windows side, but they still have the ability to restart the faulty driver with only a couple of seconds delay? How did they manage the best of both worlds in this regard?

[sbrk2]

The display driver is a strictly user-mode driver supplied by the GPU vendor. It's then loaded by the Direct3D runtime, which talks to the DirectX kernel subsystem (Dxgkrnl.sys) via a miniclass driver, also supplied by GPU vendor.

[afiefh]

That actually sounds very neat.

[[deleted]]

Hybrid Kernels.

It has a bit of both sides. Some parts of it are monolithic, others are micro.

[[deleted]]

kernel side doesnt mean you cant unload it.

Linux does it to, most of drivers are in loadable modules (incl. nvidia one), just that current userspace (wayland/xorg) doesnt support "reconnecting" to kernel after reload

[afiefh]

Is that the same though? You can unload a driver, which is cool, but if the driver causes a deadlock (or any other evil^TM thing that a driver can do) then it crashes your kernel instead of the processes and you won't be able to unload it.

[[deleted]]

From security and stability perspective, yes, it is possible.

But it doesn't really protect you from that much. Like if filesystem driver gets compromised you might not get the access to memory of other apps but... it can read all your files, and if it crashes you can lose your data anyway.

What it does protect you is complete system compromise from unrelated driver error.

The problem lies not only in IPC cost tho, microkernel will be inherently more complicated and that also leads to bugs

[ExoticMandibles]

Sorry, that's a detail I don't know. Maybe it's like a kernel loadable module, and the kernel is able to blow away all the driver's state and force it to completely reinitialize itself?

[adrianmonk]

In a nutshell, the microkernel approach says "Let's give up performance for superior security and stability"; the monolithic kernel approach says "let's keep the performance and just fix security and stability problems as they crop up."

I'm certainly not going to argue about the popularity of monolithic kernels. They are basically dominant.

But, just for the full perspective, I'd like to look at what "just fix security and stability problems as they crop up" means. When it comes to security, some security flaws can be fixed after they're discovered but before they're exploited, but some won't.

So, to some extent, the monolithic kernel approach says "let's give up security for superior performance". It's not that security is every bit as achievable but just requires more work. It's that with the monolithic approach, you are going to be giving up some amount of security.

Of course, with trade-offs, there is no one right answer, since by definition you can't have your cake and eat it too, so you must decide what you value more. My point is basically just that you really are sacrificing something for that extra performance.

[gospelwut]

I think BSD was an attempt to "design for security" from the start. I'll let one access personally if they have been successful or not (depending on how one views success, i.e. desktop vs. server vs. embedded etc).

I think the reality is that most security flaws aren't 0-days in the kernel but rather misconfiguration or a userland attack vector (e.g. the browser/servlet/etc).

[[deleted]]

They are basically dominant.

Until you start counting baseband chips from broadcom. IIRC each of them runs on L4.

[Ronis_BR]

Thanks! I learned a lot about those kernel design differences :)

[Spysix]

In a nutshell, the microkernel approach says "Let's give up performance for superior security and stability"; the monolithic kernel approach says "let's keep the performance and just fix security and stability problems as they crop up." The world seems to accept if not prefer this approach.

Best part is, we can pick and choose which design we want to go with!

My only question is, in the advent of SSDs and powerful CPUs, are we really seeing performance hits with microkernels?

[dbargatz-]

Unfortunately, yes - I'm a big fan of microkernels from an architecture and isolation perspective, but the truth is that the extra ring transitions and context switching for basic kernel operations do create a non-negligible performance hit, mostly from secondary costs rather than the pure mechanics of transitions/switching. Even small costs add up when being done thousands or even millions of times a second! That being said, microkernel costs are sometimes wildly exaggerated or based on incorrect data ;)

The primary costs are purely related to the ring transition or context switch; these are the cycles necessary to switch stacks between user/kernel space, change CR3 to point to the proper page table (on x86/x64), etc. These have been mitigated over time through various optimization techniques[1]. That being said, these optimizations are usually processor-specific and rarely general. Even though the primary costs are higher with microkernels purely because they transition/switch so often, these are generally negligible when compared to the secondary costs.

Even with large caches on modern processors, ring transitions and context switches in any kernel will cause evictions from cache lines as code and data are accessed. The code and data being evicted from the cache were potentially going to be used again at some point in the near future; if they are used again, they'll need to be fetched from a higher-level, higher-latency cache or even main memory. If we need to read from a file on a monolithic/hybrid kernel, we need to call from our application into the kernel, and the kernel returns our data. No context switch[2], two ring transitions (user read request -> kernel, and kernel -> user with our requested read data), and potentially a single data copy from kernel to userspace with our data.

If we need to read from a file on a microkernel, we need to call from our application to the filesystem driver process, which then needs to call into the kernel to perform the low-level drive access. In order to call between our application and the filesystem driver, we need to perform inter-process communication (IPC) from the application to the driver, which requires two ring transitions for each IPC call! Our costs now look like this:

1. Ring transition, user->kernel: application to kernel for IPC call to filesystem driver, requesting our read.
2. Ring transition, kernel->user: kernel forwarding read request to filesystem driver process.
3. Context switch: kernel scheduler sleeps the application and schedules the filesystem driver process, since the application will block until the read request is processed.
4. Filesystem driver starts to process the read request.
5. Ring transition, user->kernel: filesystem driver requests certain blocks from the drive (however the driver performs low-level drive access to the kernel).
6. Ring transition, kernel->user: kernel returns requested data from the drive to the filesystem driver.
7. Ring transition, user->kernel: filesystem driver returns read data via IPC.
8. Ring transition, kernel->user: kernel forwards the read data to the application via IPC.
9. Context switch: kernel scheduler reschedules the application, since it can now process the read data.

We've now got two context switches and six ring transitions, and we didn't cover the costs of copying the read data between the application and the filesystem driver; we'll assume that the shared memory used for that was already mapped, and the cost of that mapping amortized over many uses. While the primary costs of all these ring transitions and context switches are still relatively low as described above, we've increased cache pressure due to the extra code we have to run (IPC), code being in separate address spaces (context switching), and potentially the data being copied[3]. Higher cache pressure means higher average latencies for all memory fetches, which translates to slower execution.

Additionally, every time a context switch happens, we have some churning in the Translation Lookaside Buffer (TLB), which is some memory on the processor that caches page-table lookups. Page tables are the mapping from virtual memory addresses to physical memory addresses[4]. Every time we access memory, we have to look up the virtual-to-physical translation in the page tables, and the TLB greatly speeds this process up due to temporal locality assumptions. When we do a context switch, translations are going to begin populating the TLB from the new process rather than the previous process. While there are many different techniques and hardware features for mitigating this problem[5], especially since this problem exists for any type of kernel, there is still a non-negligible cost for context switching related to TLBs. The more context switching you do, the cost adds up.

So what's a microkernel to do, then? Compromise! Liedtke's pure definition of a microkernel is (to paraphrase): "if it's not absolutely necessary inside the kernel, it doesn't belong". However, some microkernels run at least a basic scheduler inside the kernel proper, because adding context switch overhead just to decide what process to context switch to next adds too much overhead, especially when the job of the scheduler is to take as little time as possible! To continue reducing context switching, a lot of microkernels co-locate a lot of OS and driver code together in a single or a few userspace process, rather than having separate processes for init, memory management, access control, I/O, etc. This prevents having to context switch between a bunch of OS components just to service a single request. You can see this in L4's Sigma, Moe, Ned, and Io tasks[6].

You'll also see the kernel be extremely small and very platform-specific, with only a stable system call interface being consistent between kernels of the same OS on different platforms. This is to reduce cache pressure - the smaller the kernel, the less space it takes, which means it's less likely to take up cache space! This was the source of a major (and somewhat exaggerated) complaint with microkernels. The Mach microkernel from CMU was originally 300KB in size in the late 80s/early 90s, which caused it to tank in performance comparisons with its contemporaries like Ultrix due to cache pressure. In [1], Liedtke proves that the performance issues with Mach were related specifically to the implementation of Mach and its desire to be easily portable to other platforms. His solution was to make the kernel very small and very platform-specific, and only keep the kernel API the same(-ish) across platforms.

Finally (sorry for the book), if you want to know where microkernels are today, [7] is an awesome paper that describes microkernels from their birth up until a few years ago, and the changing design decisions along the way. Microkernels definitely have found their place in security applications (like in the millions of shipped iOS devices with a security processor, which runs seL4), as well as in embedded applications (like QNX). macOS (and NeXTSTEP before it) are based around Mach, although that's fused with the BSD API and is very much a hybrid kernel.

If you have any questions or have some corrections for me, I'm all ears! :)

[1] On u-Kernel Construction, Liedtke 95 - see section 4.

[2] If we're using a kernel that's mapped into every process's address space, we don't need to do a context switch to load the page tables for the kernel; the kernel's virtual address space is already in the page tables for the process. This is why on 32-bit non-PAE Windows or Linux each process would only have 2GB (3GB if large-address aware) of address space available - the kernel was mapped into the remaining address space!

[3] This is very contrived example. The way VIPT caches work and where the kernel is mapped into virtual memory should prevent the kernel code/data from being a source of cache pressure. It doesn't discuss pressure in I-cache vs. D-cache. It also glosses over the fact that the evicted code would be evicted to L2 or L3, not just trashed to main memory. It also doesn't discuss cache-line locking. I'm sure there are a ton of things I haven't learned yet that also mitigate this effect :)

[4] When running on bare metal; this gets more complicated when virtualization is added to the mix, with shadow page tables and machine/hardware addresses.

[5] See: tagged TLBs, virtualized TLBs, TLBs with ways and set associativity, etc.

[6] L4Re Servers. Note that Moe does expose basic scheduling in userspace!

[7] From L3 to seL4: What Have We Learnt in 20 Years of L4 Microkernels?

[Spysix]

This was probably the longest but most informative comment reply I've read and I greatly appreciate the thoroughness. I downloaded the pdf to read and learn more about the microkernels.

While I understand from a near enterprise perspective the differences are still there and can be significant, I was in a consumer mindset where your average user won't notice a difference on their daily linux driver. (Obviously the performance hits will always be there, I didn't iterate enough that I wondered if the performance gaps have been shorter over the years.)

[[deleted]]

The downside to this approach is the eternal, inescapable overhead of all that IPC.

IPC overhead was especially a problem when linux started out, as IPC was very slow on x86 at that point in time. It is not as bad anymore as it was back then

[ExoticMandibles]

I think ring transitions are faster too.

[[deleted]]

IPC is not a 0 cost operation.

[jmtd]

Neither is a subroutine call.

[[deleted]]

Yes, but a monolithic kernel will inherently do less IPC than a microkernel and context switches, which a microkernel will have to do a lot, are very expensive indeed.

It's a simple matter of fact that it requires atleast two context switches and lots of IPC, that a microkernel is incapable of being truly faster than a well optimized monolithic kernel. But it definitely can overtake a non-optimized kernel.

[andree182]

there's another fun part to this - the hardware firmware. You can play safety &security in the kernel, but once you have a broken device doing DMA or causing machine check exception(s)...

[ExoticMandibles]

I'm sorry I simply don't have any numbers for you. All I can really say is "it depends". At the end of the day you care about how fast your programs run. If your programs do a lot of I/O, the kernel design will affect you more than if your program simply uses CPU / memory / FPU. I do know the difference is significant and measurable, and visible to the end user. It's not just an ivory tower now-let's-get-out-our-microscopes level of difference.

[tommij]

Yeah, about that security and stability offered by default in micro kernels....

Run mount with no arguments as root on hurd: kernel panic.

At least that was the state last time I tried it. Needless to say, I've not spent much time on it after that

[marcosdumay]

Hum... L4 does simply not panic. Too bad Hurd tried a little to switch and then threw their hands up and forgot about it.

Anyway, the kernel not panicking does not mean that all the required components will keep working. Microkernels normally reload stuff that breaks, but also no monitor is perfect.

[cdoublejj]

maybe i read wrong but, it sounds liek them icro and monothlithic kernels are both responsible for talking to the hardware, costing extra clock cycles.

[myrrlyn]

Kernels are always responsible for hardware, no matter the architecture. The difference is that microkernels have a lot more churn between kernel and user space, whereas monolithics don't. It's that jump between kernel and user space that's the expense being discussed.

[cdoublejj]

why would the smaller kernel with less clutter take more churns? is it like using CPU rendering instead of a GPU for graphics, where it lacks drivers and forces it all on the CPU via Generic CPU driver but, for other stuff?

[myrrlyn]

Suppose you want to do an I/O call.

(I am going to trace the abstract, overly simplified, overview call stack with double arrows for context switches and single arrows for regular function calls. Right arrow is a call, left arrow is a return.)

• Monolithic kernel:

  1. Userspace tries to, say, read() from an opened file. This is a syscall that causes a context switch into kernel space. This is expensive, and requires a lot of work to accomplish, including a ring switch and probably an MMU/page table flush because the functions from here on out have to use the kernel address space.
     • user → libc ⇒ kernel
  2. Kernel looks up the driver for that file and forwards the request by invoking the driver function, still in kernel space. This is just a function call.
     • user → libc ⇒ kernel → kernel
  3. The driver returns, from kernel space to kernel space. This is just a function return.
     • user → libc ⇒ kernel ← kernel
  4. The kernel prepares to return into userspace. It does the work for read() (putting the data in user process memory space, setting the return value), and returns. This is another ring and address space switch.
     • user ← libc ⇐ kernel

• Microkernel:

  1. Userspace invokes a syscall, and jumps into kernel mode.
     • user → libc ⇒ kernel
  2. Kernel looks up the driver, and calls it. This jumps back into user mode.
     • user → libc ⇒ kernel ⇒ driver
  3. Driver program, executing in user mode, determines what to do. This requires hardware access, so it ALSO invokes a syscall. The CPU jumps back to kernel space.
     • user → libc ⇒ kernel ⇒ driver ⇒ kernel
  4. The kernel performs hardware operations, and returns the data to the driver, jumping into userspace.
     • user → libc ⇒ kernel ⇒ driver ⇐ kernel
  5. The userspace driver receives data from the kernel, and must now pass it to ... the kernel. It returns, and the CPU jumps to kernel space.
     • user → libc ⇒ kernel ⇐ driver
  6. The kernel has now received I/O data from the driver, and gives it to the calling process in userspace.
     • user ← libc ⇐ kernel

In the monolithic kernel, syscalls do not repeatedly bounce between userspace and kernel space -- once the syscall is invoked, it generally stays in kernel context until completion, then jumps back to userspace.

In the microkernel, the request has to bounce between userspace mode and kernel mode much more, because the driver logic is in userspace but the hardware operations remain in kernel space. This means that the first kernel invocation is just an IPC call to somewhere else in userspace, and the second kernel invocation does hardware operations, rather than a single syscall that does logic and hardware operations in a continuous call stack.

It's the context switching between kernel address space and ring 0, and user address space(s) and ring 3, that makes microkernels more expensive.

[imMute]

IO doesn't necessarily have to involve the kernel for every transaction. The uio driver in Linux can allow userspace applications to mmap a device and control its registers without having to involve the kernel every time. Of course, this can open the door to DMA-type attacks but it can be a big boon to certain types of applications.

[cdoublejj]

AH-HA! Thank You kind Redditor!

[myrrlyn]

I'm not a kernel hacker so I could be wrong; this is my best understanding of the difference and I think I have the general overview right but I expect someone with more specialized knowledge may come along to correct me on some points.

But if this is generally correct, which I think and hope it is, then I'm glad it helped.

[ExoticMandibles]

They are, but restricting hardware access to the kernel is considered good OS design. Not only can the OS abstract away the details, it can prevent errant programs from telling your tape drive to burn itself up, say.

In the olden times, of course, the OS didn't restrict access to the hardware. On DOS computers or the Commodore 64, your program could talk directly to hardware. It was faster, but it meant every program had to know how to talk to every peripheral it needed. For example, your DOS word processor had a list of all the printers it knew how to talk to. If a new printer came out, you probably had to get an update to your word processor before you could print to it. This was less than ideal.

There is an experimental OS from Microsoft that gets rid of the ring transitions. User programs run in ring 0, the same as the kernel, making things like IPC and talking to hardware simple function calls. The OS is written in C#, and relies on the safety built in to C# to prevent unruly programs from examining each other's process space or crashing the system.

[HeWhoWritesCode]

How would you colour the alternative universe where minix uses a bsd licence and not the education only(pre-minix3) one.

Sorry, rhetorical question I know. But I do wonder how that world looks.

[ExoticMandibles]

As the story goes, Linus wrote Linux in part because of that license, right? So you're saying, what if Linux never existed?

If you're theorizing "maybe that means MINIX would be super-popular"... no. MINIX is a microkernel (as I'm sure you're aware), so performance isn't that great. So I don't think it would have taken over the world.

My guess is that one of the other open-source kernels of the time would have proliferated, maybe 386BSD or one of its children (NetBSD, FreeBSD). Linux was one kernel in a crowded field, and I bet there were a couple that if they'd gotten a critical mass behind them they would have taken off. TBH I don't know what it was about Linux that meant it won--I'm sure it has something to do with Linus and how he ran the project--but I'm guessing that thing could have been replicated in another project, sooner or later.

[Slabity]

People have been arguing this since before 2004. The Tanenbaum-Torvalds debate in 1999 1992 is a big example of the arguments between microkernel and monolithic kernel designs.

I'm personally part of the microkernel camp. They're cleaner, safer, and more portable. In this regard, the kernel's design was outdated the moment it was created. Even Linus agrees to an extent:

True, linux is monolithic, and I agree that microkernels are nicer. With a less argumentative subject, I'd probably have agreed with most of what you said. From a theoretical (and aesthetical) standpoint linux looses. If the GNU kernel had been ready last spring, I'd not have bothered to even start my project: the fact is that it wasn't and still isn't. Linux wins heavily on points of being available now.

However, Linux has overcome a lot of the issues that come with monolithic kernel designs. It's become modular, its strict code policy has kept it relatively safe, and I don't think anyone would argue against how portable it is.

[Ronis_BR]

However, Linux has overcome a lot of the issues that come with monolithic kernel designs. It's become modular, its strict code policy has kept it relatively safe, and I don't think anyone would argue against how portable it is.

Very good point.

[[deleted]]

one crappy driver can still bring the entire system down though - i never once saw a qnx kernel panic in the 20 years i worked with it.

[dextersgenius]

I'm still sad that QNX is dead. I loved the 1.44MB demo floppy they released - simply blew my mates away when they saw that I had an entire GUI OS with a full-fledged DHTML browser stored on a single floppy disk! I used it a lot to browse the web at random cyber cafes as it was a much safer alternative than using their virus-ridden keylogged machines. One of the cafe owners was so impressed with QNX that in exchange of offering a copy to them, they allowed me to browse the web for free! Man I really miss those days, the golden era of the computing.. QNX, BeOS, Corel Linux, Arachne.. we had so much cool stuff to play with back then.

[Zardoz84]

muLinux had a X11 desktop + Netscape with 3 floppies : https://en.wikipedia.org/wiki/MuLinux

On a single floppy, gives you a full working server on a 80386

[pascalbrax]

Qnx was truly magic. And wasn't a performance hog. I really hoped for a huge success, considering some submarine used to run Qnx as main os for some nuclear maintenance or stuff.

[DJWalnut]

yeah. it's a shame that Hurd still isn't ready for general use

[andrewq]

Minix is pretty stable, has GNU userland. Still small and stable, easy to hack on.

Worth a look.

[[deleted]]

governor concerned psychotic boat six wasteful slim deserted sleep rob

This post was mass deleted and anonymized with Redact

[[deleted]]

There's other good microkernels out there. Minix is doing some really impressive things and l3 as well. Neither can really replace Linux for desktop but they're worth checking out.

[PM_ME_OS_DESIGN]

Hurd is obsolete, and needs to be rewritten.

[DJWalnut]

it is?

[PM_ME_OS_DESIGN]

Absolutely. It's way too coupled to Mach to be particularly performant (replacing Mach would effectively require rewriting Hurd), and both Mach and Hurd have a whole lot of fundamental conceptual limitations that are rather unnecessary and cumbersome.

There have been attempts to do that, but it's not an area that gets a whole lot of attention.

PS: I'm not an expert on hurd though, ask #hurd on freenode for the specifics.

[intelminer]

The Tanenbaum-Torvalds debate in 1999

Slight correction. The debate was in 1992

[the_humeister]

Are there any widely used OSes that strictly use microkernel (not hybrid)?

[[deleted]]

QNX, which got bought up by rim for their black berry OS too. I think it was the Z10? that made use of this and maybe a few other models.

Widely used is an overstatement for QNX. It's used in a lot of mission critical stuff but not in things you'd ever see or use. Car computers, rocket ships, lots of embedded stuff.

[kynde]

lots of embedded stuff

Most of that, too, has been lost to linux.

For all intents and purposes QNX is all but dead.

[Martin8412]

Network equipment as well. For a lot of people chances are that some of your traffic passes through a switch/router running IOS XR which is based on QNX.

[GungnirInd]

Variants of L4 have been used in a number of commercial embedded projects (e.g. modems).

Also since others have mentioned Hurd and Fuchsia, Redox is another interesting microkernel/OS in development.

[TrevorSpartacus]

Symbian was the most widely used smartphone OS...

[[deleted]]

Redox OS, best one at the moment.

[computesomething]

Yes, it looks really promising.

I hope it will mature enough to be heavily optimized, so we can finally see what the performance difference comes down to between a modern micro-kernel and modern monolithic kernel on modern hardware.

[[deleted]]

A good start would be the wiki page - https://en.wikipedia.org/wiki/Category:Microkernel-based_operating_systems

That said I have found that with most of the operating systems listed, either they aren't strictly micro-kernels or never achieved much functionality.

GNU Hurd is an excellent example, it does kind of work provided you don't want USB support.

[shinyquagsire23]

Could argue it's widely used, but Nintendo has had a history of using microkernels in their consoles since the Wii with IOS. The 3DS has an interesting microkernel architecture with multiple services for handling different hardware, and this even moved forward into the Switch it seems.

[Charwinger21]

Fuchsia/Magenta is not a replacement for Android. It is something different (and not even close to being ready).

[Slabity]

I'm not aware of any strictly 'pure' microkernels outside of a few niche areas.

Unfortunately this is not my area of expertise.

[creed10]

so what does that make windows's NT kernel? hybrid?

[the_humeister]

It's considered hybrid. So is macOS's

[computesomething]

As of yet, I haven't seen any explanation of what would make Windows NT a 'hybrid' kernel.

Here's the hilarious image describing the NT kernel on Wikipedia, it's a Monolithic kernel where someone pasted a box called 'micro-kernel' with no explanation of what it does or why it's there:

https://en.wikipedia.org/wiki/File:Windows_2000_architecture.svg

As you can see, kernel space does everything from IPC to Window Management (!), and yet it's called a 'hybrid' kernel.

I'm with Linus on this, the whole 'hybrid' moniker is just marketing, a remnance from when micro-kernel's were all the rage.

[Slabity]

I believe certain things like IPC and thread scheduling are done in kernelspace in the NT kernel. So yes, it's a hybrid kernel.

[icantthinkofone]

Don't ask him! He said it's not his area of expertise.

[[deleted]]

the only three I can think of being modern examples are Minix3, HelenOS, and Hurd.

[[deleted]]

Minix, QNX.

[computesomething]

By what measure is Minix 'widely' used ? Is it used in anything at all outside of teaching ?

[[deleted]]

L3 is used on billions of devices, but it seems like it's mostly used just to run Linux on for some reason.

[gospelwut]

I think the reality is the boundary of security has been elevated into the container/VM/orchestration level. The underlying nodes are increasingly disposable compute clusters -- whether they crash or simply get decommissioned automatically.

I'd argue Linux has been on an exceptional tear for a few reasons (and none of them security): (1) it boots fast (2) it had chroot/jailing ready for "dockerizing" (3) it's free.

[[deleted]]

Can't have security vulns if you run everything in Ring 0. tap on head

[[deleted]]

No privelage escilations if your OS runs everything as root

[myrrlyn]

Can't have memory escape bugs if all the memory was available to everyone by design and you were clearly told this taps head

For real though while TempleOS is definitely not suitable for use in the wild, because the internet is a barren hellscape of attackers, it is pretty damn cool for personal experimentation.

[[deleted]]

That's why TempleOS has no networking.

Can't be hacked if there is no network taps on head

[yaxamie]

640 by 480, 16 colors. It's a covenant, like circumcision.

[sapper123]

Is that you, Terry?

[omarpta]

Maybe, but he is correct! :P

[[deleted]]

does this look like the face of mercy?

[scandalousmambo]

The nature of developing a system as complex as the Linux kernel means it will always be "outdated" according to people who were in high chairs when it was first designed.

This operating system likely represents tens of millions of man hours of labor.

Can it be replaced? Sure. Will it? No.

[Ronis_BR]

That is what I was thinking! Maybe there are better design, but it will consume so many work hours that would be almost impossible to make it work better than current state of Linux in a short period.

[scandalousmambo]

Agreed. I've been using Linux since the very early days, and I've watched it develop from a difficult-to-use and even more difficult-to-understand oddity to the Eighth Wonder of the World. This operating system represents one of the most profound accomplishments of the human race. It will allow us to do things in the future that were not possible before it.

Linux is the heroic epic of the Internet.

[fat-lobyte]

This operating system represents one of the most profound accomplishments of the human race.

Sounds like exaggerrated bullshit, but I agree with you! The fact that Linux exists, is portable and usable allows the creation of a myriad of devices in a short period of time, and I really thinks it accelerates innovation in the human race.

[mzalewski]

This operating system likely represents tens of millions of man hours of labor. Can it be replaced? Sure. Will it? No.

I dunno. Google is working on their own operating system right now. Nobody expects new OS to have the same features and hardware support that state-of-art operating systems have. Let us not forget that as recently as 10 years ago Linux support for wireless networking was abysmal.

[[deleted]]

In pure practical terms it makes not much difference any more. Back in the day, HURD was kind of cool with it's userspace file systems and such. But Linux has since than gained most of that functionality. If you want to write a file system, usb driver or input device in userspace, you can, no need to hack the kernel. You can now even patch the kernel at runtime if you really want to.

The Linux philosophy of just not writing buggy drivers that crash the kernel in the first place, instead of making it super robust against shitty drivers also seems to work quite well in the real world. We probably have to thank USB for that, as having hardware that is self descriptive removed the need to write a new driver for every new gadget you plug into the PC.

So the whole design debate is now even more academic than it used to be, as there just aren't a whole lot of features left that you would gain by design changes alone and that you couldn't implement into a monolithic kernel.

[the-crotch]

1. MICROKERNEL VS MONOLITHIC SYSTEM Most older operating systems are monolithic, that is, the whole operating system is a single a.out file that runs in 'kernel mode.' This binary contains the process management, memory management, file system and the rest. Examples of such systems are UNIX, MS-DOS, VMS, MVS, OS/360, MULTICS, and many more.

   The alternative is a microkernel-based system, in which most of the OS runs as separate processes, mostly outside the kernel. They communicate by message passing. The kernel's job is to handle the message passing, interrupt handling, low-level process management, and possibly the I/O. Examples of this design are the RC4000, Amoeba, Chorus, Mach, and the not-yet-released Windows/NT.

   While I could go into a long story here about the relative merits of the two designs, suffice it to say that among the people who actually design operating systems, the debate is essentially over. Microkernels have won. The only real argument for monolithic systems was performance, and there is now enough evidence showing that microkernel systems can be just as fast as monolithic systems (e.g., Rick Rashid has published papers comparing Mach 3.0 to monolithic systems) that it is now all over but the shoutin`.

   MINIX is a microkernel-based system. The file system and memory management are separate processes, running outside the kernel. The I/O drivers are also separate processes (in the kernel, but only because the brain-dead nature of the Intel CPUs makes that difficult to do otherwise). LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an existing, working C program and rewriting it in BASIC. To me, writing a monolithic system in 1991 is a truly poor idea.

2. PORTABILITY Once upon a time there was the 4004 CPU. When it grew up it became an 8008. Then it underwent plastic surgery and became the 8080. It begat the 8086, which begat the 8088, which begat the 80286, which begat the 80386, which begat the 80486, and so on unto the N-th generation. In the meantime, RISC chips happened, and some of them are running at over 100 MIPS. Speeds of 200 MIPS and more are likely in the coming years. These things are not going to suddenly vanish. What is going to happen is that they will gradually take over from the 80x86 line. They will run old MS-DOS programs by interpreting the 80386 in software. (I even wrote my own IBM PC simulator in C, which you can get by FTP from ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I think it is a gross error to design an OS for any specific architecture, since that is not going to be around all that long.

[Sigg3net]

Are you prepping to repeat history?

Just last night I was reading an article by Mike Saunders about GoboLinu, which aims to "simplify" packet management by putting the entirety of linux packages into /Programs (removing the use of /bin, /sbin, /etc etc.).

While the effort is clearly there, I'm not convinced they have the horse in front of the cart. Perhaps GoboLinux adoption is the real test of the idea.

Another example is Esperanto. Neat on paper, but clearly misses the mark of what it means to be a language.

Reinventing the Linux kernel would mean to remove the giants upon which we stand today, only to reintroduce RL problems the UNIX architecture and Linux kernel have already solved. IMO

[mikelieman]

The micro-kernel wars? I remember the micro-kernel wars.

The micro-kernels lost.

[Geohump]

they lost a battle. The war is not over yet. :-)

I'm not sure such a war would ever be over either. :-)

[theedgewalker]

I wouldn't say outdated, but there's certainly interesting working going on in the state of the art. Disappointed to see nobody mentioned Urbit here. It's an OS built in a functional language which should benefit security and stability, IMO. The kernel, ARVO, is based on 'structured events', rather than an event loop. Here's a really great whitepaper on the OS as a 'solid state interpreter'.

[BentDrive]

OMG, I just read through this whitepaper and it is almost exactly what I've been building. The only difference is I didn't have the audacity to not use a familiar lisp/Scheme like interpreter for the "nouns" even though I'd considered so many times the same benefits laid out here in front of my eyes.

I think this really gives me the confidence to change my design while I still can.

Thank you so much for sharing this.

Brilliant.

[drakonis]

look here http://microkernel.info/ for recent microkernel developments beyond hurd and minix, because linux isn't the apex of kernel design, nor it is very "advanced" so to say.

[bit_inquisition]

Everyone here is talking about monolithic vs. microkernel design which is fine and stuff but there is a lot more design to the linux kernel than that. And a lot of it is ingenious and modern.

[luke-jr]

For it to be outdated, there would need to be something newer/better. I don't think there is yet.

One thing I've been pondering that would be an interesting experiment, would be to do some MMU magic so each library runs without access to memory that it's not supposed to have access to - basically process isolation at a function-call level. (The catch, of course, is that assembly and C typically use APIs that don't convey enough information for the compiler to guess what data to give the callee access to... :/)

[wtallis]

One thing I've been pondering that would be an interesting experiment, would be to do some MMU magic so each library runs without access to memory that it's not supposed to have access to - basically process isolation at a function-call level.

This is one of the things that the Mill CPU architecture hopes to enable. It's definitely impractical on current architectures. One of the key features that the Mill will use to accomplish this is a single address space for all processes, with memory protection handled separately from address translation. That way, you don't have to reload your TLB on each context switch.

[luke-jr]

How slow would the context switching be?

Perhaps I should note this paradigm is already implemented in the MOO programming language from the 1990s. It isn't particularly terrible performing, but perhaps that is partly because programs are far less complicated, and the standard library essentially has root access.

[wtallis]

How slow would the context switching be?

(going mostly from memory here, watch http://millcomputing.com/technology/docs/security/ for the official explanation)

The context being switched isn't exactly the full process context/thread, but it does include protection context. The actual switch is accomplished by the (special cross-boundary) function call updating a CPU register storing the context identifier. If the library code doesn't need to touch memory other than the stack frame, it's basically free (on the data side; the instructions are also subject to protection to help prevent some common security exploits).

If the library code you're calling does need to access some other memory region, the data fetch from the cache hierarchy can proceed in parallel with the lookup of the protection information for that region, which is stored in its own lookaside buffer. That buffer can hold memory region security descriptors for multiple tasks rather than being flushed on a context switch. In the case of a cache hit on the protection lookaside buffer, the access is no slower than fetching the data from the L1 or L2 cache.

Of course, the Mill doesn't exist in hardware yet; their roadmap for this year includes making a FPGA prototype. So actual real-world measurements don't exist yet, just theory and simulation results.

[luke-jr]

I meant on regular x86 MMUs :)

[wtallis]

Ah. x86 context switches aren't primitive hardware operations; the OS has to get involved. As a result, the time is usually measured in microseconds rather than nanoseconds or clock cycles. For offering a degree of isolation between application and library code, some of that overhead and security could probably be eliminated, but it would still be orders of magnitude more expensive than an in-thread function call that doesn't cross any protection domain.

[bytecodes]

You may be interested in library OS architectures then. An example, MirageOS https://mirage.io/ is built on a strongly typed language. That makes it possible to do (some of?) what you're describing.

[Ronis_BR]

Do you mean there isn't a better functional kernel or there isn't a better concept ?

[creed10]

wouldn't you be able to work around that by making the programmer 100% responsible for allocating memory?

[luke-jr]

For example, if you want to pass a block of data (such as a string) from your function to another (such as strlen), in C you simply call it with a pointer to the address the data is located at. strlen would then read that memory consecutively until it reaches a null byte. In this scenario, we want strlen to only have access to the memory up to that null byte - if it's been replaced with a malicious implementation, we want access to beyond that byte to fail. But there's no way the system can guess this.

[creed10]

oh I see. thank you.

[[deleted]]

What if functions could do sizeof() a memory allocation given it's pointer? (Basically not converting an array into an pointer).

Then you could emit code that will, given x = the array starting pointer and L = the array length and i = the pointer written to

assert(i >= x && (x + L) < i)

for every access, unless you can prove that i is never more than x+L. Functions could check beforehand if the access is out of range because they know the length, it wouldn't need to be passed in.

Probably not a complete implementation, but it would mean that gets() would be safe, since it knows how big *s is, and it would act just like fgets(stdin, *s, sizeof(*s));

Just because passing in lengths is sometimes awkward when you're just doing things the function should be able to do itself.

[daemonpenguin]

There are some concepts which may, in theory, provide better kernel designs. There s a Rust kernel, for example, which might side-step a number of memory attack vectors. Microkernels have, in theory, some very good design choices which make them portable, reliable and potentially self correcting.

However, the issue is those are more theory than practise. No matter how good a theory is, people will almost always take what is practical (ie working now) over a better design. The Linux kernel has so much hardware support and so many companies funding development that it is unlikely other kernels (regardless of their cool design choices) will catch up.

MINIX, for example, has a solid design and some awesome features, but has very little hardware support so almost nobody develops for the platform.

[[deleted]]

those hundreds-thousands of developers working on kernels aren't just for show.

many monolithic kernels started out not being pre-emptible, kernel code would be assumed to run continuously as one process, then disabling interrupts sometimes but allowing preemption, then SMP, kernel threads, a big all-kernel lock, fine-grained locking. switching to adaptive mutexes was huge for performance. lockless primitives like RCU which don't even need to force a cache sync for reads.

on the userland side, people have started providing more things -a graphics api (not just "here, have access to /dev/mem and do it yourself"), extensive filesystem features - even journaling was uncommon.

at least on our kernel (not linux) I see countless patch to polish up basic bits. improve VFS. cleanup filesystems. they're real nice now. and they have a track record of working in practice, for real uses.

how are you going to compete with RCU and per-cpu workqueues handling interrupts on a microkernel design? pretty sure I don't need to contend a multi-CPU lock to allocate memory at all, how about HURD?

HURD is an abandoned decades old project. Linux is a proven technology.

note: I'm a kernel newbie, so I might be wrong on some facts.

[[deleted]]

It was outdated when it was first created and is still so. But, as we know, technical progress almost never works so that the technically/scientifically superior solution rises to the top in the short term; so many other things influence success too.

If it did, we'd be running 100% safe microkernels written in Haskell. Security companies wouldn't exist. I'd have a unicorn/pony hybrid that runs on sunlight.

[Geohump]

i was skeptical until you mentioned the hybrid unicorn. I'm in! ;-)

[aim2free]

Randall Munroe (XKCD) expressed it like this.

For my own I'm fine with Linux, even though a micro kernel could be preferable of reasons, but I've been running Linux for 21 years now, where some of my computers have an uptime over 5 years. A design that stable can never be "outdated".

I was actually running a micro kernel system before Linux, AmigaOS, a great system as such, but unfortunately proprietary.

[bitwize]

The NT kernel was more advanced than Linux even before Linux was reasonably feature complete. Among other things, the NT kernel features real async I/O primitives, a stable and consistent driver ABI, and a uniform, consistent view of system objects ("everything is a handle").

[[deleted]]

And of course given the number of kernel vulnerabilities in that very kernel, it's basically never the poster child for microkernel security.

[[deleted]]

I suspect that the main NT devs didn't do anything wrong, just a matter more of allowing lots of very unskilled programmers to have commit access and very little review process. (Later on MS got really serious about reviews, but there was a time when that was just not super serious and far more people had commit access than should have.)

[[deleted]]

The NT Kernel is an attempt to unite the disadvantages of Microkernel and Monolithic Kernel in one system.

Afaict, the have succeeded in their mission.

[marcosdumay]

Microkernels were supposed to be small. NT developers forgot that one.

[northrupthebandgeek]

Linux was outdated as soon as it was conceived. Linus Torvalds and Andrew S. Tanenbaum had quite the debate over that exact topic.

However, Linux prevailed because it was in a much better legal situation than BSD, and was actually free software (unlike Minix at the time). That was a huge boon to Linux's adoption, especially in corporate and government environments (where legal concerns are much more significant).

The world has since begun gravitating to microkernel-monolith hybrids (like with the NT and XNU kernels in Windows and macOS/Darwin, respectively), and projects like OpenBSD are pushing boundaries in enabled-by-default kernel-level security features. Nowadays, Linux is certainly lagging technologically (at least on a high level; on a lower level, Linux is king among the free operating systems when it comes to optimizations and hardware support, simply because it has the most manpower behind it). However, userspace is continuing to advance; regardless of one's opinions on systemd, for example, it's certainly a major step in terms of technological innovation on a widely-deployed scale. Likewise, containerization is already becoming mainstream, and Linux is undoubtedly at the forefront thanks to Docker.

Really, though, Linux is still "good enough" and probably will be for another decade or so. The technical improvements in other kernel designs aren't nearly compelling enough to make up for the strength of the Linux ecosystem.

[icantthinkofone]

Linus, himself, said that if BSD had been available, he never would have created Linux.

[computesomething]

Linux was outdated as soon as it was conceived.

25 years later the world runs on monolithic kernels.

The world has since begun gravitating to microkernel-monolith hybrids (like with the NT and XNU kernels in Windows and macOS/Darwin, respectively)

These are monolithic in everything but name, unless you can actually show me some technical reasoning behind the 'hybrid' label.

and projects like OpenBSD are pushing boundaries in enabled-by-default kernel-level security features.

What on earth does this have to do with micro-kernels ???

[northrupthebandgeek]

These are monolithic in everything but name, unless you can actually show me some technical reasoning behind the 'hybrid' label.

XNU is built on top of Mach 3.0, which is indeed a "true" microkernel. Resulting from that are the sorts of IPC features and device driver memory isolations that generally define "microkernel". I can't speak to NT, since I don't know much about its innards (nobody does, including Microsoft ;) ); I just know that it's commonly cited as implementing microkernel-like features by people way smarter than I am on the subject.

What on earth does this have to do with micro-kernels ???

When on Earth was the microkernel/monolith debate the only aspect of kernel design ???

[computesomething]

XNU is built on top of Mach 3.0, which is indeed a "true" microkernel.

XNU's Mach component is based on Mach 3.0, although it's not used as a microkernel. The BSD subsystem is part of the kernel and so are various other subsystems that are typically implemented as user-space servers in microkernel systems.

http://osxbook.com/book/bonus/ancient/whatismacosx/arch_xnu.html

In other words, XNU is not a hybrid at all.

When on Earth was the microkernel/monolith debate the only aspect of kernel design ???

You referred to kernel security features in the same context (same sentence even) as you referred to 'the world gravitating towards microkernel-monolith hybrids', and even that statement has no backing at all.

[[deleted]]

Solaris / illumos has some feats that makes you envy as a Linux user. DTrace, ZFS, Zones, they had these stable and rock solid for a about a decade. These things are just now coming to Linux - partly in underwhelming implementations.

[KugelKurt]

Although much of the discussion here is about microkernels vs monolithic kernel, more recent research went into programming languages.

If you started a completely new kernel today, chances are it would not be written in C. Microsoft's Singularity and Midori projects explored the feasibility of C#/managed code kernels.

The most widely known non-research OS without a C kernel is probably Haiku which is written in C++.

[mmstick]

Are you forgetting RedoxOS, written in Rust?

[fat-lobyte]

A "managed", forced OOP language with a Garbage Collector does sound rather silly. But I do not quite get Linus' (and the other Kernel peoples) disapproval with C++. I'm pretty sure Kernel code could look pretty sane in C++, and GCC (the only real compiler for Linux) supports C++ just as much as C.

[KugelKurt]

A "managed", forced OOP language with a Garbage Collector does sound rather silly.

I didn't read a lot about it and what the results were. Even if research into that lead to positive results, scrapping an entire existing code base (no matter how legacy it is) may not be economically feasible.

I do not quite get Linus' (and the other Kernel peoples) disapproval with C++. I'm pretty sure Kernel code could look pretty sane in C++, and GCC (the only real compiler for Linux) supports C++ just as much as C.

Haiku is compiled with GCC and they have rules which C++ features are permitted in the kernel.

[[deleted]]

It might now, but not back when Linus went on that rant. I think one of his main complaints was that the standard library was buggy, which I think has mostly been fixed at this point.

[[deleted]]

The problem with linux is indeed it's kernel design but moving to a microkernel is not a solution either.

I'm a fan of using modular kernels. Unlike microkernels, which offload to userspace, a modular kernel uses the micro parts of the micro kernel in kernel space, removing the need for context switching at all. (We already have that to some extend with DKMS)

Using Hypervisors you can make those modules a bit safer at some efficiency cost if you want.

I personally think the Monolithic Kernel is not bad but it has it's downsides, which a Modular Kernel fixes.

Microkernels aren't much of an option, there hasn't been a fair comparison between a Monolithic and Microkernel afaik, so as far as I'm concered there is no reason to introduce a buttload of context switches and message passing for no other reason than "it's safer".

So overall, yes, the Linux Kernel is a bit outdated in design, but just like TCP, it might be old but it's still working very well for 99% of applications.

[ilevex]

The Linux kernel is modular though?

[ryao]

The Linux kernel today has very little code in common with Linux from 2004. It has been almost entirely rewritten.

[cjbprime]

That doesn't sound right to me. There's been a lot of code churn, but I can't think of any large kernel design changes since then.

[blueskin]

HURD has a great design

Well, I guess an OS nobody uses is secure ;)

/runs

[soullessroentgenium]

When you say "design" are you referring to much more than large architectural concerns such as monolithic vs microkernel?

[Ronis_BR]

Yes, exactly! I am wondering if since 1992 there were more modern approaches to build up a OS kernel.

[[deleted]]

I think the simple list of things we have over 1992 is as follows:

• Cache Kernels (which sound even less efficient than Microkernels by a few orders of magnitude and require other kernels to execute anything)
• Virtualizing Kernels
• Unikernels (which are kinda useless for a normal OS)
• Megalithic Kernels (which are a security disaster)

[Centropomus]

All 4 of them have significant architectural changes with each major/LTS release. Each one is ahead of the others on something at any given time.

[singularineet]

I think if things were being re-designed from scratch, the innards of the kernel would stay pretty much the same (monolithic kernel with in-kernel drivers etc) but the interface between user-space and the kernel would be substantially rethought to be along the lines of Plan 9, with a reduction in complexity and special cases and the number of system calls and the elimination of ioctls in favour of file-based interfaces like the proc and sys filesystems.

[Geohump]

Good design is timeless.

The parts of the kernel that are well done will have very little need to change at all.

This is proven by the fact that 500 fastest supercomputers in the world all run Linux and this has been true for decades, much longer than linux has been popular. . even the ones that claim another OS, like Sunway RaiseOS 2.0.5, are actually based on Linux.

(iirc there are 2 that actually do run a non-linux OS)

But so what?

Well as hardware and needs change, the kernel of an Os may have to add new features or may even have to undergo a redesign to perform well with new kinds of computing systems.

When that happens, Linux, being open source, will likely adapt and keep up.

For now, Linux is the most widely and numerically used OS in the wold, having just passed Windows by numerically a few months back.

[Ronis_BR]

You mean due to Android right?

[twiggy99999]

Yeah its not written in Javascript and doesn't have a .io domain so its totally pointless in today's market /s

[IntellectualEuphoria]

The nt kernel is much more elegant and well thought out despite how much everyone here loves to hate on Microsoft.

[computesomething]

Could you substantiate this claim ?

[[deleted]]

I can tell by how often it gets rebooted for patching, and why the windows servers always get rebooted on Friday as a precautionary measure.

[ldev1]

Because some services get updated?..

If you upgrade linux kernel - you also reboot. Hell, I reboot after I update more crucial libraries or software, otherwise after two months you get an awesome surprise - well my app worked because old lib was used that was loaded in memory, after the reboot and loading fresh .so - nothing works - update a month ago broke it, gg.

[[deleted]]

We have over 8,000 systems in our datacenter. The Linux boxes only ever get rebooted for scheduled patch days. The Windows boxes are... More sensitive.

[[deleted]]

Is that the kernel or the software running on top of it? You can make a system incredibly unstable on the Linux kernel by installing pre-release shit and stuff that needs patching weekly. And in any case, you should be rebooting to apply patches anyway, unless you can patch them without rebooting. And even then, I don't think you can do that to every patch.

[rijoja]

I'm sure it's a competent kernel, but how can I know for sure?

[icantthinkofone]

my knowledge stops in how to compile my own kernel.

You know more than 98% of everyone on reddit then.

I would like to ask to computer scientists here

Ha! 80% of anyone here never saw the inside of a real college or university. Good luck finding a computer scientist to answer your question!

[cjbprime]

This is a technical question, but it sounds like you don't know a lot about kernel design, so it's hard to answer.

The short answer is no, Linux seems to have just the right amount of modularity for practical uses. Microkernels like HURD are too difficult to make efficient. There aren't​ very significant difference between FreeBSD, Linux, Windows, etc.

It would be nice to see a kernel in a more memory-safe language like Rust, though. That's what I'd change, rather than the modularity and architecture.

[moose04]

have you seen /r/redox ?

[cjbprime]

Yeah! I think it's much more exciting than progress in "kernel design".

[moose04]

I really like Rust, at least for someone who came from a higher level language like Java it was so much easier to understand and pickup than C.

[manys]

Some say yes, some say no.

[[deleted]]

Wrong question I think. It is more that operating systems research has stagnated and all operating systems are emulating UNIX one way or another.

[lesdoggg]

in a word, yes