3 ms·
"Quality" is a very subjective idea. Yes, docs are easy to keep consistent over long stretches of time if the speed of evolution is slow and a small number of l
by _wmd 8y ago
"Quality" is a very subjective idea. Yes, docs are easy to keep consistent over long stretches of time if the speed of evolution is slow and a small number of like-minded assiduous gatekeepers can vet every change from a small number of contributors, but since the speed of evolution is slow, OpenBSD for example still has a giant lock protecting most of the kernel -- this despite nearly 2 decades of multicore chips shipping pretty much everywhere.
Any growing project will always suffer from consistency problems -- humans just aren't capable of scaling to the point where a single hierarchy can consistently manage a monstrously large system. Linux doesn't have a 'base system' quite like OpenBSD: coreutils, libc, bash, and 20 other similar packages all come from a large variety of differently minded maintainers across the world.
Viewed from a macro scale, OpenBSD's consistency breaks down immediately upon starting to install stuff from the ports collection - sure the base system makes a great firewall and basic HTTP server, but to use anything popular you pretty much immediately end up with ports. And the quality standards there are identical to Linux land, because it's the same code.
- aquabeagle 8y agoFrom the release notes: sendmsg(2), sendto(2), recvfrom(2) and recvmsg(2) are run without KERNEL_LOCK. The lock is being removed, slowly with care, piece by piece.
- mrpippy 8y agoAlso, I think FreeBSD eliminated the giant lock ~10 years ago and maintains similarly good documentation. It’s just a matter of priorities, and SMP scalability/high performance has never been on the top of the OpenBSD list.
- IcePic 8y agoI thinks its a greyscale and have always been. Silly things like floppy (that noone uses) on fbsd used to attach with [GIANT LOCKED] for the longest time (if not still) but it doesn't matter. You would not call fbsd still under GL just because 1.44MB floppy drivers don't get any attention. So its not a binary on-or-off on any OS, its a process of unlocking one part at a time, out of hundreds, thousands of small subsystems and drivers without causing races. OpenBSD is most certainly behind, but there is no nice line over which you can say "Ah, now its not GL anymore", since there will be some part somewhere for some arch where you don't care that still retains the lock, and there were parts from day #1 that was completely unlocked on obsd like the syscall getpid() in all its triviality and race-free-ness.
- kbenson 8y ago> It’s just a matter of priorities Yes, and goals. OpenBSD is much more conservative with regard to features, and focuses on security, and that results in a more secure system overall. If you need to eek out every last percent of performance, use something else. If you want to worry less about security on a system that is fairly exposed (e.g. a firewall), then it can be an extremely good fit. For example, here's a comparison of security advisories for the main OpenBSD, FreeBSD and Linux projects (that is, not separated and exported items like OpenSSH).[1][2] While I'm sure these lists have their problems, they are interesting. Specifically, the number of exploits column... 1: https://www.cvedetails.com/product/7/Freebsd-Freebsd.html?vendor_id=6 https://www.cvedetails.com/product/7/Freebsd-Freebsd.html?ve... 2: https://www.cvedetails.com/product/163/Openbsd-Openbsd.html?vendor_id=97 https://www.cvedetails.com/product/163/Openbsd-Openbsd.html?... 3: https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
- SahAssar 8y agoOn the other hand some of this can be explained by linux being a higher value target with more security research around it. If I find a remote exploit in the linux kernel I have a few billion targets, but if I find one in a *BSD I probably have a few million, tops.