I used OpenBSD on a netbook and it was awesome. But I really needed 32-bit Linux binary compatibility, and I was also one of the 3 people who used bluetooth. Both of these features were removed entirely. I wish there was a way I could "live dangerously" and have access to them again. I would love to have access to bluetooth based serial terminals, and use my favorite keyboard.
> Think of the following: You download a random file from the internet and analyze it using file. If file has a security hole (local code execution for example), he can run attacks with his prepared file. Thats why the file utility is sandboxed and chrooted by default.
Isn't that exactly the sort of case where file(1) would open(2) the downloaded file and its own database, and then proceed to drop all other access privileges before doing any of the parsing of the untrusted file?
It does use pledge(2) these days, those references are to how file(1) was sandboxed before. Why the author has linked to that I don't know.
* ifconfig handling everything is brilliant. Having one tool to do networking, including WiFi(!) is great.
* the documentation is good. `man -k` normally gets you what you need.
* "base builds base" is pretty cool. I managed to rebuild base on a 1GHz single core BeagleBone Black in 48hrs.
* Performance. I didn't think this would be a huge issue, however it's much slower than Trisquel, Parabola and GuixSD running GNOME on a x200. WiFi also seemed slow.
* IPv6 seemingly didn't work, even when verifying my ifconfig setup.
* Filesystem. I don't expect them to add ZFS due to code size and license, but still using UFS is laughable. UFS seemed to have I/O deficiencies which exacerbated the performance issue.
* the other documentation. While the manpages are good, information on the internet can be contradictory depending on it's age.
* No lsblk. This is more of a nitpick, but there is seemingly no way to get the right name for a disk without parsing through `dmesg` and guessing with partition number.
* pkg_add. It's extremely slow compared to apt even and separates it's parts out for seemingly no reason. Package management in general is somewhat awful.
I've tried to use it on a server some months ago (trying out OpenBSD every few years because I do like the philosophy) but things behaved odd and slow, so I just used FreeBSD and problems disappeared.
I'd like to see a completely server focused one instead of trying to do it all and keep issues hanging loose.
Turning on soft dependencies can help:
After ~20 years of using Debian, I switched my desktop PC to OpenBSD about a year ago due to concerns about the direction Linux has taken (eg. systemd).
It was easier to set up the kind of minimalist desktop I like than on Debian, where I have to change a lot of defaults (eg. switching to sysvinit). The package manager is great, and there are ~10k packages available for 6.4. I'm now looking at switching my server to OpenBSD. I'm keeping some dedicated audio workstations on Linux for now (need the raw performance and drivers), but my impression of OpenBSD so far has been very good.
OpenBSD caveats: Video and audio can be a little glitchy. Releases are only supported for one year. ABI can change between releases. There's no filesystem journal. The only non-BSD filestems supported are msdos and ext2fs (and read/write speeds on those are slow).
That's one that has been sticking out to me lately. Both NetBSD and OpenBSD, as much as I like them, lack a modern filesystem..
On the other hand, if it's the lack of journaling that's a turn-off, seriously consider soft updates (softdep). Despite being seemingly an evolutionary dead end due to implementation complexity demands (basically, it's only feasible to implement at the level where it's possible to diagram out implied dependencies between all primitive operations), it is still in some respects superior to the journaling approach.
In any case, I find that, from reading the design, it feels more elegant and fundamentally right.
I see systemd as a framework to define and control services that is much more robust than the old system that relied on scripting conventions. Why the hate? What's people's ideal here?
Fuck that. In the last two years, they have changed at least three times the way that the option to delete the /tmp dir is specified. I understood the configuration, edited it so that it did not delete the /tmp dir automatically; and then, upon an innocent update the old config is overridden and the /tmp dir is magically cleaned! This is infuriating. I have never felt actual, physical, rage against any software in 25 years of using computers. That is, until I met systemd!
I do not really care whether the init system is written in C or scripts. But please, allow me to follow a simple logic. Scripts maybe are not very elegant, but I can follow the init process end-to-end and understand where it does that. I have honestly tried to do that with systemd and it is impossible. And I am quite proficient in reading C code and bash scripts. I have a lot of patience and I am willing to spend a few hours of my free time to understand how a program is configured, by reading code if necessary. But this stuff is just batshit crazy.
I can hear in my mind the smug voices of systemd developers saying "but why do you even want to not delete the tmp files". That's not the fucking point motherfuckers! I just want to control my computer.
Why do you say that? You can even use gnome without systemd, but there are still other desktops.
Beyond that, systemd's extensive scope creep makes the system less robust and more complex than it could be, compared to predecessors which some of us have been working with over a decade, such as the daemontools family (runit, s6, nosh &c.) of supervision systems.
However, I have doubts about Devuan as a long-term solution, and it's a long-term solution that I'm seeking.
I had some reservations about what seemed to be an "angry" fork and its longevity, but so far, Devuan's been up to date, and last I heard most of the acrimony has dissipated up to the point where Devuan was about to get involved in the sysvinit maintenance of Debian itself.
So I don't know about the real long-term, but it appears they are serious about producing and keeping up a distribution.
I use daily two fine linux distributions that do not have systemd: void and slackware. It is a real pleasure to run htop and see that all the running processes do not even fill a 25-line terminal.
Signify sounds great. It has been ported to Linux: https://github.com/Blitznote/signify
Support for other file systems, which is a part of life for me, was pretty lacking; for me, ext4 write support and fat32 read/write isn't essential but would have been enough to stop me from moving back to GNU/Linux.
In the end, it looks like a great system but it just didn't fit my needs, just as, for instance, NixOS (and Guix) didn't fit my needs when I wanted a custom XKB layout.
* ASLR - every modern OS has some form of this.
* FDE - there are reasons (IIRC) FDE is better at FS level than block so this is sort of a negative.
* LibreSSL - OpenSSL API is still a tire fire.
* PIE - Possible on IIRC fbsd, nbsd, linux, etc.
* UTF-8 only libc - there are issues here, such as strcasecmp.
* noexec - IIRC this has been cross OS since the dawn of time (at least early 2000's).
* pledge - pledge is cool, I'm trying to implement something similar using google kafel and a macro that turns `vow(id, kafel_string, flags)` into a compile time bpf filter.
* strlcpy - is sort of junk as it has to iterate over ALL of src so for example strlcpy(d, "superlongstring...", 2) will read all of "superlongstring..."
Some people find the ERL's performance isn't sufficient to pass packets and also host services such as radius or that the passive heat management on the edgerouter isn't sufficient. In that case Protectli.com  makes appliances with monster heat sinks on top and despite running an old ATOM processor can push data at gigabit speeds  thanks to onboard Intel NICs.
Finally you can just grab any refurb wintel box, add a couple of Intel NICs and throw away the windows license.
The great thing about OpenBSD is particularly for its typical roles of firewall, load balancer, edge gateway, authentication server, etc it doesn't require much CPU or storage.
I recently rebuilt a laptop with Windows from a USB 3 stick to an Intel M.2 NVME SSD. It took less than 5 minutes to go from booting to install to reboot. OpenBSD's footprint is so small you'll see similar build times particularly when you leave off X Window.
If you’re using it on a laptop, just make sure to use an older, less ultrabook-like machine and you’ll be good.
What about desktop hardware support? Does it have working drivers for different WiFi chipsets, video cards, trackpad, etc. (referring only to x86 based systems)?
I'll answer this honestly;
All of the X11 based ones until SystemD and wayland came about are essentially supported or working. Gnome created a hard dependency on systemd and thus can't be used any longer on openbsd.
Wayland (and thus; Sway) is not supported by OpenBSD.
But i3, xmonad, KDE4, XFCE4 and cwm are all running flawlessly and I used them before on OpenBSD myself.
I think even Budgie works, but I've not tried that myself.
> What about desktop hardware support?
Hardware support is obviously up to whatever you have. I can only share my experiences and I had a thinkpad x201. Which was obviously very well supported.
However there is a caveat to that: the drivers were indeed supporting the hardware very well BUT OpenBSD does not support bluetooth in any form (citing the fact that bluetooth is a horrible standard and implementing it simply; has never been done and would be hard/impossible).
WiFi was relegated to 802.11g (not 802.11n despite my hardware supporting it). Support for N was added a couple of years ago (after it had been widely adopted for more than half a decade by other OS's) I wouldn't hold my breath for AC support given that.
This isn't true, OpenBSD has GNOME 3.30.2 in ports. It maintains patches to keep it working for users, who can install it with the meta package: pkg_add gnome
6.4 has 3.28.2 in packages: https://www.openbsd.org/64.html
Antoine Jacoutot is the maintainer.
Is this lack of support philosophical or due to prioritization?
# pkg_add gnome
But there are downsides. Upgrading OpenBSD can feel painful to the point where I put it off (though it's getting better). You may have to randomly re-write a config file at upgrade time, or sometimes release-to-release they will remove useful features, like Linux emulation a few years ago. FreeBSD ports and pkg sometimes has stuff that I don't see in OBSD's ports tree.
I think to answer the question you'd need to take a look at what features, hardware support, and ports you need, and how well OpenBSD does or doesn't suit it. Maybe try out OBSD on a USB stick or something and see how you like it.
* LibreSSL (most Linux distros use OpenSSL, YMMV)
* License (GPL, GPL everywhere)
* PID randomization
* Priv sep (for some package managers, for example)
* Swap encryption (probably opt-in, so not default)
* UTF-8 only
* W^X Memory
* autoinstall (though ansible and co. might help)
* base system (it's GNU/Linux after all, not just GNU nor Linux -- some outliers)
* doas(1) (yeah, sudo(1) was made in OpenBSD, but they ditched it)
* pf (http://man.openbsd.org/pf.conf.5)
* signify (most distros use GnuPG instead) (though porting it should be a breeze)
Unveil, pledge, and co. probably have AppArmor/SELinux counterparts, but adding layer upon layer make the whole thing brittle. Unveil, pledge, etc. are built-into all base utils (see also base system concept)
Guess I'll need to submit a merge request.
1) It's not W^X. W^X implies read-only pages are not possible, and they are.
2) They "invented" that, what 5-10 years after Linux?
What? W^X implies that Write and Execute or mutually exclusive, can't have both active at the same time.
> They "invented" that, what 5-10 years after Linux?
It's not so much that they "invented" it, but that they're much more diligent about making sure all the base system and ports use it. It's enforced that unless your file-system is mounted with "wxallowed" then any process that tries to mark a page both writeable and executable will fail.
The truth table for XOR also says that "neither write nor execute" is impossible.
> It's not so much that they "invented" it, but that they're much more diligent about making sure all the base system and ports use
They've definitely taken it further, and turned on by default and all that, which is great.
However they did at the time say that they both invented it, and that it couldn't be done on x86. Of course grsec had been doing it, including on x86, for many years. Theo's defense of why they've not done things Linux has done is that they're not interested in Linux, and don't look at it. Which is an interesting way to assure you're "state of the art"; don't look at what others are doing.
So both at the time and now they say they "invented" it.
Later of course they "invented" how to do it on x86, too.
When OpenBSD was preaching about W^X and things like -fstack-protector, they really were novel ideas and Linux hadn't yet picked them up.
By default in an OS distribution, yes I do believe so. But by the time OpenBSD introduced it I'd been running it on Linux for years.
I'm not wet behind the ears, here. I've been running OpenBSD since 2.1.
I don't dispute that OpenBSD pushed execution prevention (and many other things) in the default OS system wide. But it's pretty dishonest to say that they "invented" it. Which they explicitly did at the time, and that the article does now.
What? That doesn't seem implied to me-- just means a page can't be w and x at the same time.
They adapted it to OpenBSD and I do credit them for doing great work being the first to do it by default in a vanilla OS install, sure.
Dead simple. Fixed latency that you set when you run the sound daemon. Same API with the sound daemon in or out. You can yank it out and the programs get to use the same interface for both audio and mixer. So nothing like the pointless ALSA mixing interface laying around when you run pulseaudio. It all works transparently.
There must have been a regression. There still was lingering suid root binaries that OpenBSD got bit by recently.
I mean, it was security fix #1 for release 6.4: https://www.openbsd.org/errata64.html
It sounds nice, but can someone explain if there are any downsides?
on the upside, these changes often improve overall security of the code and are merged upstream so those using other OS's benefit.
Edit: To answer GP's question, you're probably already incurring a cache miss if you're pointer chasing so in most cases there should be no effect on performance.
> Library order randomization: In rc(8), re-link libc.so, libcrypto, and ld.so on startup, placing the objects in a random order. Theo de Raadt and Robert Peichaer, May 2016, enabled by default since OpenBSD 6.0 and 6.2.
> Kernel relinking at boot: the .o files of the kernel are relinked in random order from a link-kit, before every reboot. This provides substantial interior randomization in the kernel's text and data segments for layout and relative branches/calls. Basically a unique address space for each kernel boot, similar to the userland fork+exec model described above but for the kernel. Theo de Raadt, June 2017.
And that's good?
seems preferable to accepting arbitrary segmentation of packages into subsets based on some random package maintainers preference..
also, it's not 1993 and having 100kb of headers on my system is not really a big deal.
my point is this is the package maintainer interjecting their own notions of what a package is into what is actually provided by the upstream source. the only 'package X' that is 'correct' w/r/t original author is the one that provides exactly what the source based install provides, anything else is maintainer bias. (which isn't inherently bad; just providing a counterpoint as above claim was questioning)
I don't know about good or bad, but for people like me, it's certainly convenient.
Uh, yeah. They did that, just like Linux did before them. I especially like the reply to the announcement that was "uh… I hope you didn't spend these two months coming up with that solution. We already did that for Linux, so you could have just asked".
Linux developers were told about meltdown/spectre right away, but OpenBSD wasn't told until the end of the embargo over two months later.
It appears that OpenBSD chose to spend months starting from scratch researching exactly what needed to be mapped in virtual memory, instead of just confirming the x86/x64 platform needs that were already researched and published by that time.
I'm not talking about the two months (or whatever it was) Linux had as head start. I'm talking about the post-publication ~two months.
Sure, it does look better now, and I'm fine with this setup being a bit annoying since it's a one-time thing.