7 ms·

Wow multiserver, so it would seamlessly distribute tasks to different servers? That's really cool if I understand it correctly.

chillfox 4y ago
Their webpage has this to say about it in the FAQ, so I would say nope. "Within the scope of microkernel operating systems, a multiserver spreads the operating system functionality over multiple user processes. Note how this differs from a single-server microkernel that concentrates all these functions into a single user process." - http://www.helenos.org/wiki/FAQ http://www.helenos.org/wiki/FAQ
krylon 4y ago
It's not about clustering, "multiserver" in this context means that parts that are stuffed together in the kernel on Linux or BSD run in separate userspace processes (i.e. networking, file system, device drivers, ...). This approach gives better isolation of those components, so a bug in one is less likely to affect others, and if one crashes, it can potentially be restarted, while the rest of the system keeps running. If done right, it can also make these individual parts simpler. GNU/Hurd tries the same, but with POSIX compatibility and so far with mixed success. Other multiserver microkernel systems I know off are Minix and QNX. I'm sure there's more.
- forgotpwd16 4y ago
  Redox, Fuchsia, Genode, Helios/Ares, are some more recent examples.
- mike_hearn 4y ago
  Modern operating systems are all microkernel-ish to some extent. Linux can run filesystems in usermode processes, Windows does run the graphics subsystem in a separate process, macOS consists of tons of components running in various servers connected by Mach ports and is similar to Android in that they're moving drivers progressively out of the kernel into processes. The two classic examples of the networking stack and the filesystem generally don't move because they aren't buggy enough to be worthwhile, the performance hit is too great and because it's unreasonable to expect userland processes to cleanly handle a restart of things like that. Like, in 99.99% of real programs if every file descriptor is suddenly invalidated then that program will crash and the devs won't care if you report it as a bug because they'll say, yeah well, actually it's on you to fix your buggy OS not on us to code around it. Other platforms don't crash their network or FS driver every five minutes so why should we do extra work for yours? So the kernel vs microkernel distinction doesn't seem particularly relevant or interesting anymore, at least not to me.
  - snvzz 4y ago
    >the performance hit is too great I see this myth referenced a lot due to misconceptions constructed around design issues in early, pre-Liedtke microkernels (particularly Mach, used in IOS/OSX) leaving a long-lasting impression. L4 changed everything, and seL4 takes it to the next level. Some references: - https://archive.ph/30hhi https://archive.ph/30hhi - https://youtu.be/INBEKSkAiTA?list=PLtoQeavghzr3atxNQig-sLGbwoKBSVxGV&t=870 https://youtu.be/INBEKSkAiTA?list=PLtoQeavghzr3atxNQig-sLGbw...
    - snvzz 4y ago
      I add: https://sel4.systems/About/seL4-whitepaper.pdf https://sel4.systems/About/seL4-whitepaper.pdf
  - pjmlp 4y ago
    That is why Linux is run on top of hypervisors, alongside containers and kubernets orchestration engines, get to use that extra performance.
    - snvzz 4y ago
      With that extra insecurity due to huge TCB. The kernel is MLoCs of poorly structured, highly privileged code. A breeding field for bugs.
  - still_grokking 4y ago
    > Modern operating systems are all microkernel-ish to some extent. This won't become true even it gets repeated more. A micro kernel requires a micro kernel design form the ground up. (Something like FDs would be only one example of something where you would need different APIs…) You can't make a micro kernel out of a monolith. That's one of the reasons something like Hurd failed, and something like macOS is a slow and buggy hell. The story about the graphics drivers on Windows is also not true, afik. I've heard they moved this back into kernel space (with some special encapsulation) long ago because it was way to slow otherwise. Because you can't move an existing design to be an micro kernel after the if your APIs are all designed for a monolith setting. Alone the fact that you need async "SysCalls" (or better said "ServerCalls") in a proper micro kernel design makes it impossible to make a micro kernel out of a monolith (where all SysCalls are usually sync, because it makes no sense to have an async layer for intra-process calls). Also micro kernels aren't slow. The canonical link was posted already in a sibling. The main point about micro kernels, and why they still more than matter, is not about bugs and crashes. The main point is about security. You can't have a secure monolith! The TCB would need to be way to large.
mananaysiempre 4y ago
No. “Multiserver” (a term from the microkernel literature) means that the conventional basic OS services are split into several “server” processes with distinct responsibilities (a mounted filesystem, a network card, perhaps a hardware bus, etc.). This is the original conception of a microkernel- (as opposed to e.g. an exokernel-) style system and its architectural promise, although it’s not made necessary by the mere fact of being built on top of a microkernel: AFAIK L4Linux is a single server so the L4 microkernel basically acts as a simple VMM / HAL without further architectural benefits. (For other monolithic but userspace OS servers, look at wineserver in Linux, CSRSS and LXSS in Windows NT, etc. For multiserver systems of varying purity, look at QNX and Minix.) What you’re thinking of is a “distributed OS”, although those academic efforts look terribly naïve from today’s distributed consensus standpoint. Good points of entry may be Barrelfish and Plan 9.
- als0 4y ago
  Amoeba is a famous example of a distributed OS https://en.wikipedia.org/wiki/Amoeba_(operating_system) https://en.wikipedia.org/wiki/Amoeba_(operating_system)
  - api 4y ago
    It’s too bad this research didn’t continue. Instead we got a giant tower of kludges including containers, Kubernetes, service meshes, endless API design problems, endless reinventing of data serialization and protocols, and so on.
    - deleted 4y ago
      [deleted]
    - johnisgood 4y ago
      Or something like https://en.wikipedia.org/wiki/Sprite_(operating_system) https://en.wikipedia.org/wiki/Sprite_(operating_system) but with a microkernel!
    - mananaysiempre 4y ago

