3 ms·

>> And so now we have 70's era tech instead of 90's. That being said, I would really like to know if Minix tech is better than Linux. I have heard the whole m

by psibi 12y ago

>> And so now we have 70's era tech instead of 90's. That being said, I would really like to know if Minix tech is better than Linux. I have heard the whole microkernel/monolithic kernel debate. But to this day, Linus admits that monolithic is a better design choice. And on the other hand, HURD is a microkernel which suffers from development and I have heard RMS saying somewhere that choosing microkernel was a bad decision.

jacquesm 12y ago
> That being said, I would really like to know if Minix tech is better than Linux. No, it isn't. > But to this day, Linus admits that monolithic is a better design choice. Well, that depends. Linus is somewhat invested in the monolithic side of things. If you see the world through a real-time lens and you think of computers as things that simply never get switched off until they are physically end-of-lifed, if reliability and latency are more important than raw throughput, if you want to be able to upgrade your OS without a reboot and so on then microkernels start to make a lot more sense. In the traditional sense, minix is more of a 'small unix' than a micro kernel, the kernel supports all kinds of primitives that you'd not see in other micro kernels. See: http://wiki.minix3.org/en/DevelopersGuide/KernelApi http://wiki.minix3.org/en/DevelopersGuide/KernelApi (For instance, the 'device io' calls are not what I'd expect in a true micro kernel, messaging primitives are not present). HURD is committeeware. L4, QnX and a bunch of closed source industrial systems are real, battle tested microkernels that I would put opposite UNIX/Linux/BSD for comparison, not minix, to me that always was a 'toy' operating system, which just like plan9 never really outgrew the lab.
- jude- 12y ago
  Out of curiosity, why shouldn't some level of device I/O be handled by the kernel? If the alternative is putting all device I/O responsibility in userspace processes, then wouldn't the kernel still need to do basic driver-related tasks like programming the IOMMU and DMA engine? Even if that's outsource-able to userspace, then wouldn't the kernel still need to run some sort of security-preserving outsourcing logic (e.g. only letting a trusted process access a hardware device)?
  - justincormack 12y ago
    Sure, minimal amount needed for safety should be in the kernel. That can also be somewhat federated if you like. Much of a kernel is not hardware access though, it is things like filesystems and sockets way on top of hardware.
    - imanaccount247 12y ago
      >Sure, minimal amount needed for safety should be in the kernel Which is exactly how it is. So the question remains, what's the problem?
- imanaccount247 12y ago
  Again, you are conflating minix and minix3. Minix3 was never in a lab to outgrow it. It is a new system, developed quite quickly and quite recently. And yes, it is significantly better than linux. Why do you think the device IO calls shouldn't be there? Messaging primitives are present, those calls use them. They are just wrapped in a library for you, like it says right on that page. The "kernel interface" is exposing a unix like API. If you want to send arbitrary messages then you use the low level messaging API. L4 is not a kernel, it is a family of kernels. You can't run L4 any more than you can run BSD. You have to pick an actual specific implementation. Some L4 kernels are "battle tested" and some are learning projects made by single individuals and never used for anything else.

by psibi 12y ago

jacquesm 12y ago

> That being said, I would really like to know if Minix tech is better than Linux. No, it isn't. > But to this day, Linus admits that monolithic is a better design choice. Well, that depends. Linus is somewhat invested in the monolithic side of things. If you see the world through a real-time lens and you think of computers as things that simply never get switched off until they are physically end-of-lifed, if reliability and latency are more important than raw throughput, if you want to be able to upgrade your OS without a reboot and so on then microkernels start to make a lot more sense. In the traditional sense, minix is more of a 'small unix' than a micro kernel, the kernel supports all kinds of primitives that you'd not see in other micro kernels. See: http://wiki.minix3.org/en/DevelopersGuide/KernelApi http://wiki.minix3.org/en/DevelopersGuide/KernelApi (For instance, the 'device io' calls are not what I'd expect in a true micro kernel, messaging primitives are not present). HURD is committeeware. L4, QnX and a bunch of closed source industrial systems are real, battle tested microkernels that I would put opposite UNIX/Linux/BSD for comparison, not minix, to me that always was a 'toy' operating system, which just like plan9 never really outgrew the lab.

jude- 12y ago
Out of curiosity, why shouldn't some level of device I/O be handled by the kernel? If the alternative is putting all device I/O responsibility in userspace processes, then wouldn't the kernel still need to do basic driver-related tasks like programming the IOMMU and DMA engine? Even if that's outsource-able to userspace, then wouldn't the kernel still need to run some sort of security-preserving outsourcing logic (e.g. only letting a trusted process access a hardware device)?
- justincormack 12y ago
  Sure, minimal amount needed for safety should be in the kernel. That can also be somewhat federated if you like. Much of a kernel is not hardware access though, it is things like filesystems and sockets way on top of hardware.
  - imanaccount247 12y ago
    >Sure, minimal amount needed for safety should be in the kernel Which is exactly how it is. So the question remains, what's the problem?
imanaccount247 12y ago
Again, you are conflating minix and minix3. Minix3 was never in a lab to outgrow it. It is a new system, developed quite quickly and quite recently. And yes, it is significantly better than linux. Why do you think the device IO calls shouldn't be there? Messaging primitives are present, those calls use them. They are just wrapped in a library for you, like it says right on that page. The "kernel interface" is exposing a unix like API. If you want to send arbitrary messages then you use the low level messaging API. L4 is not a kernel, it is a family of kernels. You can't run L4 any more than you can run BSD. You have to pick an actual specific implementation. Some L4 kernels are "battle tested" and some are learning projects made by single individuals and never used for anything else.