After Heartbleed, BSD developers forked OpenSSL and "cleansed" it. They removed ridiculous amounts of unmaintained legacy code, rewrote much of the rest, and tightened the security.
The old code was littered with conditional compilation macros that made it virtually impossible to reason about or test. There are just too many forks in the tree of possible compile flags.
The style of "make this code work against every possible standard library" is broken and results in insane spaghetti code. Instead, the BSD team rewrote OpenSSL in terms of a modern, complete C standard library. Then instead of making their LibreSSL cryptography code have conditional flags in it, they wrote shims for the standard library so that it would work on platforms where there are missing functions.
This results in far cleaner code that can be reviewed and tested with much greater confidence.
I dug up a couple of presentations by the LibreSSL team 9 years ago. It's full of "Wat!?" moments, such as discovering the OpenSSL has its own implementation of malloc & free! Why? Because on one platform they nobody uses any longer, those functions were "slow"! So now they have a custom-developed poorly maintained heap full of security issues. Worse still, that custom heap does not benefit from the security features of modern allocators or analysis tools like valgrind.
What you consider "insanity" was functional and useful at one point and may still be useful in some projects. I see systems in the wild running DOS (rarer and rarer) because there is still functional hardware that does not have modern OS support.
The OpenSSL codebase is a legacy codebase, for sure. That said, it's a pretty consistent one (even with all the macros). I don't actively hunt for bugs, but I know the codebase enough that when one or two exploit came out in the past, I knew the relative area where things were impacted.
Also, writing one's own memory allocation library isn't that far fetched, especially if you want to encapsulate platform quirks at a specific layer. I don't think it made the transition to Mozilla owned Firefox, but Navigator (the predecessor) had it's own encapsulation of memory management because, in part, all the platforms and architectures it would compile for.
Do watch the BSD team's video presentation, they cover everything you've said.
I don't want to re-iterate too much of it, but the gist was: "If Microsoft won't support DOS or Win16, why should the two part-time volunteers support it!?"
The OpenSSL team clearly did not have the time or budget to both maintain that many platforms and maintain the security of supported platforms.
If "some projects" or "some vendors" want to support esoteric platforms they can fork LibreSSL and add support at their own expense instead of at the expense of the larger community using SSL libraries at-scale on modern platforms for production workloads worth trillions of dollars to the economy.
I 100% agree with the BSD team's points and their approach, and whatever contrary argument you make has to also explain away Heartbleed, which was at the time the worst security vulnerability in history.
It's like arguing that: "Sure, the Wuhan Lab of Coronaviruses may have had some biosecurity lapses, but just because the world's biggest pandemic originated form there doesn't automatically mean those practices were a problem!"
(Or if you disagree with the lab-leak hypothesis, substitute unsanitary animal handling practices at the Wuhan Markets.)
A legitimate question I have, why can’t these legacy machines running DOS just run a legacy version of OpenSSL? I understand there’s probably security concerns etc, but if security is such a big concern why would anyone still be running DOS? And why would anyone on DOS feel entitled to software updates in 2023? I just have a hard time wrapping my head around the need for to provide any consideration for ultra legacy code like this.
Well FreeDOS is not a legacy OS, it is actively maintained one. Besides, DOS is the simplestg hard RTOS, due to being single-task, zero protection, close to the metal system.
> A legitimate question I have, why can’t these legacy machines running DOS just run a legacy version of OpenSSL?
Compatibility. OpenSSL is at its core a networking protocol library, and legacy versions of OpenSSL will not understand the only versions of the protocols accepted by modern systems.
Not all of the things they cut out are nonsensical, though. They laughed at the ifdowhile loop, for example,
if (C) { do { /* THINGS */ } while (C); }
but on a puny compiler and/or CPU this seems like a fairly reasonable way to express that C is unlikely to be true, but if it happens to be we’re going to spend a while to turning it false. Whether such code belongs in a TLS implementation is a different question.
(Cutting out inline assembly for rotation operations is even more obviously dependent on the presence of a modern, heavyweight compiler, as only those have—or can afford—an explicit list of idiomatic AST templates they match against your code.)
Hopefully HAMMER2 is ported to it soon. No hope for ZFS. Having old school UFS is a deal breaker, even though most Linux users still live with a comparably old Ext4, but once you get used to ZFS you don't want to go back.
-- FreeBSD user
I put OpenBSD on my router earlier this year to get in-kernel NAT64 support and to learn pf, among other things.
I’m massively regretting that choice due to the UFS root filesystem. Power outage? Hope you weren’t planning on your internet coming back up without manual intervention. Get ready to plug that keyboard in and type “fsck” manually at boot, and press “y” a few dozen times while it asks you questions about what to do with corrupted inodes. I hope none of that data is important to the correct operation of the system!
A filesystem lacking journaling support in 2023 is an absolute travesty given that the rest of the world has had this problem solved for 25 years or so.
I’d have to put /etc on another partition, which really means I’d have to up front plan to put every damned writable thing on its own partition, which OpenBSD encourages specifically because it allows you to mount more stuff as r/o. And even then, any partitions which are writable would not be able to be mounted after boot until I do the same ridiculous fsck dance.
But that’s, in my opinion, brain-dead stupid when it only exists to work around the idiocy of not having a journaled file system like ever other modern OS has had for the past 25 years. Having to up-front plan a size (and inevitably get it wrong) for half a dozen partitions, just to work around glaringly obvious weaknesses in the OS itself, is beyond stupid.
You are on point. I still use OpenBSD where it makes sense though—in your case it does not. All my OpenBSD systems are backed by a UPS, but a crash, while rare, could still readily cause file system corruption.
Great article and a cool way to learn more about the inner workings of OpenBSD, thanks for sharing. I like the idea of a separate /var/syspatch directory. I typically make separate /var/log and /var/www directories too.
I noticed you're using a good quality SD card and wrote a couple times about flash wear, is there any reason you didn't opt for an mSATA SSD? It might be more resilient than SD.
I know of the non-standard workarounds, I'm just not interested in doing them unless it's for a very specific deployment and needs to be repeatable across a large number of systems.
Oh, that's interesting! Huh. I wouldn't have guessed that, although I haven't tracked OpenBSD development in ages, so maybe that was a big public debate for years for all I'd know.
This happened quite recently ( at the July 2023 hackathon), apparently to make it easier to update/fix other stuff as it was tied into a lot of kernel subsystems.
Ok say my root file system is read only, and say, /var/log is writable. The power goes out. Then what? Does /var/log just not mount until i type fsck? Aren’t i back to the same issue?
It's probably not a safe assumption to rely on for a device out in the field, but in my experience, OpenBSD's fsck typically works just fine unattended. I could pull the plug on my router right now and I would expect it to come back up on its own.
However, yes, sometimes a badly timed power loss will break the filesystem in a way that requires a manual fsck.
I’ve had 3 power outages this year since installing OpenBSD (which is a lot for my area, admittedly) and it has required manual intervention each time. My root FS is on an SSD, it that matters.
>which means that poorly written software will crash a lot more often on OpenBSD than elsewhere.
And this is why I test everything I write for use at work on OpenBSD, it has helped me find some issues with items I have written for use on an application hosted on AIX
A more significant issue, in my experience, is that a lot of useful nonstandard APIs simply do not exist on the BSDs, under any name - or worse, exist with unstable names, so you have to #ifdef your source code to make it work with more than one release. There is no equivalent to Linux's "we do not break userland".
FreeBSD is generally assumed to be the least painful, but I usually don't even bother with that these days. If someone cares they can do the work.
Yes, an OpenBSD release is a full system: kernel + userland. Running anything from a different release might work, but isn't supported and you won't get any help if something breaks as a result.
Also there is no "LTS" release. The prior release gets updates until the next release drops. So you need to plan on release updates every 6 months. Luckily "sysupgrade" is usually painless but you need to check the release notes and packages you have installed for potential extra work (e.g. if you're running Postgres and it got a major version bump, you'll probably need to upgrade your database).
My experience is that OpenBSD works best if you don’t go too much outside of what comes with the distribution.
As soon as you install packages you are going to be dealing with incompatibilities between OpenBSD releases and dealing with a lot of recompilation.
As an example I had installed fish from the packages as my default shell and after upgrading from 6.X to 6.x+1 I could not log in anymore because the compiled fish binary simply was not compatible anymore.
It is all by design and once you know these people things you can work around “quirks” like this.
I would say packages mostly work well and are not as bad as you make them sound. Yes, after upgrading the OS release you need to run "pkg_add -u" to upgrade all your installed packages. This is normally pretty easy.
There are a few potential "gotchas" and changing your login shell (or especially root's login shell) or any other defaults in the login or other base configurations are things that you learn to to do very deliberately after getting burned a few times.
The last thing I usually want to do on something in production is upgrade all the things and hope for the best or potentially spend a lot of time fixing things.
FWIW I think all the BSDs suffer from this. Not just OpenBSD.
I guess you're being ironic but I didn't mean to say it was a "downside" just that it is different from what one may be used to with Linux distros.
I actually think it's good that you're sort of forced to keep up, but it's something you need to be aware of in case that isn't practical for your planned use.
For example if you get too far behind you'll find that sysupgrade doesn't work anymore, because it will only upgrade from one release to the next, and if you're more than two releases behind the "next" release might not be on the mirrors anymore. In that case you'll have to go hunting for it or just do a new install of the current release and then copy/update all your local config.
That can happen with Linux too, but typically not as quickly. With OpenBSD, if you're much more than a year behind, upgrading will become increasingly problematic.
I think I actually left words out and so my point was lost.
The difference I see is that OpenBSD is so well documented that one can judge wether or not any of the updates is needed. One can consider each release as a standalone environment. The change notes going forward can be monitored. Upgrades are only required for feature changes. There is no requirement to upgrade.
sysupgrade was released with OpenBSD 6.6. I think my wildest upgrade was going from 6.8 to current (7.3), so 5 releases without a hitch. Granted the box was mostly just base anyways. Always remember to "pkg_add -u" after every release.
The biggest change for me was when they added security to GPIO. I forget the details, but fabBSD(openBSD variant for CAMs) was a casualty last I checked.
It's a documented system what more could one ask for.
>"All of those features have been integrated in the OpenBSD source tree, and with the developers admonished to adhere to the rule
"where it is possible to spot damage, fail hard".
-which means that
poorly written software will crash a lot more often on OpenBSD
than elsewhere."
In other words, testing software on OpenBSD -- is one great way to find some types of bugs and other incorrect software designs...
In other words, testing software on OpenBSD -- can be thought of as applying a higher degree of correctness, rigor, and discipline -- to Software Engineering...
Sort of like a 'lint', but for a runtime...
It's not the only software test, that's true, not by a long shot -- but testing on OpenBSD would make a valuable addition to any professional software test corpus...
>"That in itself should make the platform attractive to developers."
I tinkered with OpenBSD a long time ago and found installing was more of a headache than I cared for - specifically disk partitioning was a chore. I wonder if that’s gotten much better?
Can’t see myself switching to OpenBSD at this point, but I’d try it just for fun if the installation has improved enough.
In contrast, I find the installer refreshing. Yes, it's text-based, but it's streamlined and for most use cases all you have to do is hit Enter at the prompts. As for the partitioning, I don't know when you last installed OpenBSD, but, with the auto partitioning, you just hit Enter as well. If you wanted to customize the partitioning, it is a bit daunting for the uninitiated, but after you do it a few times it really is just as streamlined as the rest of the installer.
Nope, I am firmly with Joe here on this one. The installer is the first major pain point new OpenBSD users are likely to encounter, and especially partitioning is weird, cryptic, and downright unhelpful.
In real life OS testing and evaluation, I don't get to dedicate whole machines to any OS. No OS is that special, that important, or that versatile.
I always dual-boot because that often uncovers weaknesses and assumptions in installers... just as the OpenBSD devels encourage people to fail hard, the OpenBSD installer itself fails hard in a multi-boot scenario.
Example, to recreate if you are curious enough:
0. Set up a new PC (or VM, it doesn't matter.)
1. Install Windows (say, v10 as it's easy.)
2. Add a random Linux distro. For best results, have separate /, /home and swap partitions.
3. Now, try to add OpenBSD to that.
For best results, do this by directing a friend who has never used Unix through the process, over the phone so you can't see the screen. ;-)
If that's too easy, partition the disk with MBR so you have to deal with logical partitions too.
Text based is fine. I started with Slackware in 96, and I’m totally comfy with that - but when I installed OpenBSD I recall needing to supply some pretty detailed stuff about starting cylinders? It was lower level than I remember having to get even with Linux in very early days.
For me it was the other way around. In 2000/2001 I had zero experience with anything *nix apart from a couple of failures to get anything Linux to run, but on the first try with OpenBSD I managed to get it up and running in no time. I've always considered their installer to be simple, explaining, understandable and straightforward.
That's right around the same time I first started tinkering with Linux, and I had a similar experience. I didn't know about BSD at the time, but it took me weeks to get my first Gentoo install up and running. That being said, the amount I learned throughout the process made the experience absolutely worth the hassle. Then it was just a matter of getting the conexant chipped dial-up modem to work...
It's like an filter to determine whether the user is worthy enough to use OpenBSD. Last time I used OpenBSD must have been back in 2000, 2001. Extremely well built system and the impact it has had on the world is mind blowing. I later changed to FreeBSD which had a bigger community and better support for graphics drivers, etc.
I think you might be right. The partitioning is very old school but if you need old school partition it's right there.
If you don't need old school partition learn what you do need and move on.
The documentation has always matched the experience with OpenBSD. I enjoy OpenBSD simply becuase I know where to find the documentation. Some OS's have so many variations that I'm overwhelmed.
Considering the goals of OpenBSD the partitioning is a feature and structural.
If you decide to put everything in one large partition (not really recommended), always make sure /usr/local is on its own partition. If you do not do that, some ports will core dump. If you use one big partition, you will need to disable an important security feature to allow the ports to run.
And yet the last time I accepted OpenBSD's partitioning defaults I ended up with "/usr: no space left on device" the first time I tried building something from ports.
The defaults probably are probably close to the minimums required. Remember this is a conservative operating system. They will not look at your system and guess how you want to use it and make more guesses at your partition size should be.
They assume since it's your disk you best know how to partition it. One is free to edit the default save them to file for next time.
If one wants to manage the details of a computer system with documentation describing the implications of each decision OpenBSD is perfect.
There are plenty of other operating systems that will most do the right thing. How many operating systems do exactly what you tell it to?
> They will not look at your system and guess how you want to use it and make more guesses at your partition size should be.
Then it shall have some documentation on system requirements.
I tried to install Freebsd on a VM with UFS as a filesystem and the show ended with out of inodes when installing the ports system. This in 2020 is a bit sad.
Oh right. I've just never encountered such issues in the years I've been using FreeBSD, with /usr/local being one big partition.
I'm aware of that if no partitions are filled it causes an domino effect if not on its own partition. I have ZFS quotas configured so surely that mitigates the issue?
Each of the BSD's have their own personality and group of adherents. There is a secondary circle that may love all BSDs. Long ago there was east coast unix and west coast unix. The BSDs represent the West Coast thread.
I just like the BSDs because they all maintain a single document that can get you from a single system host install to a supporting network installs DHCP->TFTP install.
I always go for either NetBSD "We install on anything" or OpenBSD "We are still just trying to get secure implementation of the 4.4 spec"
Unlike some other operating systems, OpenBSD encourages users to split their disk into a number of partitions, rather than just one or two large ones. Some of the reasons for doing so are:
• *Security: Some of OpenBSD's default security features rely on filesystem mount options such as nosuid, nodev, noexec or wxallowed.*
• *Stability: A user or a misbehaved program can fill a filesystem with garbage if they have write permissions for it. Your critical programs, which hopefully run on a different filesystem, do not get interrupted.*
• *fsck(8): You can mount partitions that you never or rarely need to write to as readonly most of the time, which will eliminate the need for a filesystem check after a crash or power interruption.*
[1]: https://www.openbsd.org/faq/faq4.html#Partitioning
the bit that resulted in me removing it from all my routers/firewalls was having to run "make world" and rebuild the entire OS to install security fixes
not at all practical on a router with a underpowered cpu and little disk
apparently the developers have had a change of heart here (previously they didn't believe in providing binaries for security fixes)
That particular problem has been addressed in the more common architectures - syspatch was introduced in OpenBSD 6.1 (April 2017) https://man.openbsd.org/syspatch
I think the expectation is that you would cross-compile for your router on a faster machine. I have no idea whether you need to be running OpenBSD on the build machine.
This is indeed how I did it before syspatch was available. I ran a more powerful Dell Optiplex tower as my "build box" and built the -stable branch on it, then installed those sets on my low power router boxes.
With OpenBSD in particular I like it because from the default install it's got a built in web server [1] which can handle most use cases. I can pretty much just put it anywhere and trust in the secure defaults that it provides, throw my own software on that server, and then have a pretty good standard from OS level to my own software on how secure that's going to be. It doesn't change much [2].
Linux doesn't really offer that. Yeah it's got PACKAGES that offer web server solutions (apache, nginx, whatever else) but then I gotta maintain those. I find myself having to patch everything on my OpenBSD boxes way less if I stick to how it seems to be intended to be used - When all I've got to maintain are my own secure os installation + configuration, and my own software that I wrote myself, literally no packages, it's really cool.
The documentation and the source code is all you need to do anything with an OpenBSD system. There is no need to track down anything the OpenBSD doesn't explicitly provide or document.
They're best suited for people who had a good experience with a BSD in the 90s and are sentimental about that. Otherwise, there's really no reason to go with them over a Linux system.
For me there's really no reason to go with linux over BSD (or illumos). For the occasional linux-locked software one can always run lx-zones or full bhyve HVMs anyway.
Some would say the only notable example is Netflix and it’s likely because of the aforementioned warm fuzzies which align with the ages of people who made the decision to go with it.
WhatsApp also used a BSD IIRC but I imagine they’ve transitioned to Meta’s standard stack by this point.
> WhatsApp also used a BSD IIRC but I imagine they’ve transitioned to Meta’s standard stack by this point.
Yes, that happened. I was there. FreeBSD is great and we would have continued to use it, but as an aquisition, you can only push back on so much of the incumbent tech stack. Much of the team had experience at Yahoo and saw how hard it is for acquisitions to run in the same infrastructure if they're running a different OS, so we spent zero time asking to run FreeBSD at Facebook.
The hardware at Facebook was quite a bit different, so there was never an apples to apples comparison to say whether one OS (as tuned) was better than the other at the use case. They clearly both work, and I've got my opinions and other people have theirs, and that's fine.
I think it is sadly not true for the Nintendo Switch [1], so it seems that it is still mainly Apple’s macOS and Sony’s PlayStation 3 and 4 [2,3] (could not find any hard facts on the PlayStation 5, but it is still early days).
You have also had patches go from Apple straight into the FreeBSD tree with improvements they made on their side. So, yes, it certainly is not as easy a case as one would make for Sony’s forks, but the answer is certainly not a resounding “no”.
It’s too bad certain games don’t use this idea of random load locations to avoid injections. Seems like most game hacks basically work by reading/manipulating certain memory offsets which contain useful data. Unless I misunderstand them.
That's how I used CheatEngine back in the day. You would probe the game's memory looking for a value you can control (like health, item count, etc.) then increment/decrement it in game until you reliably found which location in memory was changing. Then you'd save it with a name and enjoy your cheat.
I used to use OpenBSD about a decade ago, I liked it quite a bit. I haven’t paid attention for over a decade though. Does anyone know how the maintainer base has evolved? I guess my main question is will OpenBSD survive Theo’s death?
> In a prime example of hacker humor of the time, a T-shirt featuring one of the early appearances of Puffy the blowfish that would become the project mascot touted the Blowfish password hashing algorithm which remains the default on OpenBSD both with the picture caption "So long and thanks for all the passwords" just below Puffy on the front, along with the full source code of the blowfish function on the back.
Is it better than sliced bread, no. But it does some things better than other systems.
First, it feels small enough that I understand what’s going on while still providing valuable services out of the box - a web server, load balancer/proxy, etc.
But more importantly the pieces all play together to make a unified system: the load balancer can do layer 3 by interacting with the system firewall, httpd works with the built in ACME client for TLS. All those pieces benefit from being part of the system as a whole, by having very consistent tooling and support - things are named very consistently and share flags across the system, and are backed by very high quality manpages.
Simply put it’s not perfect, nor revolutionary, but it gets a lot of things right.
This appears to have been published in the second half of 2021.
I recall some heady weeks in 1998, attempting to enable IPSEC between my twin OpenBSD Apollo 425t systems. "hard and near impossible to debug from an almost-working to a fully working setup" is an understatement! I never got it to the almost-working stage!
> What every IT person needs to know about OpenBSD
First thing that we need to know - what is it? I had to look up on Wikipedia for information on what this is and what it's trying to solve.
So my takeaway is that not every IT person needs to know this since I've been in the field for over 20 years and worked at a wide range of tech companies (from Unicorns to academia to fortune 100 companies to FAANG or whatever the name is now)?
It's a shame when articles like this make so many assumptions about their audience. It reminds me of the RTFM days of tech that was dismissive, arrogant, and not all that helpful.
Do you expect every article to assume that everyone reading it is ignorant of the topic? Then we would have same lines of introductory text in most articles which would be time-wasting since you can go and google the software that you don't know about.
It is just a linux distro. Not a handsome one either. "Every" IT person needs to learn how to use Windows Server first before jumping onto these things because 90%+ companies are using Windows Server.
Except it really isn’t, distros usually refer to different distributions of Linux but not different types of operating system.
I usually say to layman that they are different forks of unix from many years ago.
OpenBSD and Linux have a lot of the same tools to be sure but they are different enough that you have to learn them both if you are administering them.
> There is nothing that every IT person _needs_ to know about OpenBSD.
I absolutely agree. Such clickbait headlines are often strange. For a more macabre example, consider the headline "10 [things] you can't live without". This means that if you don't own these ten things, you will die.
It is a little weird seeing Peter N. M. Hansteen of all people use a clickbaity headline, but it's still not a bad thing to be aware of at least. The man will evangelize his favorite thing, he's a nice fellow.
I think OpenBSD will still be relevant outside of its own OS realm as long as people are still using software that comes from the project (openssh, tmux etc).
I agree. To underline the futility of this article, the factoid it leads with was how many years OpenBSD has been around. That bit of trivia is completely irrelevant and has no technical meaning or direct implication. No one ever asked during unscheduled downtime "quick, does anyone know how many years OpenBSD has been around for?"
It does carry meaning, see https://en.wikipedia.org/wiki/Lindy_effect. It's not something to know during downtimes, but at the point in time where you decide which technology to use going forward. Contrast this with the lifetimes of popular Javascript frameworks.
maturity of a project definitely matters; in larger businesses, the maturity of a product and how long it's had to "get past the teething stage" is very important, and for projects with public repos/issue trackers, you can get a nice feel for how the devs handle critical bugs going into it, or check if a major pain point for you has come up before and how they handled it.
the article is a call to get you comfortable picking/using BSD, and from my point of view it's reasonable to advertise its maturity.
I'm not a professional in any of this, but just from reading comments it appears that devs seem to prefer the latest, greatest, coolest thing while admins seem to prefer the oldest, robustest, boringest thing.
I can completely get that understanding; I'm not enough of a programmer to really make sense of a lot of low level code, but enough that I can understand the type of issues they've solved and how they did it.
I suspect you are correct because newest and greatest typically solve a problem, and that's the focus for the devs. the more senior devs I know take an "optimistic but cautious" approach, while less experienced devs/non-devs typically just see an answer to their particular problem and want to use it, as defending the use and the few broken instances is typically easier than solving the issue without the latest and greatest. and I can get that easily
admins probably like old and trusted because boring is exciting for them; for a few of the systems I admin, it's great to have a few on debian/bsd where they've proven that I don't need to babysit these systems; they're never fully out of the equation when troubleshooting, but it comes up rarely, and if worst comes to worst, a reboot on these systems is typically so fast and non-disruptive that it's an easy decision, which often helps and then the issue never returns. sure it's not good that I had to reboot, but a down time of 10 seconds while I boot and it never comes up again is appealing.
Code is maintenance heavy and tends to have interdependencies on other related code. Eg, I wouldn't use qt4 today because it's dead, so if something is wrong with it it's now my problem to figure out how to fix it.
Meanwhile qt6 is under active use and development, so I'm much more likely to find help and bug fixes, and developer interest. And it's less likely to say, stop building because cmake deprecated some ancient feature, or uses some ancient and now incompatible library.
Can't speak for devs, but admins definitely prefer old, robust and boring. Smart devs prefer admins with these preferences, though they might not be conscious of it.
Every single time I see something related to BSDs, I think the same. How tiring...
For more than a decade, every single thing related to BSDs has been largely irrelevant. Every. Single. Thing.
Nobody cares about that, the only thing BSDs had was their license (vs. the GPL), and that's not entirely clear to have been good at all for the ecosystem (because, clearly, Linux has enjoyed a much greater development). Nowadays, even in embedded it's either Linux or RTOS, nothing like BSDs at all, so the GPL is clearly a non-issue.
Vulkan seems to be incomplete. Graphics drivers for Nvidia are a problem due to the project not accepting blobs, not signing NDAs. And today I had a problem installing matplotlib (ninja gave some error). AFAIK, tensorflow and/or python libs are a problem with *nix as well.
Latency sensitive? I'd guess you'd have some issues, because I've read that OpenBSD doesn't have syscalls to set cpu affinity for userspace threads/processes, which means you're subject to the kernel scheduler and might have tasks move in less than ideal ways.
Not that I have ever enabled graphics or sound on my OpenBSD boxes - but I would say it’s probably not my first, second or third choice of OS for this.
But my recording studio would probably bore you as I just run macOS for both graphics and sound work.
Considering OpenBSD still supports some fairly old platforms[0] (for fairly good reasons, mainly that it helps catch bugs and keep the source tree portable) I don't see that happening soon.
As an aside, github's issue search has really gone to shit.
On that list, I think only the Loongson and Landisk architectures are in the not likely to ever be supported. The rest are all supported by LLVM and/or GCC with various efforts to support them in rust.
Wow, down votes for a question. As a non rust developer, and non BSD user, but tangently aware of these things I am just trying to understand the energy of these communities. Guess I got my answer.
OpenBSD is a tier 3 platform for Rust because of their release policy (frequent releases, no guaranteed backwards compatibility). Unless that changes it's unlikely that you'll see OpenBSD promoted beyond tier 3. From the OpenBSD side it's unlikely they'd adopt a language that's relegated them to the lowest priority.
I think if a web page formatted with nothing more than <h1>, <h2> and <p> tags isn't displayed well on your phone, the failing is with your browser, not the page.
Surely a web page with utterly default style and zero layout should be a minimally cromulent experience on any device. It's just headings and paragraphs, with the occasional bullet point and indent. There's no stylesheet. There's no reference to millimetres, pixels or point sizes. Everything is defaults.
Amazing that I would run into the owner/operator of Whirlpool on hn. I used the site a lot back in the day for modem/networking help. Thanks for all the fish!
Unlike my website, the page here is a static document. I see no information density issue showing a static document with generic mark-up. The page has no features at all, dense or otherwise. The page has no need for brand, it's just a document written by someone, and that person probably doesn't have a personal logo or corporate colours.
> it seems I am wrong for wanting them.
I never said that. What I said is that the browser is wrong for giving you an unsatisfactory experience with a generic web page.
Portable version exists and the Linux world should have replaced openssl by now, but for unknown reasons this is yet to happen.
I am hopeful someday one of the larger distributions such as Debian will have the courage to step forward.