I built my last company on OpenBSD. It was easy to understand the entire system, and secure-by-default (everything disabled) is the right posture for servers. Pledge and unveil worked brilliantly to restrict our Go processes to specific syscall sets and files. The firewall on OpenBSD is miles better to configure than iptables. I never had challenges upgrading them--they just kept working for years.
It's barely usable by itself but I don't think it's an inherent problem of
seccomp-bpf, rather the lack of libc support. Surely the task of "determine
which syscalls are used for feature X" belongs in the software that decides which
syscalls to use for feature X.
The "what does the equivalent of pledge(stdio) actually mean?" doesn't have to actually be on the kernel side. But it's complicated by the fact that on Linux, syscalls can be made from anywhere. On OpenBSD syscalls are now only allowed from libc code.
So even if one uses Cosmopolitan libc, if you link to some other library that library may also do direct syscalls. And which syscalls is does, and under which circumstances, is generally not part of the ABI promise. So this can still break between semver patch version upgrades.
Like if a library used to just not write debug logs by default, but then changed so that they are written, but to /dev/null, then there's no way to inform application code for that library, much less update it.
If you ONLY link to libc, then what you said will work. But if you link to anything else (including using LD_PRELOAD), then all bets are off. And at the very least you'll also be linking to libseccomp. :-)
If libc were the only library in existence, then I'd agree with your 100%.
> So even if one uses Cosmopolitan libc, if you link to some other library
that library may also do direct syscalls. And which syscalls is does, and
under which circumstances, is generally not part of the ABI promise. So this
can still break between semver patch version upgrades.
Well but isn't that a more general problem with pledge? I can link to
libfoo, drop rpath privileges, and it'll work fine until libfoo starts
lazily loading /etc/fooconf (etc.)
A nice thing about pledge is that it's modularized well enough so such
problems don't occur very often, but I'd argue it's not less common of an
issue than "libfoo started doing raw syscalls." The solution is also the
same: a) ask libfoo not to do it, or b) isolate libfoo in an auxiliary
process, or c) switch to libbar.
> And at the very least you'll also be linking to libseccomp. :-)
libseccomp proponents won't tell you this, but you can in fact use seccomp
without libseccomp, as does Cosmopolitan libc. All libseccomp does is
abstract away CPU architecture differences, which a libc already has to do
by itself anyway.
No, for two reasons: 1) pledge() lets you give high level "I just want to do I/O on what I already have", and it doesn't matter if new syscalls "openat2" (should be blocked) or "getrandom" (should be allowed) are created. (see the `newfstatat` example on printf). And 2) OpenBSD limits syscalls to be done from libc, and libc & kernel are released together. Other libs need to go through libc.
Yes, if libfoo starts doing actual behavioral changes like suddenly opening files, then that's inherently indistinguishable from a compromised process. But I don't think that we need to throw out the baby with that bathwater.
And it's not just about libfoo doing raw syscalls. `unveil()` allows blocking off the filesystem. And it'll apply to open, creat, openat, openat2, unlink, io_uring versions of the relevant calls (if OpenBSD had it), etc…
But yes, if libc could ship its best-effort pledge()/unveil(), that also blocks any further syscalls (in case the kernel is newer), that'd be great. But this needs to be part of (g)libc.
Though another problem is that it doesn't help child processes with a statically compiled newer libc, that quite reasonably wants to use the newer syscalls that the kernel has. OpenBSD decided to simply not support statically linked libc, but musl (and Cosmopolitan libc?) have that as an explicit goal.
So yeah, because they mandate syscalls from libc, ironically OpenBSD should have been able to make pledge/unveil a libc feature using a seccomp-like API, or hell, implemented entirely in user space. But Linux, which has that API, kinda can't.
(ok, so I don't know how strictly OpenBSD mandates the exact system libc, so maybe what I just said would open a vulnerability)
> 1) pledge() lets you give high level "I just want to do I/O on what I
already have", and it doesn't matter if new syscalls "openat2" (should be
blocked) or "getrandom" (should be allowed) are created. (see the
`newfstatat` example on printf).
You can do this with seccomp if you're libc. A new syscall is of no
consequence for the seccomp filter unless libc starts using it, in which
case libc can just add it to the filter. (Of course the filter has to be an
allow-list.)
> And 2) OpenBSD limits syscalls to be done from libc, and libc & kernel are
released together. Other libs need to go through libc.
That avoids one failure mode, but I think you assign too much importance to
it. If your dependency uses a raw syscall (and let's be honest this isn't
that common), you'll see your program SIGSYS and add it manually.
If you have so many constantly changing dependencies that you can't
tell/test which ones use raw syscalls and when, you have no hope of
successfully using pledge either.
> But I don't think that we need to throw out the baby with that bathwater.
We agree here, just not on which baby :)
> And it's not just about libfoo doing raw syscalls. `unveil()` allows
blocking off the filesystem.
You're right, seccomp is unsuitable for implementing unveil because it can't
inspect contents of pointers. I believe Cosmopolitan uses Landlock for it.
> Though another problem is that it doesn't help child processes with a
statically compiled newer libc
If you're trying to pledge a program written by somebody else, expect
problems on OBSD too because pledge was not designed for that. (It can work
in many cases, but that's kind of incidental.)
If it's your own program, fine, but that means you're compiling your binaries
with different libcs and then wat.
> So yeah, because they mandate syscalls from libc, ironically OpenBSD
should have been able to make pledge/unveil a libc feature using a
seccomp-like API, or hell, implemented entirely in user space. But Linux,
which has that API, kinda can't.
My take is "it can, with caveats that don't matter in 99% the cases pledge
is useful in." (Entirely in user space no, with seccomp yes.)
But only in very small sandboxes, right? Yes, seccomp could potentially be used for your JIT/interpreter sandbox. And because it inherently executes untrusted input, that's definitely the most important place.
But compare how many applications execute untrusted remote programs to how many programs that have had security vulnerabilities. Or indeed, how much code.
What percentage of code runs in chrome/firefox's sandbox? 0.0001%?
Have you tried to create a seccomp ruleset for a real program? I have. There are too many variations between machines and code paths that you'll necessarily need to leave wide open doors through your policy. Sure, the more you disable the "luck" you manufacture in case of a bug, preventing exploitation. But no, it's not fit for purpose outside these extremely niche use cases.
Linux is far too bloated to ve run as a secure system and the attack surface of any linux distro, due to the number of kernel modules loaded by default, is very big.
> I built my last company on OpenBSD. It was easy to understand the entire system, and secure-by-default (everything disabled) is the right posture for servers.
That really depends. You could argue a router is a server. OpenWRT has the default of WiFi off for security, which means that if the config is somehow hosed and you have to hard reset the router, you now have an inaccessible brick unless you happen to have a USB-Ethernet adapter on you.
Sensible defaults are much, much better than the absolutionist approach of "disable everything".
Edit: it's so funny to know that all the people slamming the downvote have never hit the brick wall of a dumb default. I hope you stay blessed like that!
> Edit: it's so funny to know that all the people slamming the downvote have never hit the brick wall of a dumb default.
I'll bite. OpenBSD and OpenWRT are different things, and I'm honestly surprised to hear that tech matters enough to you to setup OpenWRT but not enough to own a desktop (or a laptop that doesn't skimp on ports)
They are, but Linux or BSD doesn't matter all that much when it is about the meta case of deciding the defaults.
Funnily enough I feel a BSD is much more suited to modems / routers, if it weren't for HW WiFi support. Yes, I know you can separate your routing and your access point onto different devices.
At any rate I'm just pointing out that that absolutionism is rarely the right answer. It's also pretty telling that people actually went through my comment history to downvote a few unrelated recent comments. People get angry when they have to adjust their assumptions.
As far as computing device goed, I prefer not lugging around a plastic brick. And one is bound to either lose or forget a dongle. In which case you get boned by OpenWRT's dumb default.
The reason for that default is that if they set up an open OpenWRT WiFi (or default passworded, think "OpenWRT2025"), in that split 5 minute window before you change it, some wardriver might login and mess with your network.
Obviously the chances of that are rather insignificant. And they could generate a default password based on the hardware. For the real security nuts they could tell them to build an image without default-on WiFi (currently they do the inverse).
I'm not comparing those, I'm comparing absolutionist vs. flexible attitude.
People are downvoting because I'm making them realize they have to rethink their assumptions, and it is less painful to attack the messenger rather than actually do so. People these days are generally bad at not tying their identity to things and not taking it personal.
Servers I setup in openbsd just keep working, and are an easy patch/upgrade process. Servers I setup in Ubuntu break and have weird patching issues. Maybe it's something I'm doing, but I sure do like that OpenBSD seems a lot easier to just have solid and work indefinitely.
Debian (provided you don't just dump a bunch of 3rd party repos) just upgrades cleanly, we have hundreds of servers that just run unattended-upgrade and get upgraded to new Debian version every 2 years.
I used to have this Debian box (which was a PowerMac G4) in my hallway. It had a 1000+ day uptime, back when this kind of uptime was still cool, or at least I thought it was. At some point it was two major versions behind, and I decided to dist-upgrade it. To my amazement, the upgrade went flawlessly, and the system booted without problems afterward. Debian is just great like that.
Not the Grand Poster, but we use the Debian package "unattended-upgrades" to install security updates automatically on our servers, and send an email if a reboot is required to complete the process (kernel upgrade).
Unattended upgrades could be configured to install more than the security release. Even with the stable release, one can add the official APT source for the Debian backports.
Back to OpenBSD... realize that it has no "unattended upgrades" capability. Until syspatch(8) appeared in 6.x you had to download patches and rebuild kernel and userland to get security fixes. Today, you could run syspatch(8) in a cron job but that only covers the base system. You'd need to handle any installed packages separately. And only the current and immediately previous release are supported at all. There are two releases a year, so you have to upgrade every ~6 months to stay in the support window.
Fortunately, with the introduction of the syspatch(8) and sysupgrade(8) utilities this is much simpler than it used to be. And, release numbers are just sequential with one point number, i.e. 7.0 was just the next release after 6.9, nothing more is implied by the "major" number ticking up.
Just curious, how do you manage service restarts, just restart as the update finishes?
I think I’m a bit scarred when a docker upgrade took my entire stack down because of an api mismatch with portainer, so I’m trying to be present during upgrades.
Edit: I’m talking about Debian of course. I’m not familiar with OpenBSD.
Debian still has security fixes, and point releases. unattended-upgrades is the package that automates their install.
I think you can also do unattended release upgrades by using the 'stable' release alias in sources. That will probably result in some stuff breaking since there will be package and configuration churn.
Well - I would recommend using a better linux distribution than Ubuntu.
I run just lighttpd these days; used to run httpd before they decided the configuration must become even more complicated. I don't have any issues
with lighttpd (admittedly only few people use it; most seem to now use nginx).
Ubuntu seems to have a trend of taking something that works under Debian and somehow messing that up. Upgrades are one thing but for a while we had separate instruction on how to make Yubikey tokens work under each version of Ubuntu (we used them as smartcards for SSH key auth), while Debian instructions stayed the same...
Update was also hit and miss on user's desktop machines, for a while ubuntu had a nasty habit of installing new kernel upgrades... without removing old ones, which eventually made boot run out of space and poor user usually had to give it to helpdesk to fix.
Tho tbh most of the problems in any distro with packages is "an user installed 3rd party repo that don't have well structured packages and it got messy".
I have used lighttpd in the past but have been using nginx largely because I got used to it because other people chose it.
Now in more of a position to pick for myself, and I wondered how you feel about the pros and cons of lighttpd? I remember quite liking its config at the time.
One of the reasons why I'm using OpenBSD is because it passes what I think of as a litmus test for FLOSS software: can I build the whole thing from scratch, in a short time and with minimal fuss? In the case of OpenBSD, the answer is yes. I can install it on a new machine, fetch the source code from mirrors, do some edits to the source, build a fresh release, write it to a USB stick and boot it on another machine. On my machine, the whole process takes about 10 minutes for the kernel, additional 20 minutes for base and maybe an hour if you add Xenocara. Compare that to Linux distros like Ubuntu or Arch where building from scratch is either discouraged or some fringe activity that requires skimming through wiki articles, forum posts or old Websites on the Wayback Machine.
Gentoo is a Linux rolling release built from source (just recently they gave the option of using binary packages as well). I've ran it on my desktop for years.
Does OpenBSD have Bootstrappable Builds from source without any binaries? I'm guessing not yet, since GNU Guix (Linux distro) pioneered that, and I haven't seen any BSD distro interested in the related Reproducible Builds project.
Long time OpenBSD fan. Used it as my daily driver for years before standardizing all computers at home to macOS. I still think about going back to openBSD one day, but it's no longer very practical as a daily driver.
I want to use OpenBSD for the next project I'm building. However, I can't wrap my head around the old way of doing deployments (before containers). People who've built production grade systems with OpenBSD:
1. How do you deploy software?
2. How do you manage fleets of servers?
3. How do you spin up/turn down servers from cloud providers? (I only know of Vultr who provided an OpenBSD option out of the box).
> Long time OpenBSD fan. Used it as my daily driver for years before standardizing all computers at home to macOS. I still think about going back to openBSD one day, but it's no longer very practical as a daily driver.
It's only practical for hobbyists. I used OpenBSD as a daily driver between 2001-2005. I fought, I suffered, I conquered, and I got tired of not being able to watch video on the web reliably and MacOS in those days was so clean and refreshing. I learned so much, though.
> I want to use OpenBSD for the next project I'm building.
I admire your open-mindedness. But ask yourself:
1. Do you want to have to upgrade fleets of servers every year with no exceptions for extended security support instead of 5 (or more if you're willing to pay) for LTS versions of Linux?
2. Who else will need to support it?
3. You will likely have worse performance if that matters.
> 1. How do you deploy software?
Honestly, not many people create their own services that run on OpenBSD. Those that do use old-school packaging and scripting. Tooling like ansible works.
> 2. How do you manage fleets of servers?
Ansible would be my go-to for classic fleets of servers.
> How do you spin up/turn down servers from cloud providers?
There are ports of cloud-init for OpenBSD. Creating images for third party OSes can be different levels of painful, depending on the cloud provider.
OpenBSD has virtualization out of the box now. Most of the benefit of containers you can get with chroot. I don't know if any of the developers are working on a true container/jail capability.
I'd like to see a more modern performant filesystem with OpenBSD but ffs has never really let me down. Capability for logical volumes and/or live resizing of partitions would be welcome as well.
I adore openbsd and have been using it since 4.x however it is still slow, not slow to boot or anything like that but if you run it as a web server it manages about half the req/s of Debian. Network performance is also slower than Debian if you're using it as a firewall (but I still prefer it as the syntax of PF is just perfect).
there's a lot of optimisations they don't engage with because it makes the code "ugly" but there's a larger one here, where they disable hyperthreading outright due to side-channel attacks.
It used to be faster than Linux for that, but that's been a while ago.
I moved some stuff away from OpenBSD when the release of Linux 2.4 implemented all missing firewall functionality - but kept others still due to the early issues with the 2.4 kernel. But by the time 2.5 was getting decent - roughly a year before the 2.6 release - in most cases just using Linux with a custom 2.5 kernel was the better option.
The post has many links to OpenBSD's man pages, FAQ and manual. But I thought it was quite unsatisfying, even common tasks are missing. Or at least I couldn't find them.
I had a test case in mind while reading the documentation: running a custom web service with Nginx as a reverse-proxy. In the documentation, I couldn't find anything about creating a service. Are we supposed to write a frontend script (in ksh) that accepts various arguments (ie start/reload/...)? And what about the logs of this wrapper? And if I want an auto-restart when my program crashes, I have to find another tool that will wrap and monitor the process? I've done all this tedious work in Linux long ago, and I'm not willing to do it again.
If the question was "Why OpenBSD instead of Linux", I don't think documentation is a good argument. In fact, the only strong response I've read is "to try something a bit different and more niche".
You do have to buy more powerful hardware than you otherwise would. I find it worth it to run code I can more easily understand. I agree on Debian as well. My router and laptop are OpenBSD but most vms on my proxmox are Debian.
Agreed. I run my OpenBSD firewall on my odroid h4 - it's relatively cheap and plenty powerful to route gigabit+. I prefer pf and the simplicity of OpenBSD over Debian for such a purpose-built application. For my other "home servers" I simply run Debian as I believe it to be one of the more sane Linux choices for a server-type application.
To be honest I don't really see a reason to use a *BSD system myself other than just for the sake of using something different and less mainstream. FreeBSD had some advantages in the past but nowadays Linux has caught up in features.
When I switched to FreeBSD, it was because of the quality of the documentation. In Linux manpages are a patchwork from various sources, and it shows; it's not rare for a manpage to be missing, obsolete, or to document another similar tool, or to be inacurrate... Much better than in many other OSes, but still nowhere as good as in FreeBSD.
Now that I think of it, when I switched from DOS to Linux it was already because I found manpages amazing. Maybe I've just a soft spot for documentation.
BSD license so you don't have to upstream your stuff would be one. Tho it's not an advantage to *BSD systems, Linux near-forcing vendors to go mainline (as keeping separate kernel tree is PITA) did a lot of good in hardware support.
Not really a problem for users. Only for people who want to redistribute a fork. It matters if you are Apple or Sony, but not for most people.
incidentally, the requirement of the GPL is not to upstream your stuff, but to offer to make the modified source available to anyone you distribute the code to. Often the same in practice, but does not have to be.
> To be honest I don't really see a reason to use a *BSD system myself
I use FreeBSD+ZFS for storage servers. I definitely want to use ZFS for these and I don't think Linux+ZFS is as good a combination.
It depends on what you want to do. If you want a typical laptop with a desktop environment, then FreeBSD might not be a good choice. Horses for courses.
I feel like DragonflyBSD is really cool if you want to look at some BSD that offers some advantages and something unique to your day-to-day desktop usage. And I feel like their community is not as toxic as that of FreeBSD and OpenBSD with their holier-than-thou attitude towards Linux.
I'd love it if Gentoo/BSD were a thing once again, I like the BSD concepts but there's nothing like Portage on BSD so far - afaik pkgsrc is nowhere close to it.
>To be honest I don't really see a reason to use a *BSD system myself
I see some reasons:
- the BSD license
- the system is composed of pieces written to work together, it is built from start up as a coherent operating system as opposed to things cobbled together like other UNIX-like OS-es do
I tried using OpenBSD, but the support for some specific things isn't very good. For example, J language support is always missing some packages. I also don't want to, and very much do not want to, use systemd. I finally chose FreeBSD, but I'm using some things from OpenBSD as much as possible, like obhttpd, etc. It feels good now.
I feel like people user it either due to fixation/hobby reasons, or because they've heard it's secure and good for routers so they just use it as a router, assuming the rumors are true.
Honestly myself, I prefer NetBSD approaches to many things, or for Linux Alpine, which is perfectly small, minimal and secure by default.
GP is referring to the LLM crawler captcha thing. The one with the anime girls in it. It only took a few seconds on my phone, but it's slow on my old ThinkPad.
It's not about keeping spam out of comments, it's about keeping systems and content safe/operational for normal people and more costly or unavailable for the trillion dollar "AI" companies that are shitting all over everything.
Don't blame this on site operators, this is the fault of careless LLM operators knocking down everybody's walls doors and windows to "learn" from their content.
I appreciate that OpenBSD sold its course on security-everywhere.
Unfortunately I also kind of lost faith in the BSD variants. There
are a few minor things such as PC-BSD suddenly vanishing, or years
before NetBSD on their mailing list admitting that Linux outperformed
their "runs on any toaster and other gimmick" strategy. But one of
the key issues I had was this:
I installed it (FreeBSD) on my second computer. I went out of my
apartment and returned hours later. Well, the FreeBSD machine was
no longer running; my linux machine on the other hand is running
non-stop for months, literally. This may be a fluke, perhaps the
computer had a problem - I am not saying this is really what the
BSDs are all about, as I also had them installed before. But then
I also asked myself "why would I want to bother with the BSDs,
if Linux simply runs better?". And I haven't found a good, convincing
answer to that for me to rationalise why I'd still be using the
BSDs. Note: I also use Linux in a non-standard way, e. g. versioned
AppDirs, but essentially Linux is simply more flexible than the BSDs
(that is my opinion) and there are more users too. There will be always
some BSD users, but to me they are like a dying breed. They would need
to market themselves as a "runs outside the nerd bubble as well"; even
Linux is still stuck in its own nerd bubble. You have to break out of
it if you want to really dominate (Linux semi-does it indirectly, e. g.
we can count many smartphones as Linux-driven, but I am still using a
desktop computer system here, so to me this is what really counts, even
if the total number is less than the smartphone users numbers).
What Linux has is mostly better hardware support and on gnome and some distributions they have a software installation tool that look like an app store but that's about it... Everything else is pretty much the same, random people wouldn't figure out a system is freebsd instead of Linux when running same desktop (like plasma).
Which is what makes Linux kernel stand out, as we can see by Sony and Apple contributions upstream.
Had BSD not been busy with AT&T lawsuit, all major UNIXes would probably still be around, consuming whatever was produced out of BSD like the networking code and OS IPC improvements over AT&T UNIX.
Instead sponsoring Linux kernel became the plan B, as means to reduce their UNIX development costs.
> Commercial use began when Dell and IBM, followed by Hewlett-Packard, started offering Linux support to escape Microsoft's monopoly in the desktop operating system market
Ironically the major contributor to many GNU/Linux critical components, Red-Hat, is now an IBM subsiduary, recouping that investment beyond doing only Aix.
It is no accident that all FOSS OSes that came after Linux, none of them has adopted GPL, as big corporations would rather not be obliged by it.
Of course big corporations would rather not be obliged by the GPL. But my feeling is that, if we give them the option to grab the code without contributing back their improvements, they would just do that. In the long run, this risks harming the OSS community, as developers would feel like big corps are being leeches and profiting out of their work without giving anything back.
After all, the GPL forces to contribute back only if you modify and distribute a modified version of the software (the AGPL modified this point, to account for cloud services). A corporation that isn't modifying GPL'd code or isn't redistributing the modified binaries, doesn't incur any additional burden for using a software distributed under the GPL.
It is no accident that Google has removed everything GPL out of Android, falling short of the Linux kernel, and they haven't done the final step with Fuchsia/Zircon mostly due to what appears internal politics.
Just a few hours ago on the irc channel of OpenBSD someone said that OpenBSD is good at not letting a wonky hardware run compared to linux. So you could use the dmesg and ask it in the OpenBSD mailing list and they will point out which wonky hardware is causing trouble and you can replace that problematic part.
I ran OpenBSD current for 6 years and never faced such issue
Years ago (circa ~2005) I was working for a company with a mix of OpenBSD, FreeBSD, Windows, and Linux. I was more of a fan of OpenBSD and I received a lot of grief when the OpenBSD team suddenly ripped out support for one of the Dell hardware RAID controllers (I don't remember which one, but IIRC it was one based on something from Adaptec), claiming they couldn't reliably reverse engineer it to create stable drivers. Their attempts ultimately always ended up with "random" corruption.
A year or so later our main DB on Windows (long story on why we were running windows DBs with most of the other kit being BSD/Linux) had a total corruption incident (it was painful, but we had a replica failover that we recovered from) - turns out we could get an answer from Dell since Windows was obviously supported by Dell themselves. There was a known issue with that model of RAID controller that would result in random and total corruption - and there was no way to fix it in firmware.
I was smug about it, but had to concede that people should still be given an informed choice. IIRC Dell was very quiet about it, which is certainly not "informed choice". Had we known, we'd have shelled out for different hardware for our databases!
To be fair, there was not much Dell could do as their PERC cards were all rebranded Adaptec and later LSI. Adaptec was the gold standard for ages, but I assume was enshitified somewhere along the way. The long term result was that the entire hardware raid world ditched Adaptec for LSI and/or software RAID (eg ZFS). Dell (in those days, not sure if it's still the case) had excellent support. There was a bug on another server model where the onboard video card would eventually fail and fry the motherboard. Even years later out of support, Dell would for free replace it if it failed with whatever new model equivalent existed.
I left the company before things were totally resolved, but I think dell ultimately gave people who complained LSI cards, but it took awhile for those to be designed and manufactured to fit the internal drive slot. Most people who were also using external arrays moved to third party ones or other hardware.
I built my last company on OpenBSD. It was easy to understand the entire system, and secure-by-default (everything disabled) is the right posture for servers. Pledge and unveil worked brilliantly to restrict our Go processes to specific syscall sets and files. The firewall on OpenBSD is miles better to configure than iptables. I never had challenges upgrading them--they just kept working for years.
Finally Linux has something that approaches pledge/unveil: landlock.
Seccomp was never actually usable: https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.h...
> Seccomp was never actually usable
It's barely usable by itself but I don't think it's an inherent problem of seccomp-bpf, rather the lack of libc support. Surely the task of "determine which syscalls are used for feature X" belongs in the software that decides which syscalls to use for feature X.
In fact, Cosmopolitan libc implements pledge on Linux on top of seccomp-bpf: https://justine.lol/pledge/
Well, kinda.
The "what does the equivalent of pledge(stdio) actually mean?" doesn't have to actually be on the kernel side. But it's complicated by the fact that on Linux, syscalls can be made from anywhere. On OpenBSD syscalls are now only allowed from libc code.
So even if one uses Cosmopolitan libc, if you link to some other library that library may also do direct syscalls. And which syscalls is does, and under which circumstances, is generally not part of the ABI promise. So this can still break between semver patch version upgrades.
Like if a library used to just not write debug logs by default, but then changed so that they are written, but to /dev/null, then there's no way to inform application code for that library, much less update it.
If you ONLY link to libc, then what you said will work. But if you link to anything else (including using LD_PRELOAD), then all bets are off. And at the very least you'll also be linking to libseccomp. :-)
If libc were the only library in existence, then I'd agree with your 100%.
> So even if one uses Cosmopolitan libc, if you link to some other library that library may also do direct syscalls. And which syscalls is does, and under which circumstances, is generally not part of the ABI promise. So this can still break between semver patch version upgrades.
Well but isn't that a more general problem with pledge? I can link to libfoo, drop rpath privileges, and it'll work fine until libfoo starts lazily loading /etc/fooconf (etc.)
A nice thing about pledge is that it's modularized well enough so such problems don't occur very often, but I'd argue it's not less common of an issue than "libfoo started doing raw syscalls." The solution is also the same: a) ask libfoo not to do it, or b) isolate libfoo in an auxiliary process, or c) switch to libbar.
> And at the very least you'll also be linking to libseccomp. :-)
libseccomp proponents won't tell you this, but you can in fact use seccomp without libseccomp, as does Cosmopolitan libc. All libseccomp does is abstract away CPU architecture differences, which a libc already has to do by itself anyway.
(In my project, I got annoyed enough by the kernel header dependency that I just replaced libseccomp with a shell script: https://codeberg.org/bptato/chawan/src/commit/cad5664fc0aa10... although this might have gotten me a place reserved in hell.)
> isn't that a more general problem with pledge?
No, for two reasons: 1) pledge() lets you give high level "I just want to do I/O on what I already have", and it doesn't matter if new syscalls "openat2" (should be blocked) or "getrandom" (should be allowed) are created. (see the `newfstatat` example on printf). And 2) OpenBSD limits syscalls to be done from libc, and libc & kernel are released together. Other libs need to go through libc.
Yes, if libfoo starts doing actual behavioral changes like suddenly opening files, then that's inherently indistinguishable from a compromised process. But I don't think that we need to throw out the baby with that bathwater.
And it's not just about libfoo doing raw syscalls. `unveil()` allows blocking off the filesystem. And it'll apply to open, creat, openat, openat2, unlink, io_uring versions of the relevant calls (if OpenBSD had it), etc…
But yes, if libc could ship its best-effort pledge()/unveil(), that also blocks any further syscalls (in case the kernel is newer), that'd be great. But this needs to be part of (g)libc.
Though another problem is that it doesn't help child processes with a statically compiled newer libc, that quite reasonably wants to use the newer syscalls that the kernel has. OpenBSD decided to simply not support statically linked libc, but musl (and Cosmopolitan libc?) have that as an explicit goal.
So yeah, because they mandate syscalls from libc, ironically OpenBSD should have been able to make pledge/unveil a libc feature using a seccomp-like API, or hell, implemented entirely in user space. But Linux, which has that API, kinda can't.
(ok, so I don't know how strictly OpenBSD mandates the exact system libc, so maybe what I just said would open a vulnerability)
> 1) pledge() lets you give high level "I just want to do I/O on what I already have", and it doesn't matter if new syscalls "openat2" (should be blocked) or "getrandom" (should be allowed) are created. (see the `newfstatat` example on printf).
You can do this with seccomp if you're libc. A new syscall is of no consequence for the seccomp filter unless libc starts using it, in which case libc can just add it to the filter. (Of course the filter has to be an allow-list.)
> And 2) OpenBSD limits syscalls to be done from libc, and libc & kernel are released together. Other libs need to go through libc.
That avoids one failure mode, but I think you assign too much importance to it. If your dependency uses a raw syscall (and let's be honest this isn't that common), you'll see your program SIGSYS and add it manually.
If you have so many constantly changing dependencies that you can't tell/test which ones use raw syscalls and when, you have no hope of successfully using pledge either.
> But I don't think that we need to throw out the baby with that bathwater.
We agree here, just not on which baby :)
> And it's not just about libfoo doing raw syscalls. `unveil()` allows blocking off the filesystem.
You're right, seccomp is unsuitable for implementing unveil because it can't inspect contents of pointers. I believe Cosmopolitan uses Landlock for it.
> Though another problem is that it doesn't help child processes with a statically compiled newer libc
If you're trying to pledge a program written by somebody else, expect problems on OBSD too because pledge was not designed for that. (It can work in many cases, but that's kind of incidental.)
If it's your own program, fine, but that means you're compiling your binaries with different libcs and then wat.
> So yeah, because they mandate syscalls from libc, ironically OpenBSD should have been able to make pledge/unveil a libc feature using a seccomp-like API, or hell, implemented entirely in user space. But Linux, which has that API, kinda can't.
My take is "it can, with caveats that don't matter in 99% the cases pledge is useful in." (Entirely in user space no, with seccomp yes.)
Chrome and Firefox use seccomp for sandboxing since more that 15 years: https://lwn.net/Articles/346902/
But only in very small sandboxes, right? Yes, seccomp could potentially be used for your JIT/interpreter sandbox. And because it inherently executes untrusted input, that's definitely the most important place.
But compare how many applications execute untrusted remote programs to how many programs that have had security vulnerabilities. Or indeed, how much code.
What percentage of code runs in chrome/firefox's sandbox? 0.0001%?
Have you tried to create a seccomp ruleset for a real program? I have. There are too many variations between machines and code paths that you'll necessarily need to leave wide open doors through your policy. Sure, the more you disable the "luck" you manufacture in case of a bug, preventing exploitation. But no, it's not fit for purpose outside these extremely niche use cases.
Seccomp is heavily used on Android.
Linux is far too bloated to ve run as a secure system and the attack surface of any linux distro, due to the number of kernel modules loaded by default, is very big.
And yet, countless companies do just fine.
> The firewall on OpenBSD is miles better to configure than iptables.
That's understating the matter by a huge amount.
pf is easier to read and understand, easier to adjust, more dynamic, and works like every other firewall in the world not based on iptables.
Seems a bit subjective. I find iptables much easier to work with.
But then again I've not run iptables for years. nftables has many benefits.
iptables is indeed horrid, but Linux has nftables nowadays, which is much nicer and easier to configure.
> I built my last company on OpenBSD. It was easy to understand the entire system, and secure-by-default (everything disabled) is the right posture for servers.
That really depends. You could argue a router is a server. OpenWRT has the default of WiFi off for security, which means that if the config is somehow hosed and you have to hard reset the router, you now have an inaccessible brick unless you happen to have a USB-Ethernet adapter on you.
Sensible defaults are much, much better than the absolutionist approach of "disable everything".
Edit: it's so funny to know that all the people slamming the downvote have never hit the brick wall of a dumb default. I hope you stay blessed like that!
> Edit: it's so funny to know that all the people slamming the downvote have never hit the brick wall of a dumb default.
I'll bite. OpenBSD and OpenWRT are different things, and I'm honestly surprised to hear that tech matters enough to you to setup OpenWRT but not enough to own a desktop (or a laptop that doesn't skimp on ports)
They are, but Linux or BSD doesn't matter all that much when it is about the meta case of deciding the defaults.
Funnily enough I feel a BSD is much more suited to modems / routers, if it weren't for HW WiFi support. Yes, I know you can separate your routing and your access point onto different devices.
At any rate I'm just pointing out that that absolutionism is rarely the right answer. It's also pretty telling that people actually went through my comment history to downvote a few unrelated recent comments. People get angry when they have to adjust their assumptions.
As far as computing device goed, I prefer not lugging around a plastic brick. And one is bound to either lose or forget a dongle. In which case you get boned by OpenWRT's dumb default.
The reason for that default is that if they set up an open OpenWRT WiFi (or default passworded, think "OpenWRT2025"), in that split 5 minute window before you change it, some wardriver might login and mess with your network.
Obviously the chances of that are rather insignificant. And they could generate a default password based on the hardware. For the real security nuts they could tell them to build an image without default-on WiFi (currently they do the inverse).
You bring up a particular edge case as a way to discredit a much more thorough essay on the system.
And if someone is administering routers but don't have the hard-line equipment to configure them locally, I wish them well.
You are being downvoted for comparing OpenBSD to OpenWRT. They are about as different than a foundation to a house.
I'm not comparing those, I'm comparing absolutionist vs. flexible attitude.
People are downvoting because I'm making them realize they have to rethink their assumptions, and it is less painful to attack the messenger rather than actually do so. People these days are generally bad at not tying their identity to things and not taking it personal.
Servers I setup in openbsd just keep working, and are an easy patch/upgrade process. Servers I setup in Ubuntu break and have weird patching issues. Maybe it's something I'm doing, but I sure do like that OpenBSD seems a lot easier to just have solid and work indefinitely.
You are not....it's Ubuntu.
Not Linux, not Debian, Ubuntu.
Debian (provided you don't just dump a bunch of 3rd party repos) just upgrades cleanly, we have hundreds of servers that just run unattended-upgrade and get upgraded to new Debian version every 2 years.
The few Ubuntus we had had more problems.
I used to have this Debian box (which was a PowerMac G4) in my hallway. It had a 1000+ day uptime, back when this kind of uptime was still cool, or at least I thought it was. At some point it was two major versions behind, and I decided to dist-upgrade it. To my amazement, the upgrade went flawlessly, and the system booted without problems afterward. Debian is just great like that.
How to upgrade Debian unattended if it's not a rolling release
Not the Grand Poster, but we use the Debian package "unattended-upgrades" to install security updates automatically on our servers, and send an email if a reboot is required to complete the process (kernel upgrade).
Unattended upgrades could be configured to install more than the security release. Even with the stable release, one can add the official APT source for the Debian backports.
Back to OpenBSD... realize that it has no "unattended upgrades" capability. Until syspatch(8) appeared in 6.x you had to download patches and rebuild kernel and userland to get security fixes. Today, you could run syspatch(8) in a cron job but that only covers the base system. You'd need to handle any installed packages separately. And only the current and immediately previous release are supported at all. There are two releases a year, so you have to upgrade every ~6 months to stay in the support window.
Fortunately, with the introduction of the syspatch(8) and sysupgrade(8) utilities this is much simpler than it used to be. And, release numbers are just sequential with one point number, i.e. 7.0 was just the next release after 6.9, nothing more is implied by the "major" number ticking up.
Just curious, how do you manage service restarts, just restart as the update finishes?
I think I’m a bit scarred when a docker upgrade took my entire stack down because of an api mismatch with portainer, so I’m trying to be present during upgrades.
Edit: I’m talking about Debian of course. I’m not familiar with OpenBSD.
Use needrestart, you can mostly automate those restarts with it.
Debian still has security fixes, and point releases. unattended-upgrades is the package that automates their install.
I think you can also do unattended release upgrades by using the 'stable' release alias in sources. That will probably result in some stuff breaking since there will be package and configuration churn.
In case you are talking about automated upgrades between releases, there are some ideas for that here:
https://wiki.debian.org/AutomatedUpgrade
It is feasible to do if you prepare ahead of time, and you can even do automated offline upgrades with apt-offline and some scripting.
I use unattended-upgrades with Debian's rolling release (aka testing).
Mostly works fine apart from bugs in unattended-upgrades, or when my boot partition runs out of disk.
Maybe they run Debian Testing. Testing and Unstable (sid) are rolling, and the stable release cut from the testing branch (through some process)
Well - I would recommend using a better linux distribution than Ubuntu.
I run just lighttpd these days; used to run httpd before they decided the configuration must become even more complicated. I don't have any issues with lighttpd (admittedly only few people use it; most seem to now use nginx).
Ubuntu seems to have a trend of taking something that works under Debian and somehow messing that up. Upgrades are one thing but for a while we had separate instruction on how to make Yubikey tokens work under each version of Ubuntu (we used them as smartcards for SSH key auth), while Debian instructions stayed the same...
Update was also hit and miss on user's desktop machines, for a while ubuntu had a nasty habit of installing new kernel upgrades... without removing old ones, which eventually made boot run out of space and poor user usually had to give it to helpdesk to fix.
Tho tbh most of the problems in any distro with packages is "an user installed 3rd party repo that don't have well structured packages and it got messy".
I have used lighttpd in the past but have been using nginx largely because I got used to it because other people chose it.
Now in more of a position to pick for myself, and I wondered how you feel about the pros and cons of lighttpd? I remember quite liking its config at the time.
And which distribution would that be?
Debian
I agree but you could have just said it :)
Slackware
One of the reasons why I'm using OpenBSD is because it passes what I think of as a litmus test for FLOSS software: can I build the whole thing from scratch, in a short time and with minimal fuss? In the case of OpenBSD, the answer is yes. I can install it on a new machine, fetch the source code from mirrors, do some edits to the source, build a fresh release, write it to a USB stick and boot it on another machine. On my machine, the whole process takes about 10 minutes for the kernel, additional 20 minutes for base and maybe an hour if you add Xenocara. Compare that to Linux distros like Ubuntu or Arch where building from scratch is either discouraged or some fringe activity that requires skimming through wiki articles, forum posts or old Websites on the Wayback Machine.
Gentoo is a Linux rolling release built from source (just recently they gave the option of using binary packages as well). I've ran it on my desktop for years.
Does OpenBSD have Bootstrappable Builds from source without any binaries? I'm guessing not yet, since GNU Guix (Linux distro) pioneered that, and I haven't seen any BSD distro interested in the related Reproducible Builds project.
https://bootstrappable.org/ https://reproducible-builds.org/
Buildroot does exactly that and it gives you big TUI menu to pick what you want included in your linux image
There is also T2 SDE.
Long time OpenBSD fan. Used it as my daily driver for years before standardizing all computers at home to macOS. I still think about going back to openBSD one day, but it's no longer very practical as a daily driver.
I want to use OpenBSD for the next project I'm building. However, I can't wrap my head around the old way of doing deployments (before containers). People who've built production grade systems with OpenBSD:
1. How do you deploy software? 2. How do you manage fleets of servers? 3. How do you spin up/turn down servers from cloud providers? (I only know of Vultr who provided an OpenBSD option out of the box).
> Long time OpenBSD fan. Used it as my daily driver for years before standardizing all computers at home to macOS. I still think about going back to openBSD one day, but it's no longer very practical as a daily driver.
It's only practical for hobbyists. I used OpenBSD as a daily driver between 2001-2005. I fought, I suffered, I conquered, and I got tired of not being able to watch video on the web reliably and MacOS in those days was so clean and refreshing. I learned so much, though.
> I want to use OpenBSD for the next project I'm building.
I admire your open-mindedness. But ask yourself:
1. Do you want to have to upgrade fleets of servers every year with no exceptions for extended security support instead of 5 (or more if you're willing to pay) for LTS versions of Linux?
2. Who else will need to support it?
3. You will likely have worse performance if that matters.
> 1. How do you deploy software?
Honestly, not many people create their own services that run on OpenBSD. Those that do use old-school packaging and scripting. Tooling like ansible works.
> 2. How do you manage fleets of servers?
Ansible would be my go-to for classic fleets of servers.
> How do you spin up/turn down servers from cloud providers?
There are ports of cloud-init for OpenBSD. Creating images for third party OSes can be different levels of painful, depending on the cloud provider.
OpenBSD has virtualization out of the box now. Most of the benefit of containers you can get with chroot. I don't know if any of the developers are working on a true container/jail capability.
I'd like to see a more modern performant filesystem with OpenBSD but ffs has never really let me down. Capability for logical volumes and/or live resizing of partitions would be welcome as well.
RE: 1/2, doesn't Ansible work for BSDs?
I adore openbsd and have been using it since 4.x however it is still slow, not slow to boot or anything like that but if you run it as a web server it manages about half the req/s of Debian. Network performance is also slower than Debian if you're using it as a firewall (but I still prefer it as the syntax of PF is just perfect).
It's gotten a lot faster with 7.6 (lots of work on the TCP stack iirc). We saw huge improvements in throughput after updating.
The new 7.8 release should bring some more performance, haven't tested it yet though.
Yes, they've been working on unlocking more and more performance over the 7.x series of releases if not longer.
Remember the BSDs date from an era when you only had one core in the CPU.
there's a lot of optimisations they don't engage with because it makes the code "ugly" but there's a larger one here, where they disable hyperthreading outright due to side-channel attacks.
Might be a leading cause of what you're seeing.
> where they disable hyperthreading outright due to side-channel attacks.
You can turn on hyperthreading if you need/want it: https://www.openbsd.org/faq/faq10.html#SMT
So, spin up lots of single-core VMs?
for I/O intensive applications, it's always been true that VMs are a decent chunk of overhead: https://sites.cc.gatech.edu/systems/projects/Elba/pub/JackLi...
Also, it's likely already in a VM.
It used to be faster than Linux for that, but that's been a while ago.
I moved some stuff away from OpenBSD when the release of Linux 2.4 implemented all missing firewall functionality - but kept others still due to the early issues with the 2.4 kernel. But by the time 2.5 was getting decent - roughly a year before the 2.6 release - in most cases just using Linux with a custom 2.5 kernel was the better option.
The list is missing the fact that the documentation is consistent and centralized.
The post has many links to OpenBSD's man pages, FAQ and manual. But I thought it was quite unsatisfying, even common tasks are missing. Or at least I couldn't find them.
I had a test case in mind while reading the documentation: running a custom web service with Nginx as a reverse-proxy. In the documentation, I couldn't find anything about creating a service. Are we supposed to write a frontend script (in ksh) that accepts various arguments (ie start/reload/...)? And what about the logs of this wrapper? And if I want an auto-restart when my program crashes, I have to find another tool that will wrap and monitor the process? I've done all this tedious work in Linux long ago, and I'm not willing to do it again.
If the question was "Why OpenBSD instead of Linux", I don't think documentation is a good argument. In fact, the only strong response I've read is "to try something a bit different and more niche".
The documentation you need is:
https://man.openbsd.org/intro.8
https://man.openbsd.org/rcctl
https://man.openbsd.org/rc.conf.local.8
https://man.openbsd.org/rc.d.8
This is the page I was thinking of….
https://www.openbsd.org/faq/index.html
> is consistent and centralized
complete, useful, well written and contently at hand.
If you can tolerate poor performance then by all means use OpenBSD. Debian stable FTW.
You do have to buy more powerful hardware than you otherwise would. I find it worth it to run code I can more easily understand. I agree on Debian as well. My router and laptop are OpenBSD but most vms on my proxmox are Debian.
Agreed. I run my OpenBSD firewall on my odroid h4 - it's relatively cheap and plenty powerful to route gigabit+. I prefer pf and the simplicity of OpenBSD over Debian for such a purpose-built application. For my other "home servers" I simply run Debian as I believe it to be one of the more sane Linux choices for a server-type application.
To be honest I don't really see a reason to use a *BSD system myself other than just for the sake of using something different and less mainstream. FreeBSD had some advantages in the past but nowadays Linux has caught up in features.
When I switched to FreeBSD, it was because of the quality of the documentation. In Linux manpages are a patchwork from various sources, and it shows; it's not rare for a manpage to be missing, obsolete, or to document another similar tool, or to be inacurrate... Much better than in many other OSes, but still nowhere as good as in FreeBSD.
Now that I think of it, when I switched from DOS to Linux it was already because I found manpages amazing. Maybe I've just a soft spot for documentation.
To me the advantages are: simpler and more consistent configuration, less churn, better documentation, focus on security and secure-by-default.
Yes if raw performance is your top priority, linux wins. But for a desktop or general-purpose server, that's not the most important thing for me.
BSD license so you don't have to upstream your stuff would be one. Tho it's not an advantage to *BSD systems, Linux near-forcing vendors to go mainline (as keeping separate kernel tree is PITA) did a lot of good in hardware support.
Not really a problem for users. Only for people who want to redistribute a fork. It matters if you are Apple or Sony, but not for most people.
incidentally, the requirement of the GPL is not to upstream your stuff, but to offer to make the modified source available to anyone you distribute the code to. Often the same in practice, but does not have to be.
> To be honest I don't really see a reason to use a *BSD system myself
I use FreeBSD+ZFS for storage servers. I definitely want to use ZFS for these and I don't think Linux+ZFS is as good a combination.
It depends on what you want to do. If you want a typical laptop with a desktop environment, then FreeBSD might not be a good choice. Horses for courses.
The development move in ZFS from FreeBSD to OpenZFS (AKA Linux) was a mayor point on that.
I feel like DragonflyBSD is really cool if you want to look at some BSD that offers some advantages and something unique to your day-to-day desktop usage. And I feel like their community is not as toxic as that of FreeBSD and OpenBSD with their holier-than-thou attitude towards Linux.
I'd love it if Gentoo/BSD were a thing once again, I like the BSD concepts but there's nothing like Portage on BSD so far - afaik pkgsrc is nowhere close to it.
>To be honest I don't really see a reason to use a *BSD system myself
I see some reasons:
- the BSD license
- the system is composed of pieces written to work together, it is built from start up as a coherent operating system as opposed to things cobbled together like other UNIX-like OS-es do
I tried using OpenBSD, but the support for some specific things isn't very good. For example, J language support is always missing some packages. I also don't want to, and very much do not want to, use systemd. I finally chose FreeBSD, but I'm using some things from OpenBSD as much as possible, like obhttpd, etc. It feels good now.
I feel like people user it either due to fixation/hobby reasons, or because they've heard it's secure and good for routers so they just use it as a router, assuming the rumors are true.
Honestly myself, I prefer NetBSD approaches to many things, or for Linux Alpine, which is perfectly small, minimal and secure by default.
Why use BSD
Single source tree for kernel and userland
"BSD from scratch" is less work than Linux from scratch
Why isn’t it used more often at BigCorp? Or as a base container image?
[flagged]
Are you calling Anubis an AI trashcan? Are you opening their website with an i286 for it to take 40s to load?
it took 30s to even load the trashcan
Doesn't load here at all, I had to change my User-Agent to "curl".
AI? I may be missing something. You are talking about whom here? The blog author?
GP is referring to the LLM crawler captcha thing. The one with the anime girls in it. It only took a few seconds on my phone, but it's slow on my old ThinkPad.
it took tens of seconds to load, once it loaded it was quick
And the point of "why waste time for captcha for static file" still stands, it's not like there is comment section for bots to abuse
It's not about keeping spam out of comments, it's about keeping systems and content safe/operational for normal people and more costly or unavailable for the trillion dollar "AI" companies that are shitting all over everything.
Don't blame this on site operators, this is the fault of careless LLM operators knocking down everybody's walls doors and windows to "learn" from their content.
So if the author recommended software that you loved and used everyday you would stop using that software?
Even broken clock is right twice a day so no.
You mistake dismiss with "do opposite"
I appreciate that OpenBSD sold its course on security-everywhere.
Unfortunately I also kind of lost faith in the BSD variants. There are a few minor things such as PC-BSD suddenly vanishing, or years before NetBSD on their mailing list admitting that Linux outperformed their "runs on any toaster and other gimmick" strategy. But one of the key issues I had was this:
I installed it (FreeBSD) on my second computer. I went out of my apartment and returned hours later. Well, the FreeBSD machine was no longer running; my linux machine on the other hand is running non-stop for months, literally. This may be a fluke, perhaps the computer had a problem - I am not saying this is really what the BSDs are all about, as I also had them installed before. But then I also asked myself "why would I want to bother with the BSDs, if Linux simply runs better?". And I haven't found a good, convincing answer to that for me to rationalise why I'd still be using the BSDs. Note: I also use Linux in a non-standard way, e. g. versioned AppDirs, but essentially Linux is simply more flexible than the BSDs (that is my opinion) and there are more users too. There will be always some BSD users, but to me they are like a dying breed. They would need to market themselves as a "runs outside the nerd bubble as well"; even Linux is still stuck in its own nerd bubble. You have to break out of it if you want to really dominate (Linux semi-does it indirectly, e. g. we can count many smartphones as Linux-driven, but I am still using a desktop computer system here, so to me this is what really counts, even if the total number is less than the smartphone users numbers).
What Linux has is mostly better hardware support and on gnome and some distributions they have a software installation tool that look like an app store but that's about it... Everything else is pretty much the same, random people wouldn't figure out a system is freebsd instead of Linux when running same desktop (like plasma).
The license makes it very different philosophically.
Which is what makes Linux kernel stand out, as we can see by Sony and Apple contributions upstream.
Had BSD not been busy with AT&T lawsuit, all major UNIXes would probably still be around, consuming whatever was produced out of BSD like the networking code and OS IPC improvements over AT&T UNIX.
Instead sponsoring Linux kernel became the plan B, as means to reduce their UNIX development costs.
> Commercial use began when Dell and IBM, followed by Hewlett-Packard, started offering Linux support to escape Microsoft's monopoly in the desktop operating system market
-- https://en.wikipedia.org/wiki/Linux
> 1998: Many major companies such as IBM, Compaq and Oracle announce their support for Linux.
-- https://en.wikipedia.org/wiki/History_of_Linux
Ironically the major contributor to many GNU/Linux critical components, Red-Hat, is now an IBM subsiduary, recouping that investment beyond doing only Aix.
It is no accident that all FOSS OSes that came after Linux, none of them has adopted GPL, as big corporations would rather not be obliged by it.
Of course big corporations would rather not be obliged by the GPL. But my feeling is that, if we give them the option to grab the code without contributing back their improvements, they would just do that. In the long run, this risks harming the OSS community, as developers would feel like big corps are being leeches and profiting out of their work without giving anything back.
After all, the GPL forces to contribute back only if you modify and distribute a modified version of the software (the AGPL modified this point, to account for cloud services). A corporation that isn't modifying GPL'd code or isn't redistributing the modified binaries, doesn't incur any additional burden for using a software distributed under the GPL.
It is no accident that Google has removed everything GPL out of Android, falling short of the Linux kernel, and they haven't done the final step with Fuchsia/Zircon mostly due to what appears internal politics.
It is good for Google, not Android users.
It was a fluke or a problem with the computer unless you can provide more than 1 data point with more info than "it wasn't running".
Just a few hours ago on the irc channel of OpenBSD someone said that OpenBSD is good at not letting a wonky hardware run compared to linux. So you could use the dmesg and ask it in the OpenBSD mailing list and they will point out which wonky hardware is causing trouble and you can replace that problematic part. I ran OpenBSD current for 6 years and never faced such issue
Years ago (circa ~2005) I was working for a company with a mix of OpenBSD, FreeBSD, Windows, and Linux. I was more of a fan of OpenBSD and I received a lot of grief when the OpenBSD team suddenly ripped out support for one of the Dell hardware RAID controllers (I don't remember which one, but IIRC it was one based on something from Adaptec), claiming they couldn't reliably reverse engineer it to create stable drivers. Their attempts ultimately always ended up with "random" corruption.
A year or so later our main DB on Windows (long story on why we were running windows DBs with most of the other kit being BSD/Linux) had a total corruption incident (it was painful, but we had a replica failover that we recovered from) - turns out we could get an answer from Dell since Windows was obviously supported by Dell themselves. There was a known issue with that model of RAID controller that would result in random and total corruption - and there was no way to fix it in firmware.
I was smug about it, but had to concede that people should still be given an informed choice. IIRC Dell was very quiet about it, which is certainly not "informed choice". Had we known, we'd have shelled out for different hardware for our databases!
Hangon on a second, you paid dell support and they knowingly let you run production on kit with known total irreversible data loss bugs? Da. Fuq?!?
To be fair, there was not much Dell could do as their PERC cards were all rebranded Adaptec and later LSI. Adaptec was the gold standard for ages, but I assume was enshitified somewhere along the way. The long term result was that the entire hardware raid world ditched Adaptec for LSI and/or software RAID (eg ZFS). Dell (in those days, not sure if it's still the case) had excellent support. There was a bug on another server model where the onboard video card would eventually fail and fry the motherboard. Even years later out of support, Dell would for free replace it if it failed with whatever new model equivalent existed.
I left the company before things were totally resolved, but I think dell ultimately gave people who complained LSI cards, but it took awhile for those to be designed and manufactured to fit the internal drive slot. Most people who were also using external arrays moved to third party ones or other hardware.
Some background from an OpenBSD dev:
https://nickh.org/warstories/adaptec.html
The NetBSD thing is becoming true again as Linux distros and the kernel are lately on a tear of purging old and niche architectures.
Linux won't run on legacy machines the same way NetBSD does today.
I hope people here keep donating to the OpenBSD project. I have myself not yet but I'm waiting yo do that