5 ms·

The Linux kernel itself is a a monolithic kernel and it beat out Hurd which was a micro kernel. I would say Linux has a history of certain programs being monoli

The Linux kernel itself is a a monolithic kernel and it beat out Hurd which was a micro kernel. I would say Linux has a history of certain programs being monolithic being a good thing.

jcoffland 11y ago
Hurd has failed after many years to produce a kernel even nearly as complete as Linux.
- ferrari8608 11y ago
  That's because there are only a couple of guys working on it. Linux has had hundreds of contributors over the years, many of which work for large tech companies like Intel and get paid by their company for their contributions. I would be fascinated if Hurd could get the same sort of developer momentum to be comparable to Linux. A completely new (as in 1.0 released) and usable FOSS Unix-alike would be quite welcome amongst Linux and the BSD's I think.
  - schmichael 11y ago
    GNU's kernel efforts had an entire team debating, discussing, prototyping, and eventually working on Hurd before Linux even existed. Linux was initially written and released by one guy. Linux obviously gained a wider team while Hurd languished, but it's still interesting that GNU's kernel efforts started with far more initial human resources and were still quickly overshadowed by Linux.
cyphar 11y ago
Linux is a kernel. Monolithic and micro kernel architectures are a different problem to the Unix philosophy which specifically concerns design of userspace programs. I don't see how having pipes between kernel components would be a useful feature for a user. Also, the userspace of GNU/Linux isn't called Linux. Linux isn't an operating system.
- lobster_johnson 11y ago
  I think you're post-rationalizing. The kernel is an exception today, true, but that doesn't mean it needs to be special. The established Unix philosophy of everything being "one program that does one thing" would be hugely beneficial if applied to an OS kernel. Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel? Not to mention that it could be much easier to develop them if they could just run as processes and die if they failed, as opposed to inducing a kernel panic.
  - cyphar 11y ago
    > Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel? Except that it makes debugging almost impossible and the overhead of IPC is very large. I'd argue that most popular kernels today (k{Free,Open,Net}BSD, illumos, Linux) are monolithic because that model makes development much simpler than a microkernel (not for historical reasons). Hybrid kernels like NT are a compromise for efficiency against the benefits of having a microkernel. The panic argument is a good point, until you realise that kernel drivers don't panic --they oops. And a kernel oops just kills the thread it was running in. Linux has kernel threads that can be killed, but they're all playing in the same address space. So you can think of that as having the advantages of a microkernel without the debugging issues.
    - JdeBP 11y ago
      IPC overhead applies to monolithic and micro kernels alike and is a general design issue, not a microkernel one. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/microkernel-conceptual-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/mi...
    - lobster_johnson 11y ago
      Debugging would be easier in user mode, surely. You could attach with gdb or whatever. Last I checked, IPC overhead was not a barrier to performance in modern microkernels. QNX and XNU (used by OS X) both use microkernel-type IPC and are fast. XNU is even able to survive with an old Mach kernel. If a kernel driver ends up in a faulty state (accesses invalid memory, does the wrong interrupt thing) then surely the whole kernel will panic? NT is frequently referred to as "hybrid", but it's a frequently misunderstood design. First, while it uses IPC internally, it's not really comparable to microkernels since there's no context switch; every participant in the IPC communication is in the kernel. This is done purely as a way to isolate internals behind a rigorous, message-oriented API. Secondly, almost all of NT's services run in the kernel. A fairly small number of services run in userland: There's the user-mode driver system (UMDF, available since Vista), and graphics drivers also have the option of running partly in usermode.
maaku 11y ago
Hurd was never a viable alternative for reasons that have nothing to do with the mono/micro distinction.

The Linux kernel itself is a a monolithic kernel and it beat out Hurd which was a micro kernel. I would say Linux has a history of certain programs being monolithic being a good thing.

jcoffland 11y ago

Hurd has failed after many years to produce a kernel even nearly as complete as Linux.

ferrari8608 11y ago
That's because there are only a couple of guys working on it. Linux has had hundreds of contributors over the years, many of which work for large tech companies like Intel and get paid by their company for their contributions. I would be fascinated if Hurd could get the same sort of developer momentum to be comparable to Linux. A completely new (as in 1.0 released) and usable FOSS Unix-alike would be quite welcome amongst Linux and the BSD's I think.
- schmichael 11y ago
  GNU's kernel efforts had an entire team debating, discussing, prototyping, and eventually working on Hurd before Linux even existed. Linux was initially written and released by one guy. Linux obviously gained a wider team while Hurd languished, but it's still interesting that GNU's kernel efforts started with far more initial human resources and were still quickly overshadowed by Linux.

cyphar 11y ago

Linux is a kernel. Monolithic and micro kernel architectures are a different problem to the Unix philosophy which specifically concerns design of userspace programs. I don't see how having pipes between kernel components would be a useful feature for a user. Also, the userspace of GNU/Linux isn't called Linux. Linux isn't an operating system.

lobster_johnson 11y ago
I think you're post-rationalizing. The kernel is an exception today, true, but that doesn't mean it needs to be special. The established Unix philosophy of everything being "one program that does one thing" would be hugely beneficial if applied to an OS kernel. Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel? Not to mention that it could be much easier to develop them if they could just run as processes and die if they failed, as opposed to inducing a kernel panic.
- cyphar 11y ago
  > Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel? Except that it makes debugging almost impossible and the overhead of IPC is very large. I'd argue that most popular kernels today (k{Free,Open,Net}BSD, illumos, Linux) are monolithic because that model makes development much simpler than a microkernel (not for historical reasons). Hybrid kernels like NT are a compromise for efficiency against the benefits of having a microkernel. The panic argument is a good point, until you realise that kernel drivers don't panic --they oops. And a kernel oops just kills the thread it was running in. Linux has kernel threads that can be killed, but they're all playing in the same address space. So you can think of that as having the advantages of a microkernel without the debugging issues.
  - JdeBP 11y ago
    IPC overhead applies to monolithic and micro kernels alike and is a general design issue, not a microkernel one. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/microkernel-conceptual-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/mi...
  - lobster_johnson 11y ago
    Debugging would be easier in user mode, surely. You could attach with gdb or whatever. Last I checked, IPC overhead was not a barrier to performance in modern microkernels. QNX and XNU (used by OS X) both use microkernel-type IPC and are fast. XNU is even able to survive with an old Mach kernel. If a kernel driver ends up in a faulty state (accesses invalid memory, does the wrong interrupt thing) then surely the whole kernel will panic? NT is frequently referred to as "hybrid", but it's a frequently misunderstood design. First, while it uses IPC internally, it's not really comparable to microkernels since there's no context switch; every participant in the IPC communication is in the kernel. This is done purely as a way to isolate internals behind a rigorous, message-oriented API. Secondly, almost all of NT's services run in the kernel. A fairly small number of services run in userland: There's the user-mode driver system (UMDF, available since Vista), and graphics drivers also have the option of running partly in usermode.

maaku 11y ago

Hurd was never a viable alternative for reasons that have nothing to do with the mono/micro distinction.