Effortless OpenBSD Audio and Desktop Screen Recording Guide
undeadly.org
undeadly.org
Glad guides like this exist, however this shows me that I am really not cut out for running an OpenBSD desktop (I did try it, and my internet browser would crash ever 20 minutes).
In openbsd land security means more like "works correctly"
Elsewhere it is closer to "no unauthorized access"
So when the openbsd folks say "our system is more secure" and others say "it isn't really" they are both correct and talking past each other.
I don't use openbsd because it is more "secure" (whatever that means) I use it because it "works correctly" (with the caveat that what works tends to be only what is in openbsd's very limited domain)
I've looked at OpenBSD on the desktop and felt the same, but I'm also thinking about how many times I've bumped up against what feel like arbitrary app armor blocks or such (not always desktop) and wonder both "am I cut out for any of this," and "maybe this would be easier if there was higher-level, consistent handling of this." Reading the article, it seems maybe excessive to need a sysctl flag to allow audio recording, but at least you know where to go to get that permission, and seemingly without much additional overhead.
In my experience using Linux+XOrg+ALSA on an X220 ThinkPad it works pretty well, at least in its current form.
Disclaimer: I'm the maintainer of the linked fork, prior to this fork it was ~useless. If anyone tries it out on OpenBSD and finds issues, PRs for what's necessary to make it Just Work there are welcome.
It reminds me of the experience I had +/- 15 years ago under Ubuntu, trying to record from a webcam. (With cheese, if I recall properly?)
https://github.com/rfht/fauxstream
I was testing a stream over ipfs proof of concept. and the trickiest thing for me was figuring out what ffmpeg arcana was needed to grab the desktop and audio. And fauxstream proved very valuable in providing a known working config.
OpenBSD is my behind-the-scenes, CLI focused, rock solid, lab project driver. It delivers when used correctly.
I've tried it out and while I appreciated many aspects, the system as a whole does not feel "much better" than Linux in any way to me apart from the security aspect [1]. It's slow and I've lost about 2 installations of OpenBSD just because my VM crashed or it was shutdown uncleanly. This is probably because it does not have a journalled filesystem. I don't care much for its pkg package manager either. Again it was very slow and felt a bit crufty/ancient.
Now, in 2024 "Effortless OpenBSD Audio and Desktop Screen Recording Guide" is on page 1 on HN. Maybe in 2030 (!?) when the default filesystem acquires a journal, I expect to read a similar article on HN page 1, rank 1. I look forward to it :)
[1] I don't absolutely, fully buy into OpenBSD is "very secure". Some of its mitigations are good but many do feel a bit arbitrary.
Can you explain how "some mitigations feel arbitrary"? A specific example for us to ponder on?
Let me answer that first in a general way. Every security measure needs to have a threat model. A model is necessary because one could come up with all kinds of security measures that while boosting security in some (possibly even minor) way might lead to drastically reduced performance/useability. Using OpenBSD on a day to day basis I realized it was very slow. I don't know how much of a slowness of OpenBSD is due to some of these security measures with unbalanced tradeoffs or how much it was just due to a lack developer manpower to improve performance.
Mitigations. One of the OpenBSD mitigations is to allowing syscalls only from OpenBSD libc and then only only certain portions of libc. That is something I'm not a fan off. I feel it (a) makes OpenBSD libc special and prevents competing libc-s from coming up (b) reduces freedom in userspace programs -- they have to go via blessed userspace piece of code. I think OpenBSD should continue locking down the userspace/kernel interface from a security perspective but not ban syscalls from locations other than libc. I'm not sure how much extra security it buys you compared to the reduced overall flexibility of the system. The interface to concentrate on security is userspace/kernel and not userspace/userspace-libc IMHO.
Lastly, I find that OpenBSD invests a lot of time and energy in mitigations. But the biggest problem of all is that the C/C++ based kernel and system inherently are very unsafe. I would have expected a greater emphasis in OpenBSD to move towards safer languages at least in userspace if not the kernel. But OpenBSD resolutely sticks to C/C++. Linux OTOH is a bit more open -- Rust is small now but give it a decade or so and I expect a lot of drivers will be written in Rust -- an inherently safer choice.
The project feels very fossilized on various somewhat-outdated views. It probably won't change until there is a significant change in leadership, something that is always difficult and traumatic for BSD projects.
Cvs "works", but then again I haven't yet seen a worse version control system.
Like with binary patches, moving from CVS is something that they will never do until someone "inside" decides that it's time to do it.
Edit: I say that with love