Up-voting because the original thread and the linked rebuttal are interesting reads.
What it comes down to is that the OpenBSD developers believe that re-implementing a user-land network stack is silly because of the risk it introduces, and the rebuttal says that is woefully outdated thinking because of the high demand for specialized and dedicated user-land networking. Given OpenBSD’s philosophy and valid point about maintenance costs, I think the rebuttal is unfair. If netmap is critical for some specialized application, couldn’t one go use it on FreeBSD? Expecting distros to have the same philosophies about user- vs kernel-space, generality vs specialization, etc defeats the purpose of having multiple distros to begin with.
I feel like I’m missing some context which would require a two year old email to require a rebuttal. I’m not even saying he’s wrong, but it’s weird to dig up an old email like this. And for record, one shouldn’t extrapolate from one developer (even Henning) to the whole project
In this particular case, my guess is that he was wondering whether OpenBSD supports or has plans to support Netmap, so googled for netmap openbsd, which this thread comes up as the #1 hit for. So in a sense, Google is telling people: “if you want to know why OpenBSD doesn’t support Netmap, read this thread!”. Which may or may not be good advice, but is the best advice Google has at the moment.
If you don’t need multiple users or even multiple applications, why would you be running a multiuser kernel? These single-application appliances sound like a perfect use case for unikernels, which would have all the performance advantages outlined here, better security than even OpenBSD, and wouldn’t require messing with OpenBSD code.
sound like a perfect use case for unikernels, which would have all the performance advantages outlined here, better security than even OpenBSD, and wouldn’t require messing with OpenBSD code
That is a premature claim to make. There is not sufficient evidence to claim a unikernel (which one??) would have better security than an operating system such as OpenBSD.
Or any operating system at all. Indeed, there’s good reason to think they’re less secure because the entire point is to bypass layers of hardware-enforced security.
I am in the process of writing a special-purpose network stack that runs on bare hardware; no OS at all. It’s remarkable how little code it takes when you don’t have to worry about coordinating between userspace and kernel space, between separate processes, between multiple use cases for the same software. Trying to write the same kind of software for a much faster processor, but in the context of an OS, was so much harder and wasted so much time just doing context switches.
Now, this thing I work on is much simpler than even the simple examples given, but for highly specialized software with tough performance requirements, I really don’t think you get much benefit at all from a Unix-style OS. Isolation between processes is meaningless when there’s only one process, or when “processes” are just cooperatively-scheduled subroutines with their own working memory. There are plenty of things that Unix is great for, but I am very happy to see wider acceptance of using other OS architectures or library-OS “unikernel” applications when they make sense.
What a masterful troll.
Up-voting because the original thread and the linked rebuttal are interesting reads.
What it comes down to is that the OpenBSD developers believe that re-implementing a user-land network stack is silly because of the risk it introduces, and the rebuttal says that is woefully outdated thinking because of the high demand for specialized and dedicated user-land networking. Given OpenBSD’s philosophy and valid point about maintenance costs, I think the rebuttal is unfair. If netmap is critical for some specialized application, couldn’t one go use it on FreeBSD? Expecting distros to have the same philosophies about user- vs kernel-space, generality vs specialization, etc defeats the purpose of having multiple distros to begin with.
I feel like I’m missing some context which would require a two year old email to require a rebuttal. I’m not even saying he’s wrong, but it’s weird to dig up an old email like this. And for record, one shouldn’t extrapolate from one developer (even Henning) to the whole project
In this particular case, my guess is that he was wondering whether OpenBSD supports or has plans to support Netmap, so googled for netmap openbsd, which this thread comes up as the #1 hit for. So in a sense, Google is telling people: “if you want to know why OpenBSD doesn’t support Netmap, read this thread!”. Which may or may not be good advice, but is the best advice Google has at the moment.
Since it’s Google we’re talking about, “it’s the best advice Google has, at the moment, for you.” There’s potentially a lot of bias in there…
If you don’t need multiple users or even multiple applications, why would you be running a multiuser kernel? These single-application appliances sound like a perfect use case for unikernels, which would have all the performance advantages outlined here, better security than even OpenBSD, and wouldn’t require messing with OpenBSD code.
That is a premature claim to make. There is not sufficient evidence to claim a unikernel (which one??) would have better security than an operating system such as OpenBSD.
Or any operating system at all. Indeed, there’s good reason to think they’re less secure because the entire point is to bypass layers of hardware-enforced security.
I am in the process of writing a special-purpose network stack that runs on bare hardware; no OS at all. It’s remarkable how little code it takes when you don’t have to worry about coordinating between userspace and kernel space, between separate processes, between multiple use cases for the same software. Trying to write the same kind of software for a much faster processor, but in the context of an OS, was so much harder and wasted so much time just doing context switches.
Now, this thing I work on is much simpler than even the simple examples given, but for highly specialized software with tough performance requirements, I really don’t think you get much benefit at all from a Unix-style OS. Isolation between processes is meaningless when there’s only one process, or when “processes” are just cooperatively-scheduled subroutines with their own working memory. There are plenty of things that Unix is great for, but I am very happy to see wider acceptance of using other OS architectures or library-OS “unikernel” applications when they make sense.