4 ms·

Hurd is a microkernel so it is lean by design. I suspect that statement was a dig on perceived architectural flaw of Linux.

by _8j50 3y ago

taeric 3y ago
I get that. But it is still an unfair dig when a large chunk of the code that is being pointed at is the code that they will have to write? (Granted, they can put an easier line in the sand on how far back they go on what they support hardware wise, but still...)
- pengaru 3y ago
  It's not about the code existing, it's about the code being an integral part of a monolithic architecture vs. "servers" facilitating a microkernel design like hurd/mach.
  - taeric 3y ago
    But that is silly? If I have to audit the code for my system running, I would have to audit the code for each of the "servers" as well? If not, why not? To that end, how different is it, actually? And what are the other tradeoffs?
    - pengaru 3y ago
      The servers are run in isolated address spaces like processes, taking advantage of MMU protection for more of the low-level facilities. Ask yourself why it's safer to use FUSE filesystems on Linux when mounting untrusted block devices/image files than the in-kernel filesystem drivers and maybe it'll become clear why this is advantageous. Or if you're familiar with containers and why that's a good thing, you can think of it as containerizing the kernel's subsystems/drivers.
      - taeric 3y ago
        This... didn't answer my question? For many that are concerned with containers and such, they also have to audit the container process code. Such that, fine, try to use that to inflate the numbers on Linux. Pointing at literally decades of device drivers as why the size of the code is bad, while acknowledging that it will take time to write device drivers so this will work on a respectable amount of hardware just feels weird. That all said, please don't take this as a criticism of any of these ideas. I confess seeing Hurd in the headlines gave me a smile. Is nice to see people can still work on many ideas out there. I am only questioning the "size of code bad!" right next to "it will take us a long time to replicate a large portion of the code we just pointed at."
    - tlb 3y ago
      That's the big unknown question with microkernels. It was (in the 90s) a reasonable theory that a microkernel could be much more robust and secure and easy to develop than a monolithic kernel. It would be more robust because individual services could crash and restart. That could really work for, say, WiFi drivers. It doesn't quite work for disk drivers or the file system, since how do you even restart something without a file system? It would be more secure because drivers would live in isolated memory spaces. So a non-critical piece like a printer driver couldn't read memory from something more critical like a file system. Part of what changed since microkernels were originally proposed is that drivers are often split into low- and high-level parts. So a printer driver in Linux consists of a standard USB or network driver in the kernel, plus a user-level driver that can be worked on like a microservice. And the WiFi driver is a low-level driver plus wpa_supplicant running at user level. The USB and network drivers are shared with critical services, so you can't easily restart them anyway. It would be easier to develop because you can restart just the piece you're working on without rebooting the whole kernel. That's a plausible argument, but somewhat undermined by HURD taking 30 years to develop. But there were many other reasons for that. I guess the way to convince yourself one way or another is to try writing a driver for both.
      - taeric 3y ago
        Right, I remember parts of that history. Memory protection schemes in other operating systems didn't exactly stay static, though. And a ton of the optimizations that monolithic kernels (mostly looking at windows) did went away just with the lack of need for them. Heck, at the time, Mac wasn't even a preemptive multitasking operating system. And "drivers" could just restart is laughable with a role play of it. Ok, your wifi driver restarted. What are the protocols to get everyone caught up between that driver and your application for what messages were lost and the messages that are now arriving? This is effectively no different from any distributed application where similar things are unsurprisingly hard to achieve well. I'll state that I think this is a laudable goal. And I'm happy to see people working on it. Would be thrilled to be shown I'm wrong.
        rcxdude 3y ago
        It can be done though: see what Windows has managed to do with graphics drivers. I've experienced a full crash of the graphics driver and windows just restarted it and kept on trucking, the only casualty being the 3D application which presumably triggered the crash. It's not just a matter of sprinkling the microkernel architecture on your system, but something like that is a prerequisite.
- strbean 3y ago
  Code that will have to be written, but won't be part of the kernel. I think that's on the cusp of fair/unfair.
  - taeric 3y ago
    I agree it is defensible. But, it is code that has to run for me to use my computer. I'm not clear that I have reason to care about the kernel distinction, at this level. Would help the defense to lean in and show legit and not theoretical examples of it.
    - deleted 3y ago
      [deleted]

