OpenBSD, the computer appliance maker's secret weapon(hiandrewquinn.github.io)
hiandrewquinn.github.io
OpenBSD, the computer appliance maker's secret weapon
https://hiandrewquinn.github.io/til-site/posts/openbsd-the-computer-appliance-maker-s-secret-weapon/
96 comments
There's something... oddly satisfying about tailing your logs and watching skiddie exploits harmlessly glance off OpenBSD's hide. Still the only OS I'd trust hooking directly up to the internet with a web server or something, without a firewall of some sort in between.
I got into OpenBSD again when I bought a new, cheap potato to play with -- an HP thin client PC I scored off eBay for $25. The super-lightweight candidate operating systems I tried for it -- AROS and Haiku -- both struggled with its eMMC controller and couldn't even find a volume to install to; the same, oddly, was true of NetBSD. OpenBSD found it just fine.
I got into OpenBSD again when I bought a new, cheap potato to play with -- an HP thin client PC I scored off eBay for $25. The super-lightweight candidate operating systems I tried for it -- AROS and Haiku -- both struggled with its eMMC controller and couldn't even find a volume to install to; the same, oddly, was true of NetBSD. OpenBSD found it just fine.
> There's something... oddly satisfying about tailing your logs and watching skiddie exploits harmlessly glance off OpenBSD's hide
It's nothing to do with OpenBSD though, is it. I swear it's ingrained to people to just unconsciously compliment OpenBSD's security and spread the myth.
Put fail2ban on a public facing webserver or setup any kind of honeypot and enjoy the exact same thing.
It's nothing to do with OpenBSD though, is it. I swear it's ingrained to people to just unconsciously compliment OpenBSD's security and spread the myth.
Put fail2ban on a public facing webserver or setup any kind of honeypot and enjoy the exact same thing.
Why would you turn off the firewall?
Because you just have services that are already "internet hardened" running?
Sounds like a poor reason to turn off your firewall
Can't see a reason to close ports with firewall on which there is nothing listening anyway.
The best defence, IMO, is not to have the thing if you don't need the thing. Having to remember about it all the time sometimes prevents the work from getting done.
The best defence, IMO, is not to have the thing if you don't need the thing. Having to remember about it all the time sometimes prevents the work from getting done.
You may want to not send back the "unreachable port" ICMP messages that are the default behavior for ports on which there is nothing listening.
The traditional configuration for a server or router is to block in the firewall all the unused ports, which means that ICMP responses will not be sent back, with the exception of the range of ports that are normally used by the "traceroute" utility.
Unfortunately, there are also stupid people who block in the firewall even the traceroute ports, which makes more difficult the diagnosing of any network problem.
The traditional configuration for a server or router is to block in the firewall all the unused ports, which means that ICMP responses will not be sent back, with the exception of the range of ports that are normally used by the "traceroute" utility.
Unfortunately, there are also stupid people who block in the firewall even the traceroute ports, which makes more difficult the diagnosing of any network problem.
What would the firewall do in this case exactly? It's just a webserver, so you'd normally allow all http/https traffic through anyway.
> If they run into OpenBSD, however, their efforts are quite likely to be thwarted just because the blowfish is so darn spiky.
Ehhhhhhh.
As a teen eating up all the computer security stuff I could find, and getting into osdev and learning as much as I could, OpenBSD always seemed kind of off to me. The security claims are hugely overstated, and for an OS that claims security as its focus, they are slow if not reluctant to add tools that vastly increase security, like even a simple RBAC implementation.
Disabling services by default should have been the default for all operating systems, and writing OpenSSH has been great, but let's all stop perpetuating the myth of OpenBSD as an especially hardened OS.
I agree about the BSDs being a secret weapon, but that's more to do with the license as someone else mentioned, and I'd think Net and Free are more commonly taken from.
Ehhhhhhh.
As a teen eating up all the computer security stuff I could find, and getting into osdev and learning as much as I could, OpenBSD always seemed kind of off to me. The security claims are hugely overstated, and for an OS that claims security as its focus, they are slow if not reluctant to add tools that vastly increase security, like even a simple RBAC implementation.
Disabling services by default should have been the default for all operating systems, and writing OpenSSH has been great, but let's all stop perpetuating the myth of OpenBSD as an especially hardened OS.
I agree about the BSDs being a secret weapon, but that's more to do with the license as someone else mentioned, and I'd think Net and Free are more commonly taken from.
OpenBSD was stagnant when it came to hardening for a while, but the last few releases really added new defense in depth technologies e.g. whitelisting all syscall entry points at link time -> if your process doesn't contain fork() and execve() they're is unavailable even after you exploited a RCE. If the process is already restricted by pledge() and unveil() it can't just regain the disabled system calls. These technologies are not a fine grained and "theoretical sound" like a pure capability like FreeBSD's Capsicum, but they're a whole lot easier to retrofit to existing non-trivial applications which means more code is covered by good enough mitigations to drive the attack costs up significantly and make certain (classes of) bugs unexploitable.
The thing is I find stuff like pledge adn unveil to be basically toys. Pledge especially since it relies on the software author utilizing it. We've had stuff like RBAC and MAC implementations for 20 years, and RBAC doesn't have to be complicated, look at AppArmor. If the OpenBSD guys really cared about security, they would be working on something like that.
Look at their remote root ssh bug. If they were a secure OS, someone getting remote root wouldn't be such a big issue, with RBAC/MAC it's clearly not such an issue, with the default 'secure' install, it sure was. Then again, I don't think the obsd devs have a real interest in security, so much as an interest in correcting bugs, which they falsely equate to be the same thing. Pretty sure one dev had no idea what MAC/RBAC even is and was trying to claim pledge is the exact same thing, which only lessens any confidence I had in them.
Look at their remote root ssh bug. If they were a secure OS, someone getting remote root wouldn't be such a big issue, with RBAC/MAC it's clearly not such an issue, with the default 'secure' install, it sure was. Then again, I don't think the obsd devs have a real interest in security, so much as an interest in correcting bugs, which they falsely equate to be the same thing. Pretty sure one dev had no idea what MAC/RBAC even is and was trying to claim pledge is the exact same thing, which only lessens any confidence I had in them.
The remote ssh bug? It was caused by some Linux distributions patching sshd to link to libsystemd which required liblzma which had the backdoor. It didn’t affect OpenBSD or involve upstream OpenSSH.
I mean the remote ssh bug from 2002 that caused OpenBSD to alter their tagline to "One remote hole in the default install, in nearly 6 years!". Pretty sure that affected OpenBSD.
The thing that seems to be missing from your post is a list of examples of its security not being all that in practice.
I wouldn't say it's missing. I deliberately generalized. I mentioned RBAC as an example.
If people want to learn more there is no shortage of info. There was even a talk[0] at the 36th CCC.
[0] - https://www.youtube.com/watch?v=3E9ga-CylWQ
If people want to learn more there is no shortage of info. There was even a talk[0] at the 36th CCC.
[0] - https://www.youtube.com/watch?v=3E9ga-CylWQ
Doesn't OpenBSD files system corrupt easily, ie due to powercuts? I can recall OpenBSDers talking about how they used a UPS to prevent this.
My first observation of this calm oasis was watching a Dell Compellent boot around 2010. I was somewhat happy to see a familiar boot process on the display!
Presumably those where running FreeBSD? Can't imagine that Compellent was Net- or OpenBSD based.
[deleted]
I don't know, to this day I collect logs from my AWS instances and ripgrep/tail/less them like some unwashed pleb from the 1990s. I package RPMs and build containers from them. It's efficient, and I like to know what my stack is made of all the way up and all the way down. Is this such a boomer notion to have? (You could argue that "millenials are becoming the new boomers", but you know what I mean, stop nitpicking.)
What's completely missing here is a big topic: compliance and security
Both OpenBSD and FreeBSD have laughable security disclosures and absolute lack of any compliance processes, which is the most important part as a vendor of anything.
FreeBSD even got that far that they invented their own VuXML format (without a spec, of course) instead of adopting an open standard like OVAL, which is used by most enterprise distributions. In the BSD world, vulnerability disclosures happen via mailing lists, aka, bad luck if you missed the email. And that's the definition of being 100% unreliable.
OpenBSD doesn't even have a VuXML file. Only free form text archive of emails that is unparseable.
I don't understand how anyone can claim they are so super duper secure in their development cycle, while not even having a web page of security disclosures that happened in the past. It's pretty damn narcisstic to be honest.
Both OpenBSD and FreeBSD have laughable security disclosures and absolute lack of any compliance processes, which is the most important part as a vendor of anything.
FreeBSD even got that far that they invented their own VuXML format (without a spec, of course) instead of adopting an open standard like OVAL, which is used by most enterprise distributions. In the BSD world, vulnerability disclosures happen via mailing lists, aka, bad luck if you missed the email. And that's the definition of being 100% unreliable.
OpenBSD doesn't even have a VuXML file. Only free form text archive of emails that is unparseable.
I don't understand how anyone can claim they are so super duper secure in their development cycle, while not even having a web page of security disclosures that happened in the past. It's pretty damn narcisstic to be honest.
So *BSD is a joke because all the apparatus, "compliance processes" and "standards" are not followed? Is that the gist of it?
Never mind the actual security and quality of the code and professionalism of the people involved. The dances are not performed and the compliance Gods are not appeased.
btw: https://www.vuxml.org/freebsd/
Never mind the actual security and quality of the code and professionalism of the people involved. The dances are not performed and the compliance Gods are not appeased.
btw: https://www.vuxml.org/freebsd/
> Never mind the actual security and quality of the code
Security is not about code quality, it's about how quickly you can mitigate mistakes. And "quickly" meaning since around 2005ish that it is done in an automated manner.
For BSDs, you will always need a dedicated person that is not only able to read code, but also able to maintain patchsets, roll out an update mirror for themselves, and understand _every line of code_ of the distribution, because BSD doesn't have a workflow to let package maintainers communicate what happened in CVEs so that their using parties can consume that data in an automated manner.
Nobody will do that job correctly, because nobody can. If you claim you can do, you must be the all knowing "God of compliance" how you put it. If you think you don't make programming mistakes, guess what, you are wrong.
Get over your elitarian opinion and realize that all humans make mistakes, therefore automated tools must adapt to that scenario and ease up mitigating those issues.
And that's where open industry standards like OVAL come in.
Security is not about code quality, it's about how quickly you can mitigate mistakes. And "quickly" meaning since around 2005ish that it is done in an automated manner.
For BSDs, you will always need a dedicated person that is not only able to read code, but also able to maintain patchsets, roll out an update mirror for themselves, and understand _every line of code_ of the distribution, because BSD doesn't have a workflow to let package maintainers communicate what happened in CVEs so that their using parties can consume that data in an automated manner.
Nobody will do that job correctly, because nobody can. If you claim you can do, you must be the all knowing "God of compliance" how you put it. If you think you don't make programming mistakes, guess what, you are wrong.
Get over your elitarian opinion and realize that all humans make mistakes, therefore automated tools must adapt to that scenario and ease up mitigating those issues.
And that's where open industry standards like OVAL come in.
> So *BSD is a joke because all the apparatus, "compliance processes" and "standards" are not followed? Is that the gist of it?
No one said anything like that. They're just saying it's harder for developers and businesses to utilize them as they do other projects that use standard formats and practices. Relax.
No one said anything like that. They're just saying it's harder for developers and businesses to utilize them as they do other projects that use standard formats and practices. Relax.
> while not even having a web page of security disclosures that happened in the past
https://www.openbsd.org/errata75.html
https://www.openbsd.org/errata75.html
You seem to have ignored the rest of my comment on purpose.
Useless source, because it is not parseable in an automated manner.
Useless source, because it is not parseable in an automated manner.
isn't this a list of all FreeBSD vulnerabilities over time?
https://www.freebsd.org/security/advisories/ or
http://vuxml.freebsd.org/freebsd/index.html
Missing one of the infrequent emails from the security mailing list would be hard but my boxes also email me about vulnerabilities they are exposed to so it would be very hard to ignore them.
I am sure there is room for improvement though.
https://www.freebsd.org/security/advisories/ or
http://vuxml.freebsd.org/freebsd/index.html
Missing one of the infrequent emails from the security mailing list would be hard but my boxes also email me about vulnerabilities they are exposed to so it would be very hard to ignore them.
I am sure there is room for improvement though.
If only you could install Java.
You can? There's OpenJDK 17 available
Is that native support?
Ahh, even version 21 now, I've been waiting for that one
[deleted]
> This is the little slice of computing heaven I currently live within. In a lot of ways it feels like what I imagine employed hackers of old in the 90s were up to.
That does sound like a dream come true; how does one end up in such a gig?
> If only there were a freely-usable set of Unix-like operating systems, with an emphasis on keeping things very, very stable over releases, even more stable than Debian does. Enter the BSDs. Free, Open, Net, take your pick. All of them take a “don’t fix it if it ain’t broken” approach to things, which means someone who started slinging NetBSD installs back in 2007 can probably spin up a well-manicured VM of that 2007 install and reliably make their way around the system, even today, in 2024.
I dearly love all the major BSDs, but that... isn't the argument I would make for OpenBSD, which is quite happy to break things to improve them. For example, replacing sudo with doas - excellent move, but if you go back multiple versions your knowledge no longer works, much like Debian.
(If I were making suggestions, I tend to feel that NetBSD has largely not yet realized it isn't a barely-forked UNIX running on a VAX; it feels much more unchanging to me, at least from a user perspective, though perhaps I merely lack the experience to know better.)
That does sound like a dream come true; how does one end up in such a gig?
> If only there were a freely-usable set of Unix-like operating systems, with an emphasis on keeping things very, very stable over releases, even more stable than Debian does. Enter the BSDs. Free, Open, Net, take your pick. All of them take a “don’t fix it if it ain’t broken” approach to things, which means someone who started slinging NetBSD installs back in 2007 can probably spin up a well-manicured VM of that 2007 install and reliably make their way around the system, even today, in 2024.
I dearly love all the major BSDs, but that... isn't the argument I would make for OpenBSD, which is quite happy to break things to improve them. For example, replacing sudo with doas - excellent move, but if you go back multiple versions your knowledge no longer works, much like Debian.
(If I were making suggestions, I tend to feel that NetBSD has largely not yet realized it isn't a barely-forked UNIX running on a VAX; it feels much more unchanging to me, at least from a user perspective, though perhaps I merely lack the experience to know better.)
Not as radical a change as, e.g. integrating systemd though
The aim of systemd seems to be to use the Linux kernel as the base for a non-unix OS as shown (hence the "now with 42% linux philosophy tagline of the latest recent release https://www.theregister.com/2024/06/13/version_256_systemd/).
Its not a bad idea if you agree with the aim - Linux already has lots of hardware support and an ecosystem to leverage.
In the long run BSDs and non-systemd Linux will be more similar to each other than they are to Linux with systemd in a lot of ways.
I have started using Alpine for servers - its small and fast. Not so sure about switching on desktops.
Its not a bad idea if you agree with the aim - Linux already has lots of hardware support and an ecosystem to leverage.
In the long run BSDs and non-systemd Linux will be more similar to each other than they are to Linux with systemd in a lot of ways.
I have started using Alpine for servers - its small and fast. Not so sure about switching on desktops.
> I have started using Alpine for servers - its small and fast. Not so sure about switching on desktops.
It's fine. I've run it on laptops (IIRC, it does have the small downside of not sleeping on lid close by default) and my desktop (my gaming machine for a while; flatpak Steam runs nicely on Alpine) and it's fine.
It's fine. I've run it on laptops (IIRC, it does have the small downside of not sleeping on lid close by default) and my desktop (my gaming machine for a while; flatpak Steam runs nicely on Alpine) and it's fine.
> Not so sure about switching on desktops.
I've been using it for years. It's the successor to slack for me. Not a fan of rolling release and prefer minimalism to Devuan's approach. Void looks interesting but I had issues, whereas I had none with Alpine. I recommend it.
I've been using it for years. It's the successor to slack for me. Not a fan of rolling release and prefer minimalism to Devuan's approach. Void looks interesting but I had issues, whereas I had none with Alpine. I recommend it.
> I have started using Alpine for servers - its small and fast.
I'm curious about "fast" here, as for "small" I don't care much - you mean benchmarks doing better on Alpine or fast in which terms?
I'm curious about "fast" here, as for "small" I don't care much - you mean benchmarks doing better on Alpine or fast in which terms?
I don't believe for a moment that was the initial aim of systemd. They just tried to improve on a pile of hacks and by pulling on that string it sort of ends up touching (or from your perspective infecting) everything.
It vaguely reminds me of people arguing about "what color is your function". You open that portal and end up in a new universe. All or nothing.
The unix wars are long over I'm not sure what you can point to that ever was a True Unix. Nostalgia not withstanding. What well defined standard Right Way you're actually clinging to is not clear.
Whether it will end up for the best or not I don't know but the entire saga seems to be the pitfalls of endless tinkering on display rather than some unifying vision. I wish we lived in a world where systemd type efforts had clear end goals and well thought out architecture in mind when they start but open source doesn't like working this way.
It just ends up as "my favorite way of doing things is better" based on vibes. In both directions. That's the problem with "philosophies".
It vaguely reminds me of people arguing about "what color is your function". You open that portal and end up in a new universe. All or nothing.
The unix wars are long over I'm not sure what you can point to that ever was a True Unix. Nostalgia not withstanding. What well defined standard Right Way you're actually clinging to is not clear.
Whether it will end up for the best or not I don't know but the entire saga seems to be the pitfalls of endless tinkering on display rather than some unifying vision. I wish we lived in a world where systemd type efforts had clear end goals and well thought out architecture in mind when they start but open source doesn't like working this way.
It just ends up as "my favorite way of doing things is better" based on vibes. In both directions. That's the problem with "philosophies".
It may not been the initial intention, but the aim of adding a layer to the OS does lead to what is effectively a new OS. Its a bit like MacOS vs BSD, or maybe Chimera Linux (Linux kernel with BSD userland) or Debian/kFreeBSD.
The best argument I have seen for systemd is that it adds a layer that will be used and standardised across multiple distros (most effectively in a video of a talk by a FreeBSD developer). The best argument against is that it is massive and does too much.
The best argument I have seen for systemd is that it adds a layer that will be used and standardised across multiple distros (most effectively in a video of a talk by a FreeBSD developer). The best argument against is that it is massive and does too much.
> systemd.. adds a layer that will be used and standardised across multiple distros
Like Google Play Services on Android.
Like Google Play Services on Android.
Given android doesn't use systemd, and containers don't expose it even if the host machine uses it, systemd isn't actually that entrenched or irreversible. Containerized applications don't know or care, and neither do all the people toting around android as phones, tablets, or laptops. Unix may only be tied together as a concept at this point by a posixish libc api, and that is probably just fine.
ChromeOS doesn't use systemd, either. (It uses upstart, which I am guessing they have to maintain without any significant outside help.)
I'm pretty sure ChromeOS is getting upstart from their Gentoo base, so what little maintenance it needs should be shared. And I do mean little maintenance; without systemd's infinite scope creep, an init system could reach "done" and coast indefinitely.
[deleted]
Author here - yeah, as I've learned more about OpenBSD I've realized that, while "don't fix it if it ain't broken" is still a valid claim about their overall approach, the OpenBSD hackers also just ... see a lot of stuff that's broken, everywhere.
Still, somehow, on the margin, I feel I'd be more comfortable hopping back into a much earlier OpenBSD than a much earlier Debian. Maybe it's a taste thing.
Still, somehow, on the margin, I feel I'd be more comfortable hopping back into a much earlier OpenBSD than a much earlier Debian. Maybe it's a taste thing.
What NetBSD's focus is to get it running on all possible hardware so yea that's why they really haven't gotten it to be much more different than any of the other BSDs.
Since OpenBSD's purpose is to make one of the most secure UNIX platforms that's where they generally break things. They also anticipate security holes related to speculative execution like disabling hyperthreading.
Since OpenBSD's purpose is to make one of the most secure UNIX platforms that's where they generally break things. They also anticipate security holes related to speculative execution like disabling hyperthreading.
[deleted]
I've played this distro hopping game since I was a teenager and they were mailing free cds of this weird new south-african thing called Ubuntu which wasn't nearly as cool as the FreeBSD 5.0 release.
Enough of the astrological pseudo-science. This distro is good for hackers, use this if you want stability, use this for bleeding edge, this one is secure by default, that one has a nice UI, it's all nonsense.
The only meaningful changes have been: The effective mandatory adoption of SystemD, and the emergence of NixOS.
NixOS elevates the entire discussion. I can't wait for it to work across different UNIX kernels. It's not ready for regular people, it's not even ready for most enthusiasts, the language is awful and the nixpkgs set is full of inconsistencies, but it's all worth it.
So let's stop with the voodoo and start applying the techniques in other places. Nix without Nix is what we need.
Enough of the astrological pseudo-science. This distro is good for hackers, use this if you want stability, use this for bleeding edge, this one is secure by default, that one has a nice UI, it's all nonsense.
The only meaningful changes have been: The effective mandatory adoption of SystemD, and the emergence of NixOS.
NixOS elevates the entire discussion. I can't wait for it to work across different UNIX kernels. It's not ready for regular people, it's not even ready for most enthusiasts, the language is awful and the nixpkgs set is full of inconsistencies, but it's all worth it.
So let's stop with the voodoo and start applying the techniques in other places. Nix without Nix is what we need.
Your humble author here... Sadly, I've heard Nix is quite a ways away from being ready for the big leagues with the BSDs.
I'm quite a fan of its approach as well, maybe a little less so when disk space is a big concern like it often is for computer appliances.
I'm quite a fan of its approach as well, maybe a little less so when disk space is a big concern like it often is for computer appliances.
you wouldn't be installing and forgetting loads of different versions of everything on computer appliances. you'd develop on a normal pc and then push just what's needed to the appliance.
on the dev pc you'd run garbage collection once your new env is acceptable and the old one gets removed.
on the dev pc you'd run garbage collection once your new env is acceptable and the old one gets removed.
>Nix without Nix is what we need.
OStree exists and is used in lots of places: https://ostreedev.github.io/ostree/#operating-systems-and-di...
OStree exists and is used in lots of places: https://ostreedev.github.io/ostree/#operating-systems-and-di...
Agreed it's an excellent step, I confess I don't know if it answers the package building component however.
> Nix without Nix
So, GNU Guix?
So, GNU Guix?
I have only read about it but my takeaway was that it was like an opinionated sibling technology rather than a successor one.
I don't know what a successor would look like, I worry that it would have to wrangle with 40 years of software compilation techniques.
I don't know what a successor would look like, I worry that it would have to wrangle with 40 years of software compilation techniques.
I would start with Gentoo, which has recipes to build stuff from scratch for just about everything.
I came from fbsd ports so agreed but that's what I'm saying, that's more thsn 20 year old tech and we should be able to improve.
You can use Nix to build derivations on at least some of the BSDs - so I guess if you wanted to build some BSD based appliance with Nix it is possible, but would take some doing…
> NixOS elevates the entire discussion.
NixOS and Docker and other Linux container and isolation madness only exist because the Linux illuminati can't admit that zones and ZFS got it right.
I wish Linux would just STFU and copy them already. Given the amount of code that has been spilled, Linux could have cleanroom reimplemented zones and ZFS 10 times over by now.
NixOS and Docker and other Linux container and isolation madness only exist because the Linux illuminati can't admit that zones and ZFS got it right.
I wish Linux would just STFU and copy them already. Given the amount of code that has been spilled, Linux could have cleanroom reimplemented zones and ZFS 10 times over by now.
So... Linux literally has ZFS, ported wholesale from OpenSolaris, and is also homegrowing BTRFS and bcachefs as alternatives. I don't think zones could be ported as easily as ZFS, but LXC seems like a pretty close recreation, and honestly for most people I think docker was an improvement.
No, zones / jails are about isolation. I'm talking about composability and repeatability.
The process feels more like compiling a program than decorating a house.
The process feels more like compiling a program than decorating a house.
And HP-UX Vaults.
Just use ZFS with Linux? It's been available as kernel modules for I don't know how long.
I was under the impression that was the much less reliable implementation of ZFS but maybe I'm remembering incorrectly.
No it's the one true implementation now. With original flavour developers and everything.
Saying that something hasn't evolved in almost 20 years is a... strange flex ? I suppose there's a need for everything.
I appreciate something like that. It can mean one of two things:
* it's abandoned.
* it's good for what it does, why change it?
I don't know, to be honest, in which of these most BSDs are. But I see very little reason for an Operating System's tools and utilities to have changed much since the early 2000's. Perhaps even since the 1990's. Sure, their implementations may have been significantly improved, and maybe they've got some new stuff (specially in things that do need to evolve, like crypto) but the overall user interface remains the same. I think we should start seeing change for the sake of change as a bug, not a feature.
* it's abandoned.
* it's good for what it does, why change it?
I don't know, to be honest, in which of these most BSDs are. But I see very little reason for an Operating System's tools and utilities to have changed much since the early 2000's. Perhaps even since the 1990's. Sure, their implementations may have been significantly improved, and maybe they've got some new stuff (specially in things that do need to evolve, like crypto) but the overall user interface remains the same. I think we should start seeing change for the sake of change as a bug, not a feature.
it's good for what it does, why change it?
Immediately, this quote came to mind: Those who don't understand Unix are condemned to reinvent it, poorly. - Henry Spencer
Alternatively, Just do what slack did with irc. 'Reinvent' it with a modern interface and some fixes. The mercurial masses will flock to the hot new platform, VC will shower you with adoration and cash, we'll tell stories about how you don't eat breakfast and only ever wear one sock. Everyone will emulate you and then you can come back around as a wealthy guru investor. - @more_corn
Or the wise man yells at cloud version, It used to be the case that people were admonished to "not re-invent the wheel". We now live in an age that spends a lot of time "reinventing the flat tire!" The flat tires come from the reinventors often not being in the same league as the original inventors. This is a symptom of a "pop culture" where identity and participation are much more important than progress... - Alan Kay (2016)
... via https://github.com/globalcitizen/taoup
Immediately, this quote came to mind: Those who don't understand Unix are condemned to reinvent it, poorly. - Henry Spencer
Alternatively, Just do what slack did with irc. 'Reinvent' it with a modern interface and some fixes. The mercurial masses will flock to the hot new platform, VC will shower you with adoration and cash, we'll tell stories about how you don't eat breakfast and only ever wear one sock. Everyone will emulate you and then you can come back around as a wealthy guru investor. - @more_corn
Or the wise man yells at cloud version, It used to be the case that people were admonished to "not re-invent the wheel". We now live in an age that spends a lot of time "reinventing the flat tire!" The flat tires come from the reinventors often not being in the same league as the original inventors. This is a symptom of a "pop culture" where identity and participation are much more important than progress... - Alan Kay (2016)
... via https://github.com/globalcitizen/taoup
15 to 30 year lifespan of an average B2B computer appliance
Decades of recurring, non-evolving revenue vs. S-curve surfing.
Decisions, decisions.
With an unchanging system you could sit on the beach collecting the recurring revenue, or build new products and look for more customers. It's not as glamorous as trying to get a hyperscaling startup but there's a lot of money to be made doing boring things.
Author talks about stability of the userland.
OpenBSD is innovative, especially in all matters of security and stability. SROP, privilege separation and revocation, W^X, PIE, trapsleds, fork+exec separation.
Removing weaknesses is evolution.
OpenBSD is innovative, especially in all matters of security and stability. SROP, privilege separation and revocation, W^X, PIE, trapsleds, fork+exec separation.
Removing weaknesses is evolution.
Especially if you see other OSs actually devolving.
Enshittification is also happening for software. "We haven't changed in 20 years" equals "Our stuff is not shittified".
The author has a good point but I am surprised they neglected to mention the most important aspect for any aspiring appliance maker:
The BSD license
Yes, thanks to the magic of the BSD license you can ship an appliance that is nothing more than a vanilla BSD and some hacky scripts and never have to worry about your customers demanding to see how much jank you have shoved into the box.
The BSD license
Yes, thanks to the magic of the BSD license you can ship an appliance that is nothing more than a vanilla BSD and some hacky scripts and never have to worry about your customers demanding to see how much jank you have shoved into the box.
As a user, that is precisely the main drawback of the bsds (as much as I love them, especially OpenBSD). If I'm using a bsd in some third-party computer, some icky middleman may have changed stuff in the system for which I'm not allowed to see the patches. If the license was GPL, I would have the right to see these changes!
Forbidding your users to see the inner workings of the system (hiding the jank that has been shoven into the box, as you say), does not seem like a positive thing..
Forbidding your users to see the inner workings of the system (hiding the jank that has been shoven into the box, as you say), does not seem like a positive thing..
Has nothing to do with the licence, if you need a lawyer (GPL) to see the magic changes in your appliance, you should probably not trust that vendor.
Also, if the appliance vendor has put in some binary blob/module, you have no right to see that either (only the changes to the kernel). In the end, it really doesn't matter.
Buy proprietary stuff or don't.
Also, if the appliance vendor has put in some binary blob/module, you have no right to see that either (only the changes to the kernel). In the end, it really doesn't matter.
Buy proprietary stuff or don't.
> Has nothing to do with the licence, if you need a lawyer (GPL) to see the magic changes in your appliance, you should probably not trust that vendor.
Of course! But trust is unnecessary with code in hand.
Of course! But trust is unnecessary with code in hand.
But you don't have the code, just the changes to the Linux-Kernel, and that is often NOT the secret sauce.
Again buy proprietary or don't, the license (if opensource) has nothing to do with it.
Again buy proprietary or don't, the license (if opensource) has nothing to do with it.
[deleted]
I mean, it's not great.
But there's plenty of jank in e.g. Android phones. And of course anything the vendor doesn't feel like open sourcing they can just cram into something like 'google play services' to keep it closed source.
And vendors who want to TiVo-ize Linux can do it just fine, thanks to the Linux kernel embracing the TPM.
But there's plenty of jank in e.g. Android phones. And of course anything the vendor doesn't feel like open sourcing they can just cram into something like 'google play services' to keep it closed source.
And vendors who want to TiVo-ize Linux can do it just fine, thanks to the Linux kernel embracing the TPM.
Tivoization is completely orthogonal to the issue of opaque patched blobs.
For example every software/firmware using custom Risc-V instructions is tivoized.
The problem of blobs are inability to examine it and inability to reasonably modify it.
Tivoization just makes it harder to run a software/blob on different hardware.
For example every software/firmware using custom Risc-V instructions is tivoized.
The problem of blobs are inability to examine it and inability to reasonably modify it.
Tivoization just makes it harder to run a software/blob on different hardware.
>every software/firmware using custom Risc-V instructions is tivoized
I disagree. Tivoization means using hardware restrictions unrelated to the core functionality of the hardware to make it difficult to run modified code. The original Tivo checked digital signatures in the bootloader. This isn't core functionality, because it could be deleted without harming anything.
Merely writing software for unique hardware doesn't count as Tivoization. It's very common for software written for older machines to only run on that exact machine, and nobody calls it Tivoization. There has to be some feature added specifically for the purpose of restricting user freedom.
I disagree. Tivoization means using hardware restrictions unrelated to the core functionality of the hardware to make it difficult to run modified code. The original Tivo checked digital signatures in the bootloader. This isn't core functionality, because it could be deleted without harming anything.
Merely writing software for unique hardware doesn't count as Tivoization. It's very common for software written for older machines to only run on that exact machine, and nobody calls it Tivoization. There has to be some feature added specifically for the purpose of restricting user freedom.
TiVoization is about the inability to patch a system you bought to run different software. The TiVo boxes would refuse to run the proprietary TiVo software that did the whole magic if they detected a modified version of any of the system software, this is what annoyed RMS and led to the GPLv3. It's nothing like custom instructions.
> For example every software/firmware using custom Risc-V instructions is tivoized.
Can you explain?
Can you explain?
> Forbidding your users to see the inner workings of the system (hiding the jank that has been shoven into the box, as you say), does not seem like a positive thing..
Indeed, I don't consider the BSD license a good thing from a user's perspective. Companies love BSD/MIT licensed software though.
Maybe I should have included a "/s" in my post.
Indeed, I don't consider the BSD license a good thing from a user's perspective. Companies love BSD/MIT licensed software though.
Maybe I should have included a "/s" in my post.
> If the license was GPL, I would have the right to see these changes!
if you can afford the lawyers.
if you can afford the lawyers.
I would have argued that the most important aspect for any aspiring appliance maker is security, and that OpenBSD provides for that incredibly well.
I don't think consumers value security that much.
But for appliance use, I think NetBSD has a very slight edge over OpenBSD:
* NetBSD has very long release cycles. OpenBSD's 6 month release means you will have to upgrade all appliances at least once per year.
* On install, NetBSD allows you to install a very small subset of the system. OpenBSD recommends installing all packages. But with that said, both systems are very small when compared to Linux.
OpenBSD to me has one advantage I can think of right now. Upgrading is a easier, if you keep upgrading every 6 months. They seem to be heading to fully automated upgrades.
But with NetBSD, it is possible to skip releases (ie: 8.x to 10.x) if you know what you are doing. I went from 7.1 directly to 9.3 and got a workable system. But that did mung pkgsrc, a bit of hacking got that "workable". Once the "emergency" was over, I did a full reinstall of 9.3.
Anyway, yes, I agree just about any BSD would be great for appliance use.