4 ms·

SELinux was released in 1998. Linux was totally usable back then. I've been using it since 1995. I've never heard anyone claim lacking SMP support being a feat

by Canada 10y ago

SELinux was released in 1998. Linux was totally usable back then. I've been using it since 1995. I've never heard anyone claim lacking SMP support being a feature. In the case of OpenBSD it was just that nobody got around to it until much later. The project never had even close to the number of developers as Linux or FreeBSD. Back in the 90s OpenBSD focused on code audit and fixing bugs rather than adding features. I found it most useful as a firewall and nameserver because it came with ipf and they included BIND with chroot support built in. Installation was dead simple. As long as you stuck to well supported hardware, it just worked out of the box. Back then SMP meant you had multiple physical CPUs, and that wasn't generally necessary for systems dealing with 100mbit interfaces. If you needed to deal with a lot of traffic you had to get real routers because the PC wasn't great at handling tons of interrupts. In 2000 or 2001 the author of ipf decided to "clarify" his license, asserting that it could not be shipped with patches. OpenBSD deleted it from the tree and pf was born. They also forked SSH over licensing issues in 1999, but at the time there wasn't any great benefit to using it over the original version. Starting in the early 2000s OpenBSD added a lot of really useful networking tools. The carp and pfsync interfaces let you run redundant firewalls very easily. Support for syncing the dhcpd state was added. For managing wireless networks hostapd. For load balancing tasks relayd. VPN setup was simplified greatly with ipsecctl. They added privsep to OpenSSH. They created OpenNTPD in response to many ntpd vulnerabilities. They made buffer overflow protections the default. They reduced privileged programs left and right. And everything remained simple with accurate man pages. So SMP support was lacking? Not such a big deal in exchange for a system that just worked. The problem is when you need to run a big file server, database server, web server, etc. For such uses having good SMP helps. Having ZFS helps. Having packages for the boatload of dependencies your shiny new web framework requires is critical. And you want binary updates, which OpenBSD doesn't officially have.

