OpenBSD userspace and kernel are developed together
OpenBSD devs have good taste
Linux userspace changes and breaks constantly but never improves. On OpenBSD things move much more slowly, so for the most part my servers work exactly how they did yesterday, and when something does change it’s actually for the better.
I don’t update my Linux machines anymore because random shit breaks every time and I don’t want to deal with it. With OpenBSD I get a nice document telling me what is going to break (often nothing) a nice tool to help fix it.
I don’t update my Linux machines anymore because random shit breaks every time and I don’t want to deal with it.
I have been running run Ubuntu and Debian all over the place for over a decade and I’ve never had random shit break as a result of a regular update. Sometimes there are changes in behavior between releases but as a sysadmin, it’s my job to know about those and test things out before upgrading anything important. That would be true regardless of the OS.
Sometimes there are changes in behavior between releases but as a sysadmin, it’s my job to know about those and test things out before upgrading anything important.
That sounds like something you’d rather want to accuse the OpenBSD community of, since they have a reputation of amputation.
@joshklein and @myfreeweb You guys are missing my point. I’m aware that as it stands now, systemd has not absorbed all of the things that would make it, plus the linux kernel, BSD like. My point is that systemd keeps absorbing functionality that was traditionally separate in Linux, making Linux more and more BSD like as time goes on.
The good or bad of systemd, and the good or bad of this happening, is debatable I suppose, and I really don’t want to have that argument. I only wish to point out the converging similarities in how both OSes are developed.
You’re missing the point. Changes in BSD at the global scope are possible because it’s one project, and you don’t have to convince 53 different teams to accept a change, then coordinate it across 39 distros. This kills a lot of the pressure for the kind of wrapper-wrappers you see in Linuxland.
I respectfully disagree. How many different versions of init has systemd effectively killed (including all of the different versions of sysv)? Sure there are still holdouts trying to keep the sysv dream alive, but at this point systemd has won. Unifying RedHat, Ubuntu, and Suse alone has eliminated a large amount of differences in how those systems boot and how they’re managed.
It is true that systemd has unified service management across distributions.
What @orib is saying is that if the same team works on both kernel AND userland, changes applied to any of them will benefit directly from the other in the next release. This simply cannot be true with Linux per design.
Linus enforces a “do not break userland policy” on the kernel development, while rejecting any patch provided by userland developers to “adapt” the kernel.
He does so (and he’s right!) because the userland amd kernel teams are separate, so they must provide a boring interface that never changes, thus keeping legacy constructs for the sake of compatibility.
OpenBSD devs don’t care about compatibility, as they are their own clients regarding the kernel. That’s why they could replace strncat() with strlcat() in all core utilities, even though it’s not standard, or pledge/unveil their core daemons. They don’t care if their utilities cannot compile on linux, as long as they work for their own kernel.
You will never see Linus accepting an “Add pledge() syscall” patch provided by Lennart because he believe it’s an important construct for systemd.
Also, if Linus decides to implement pledge() in the kernel, it is unlikely that all distro will adopt it in their next release, it will needs more time to see all external userland teams to implement this syscall. They’ll probably never do it anyway because it is not standard, and not required, so why bother?
OpenBSD devs are free to do whatever they want with their OS, even if that include rewriting core utils. The Linux community simply can’t do that because it must remain consistent. Systemd is not the only “userland client” of kernel devs.
What wrapper-wrappers? Could you give some examples?
From another point of view, you could also argue that having separate teams requires requires decoupling of components and to define better APIs at the boundaries. Linux development can be messier at times, but the looser coupling also gives benefits. For example, you can actually change the init system if you want to or replace parts of the userland (as MUSL-based distributions have shown). Or (as happened a lot in the past, e.g. egcs, glibc) replace some component by an alternative if you don’t like the direction a project is going.
Such looser coupling seems to have been of an evolutionary advantage to Linux, since people can just try out new ideas and if they are worthwhile convince people to adopt them. Again, egcs and glibc are good historical examples.
Sure: netplan wrapping network-manager wrapping a broad and incoherent collection of tools, some of which are themselves wrappers.
From another point of view, you could also argue that having separate teams requires requires decoupling of components and to define better APIs at the boundaries.
You could argue that, but it doesn’t seem to hold up in practice.
In practice, everyone seems to have their own idea of what the API at the boundary should be, and then starting a new project that wraps it up that way (eg, qemu and libvirt).
Then, often, someone else comes along with a different idea of the API, but needs the wrapped functionality, so they create a new layer (pulseaudio, phonon).
And instead of the architecture getting polished with time, it grows like leaf litter at the floor of a forest.
And because the shiny bits are way up at the top, and making an improvement at the bottom that gets used needs commit access to half a dozen repos spread across multiple partially disjoint communities, nobody really maintains or polishes the lowest layers.
Ifconfig was removed from many Linuxes not because it was a bad component, but because it was last released in 2003, and nobody cared enough to update it.
On top of that, even just understanding what the top layers are actually doing to the bottom layers is a huge task, and makes a deep system understanding much harder than it needs to be.
The slide deck is super intriguing. Is there an associated talk? I’m sure the slides convey 100% of the meaning for folks super steeped in the C level UNIX security world, and I have some understanding of these topics but not enough to absorb the information in a mostly context free environment like this.
I don’t update my Linux machines anymore because random shit breaks every time
Random anecdote - I used to run OpenBSD on an old Digital AlphaStation. This was just for messing around and I had a lot of fun. I really didn’t understand how ports worked however and managed to hose my system by trying to update Perl incorrectly.
Since that time the OpenBSD team has more and more emphasized using precompiled binaries, but at the time it wasn’t practical.
OpenBSD userspace and kernel are developed together
The longer systemd goes the more this isn’t really true anymore. I wonder how long it will be before this stops being something BSDers point out as a differentiating factor. At some point it will have to morph to “OpenBSD userspace and kernel are different than Linux’s” which really should be obvious.
The difference is significantly deeper than this. By learning how one part of OpenBSD works - userspace or kernel - you gain knowledge that applies across the system with a reasonable level of consistency.
GNU is Not Unix. Some corners of Linux systems have internal design consistency, but no amount of digging into the git book will teach you a thing about nginx (for example).
With FreeBSD, I can just write a patch that touches both kernel drivers and corresponding userspace utilities and post it on phabricator and get it reviewed/merged. (example) This is really powerful. The whole system is a lot more coherent and simple.
For devs who cannot readily leave Linux fully for a BSD for software reasons (such as VS Code or Docker or other tooling), a quick recommendation on the Void Linux distro (a from-scratch distro, not a fork of a fork of a fork..) which somewhat aspires to carry as much as feasible of the BSD spirit & principles over to the Linux world in terms of various designs such as init system, services, package build system etc. Unlike all other distros I used before, it’s consistently rock-solid for me (on a number of machines for over a year now) and the first one that finally vaporized my long-evolved fear of updates.
Gentoo focuses on package customizations and fine tuning/control over your OS, while void is focusing on being an easy to use/maintain OS while avoiding systemd.
It’s not really BSD like though, as it uses the runit init system which is very different from OpenBSD rc.d. Gentoo’s ooenrc comes closer to it.
It’s not that the package system is more like BSD, but rather that they have adopted more packages and tools (libressl, mdoc, …) from the BSD community, and generally tend to prefer their style/tooling/feel over a classical GNU, such as with Debian and RedHat. From
My challenge was to figure out how to trouble shoot OS specific issues, and just simply ask developers to use OpenBSD as a dev environment, to give additional ‘testing miles’ to our backend, for that specific OS.
And that’s when we realized no Android Studio, no VisualCode, no workable remote RDP/VNC problems.
Even when developing an Android app, it is useful to have the backend tools and infrastructure running on the same machine as Android Studio (because Andr. emulator connectivity works to a local host, and our code shares a number of files/libraries between backend and android javas).
So not being able run Android studio and backend on the same host, was a major pain, that prevented us from getting more test milage for OpenBSD.
I realize that the above (may be with exception of RDP/VNC) is not something that OpenBSD team can resolve for us. I was just sharing the experience with others looking at OpenBSD and how it compares with Linux-based distros.
I was using xfreerdp today to access a Window Machine, and I am writing this via vnc (ssvnc-viewer) on an Mac Mini - both from my OpenBSD laptop - having worked at many places where the only OpenBSD machine was my work machine I have found that working with Mac OS X and Windows is possible.
I have in the passed be known to run Linux through qemu to access software that I cannot get to work on OpenBSD. I need to find time to play more with vmm(4) as I’m sure its getting to the point that I can run a Linux VM rather than using qemu.
alpine linux tends to be fairly sane as well it seems(I am only a casual user of Alpine, so can’t speak from experience) and I have no firsthand experience of void.
The closest distro I can think of if you want a BSD like taste is crux.
It comes with no precompiled binary packages though, and it’s a small community.
Here’s what you’ll get:
I’ve beeb using it for years as my main distro, and it works like a charm. It does require some admin/compilation knowledge, but if you ask me, it’s worth it!
ugh. GNU’s insistence on info pages instead of man pages has hurt Linux so much it makes me sad. All of the most common and important tools – coreutils – are poorly documented by design, in an effort to promote a failed documentation format instead of do what is best for a vast majority of people.
A use of openBSD as development platform for Java, JavaScript and Android app development – is problematic.
So a Linux OS is significantly better.
there is no android studio on openBSD (and emulators will not work)
There is no ready to go modern javascript GUI dev environment there (FB’s flow bin does not work on this os, there is no VisualCode in packages)
IntelliJ IDE works pretty well on openBSD, and is kept up todate.
But if you are trying to use an GUI remotely (eg if openBSD is in VM or on another server) – you will be for a big disappointment. As the only vnc/rdp server on OpenBSD – is x11vnc, and it is a polling system that reads framebuffer, and quite slow (and uses up significant CPU time). So GUI-based IDEs are, essentially, not usable when installed on a remote (or VM) instance of openBSD
There are no VirtualBox guest additions for OpenBSD
The referenced posts compared some of the OpenBSD ‘built-in’ features eg http to apache/nginx.
But feature-wise they are not really comparable. OpenBSD’s http (last I check) does not support even HTTP2, and in my understanding, the lead developer on it – did not think that the protocol is relevant.
This hampers somewhat OpenBSD as a hosting plataform, the hosts such as OpenBSD Amsterdam, only offers configured hosting based on OpenBSD’s http – therefore no http2 support, if you go with built in http daemon.
I am sure there are many other features that are in ngnix or apache that are not in openBSD.
no docker or other comparable tech
Overall, I personally, appreciate openBSD philosophy of excellence and almost ‘stoicism’ in their choices. If OpenBSD team chooses to concentrate on something, it will be excellent not just good.
If they decided that it is a bit of ‘fluff’ or not main area for them (eg this is not a GUI developer workstation) – a choppy support will be in packages and blog posts.
Seems like OpenBSD chose to concentrate on:
Documentation
Cohesive, exceptionally thought out configuration management for security features
Attention and good support to non-intel platforms
Excellent default setup for console and console development tools (everything is thought out, including fonts) :-)
Excellent selection of packages that are also curated from the security angle, for such a small team.
JDK 11 and Node 10, are already there – just weeks after releases of those for openBSD (in case of JDK).
TMUX is built-in !. This tells me that OpenBSD team is well aware that OpenBSD setups are often used as login hosts to manage remote environments (which is also why excellent support for anything to do with console).
So yes, the OS is a good choice for a full internet appliance for login gateways, backend servers (but perhaps not multi node clusters).
And again, I like the approach and ability to reject, what’s not in scope – this is a good practice to learn, even as a management skill!
For me, making our backend at least testable on openBSD is a goal, perhaps one day using OpenBSD in prod to host jetty and postgres parts of our backend, would be very much desired.
TMUX is built-in !. This tells me that OpenBSD team is well aware that OpenBSD setups are often used as login hosts to manage remote environments (which is also why excellent support for anything to do with console).
tmux(1) author (Nicholas Marriott) is an OpenBSD developer.
I.e. while we’re at the subject of developers, probably not many people know that sudo is now maintained by Todd Miller - he isn’t the original author, though.
I was just commenting on the twitter thread referenced in the submission.
In there, there was a mention that alternative to Linux’s nginx/apache is OpenBSD’s http.
But feature wise, those do not match.
New OpenBSD hosting services like OpenBSD Amsterdam, offer opinionated preconfigured VMs, specifically, configure OpenBSD instances with OpenBSD’s built in packages. https://openbsd.amsterdam/setup.html
So that means http2 is not supported In their default config.
Just wanted to reflect, that features of openBSD built-in packages – matter, even if there are 3rd party packages that are available to overlap with the built-in features.
openbsd built in software is not built to be feature packed but to be reliable and secure. it’s worth considering what the priorities of the developers are when you use the software that they so graciously shared with you.
I’ve tried OpenBSD a few times over the last few years, and a few weeks back I finally got a working installation (suspending, keys, etc.) but then I realized that it is just generally too slow, especially when compared to Linux on the same machine. And even if some parts are nicer or cleaner, the documentation is more thought through (but not necessarily that easy to find something, if you’re not sure what you are looking for), it’s still not worth having Emacs be 5-10 times slower, let alone Firefox or any other larger application (which to be fair, for me is just the two). It’s sad, but that’s what really what keeps me back, and the main comparison, since both are free operating systems.
Though I should say that it’s quite nice (with the exception of relayd) on servers.
For posterity I will say I’ve personally never noticed much slowness sans Firefox, which was solved in the about:config by setting layers.acceleration.force-enabled to true. A lot of packages put information like that in /usr/local/share/doc/pkg-readmes. There are also some sysctl settings that help improve OpenBSD performance, though I shan’t go into them here.
I’m thinking of trying openbsd again for a little pet home server, and relayd would necessarily be a part of that (I think, from its docs). What pain did you hit with it?
My use case was to serve a regular HTTP server (httpd) and a Go server on the same host, where one domain directs to one port, and the other to another. After looking though quite a few mailing lists (which still takes less time than reading the manual) I got it working, but it didn’t have https support. Also websockets broke sometimes.
But if you only want to host static content or cgi, then httpd should have you covered, which is a bit easier to work with.
I’ve been running relayd as a TLS termination proxy for a few web apps for a few years and it has mostly been fine. A few configuration issues, I can’t remember what exactly (but my fault), and I haven’t tried websockets. Otherwise it has worked for me.
I’m not saying it’s no doable, it’s just that it seems a lot harder to do (since there is less resources) compared with more popular alternatives like nginx. And I know I could also use nginx, but that kind of takes the whole fun out of OpenBSD.
In my opinion, running FreeBSD will give one just as good a taste of the “BSD experience”, with added performance benefits compared to OpenBSD, and with the added bonus of Linux compatibility.
In article-form: https://threadreaderapp.com/thread/1122069042083323904.html
For me the biggest differences are:
Linux userspace changes and breaks constantly but never improves. On OpenBSD things move much more slowly, so for the most part my servers work exactly how they did yesterday, and when something does change it’s actually for the better.
I don’t update my Linux machines anymore because random shit breaks every time and I don’t want to deal with it. With OpenBSD I get a nice document telling me what is going to break (often nothing) a nice tool to help fix it.
I have been running run Ubuntu and Debian all over the place for over a decade and I’ve never had random shit break as a result of a regular update. Sometimes there are changes in behavior between releases but as a sysadmin, it’s my job to know about those and test things out before upgrading anything important. That would be true regardless of the OS.
That sounds like something you’d rather want to accuse the OpenBSD community of, since they have a reputation of amputation.
@joshklein and @myfreeweb You guys are missing my point. I’m aware that as it stands now, systemd has not absorbed all of the things that would make it, plus the linux kernel, BSD like. My point is that systemd keeps absorbing functionality that was traditionally separate in Linux, making Linux more and more BSD like as time goes on.
The good or bad of systemd, and the good or bad of this happening, is debatable I suppose, and I really don’t want to have that argument. I only wish to point out the converging similarities in how both OSes are developed.
You’re missing the point. Changes in BSD at the global scope are possible because it’s one project, and you don’t have to convince 53 different teams to accept a change, then coordinate it across 39 distros. This kills a lot of the pressure for the kind of wrapper-wrappers you see in Linuxland.
Systemd doesn’t seem to be changing this.
I respectfully disagree. How many different versions of init has systemd effectively killed (including all of the different versions of sysv)? Sure there are still holdouts trying to keep the sysv dream alive, but at this point systemd has won. Unifying RedHat, Ubuntu, and Suse alone has eliminated a large amount of differences in how those systems boot and how they’re managed.
It is true that systemd has unified service management across distributions. What @orib is saying is that if the same team works on both kernel AND userland, changes applied to any of them will benefit directly from the other in the next release. This simply cannot be true with Linux per design.
Linus enforces a “do not break userland policy” on the kernel development, while rejecting any patch provided by userland developers to “adapt” the kernel. He does so (and he’s right!) because the userland amd kernel teams are separate, so they must provide a boring interface that never changes, thus keeping legacy constructs for the sake of compatibility. OpenBSD devs don’t care about compatibility, as they are their own clients regarding the kernel. That’s why they could replace
strncat()withstrlcat()in all core utilities, even though it’s not standard, orpledge/unveiltheir core daemons. They don’t care if their utilities cannot compile on linux, as long as they work for their own kernel.You will never see Linus accepting an “Add pledge() syscall” patch provided by Lennart because he believe it’s an important construct for systemd. Also, if Linus decides to implement
pledge()in the kernel, it is unlikely that all distro will adopt it in their next release, it will needs more time to see all external userland teams to implement this syscall. They’ll probably never do it anyway because it is not standard, and not required, so why bother? OpenBSD devs are free to do whatever they want with their OS, even if that include rewriting core utils. The Linux community simply can’t do that because it must remain consistent. Systemd is not the only “userland client” of kernel devs.What wrapper-wrappers? Could you give some examples?
From another point of view, you could also argue that having separate teams requires requires decoupling of components and to define better APIs at the boundaries. Linux development can be messier at times, but the looser coupling also gives benefits. For example, you can actually change the init system if you want to or replace parts of the userland (as MUSL-based distributions have shown). Or (as happened a lot in the past, e.g. egcs, glibc) replace some component by an alternative if you don’t like the direction a project is going.
Such looser coupling seems to have been of an evolutionary advantage to Linux, since people can just try out new ideas and if they are worthwhile convince people to adopt them. Again, egcs and glibc are good historical examples.
Sure: netplan wrapping network-manager wrapping a broad and incoherent collection of tools, some of which are themselves wrappers.
You could argue that, but it doesn’t seem to hold up in practice.
In practice, everyone seems to have their own idea of what the API at the boundary should be, and then starting a new project that wraps it up that way (eg, qemu and libvirt).
Then, often, someone else comes along with a different idea of the API, but needs the wrapped functionality, so they create a new layer (pulseaudio, phonon).
And instead of the architecture getting polished with time, it grows like leaf litter at the floor of a forest.
And because the shiny bits are way up at the top, and making an improvement at the bottom that gets used needs commit access to half a dozen repos spread across multiple partially disjoint communities, nobody really maintains or polishes the lowest layers.
Ifconfig was removed from many Linuxes not because it was a bad component, but because it was last released in 2003, and nobody cared enough to update it.
On top of that, even just understanding what the top layers are actually doing to the bottom layers is a huge task, and makes a deep system understanding much harder than it needs to be.
Let me try to frame this in the most productive and positive light possible. What precisely does that mean?
I think this can be answered with https://www.slideshare.net/GiovanniBechis/linux-seccomp2-vs-openbsd-pledge1
The slide deck is super intriguing. Is there an associated talk? I’m sure the slides convey 100% of the meaning for folks super steeped in the C level UNIX security world, and I have some understanding of these topics but not enough to absorb the information in a mostly context free environment like this.
Random anecdote - I used to run OpenBSD on an old Digital AlphaStation. This was just for messing around and I had a lot of fun. I really didn’t understand how ports worked however and managed to hose my system by trying to update Perl incorrectly.
Since that time the OpenBSD team has more and more emphasized using precompiled binaries, but at the time it wasn’t practical.
The longer systemd goes the more this isn’t really true anymore. I wonder how long it will be before this stops being something BSDers point out as a differentiating factor. At some point it will have to morph to “OpenBSD userspace and kernel are different than Linux’s” which really should be obvious.
EDIT: Grammar.
The difference is significantly deeper than this. By learning how one part of OpenBSD works - userspace or kernel - you gain knowledge that applies across the system with a reasonable level of consistency.
GNU is Not Unix. Some corners of Linux systems have internal design consistency, but no amount of digging into the git book will teach you a thing about nginx (for example).
Systemd has only absorbed various daemons (e.g. udev), there’s still a separation between kernel, libc, systemd and coreutils. Time is being wasted on solving the self-inflicted problem of conflicts between libc and kernel (glibc not adding wrappers for new syscalls).
With FreeBSD, I can just write a patch that touches both kernel drivers and corresponding userspace utilities and post it on phabricator and get it reviewed/merged. (example) This is really powerful. The whole system is a lot more coherent and simple.
For devs who cannot readily leave Linux fully for a BSD for software reasons (such as VS Code or Docker or other tooling), a quick recommendation on the Void Linux distro (a from-scratch distro, not a fork of a fork of a fork..) which somewhat aspires to carry as much as feasible of the BSD spirit & principles over to the Linux world in terms of various designs such as init system, services, package build system etc. Unlike all other distros I used before, it’s consistently rock-solid for me (on a number of machines for over a year now) and the first one that finally vaporized my long-evolved fear of updates.
Wasn’t Gentoo the “BSD linux distro” some time ago? Even their package manager was called “portage”.
What are the differences with Void?
Gentoo focuses on package customizations and fine tuning/control over your OS, while void is focusing on being an easy to use/maintain OS while avoiding systemd. It’s not really BSD like though, as it uses the runit init system which is very different from OpenBSD rc.d. Gentoo’s ooenrc comes closer to it.
It’s not that the package system is more like BSD, but rather that they have adopted more packages and tools (libressl, mdoc, …) from the BSD community, and generally tend to prefer their style/tooling/feel over a classical GNU, such as with Debian and RedHat. From
My challenge was to figure out how to trouble shoot OS specific issues, and just simply ask developers to use OpenBSD as a dev environment, to give additional ‘testing miles’ to our backend, for that specific OS. And that’s when we realized no Android Studio, no VisualCode, no workable remote RDP/VNC problems. Even when developing an Android app, it is useful to have the backend tools and infrastructure running on the same machine as Android Studio (because Andr. emulator connectivity works to a local host, and our code shares a number of files/libraries between backend and android javas).
So not being able run Android studio and backend on the same host, was a major pain, that prevented us from getting more test milage for OpenBSD.
I realize that the above (may be with exception of RDP/VNC) is not something that OpenBSD team can resolve for us. I was just sharing the experience with others looking at OpenBSD and how it compares with Linux-based distros.
I was using xfreerdp today to access a Window Machine, and I am writing this via vnc (ssvnc-viewer) on an Mac Mini - both from my OpenBSD laptop - having worked at many places where the only OpenBSD machine was my work machine I have found that working with Mac OS X and Windows is possible.
I have in the passed be known to run Linux through qemu to access software that I cannot get to work on OpenBSD. I need to find time to play more with vmm(4) as I’m sure its getting to the point that I can run a Linux VM rather than using qemu.
alpine linux tends to be fairly sane as well it seems(I am only a casual user of Alpine, so can’t speak from experience) and I have no firsthand experience of void.
The closest distro I can think of if you want a BSD like taste is crux. It comes with no precompiled binary packages though, and it’s a small community. Here’s what you’ll get:
I’ve beeb using it for years as my main distro, and it works like a charm. It does require some admin/compilation knowledge, but if you ask me, it’s worth it!
ugh. GNU’s insistence on info pages instead of man pages has hurt Linux so much it makes me sad. All of the most common and important tools – coreutils – are poorly documented by design, in an effort to promote a failed documentation format instead of do what is best for a vast majority of people.
A use of openBSD as development platform for Java, JavaScript and Android app development – is problematic. So a Linux OS is significantly better.
there is no android studio on openBSD (and emulators will not work)
There is no ready to go modern javascript GUI dev environment there (FB’s flow bin does not work on this os, there is no VisualCode in packages)
IntelliJ IDE works pretty well on openBSD, and is kept up todate.
But if you are trying to use an GUI remotely (eg if openBSD is in VM or on another server) – you will be for a big disappointment. As the only vnc/rdp server on OpenBSD – is x11vnc, and it is a polling system that reads framebuffer, and quite slow (and uses up significant CPU time). So GUI-based IDEs are, essentially, not usable when installed on a remote (or VM) instance of openBSD
There are no VirtualBox guest additions for OpenBSD
The referenced posts compared some of the OpenBSD ‘built-in’ features eg http to apache/nginx.
But feature-wise they are not really comparable. OpenBSD’s http (last I check) does not support even HTTP2, and in my understanding, the lead developer on it – did not think that the protocol is relevant. This hampers somewhat OpenBSD as a hosting plataform, the hosts such as OpenBSD Amsterdam, only offers configured hosting based on OpenBSD’s http – therefore no http2 support, if you go with built in http daemon. I am sure there are many other features that are in ngnix or apache that are not in openBSD.
Overall, I personally, appreciate openBSD philosophy of excellence and almost ‘stoicism’ in their choices. If OpenBSD team chooses to concentrate on something, it will be excellent not just good. If they decided that it is a bit of ‘fluff’ or not main area for them (eg this is not a GUI developer workstation) – a choppy support will be in packages and blog posts.
Seems like OpenBSD chose to concentrate on:
So yes, the OS is a good choice for a full internet appliance for login gateways, backend servers (but perhaps not multi node clusters).
And again, I like the approach and ability to reject, what’s not in scope – this is a good practice to learn, even as a management skill!
For me, making our backend at least testable on openBSD is a goal, perhaps one day using OpenBSD in prod to host jetty and postgres parts of our backend, would be very much desired.
tmux(1)author (Nicholas Marriott) is an OpenBSD developer.I did not know that!. thank you
No worries! :^)
https://www.openbsd.org/innovations.html is an interesting read in general.
I.e. while we’re at the subject of developers, probably not many people know that sudo is now maintained by Todd Miller - he isn’t the original author, though.
lobste.rs has been started by another, and @tedu honks ;^)
Both nginx and apache run on OpenBSD.
Right, of course, this is correct.
I was just commenting on the twitter thread referenced in the submission. In there, there was a mention that alternative to Linux’s nginx/apache is OpenBSD’s http.
But feature wise, those do not match.
New OpenBSD hosting services like OpenBSD Amsterdam, offer opinionated preconfigured VMs, specifically, configure OpenBSD instances with OpenBSD’s built in packages.
https://openbsd.amsterdam/setup.html So that means http2 is not supported In their default config.
Just wanted to reflect, that features of openBSD built-in packages – matter, even if there are 3rd party packages that are available to overlap with the built-in features.
openbsd built in software is not built to be feature packed but to be reliable and secure. it’s worth considering what the priorities of the developers are when you use the software that they so graciously shared with you.
And because all software is well written - it is easy to just extend and recompile, and keep your new feature as a patch.
I’ve tried OpenBSD a few times over the last few years, and a few weeks back I finally got a working installation (suspending, keys, etc.) but then I realized that it is just generally too slow, especially when compared to Linux on the same machine. And even if some parts are nicer or cleaner, the documentation is more thought through (but not necessarily that easy to find something, if you’re not sure what you are looking for), it’s still not worth having Emacs be 5-10 times slower, let alone Firefox or any other larger application (which to be fair, for me is just the two). It’s sad, but that’s what really what keeps me back, and the main comparison, since both are free operating systems.
Though I should say that it’s quite nice (with the exception of relayd) on servers.
What was notably slower? Firefox?
Firefox, Emacs, Startup, everything that had to do with I/O basically.
For posterity I will say I’ve personally never noticed much slowness sans Firefox, which was solved in the about:config by setting
layers.acceleration.force-enabledto true. A lot of packages put information like that in/usr/local/share/doc/pkg-readmes. There are also some sysctl settings that help improve OpenBSD performance, though I shan’t go into them here.I’m thinking of trying openbsd again for a little pet home server, and relayd would necessarily be a part of that (I think, from its docs). What pain did you hit with it?
My use case was to serve a regular HTTP server (httpd) and a Go server on the same host, where one domain directs to one port, and the other to another. After looking though quite a few mailing lists (which still takes less time than reading the manual) I got it working, but it didn’t have https support. Also websockets broke sometimes.
But if you only want to host static content or cgi, then httpd should have you covered, which is a bit easier to work with.
I’ve been running relayd as a TLS termination proxy for a few web apps for a few years and it has mostly been fine. A few configuration issues, I can’t remember what exactly (but my fault), and I haven’t tried websockets. Otherwise it has worked for me.
I’m not saying it’s no doable, it’s just that it seems a lot harder to do (since there is less resources) compared with more popular alternatives like nginx. And I know I could also use nginx, but that kind of takes the whole fun out of OpenBSD.
Hmmm, yeah I was hoping to virtualhost multiple domains, and redirect ports 80/443 accordingly (some static httpd, some python/flask).
In my opinion, running FreeBSD will give one just as good a taste of the “BSD experience”, with added performance benefits compared to OpenBSD, and with the added bonus of Linux compatibility.