Do you have examples of what in OpenBSD you found "utterly complicated to setup and use"? I've been using for several years now because of how devoid of complexity it is and because of how comprehensive the documentation is. Trying to even install other Unices nowadays frustrates me to no end because they're more complicated than "just keep pressing enter".
I think it's the difference between being simple, and hiding complexity behind towers of abstraction. In my experience OpenBSD goes to great lengths to rethink systems and purge intrinsic complexity. By contrast, Linux tends to merge complexity behind meta interfaces.
OpenBSD's approach appeals to me aesthetically, and I like the feeling that I could easily dive in and get to the bottom of the stack. There is no magic.
By contrast, I look at Ubuntu as a hot mess of code that I'll never understand, while simultaneously appreciating that I can click through the installer after a cocktail or two and be playing games on Steam in short order.
the openBSD community is also very pragmatic in terms of backwards compatibility.
spending time make systems backwards compatible should be better spend making the path to using <newthing> as easy as possible, and a big help in that is keeping complexity down and not building towers of abstraction.
Arguably it's a little weird that it's under "softraid", when you don't know that it's a feature provided by the softraid layer. It's easy enough to figure out after a bit of searching, but it's not the first place I'd look either.
Makes it easier to add a pledge interface to other languages with having to keep chasing bit flag changes, ie. there's been several new promises add since 2015 but the OpenBSD::Pledge perl module hasn't needed to change.
And really, unless you're using pledge wrong, ie. by using it outside of the startup path and/or not checking the return value, what does compile-time checking get you?
It's also pretty trivial to run the program. Maybe it's different in other projects, but I'm pretty sure in OpenBSD you're encouraged to actually test the code, not just ship it because it compiles. There's 2 programs in OpenBSD's base that don't abort on the pledge call failing, they're both shells, and they don't fail quietly.
I stand corrected. From the commit message this seemed much more speculative than the FPU vulnerability (where Theo admitted to being tipped off by someone under the embargo), but clearly it's more than just speculation.
OpenBSD and DragonFly had their meltdown mitigations done in a couple of weeks from when it was publicly disclosed. If it's good enough for projects developed by handfuls of volunteers, it's good enough for the multi-hundred billion dollar megacorps.
So you're saying if a small software operation can put in place mitigations in X time then a absolutely massive hardware operation with hundreds of product lines consisting of some of the most advanced, ridiculously complex, slow to develop chips in the world can push a fix to many billions of devices in X time as well, whilst ensuring backwards compatibility and reducing the performance impact across the mind mindbogglingly large number of different workloads that their chips are used for.
Exactly. So how can you compare the work that's required from Intel to patch the flaw in new designs + mitigate it with microcode vs the work that's required from 'projects developed by handfuls of volunteers'?
It's a sysctl that can be toggled. If you want hyperthreading and don't care about the security concerns, you can turn it back on. The commit message specifically mentions that this was implemented because many modern machines don't allow hyperthreading to be disabled in the BIOS.
You'll find out in a couple of months why they did this. I hope you'll remember the comments you've written when that happens, because you might learn something about what OpenBSD means when they say they "strongly suspect" something.
As I already implied in the parent post, I've no doubt we'll see more Spectre-like issues and I don't find it hard to believe that there's yet another embargo going on, that something's leaked again and that the OpenBSD people have picked up on it. I'm just curious about how many tradeoffs in performance and usability OpenBSD would be willing to make (in the form of default settings, I'm aware this one can be toggled) in the pursuit of security and how they do the cost/benefit analysis, because their process seems vastly different from that of the main OS vendors.
On the latter point, I did take "strongly suspect" at face value rather than code for "we know for sure, just can't disclose it all yet" because I'm not familiar with the development culture of OpenBSD.
Though it doesn't answer your question directly, the project goals are here: https://www.openbsd.org/goals.html. Security is important, but not the only goal. Notice that the word "performance" does not appear on this page.
If you want performance above all else, OpenBSD is not for you.
There's no backpedaling, I still think their approach is crazy for any practical usecase I care about. Beyond that, I simply expressed curiosity to learn more about the extent of the tradeoffs they're willing to make.
They don't set defaults for the average use case when security is involved. This is the difference between:
"Secure by default", turn knobs if you need more speed
"Fast by default", turn knobs if you need more security
Not that the knobs will be always available for each design decision, but sometimes they are there and you can turn them at your own risk. It probably would be wise to understand the consequences. Some people will prefer the peace of mind of knowing that safe defaults are in place if they don't change anything. Those will probably align with OpenBSD here. Some people believe that security is something you bolt on afterwards. Those definitely won't like OpenBSD design decisions.
> They don't set defaults for the average use case when security is involved.
They certainly set the defaults for some usecase, it just happens to be more security-biased than most. They don't ship an OS for an airgapped toaster, so it can't ever literally be "secure by default", it's just a compromise on the tradeoff scale that's more security-oriented than most. It still needs to be usable (for some set of people) and it still has to achieve some baseline level of performance to be usable - I was trying to get some clarity on the latter.
You seem to imply that security will always result in less speed or less usability, and that is not always the case. The thing with OpenBSD is that security will always come first between the three values when they clash, but they don't always clash. And yes, it is the most secure OS out there if you are to judge by the statistics over its history. I'd say that only two remote holes in so many years pretty much grants them the "secure by default" label.
Maybe looking from outside it seems like security is all they think about, but my impression is that it is more about correctness and simplicity, and that security comes as a consequence.
As an example of simplicity, I am not personally aware of any install that is so simple as theirs. Except maybe ubuntu's, but then with ubuntu you end up with a mess of interdependent packages and it will be a hell to uninstall shit you don't need.
> You seem to imply that security will always result in less speed or less usability, and that is not always the case.
Certainly not always, but often enough and more so than usual with Spectre and Meltdown.
> As an example of simplicity, I am not personally aware of any install that is so simple as theirs. Except maybe ubuntu's, but then with ubuntu you end up with a mess of interdependent packages and it will be a hell to uninstall shit you don't need.
That's an interesting point. How does it compare in terms of simplicity to the other BSDs (FreeBSD and Dragonfly) or something like Arch Linux?
> That's an interesting point. How does it compare in terms of simplicity to the other BSDs (FreeBSD and Dragonfly) or something like Arch Linux?
I'm not familiar with FreeBSD and DragonFly, but I have used NetBSD in the past and a bit of Arch Linux. The system management is way more consistent in OpenBSD, things generally work and are more reliable. The package management system is a pleasure to work with, and when you want to remove unused packages or dependencies of previously installed packages, it's simple and consistent. It actually works. When you are configuring something, most of the time there is one single way to do it, and it's well documented. And the simplicity can't really be compared to Arch Linux. Fire up a vm and install OpenBSD to it, just for the experience. It's mostly just accepting the defaults, extremely simple.
Ugh there's so much circumstance and context I would have to preface with, but in the end when we decided we couldn't work together anymore (after almost 3 years), we came up with 2 options:
Either one of us buys the other out, or we dissolve the business. He chose to buy me out and attempt to keep going, but the company folded less than a year after I left.
It wasn't quite a messy as this situation seems to be, but it was rough, as both of us had basically put everything we had into the business.
2-person startups are kind of platonic marriages, and as such splitting up is basically getting a divorce (at least in terms of mental stress).
edit: to answer your "what would I do differently" question, absolutely insist on getting a lawyer up front to draft all the paperwork and employment agreements (we didn't do this because it seemed so expensive).