i336_ 10y ago
I forgot to ask earlier: how much "worse" is OpenBSD's SMP implementation than Linux's/everyone else's? > SELinux was released in 1998. Linux was totally usable back then. I've been using it since 1995. Oh, okay then. Nice... > I've never heard anyone claim lacking SMP support being a feature. https://www.mirbsd.org/about.htm https://www.mirbsd.org/about.htm: > Controversial decisions are often made differently from OpenBSD; for instance, there won't be any support for SMP in MirOS. Not really sure how to interpret that ^ but it sounds like a deliberate stand to me, like it's a feature. I totally get there's some context there, but I'm not sure what exactly it is. > In the case of OpenBSD it was just that nobody got around to it until much later. Mmm. > The project never had even close to the number of developers as Linux or FreeBSD. I see. I (genuinely) wonder why. > Back in the 90s OpenBSD focused on code audit and fixing bugs rather than adding features. I found it most useful as a firewall and nameserver because it came with ipf and they included BIND with chroot support built in. Interesting. > Installation was dead simple. As long as you stuck to well supported hardware, it just worked out of the box. Ha :P How good was hardware support? > Back then SMP meant you had multiple physical CPUs, and that wasn't generally necessary for systems dealing with 100mbit interfaces. Right. That makes sense. > If you needed to deal with a lot of traffic you had to get real routers because the PC wasn't great at handling tons of interrupts. TIL, so that's why... I'm curious where I can learn more about interrupts (and the latest developments there), incidentally - I have far too little knowledge about hardware than I would like. > In 2000 or 2001 the author of ipf decided to "clarify" his license, asserting that it could not be shipped with patches. OpenBSD deleted it from the tree and pf was born. * Shakes head * > They also forked SSH over licensing issues in 1999, but at the time there wasn't any great benefit to using it over the original version. How'd they manage to fork it? Was the old license fork-compatible? > Starting in the early 2000s OpenBSD added a lot of really useful networking tools. The carp and pfsync interfaces let you run redundant firewalls very easily. Support for syncing the dhcpd state was added. For managing wireless networks hostapd. For load balancing tasks relayd. VPN setup was simplified greatly with ipsecctl. I see, I get the impression they want to make an awesome router that's resilient to attack. And then I look at the fact that OpenBSD is the only BSD advertising working hibernation support... and I get really confused about what, exactly, OpenBSD is trying to do/be :P > They added privsep to OpenSSH. They created OpenNTPD in response to many ntpd vulnerabilities. They made buffer overflow protections the default. They reduced privileged programs left and right. And everything remained simple with accurate man pages. Nice. Especially the manpages thing... > So SMP support was lacking? Not such a big deal in exchange for a system that just worked. Mmm. > The problem is when you need to run a big file server, database server, web server, etc. For such uses having good SMP helps. Having ZFS helps. Yep. > Having packages for the boatload of dependencies your shiny new web framework requires is critical. Yep :( > And you want binary updates, which OpenBSD doesn't officially have. ...I can't say I like juggling source-level updates (never found Gentoo appetizing, at least), especially in a virtualized environment.
- Canada 10y ago
  "MirOS BSD is a secure operating system from the BSD family for 32-bit i386 and sparc systems" OpenBSD dropped 32-bit sparc support. And 32-bit Intel CPU support only? MirOS isn't interested in supporting any modern hardware. So yeah, why bother with SMP... OpenBSD's hardware support back then wasn't bad. It's just that you'd definitely want to check that what you were buying was supported before you bought it rather than just assume everything's going to work. The OpenSSH fork was based off the last BSD licensed release of SSH. SSH authors decided to adopt a more restrictive license. Within 5 years 90% of internet facing SSH servers were running OpenSSH. The deal with OpenBSD is that it's great if you do the same things as their developers. If not then you're out of luck. Apparently they like building networks and closing the lids of their laptops. Regarding different operating systems SMP support and your question of interrupt handling, you should consult OS architecture books. In a nutshell for SMP: How well the kernel's scheduler can make userland processes and threads run concurrently on different CPUs or cores is a big deal. This isn't easy, because you have situations where certain cores may share cache and others don't. How well the kernel can run itself concurrently is also a big deal. If the kernel can only run on a single core at once then even if user processes can run on different cores there will be contention when they make system calls. For the kernel to be reading data from a network card, while writing data to a filesystem, while comparing a packet against the firewall ruleset, while executing the scheduler, while allocating memory to some process, all at the same time on different cores requires fine grained locking. (Or possibly lock free data structures where possible) With only a single CPU the kernel can just assume its memory is consistent. Once the kernel is running concurrently great care must be taken to prevent accidental corruption. Mistakes result in deadlock, kernel panic, or worse. Linux, FreeBSD, Windows, and Solaris for example, have all solved this problem much better than OpenBSD has for a long time. OpenBSD has only begun to address this quite recently. In a nutshell for interrupt handling: Say you're routing frames between several Ethernet interfaces. Nevermind a proper firewall which would be much worse, you're just bridging like a switch. When a frame comes in on a port you get an interrupt and context switch into the kernel. Then you have to read at least the destination address into main memory so you can compare it to your MAC table and know how to handle it. Then you need to copy the whole frame to the appropriate outputs. This is very slow compared to the CAM table lookup that dedicated switch hardware uses. Even though a general purpose CPU can do some really impressive things, if you add enough network interfaces and a high enough packet rate to a PC it won't keep up.

by Canada 10y ago

i336_ 10y ago

I forgot to ask earlier: how much "worse" is OpenBSD's SMP implementation than Linux's/everyone else's? > SELinux was released in 1998. Linux was totally usable back then. I've been using it since 1995. Oh, okay then. Nice... > I've never heard anyone claim lacking SMP support being a feature. https://www.mirbsd.org/about.htm https://www.mirbsd.org/about.htm: > Controversial decisions are often made differently from OpenBSD; for instance, there won't be any support for SMP in MirOS. Not really sure how to interpret that ^ but it sounds like a deliberate stand to me, like it's a feature. I totally get there's some context there, but I'm not sure what exactly it is. > In the case of OpenBSD it was just that nobody got around to it until much later. Mmm. > The project never had even close to the number of developers as Linux or FreeBSD. I see. I (genuinely) wonder why. > Back in the 90s OpenBSD focused on code audit and fixing bugs rather than adding features. I found it most useful as a firewall and nameserver because it came with ipf and they included BIND with chroot support built in. Interesting. > Installation was dead simple. As long as you stuck to well supported hardware, it just worked out of the box. Ha :P How good was hardware support? > Back then SMP meant you had multiple physical CPUs, and that wasn't generally necessary for systems dealing with 100mbit interfaces. Right. That makes sense. > If you needed to deal with a lot of traffic you had to get real routers because the PC wasn't great at handling tons of interrupts. TIL, so that's why... I'm curious where I can learn more about interrupts (and the latest developments there), incidentally - I have far too little knowledge about hardware than I would like. > In 2000 or 2001 the author of ipf decided to "clarify" his license, asserting that it could not be shipped with patches. OpenBSD deleted it from the tree and pf was born. * Shakes head * > They also forked SSH over licensing issues in 1999, but at the time there wasn't any great benefit to using it over the original version. How'd they manage to fork it? Was the old license fork-compatible? > Starting in the early 2000s OpenBSD added a lot of really useful networking tools. The carp and pfsync interfaces let you run redundant firewalls very easily. Support for syncing the dhcpd state was added. For managing wireless networks hostapd. For load balancing tasks relayd. VPN setup was simplified greatly with ipsecctl. I see, I get the impression they want to make an awesome router that's resilient to attack. And then I look at the fact that OpenBSD is the only BSD advertising working hibernation support... and I get really confused about what, exactly, OpenBSD is trying to do/be :P > They added privsep to OpenSSH. They created OpenNTPD in response to many ntpd vulnerabilities. They made buffer overflow protections the default. They reduced privileged programs left and right. And everything remained simple with accurate man pages. Nice. Especially the manpages thing... > So SMP support was lacking? Not such a big deal in exchange for a system that just worked. Mmm. > The problem is when you need to run a big file server, database server, web server, etc. For such uses having good SMP helps. Having ZFS helps. Yep. > Having packages for the boatload of dependencies your shiny new web framework requires is critical. Yep :( > And you want binary updates, which OpenBSD doesn't officially have. ...I can't say I like juggling source-level updates (never found Gentoo appetizing, at least), especially in a virtualized environment.

Canada 10y ago
"MirOS BSD is a secure operating system from the BSD family for 32-bit i386 and sparc systems" OpenBSD dropped 32-bit sparc support. And 32-bit Intel CPU support only? MirOS isn't interested in supporting any modern hardware. So yeah, why bother with SMP... OpenBSD's hardware support back then wasn't bad. It's just that you'd definitely want to check that what you were buying was supported before you bought it rather than just assume everything's going to work. The OpenSSH fork was based off the last BSD licensed release of SSH. SSH authors decided to adopt a more restrictive license. Within 5 years 90% of internet facing SSH servers were running OpenSSH. The deal with OpenBSD is that it's great if you do the same things as their developers. If not then you're out of luck. Apparently they like building networks and closing the lids of their laptops. Regarding different operating systems SMP support and your question of interrupt handling, you should consult OS architecture books. In a nutshell for SMP: How well the kernel's scheduler can make userland processes and threads run concurrently on different CPUs or cores is a big deal. This isn't easy, because you have situations where certain cores may share cache and others don't. How well the kernel can run itself concurrently is also a big deal. If the kernel can only run on a single core at once then even if user processes can run on different cores there will be contention when they make system calls. For the kernel to be reading data from a network card, while writing data to a filesystem, while comparing a packet against the firewall ruleset, while executing the scheduler, while allocating memory to some process, all at the same time on different cores requires fine grained locking. (Or possibly lock free data structures where possible) With only a single CPU the kernel can just assume its memory is consistent. Once the kernel is running concurrently great care must be taken to prevent accidental corruption. Mistakes result in deadlock, kernel panic, or worse. Linux, FreeBSD, Windows, and Solaris for example, have all solved this problem much better than OpenBSD has for a long time. OpenBSD has only begun to address this quite recently. In a nutshell for interrupt handling: Say you're routing frames between several Ethernet interfaces. Nevermind a proper firewall which would be much worse, you're just bridging like a switch. When a frame comes in on a port you get an interrupt and context switch into the kernel. Then you have to read at least the destination address into main memory so you can compare it to your MAC table and know how to handle it. Then you need to copy the whole frame to the appropriate outputs. This is very slow compared to the CAM table lookup that dedicated switch hardware uses. Even though a general purpose CPU can do some really impressive things, if you add enough network interfaces and a high enough packet rate to a PC it won't keep up.