chillfox 4y ago

Their webpage has this to say about it in the FAQ, so I would say nope. "Within the scope of microkernel operating systems, a multiserver spreads the operating system functionality over multiple user processes. Note how this differs from a single-server microkernel that concentrates all these functions into a single user process." - http://www.helenos.org/wiki/FAQ http://www.helenos.org/wiki/FAQ

krylon 4y ago

It's not about clustering, "multiserver" in this context means that parts that are stuffed together in the kernel on Linux or BSD run in separate userspace processes (i.e. networking, file system, device drivers, ...). This approach gives better isolation of those components, so a bug in one is less likely to affect others, and if one crashes, it can potentially be restarted, while the rest of the system keeps running. If done right, it can also make these individual parts simpler. GNU/Hurd tries the same, but with POSIX compatibility and so far with mixed success. Other multiserver microkernel systems I know off are Minix and QNX. I'm sure there's more.

forgotpwd16 4y ago
Redox, Fuchsia, Genode, Helios/Ares, are some more recent examples.
mike_hearn 4y ago
Modern operating systems are all microkernel-ish to some extent. Linux can run filesystems in usermode processes, Windows does run the graphics subsystem in a separate process, macOS consists of tons of components running in various servers connected by Mach ports and is similar to Android in that they're moving drivers progressively out of the kernel into processes. The two classic examples of the networking stack and the filesystem generally don't move because they aren't buggy enough to be worthwhile, the performance hit is too great and because it's unreasonable to expect userland processes to cleanly handle a restart of things like that. Like, in 99.99% of real programs if every file descriptor is suddenly invalidated then that program will crash and the devs won't care if you report it as a bug because they'll say, yeah well, actually it's on you to fix your buggy OS not on us to code around it. Other platforms don't crash their network or FS driver every five minutes so why should we do extra work for yours? So the kernel vs microkernel distinction doesn't seem particularly relevant or interesting anymore, at least not to me.
- snvzz 4y ago
  >the performance hit is too great I see this myth referenced a lot due to misconceptions constructed around design issues in early, pre-Liedtke microkernels (particularly Mach, used in IOS/OSX) leaving a long-lasting impression. L4 changed everything, and seL4 takes it to the next level. Some references: - https://archive.ph/30hhi https://archive.ph/30hhi - https://youtu.be/INBEKSkAiTA?list=PLtoQeavghzr3atxNQig-sLGbwoKBSVxGV&t=870 https://youtu.be/INBEKSkAiTA?list=PLtoQeavghzr3atxNQig-sLGbw...
  - snvzz 4y ago
    I add: https://sel4.systems/About/seL4-whitepaper.pdf https://sel4.systems/About/seL4-whitepaper.pdf
- pjmlp 4y ago
  That is why Linux is run on top of hypervisors, alongside containers and kubernets orchestration engines, get to use that extra performance.
  - snvzz 4y ago
    With that extra insecurity due to huge TCB. The kernel is MLoCs of poorly structured, highly privileged code. A breeding field for bugs.
- still_grokking 4y ago
  > Modern operating systems are all microkernel-ish to some extent. This won't become true even it gets repeated more. A micro kernel requires a micro kernel design form the ground up. (Something like FDs would be only one example of something where you would need different APIs…) You can't make a micro kernel out of a monolith. That's one of the reasons something like Hurd failed, and something like macOS is a slow and buggy hell. The story about the graphics drivers on Windows is also not true, afik. I've heard they moved this back into kernel space (with some special encapsulation) long ago because it was way to slow otherwise. Because you can't move an existing design to be an micro kernel after the if your APIs are all designed for a monolith setting. Alone the fact that you need async "SysCalls" (or better said "ServerCalls") in a proper micro kernel design makes it impossible to make a micro kernel out of a monolith (where all SysCalls are usually sync, because it makes no sense to have an async layer for intra-process calls). Also micro kernels aren't slow. The canonical link was posted already in a sibling. The main point about micro kernels, and why they still more than matter, is not about bugs and crashes. The main point is about security. You can't have a secure monolith! The TCB would need to be way to large.

mananaysiempre 4y ago

No. “Multiserver” (a term from the microkernel literature) means that the conventional basic OS services are split into several “server” processes with distinct responsibilities (a mounted filesystem, a network card, perhaps a hardware bus, etc.). This is the original conception of a microkernel- (as opposed to e.g. an exokernel-) style system and its architectural promise, although it’s not made necessary by the mere fact of being built on top of a microkernel: AFAIK L4Linux is a single server so the L4 microkernel basically acts as a simple VMM / HAL without further architectural benefits. (For other monolithic but userspace OS servers, look at wineserver in Linux, CSRSS and LXSS in Windows NT, etc. For multiserver systems of varying purity, look at QNX and Minix.) What you’re thinking of is a “distributed OS”, although those academic efforts look terribly naïve from today’s distributed consensus standpoint. Good points of entry may be Barrelfish and Plan 9.

als0 4y ago
Amoeba is a famous example of a distributed OS https://en.wikipedia.org/wiki/Amoeba_(operating_system) https://en.wikipedia.org/wiki/Amoeba_(operating_system)
- api 4y ago
  It’s too bad this research didn’t continue. Instead we got a giant tower of kludges including containers, Kubernetes, service meshes, endless API design problems, endless reinventing of data serialization and protocols, and so on.
  - deleted 4y ago
    [deleted]
  - johnisgood 4y ago
    Or something like https://en.wikipedia.org/wiki/Sprite_(operating_system) https://en.wikipedia.org/wiki/Sprite_(operating_system) but with a microkernel!
  - mananaysiempre 4y ago