Hurd is a microkernel so it is lean by design. I suspect that statement was a dig on perceived architectural flaw of Linux.

by _8j50 3y ago

Hurd is a microkernel so it is lean by design. I suspect that statement was a dig on perceived architectural flaw of Linux.

taeric 3y ago

I get that. But it is still an unfair dig when a large chunk of the code that is being pointed at is the code that they will have to write? (Granted, they can put an easier line in the sand on how far back they go on what they support hardware wise, but still...)

pengaru 3y ago
It's not about the code existing, it's about the code being an integral part of a monolithic architecture vs. "servers" facilitating a microkernel design like hurd/mach.
- taeric 3y ago
  But that is silly? If I have to audit the code for my system running, I would have to audit the code for each of the "servers" as well? If not, why not? To that end, how different is it, actually? And what are the other tradeoffs?
  - pengaru 3y ago
    The servers are run in isolated address spaces like processes, taking advantage of MMU protection for more of the low-level facilities. Ask yourself why it's safer to use FUSE filesystems on Linux when mounting untrusted block devices/image files than the in-kernel filesystem drivers and maybe it'll become clear why this is advantageous. Or if you're familiar with containers and why that's a good thing, you can think of it as containerizing the kernel's subsystems/drivers.
    - taeric 3y ago
      This... didn't answer my question? For many that are concerned with containers and such, they also have to audit the container process code. Such that, fine, try to use that to inflate the numbers on Linux. Pointing at literally decades of device drivers as why the size of the code is bad, while acknowledging that it will take time to write device drivers so this will work on a respectable amount of hardware just feels weird. That all said, please don't take this as a criticism of any of these ideas. I confess seeing Hurd in the headlines gave me a smile. Is nice to see people can still work on many ideas out there. I am only questioning the "size of code bad!" right next to "it will take us a long time to replicate a large portion of the code we just pointed at."
  - tlb 3y ago
    That's the big unknown question with microkernels. It was (in the 90s) a reasonable theory that a microkernel could be much more robust and secure and easy to develop than a monolithic kernel. It would be more robust because individual services could crash and restart. That could really work for, say, WiFi drivers. It doesn't quite work for disk drivers or the file system, since how do you even restart something without a file system? It would be more secure because drivers would live in isolated memory spaces. So a non-critical piece like a printer driver couldn't read memory from something more critical like a file system. Part of what changed since microkernels were originally proposed is that drivers are often split into low- and high-level parts. So a printer driver in Linux consists of a standard USB or network driver in the kernel, plus a user-level driver that can be worked on like a microservice. And the WiFi driver is a low-level driver plus wpa_supplicant running at user level. The USB and network drivers are shared with critical services, so you can't easily restart them anyway. It would be easier to develop because you can restart just the piece you're working on without rebooting the whole kernel. That's a plausible argument, but somewhat undermined by HURD taking 30 years to develop. But there were many other reasons for that. I guess the way to convince yourself one way or another is to try writing a driver for both.
    - taeric 3y ago
      Right, I remember parts of that history. Memory protection schemes in other operating systems didn't exactly stay static, though. And a ton of the optimizations that monolithic kernels (mostly looking at windows) did went away just with the lack of need for them. Heck, at the time, Mac wasn't even a preemptive multitasking operating system. And "drivers" could just restart is laughable with a role play of it. Ok, your wifi driver restarted. What are the protocols to get everyone caught up between that driver and your application for what messages were lost and the messages that are now arriving? This is effectively no different from any distributed application where similar things are unsurprisingly hard to achieve well. I'll state that I think this is a laudable goal. And I'm happy to see people working on it. Would be thrilled to be shown I'm wrong.
      - rcxdude 3y ago
        It can be done though: see what Windows has managed to do with graphics drivers. I've experienced a full crash of the graphics driver and windows just restarted it and kept on trucking, the only casualty being the 3D application which presumably triggered the crash. It's not just a matter of sprinkling the microkernel architecture on your system, but something like that is a prerequisite.
strbean 3y ago
Code that will have to be written, but won't be part of the kernel. I think that's on the cusp of fair/unfair.
- taeric 3y ago
  I agree it is defensible. But, it is code that has to run for me to use my computer. I'm not clear that I have reason to care about the kernel distinction, at this level. Would help the defense to lean in and show legit and not theoretical examples of it.
  - deleted 3y ago
    [deleted]