4 ms·

Effortless OpenBSD Audio and Desktop Screen Recording Guide

echelon_musk 3y ago
Ah yes. This will be useful for the 5 people who use OpenBSD on the desktop.
- scrps 3y ago
  It is nostalgic to see it is still painful. Edit: I say that with love
- toyg 3y ago
  First they ignore you, then they make fun of you, then they fight you, then you can't match performance speeds on modern architectures and just troll people about fonts.
CharlesW 3y ago
Direct link: https://rsadowski.de/posts/2024-01-14-openbsd-video-audio-screen-recording/ https://rsadowski.de/posts/2024-01-14-openbsd-video-audio-sc...
frankjr 3y ago
Is it just me or is the audio in the YouTube demonstration a bit broken?
- CharlesW 3y ago
  Definitely broken, buffer under-runs?
fransje26 3y ago
Although I have no doubt that it required quite some effort, it is pretty ironic that the audio recording is that bad.. 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?)
pengaru 3y ago
recordMyDesktop[0] should work on any *NIX w/OSS+X, and it defaults to a cached mode with deferred encoding so there's less load on the system during the recording. 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. [0] https://github.com/recordmydesktop/recordmydesktop https://github.com/recordmydesktop/recordmydesktop
Aaronstotle 3y ago
I think OpenBSD folks and non-OpenBSD folks have a different meaning of the word effortless. 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).
- somat 3y ago
  The funny thing is that "security" means something different to openbsd heads as well. 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)
  - SoftTalker 3y ago
    I think in OpenBSD heads, "works correctly" implies "no unauthorized access"
- eddieroger 3y ago
  > I am really not cut out for running an OpenBSD desktop 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.
sidkshatriya 3y ago
OpenBSD emphasises security, simplicity and a whole system approach and has a devoted following. 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.
- zvmaz 3y ago
  > 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?
  - sidkshatriya 3y ago
    > 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.
somat 3y ago
There is also the very useful project fauxstream which encapsulates this knowledge. https://github.com/rfht/fauxstream 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.
prmoustache 3y ago
The fact there is a need of a guide means it is not effortless.
- amatecha 3y ago
  I think the "effortless" part is once you've altered your system config to allow recording these sources. Once it's set up (simply/clearly described in the post), you'll have a setup that allows effortless recording.
dartharva 3y ago
Excuse my ignorance but don't BSD distros have Linuxulator that allows running Linux binaries on them? Why can't you just use Linux software for the actual recording part once you have set up the hardware?
- amatecha 3y ago
  I believe FreeBSD has some kind of Linux compatibility layer, but OpenBSD doesn't.
idatum 3y ago
I'm happy to not see the term "daily driver" (yet again) used so far -- usually seen in discussions near the term "desktop". OpenBSD is my behind-the-scenes, CLI focused, rock solid, lab project driver. It delivers when used correctly.
- amatecha 3y ago
  I daily-drive OpenBSD :) typing this msg from that OS on a ThinkPad X230. I use i3wm though, not really a "desktop". I use the terminal emulator heavily of course. I actually do the majority of my personal computing on this machine these days.

Ah yes. This will be useful for the 5 people who use OpenBSD on the desktop.

scrps 3y ago
It is nostalgic to see it is still painful. Edit: I say that with love
toyg 3y ago
First they ignore you, then they make fun of you, then they fight you, then you can't match performance speeds on modern architectures and just troll people about fonts.

Direct link: https://rsadowski.de/posts/2024-01-14-openbsd-video-audio-screen-recording/ https://rsadowski.de/posts/2024-01-14-openbsd-video-audio-sc...

frankjr 3y ago

Is it just me or is the audio in the YouTube demonstration a bit broken?

CharlesW 3y ago
Definitely broken, buffer under-runs?

fransje26 3y ago

Although I have no doubt that it required quite some effort, it is pretty ironic that the audio recording is that bad.. 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?)

pengaru 3y ago

recordMyDesktop[0] should work on any *NIX w/OSS+X, and it defaults to a cached mode with deferred encoding so there's less load on the system during the recording. 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. [0] https://github.com/recordmydesktop/recordmydesktop https://github.com/recordmydesktop/recordmydesktop

Aaronstotle 3y ago

I think OpenBSD folks and non-OpenBSD folks have a different meaning of the word effortless. 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).

somat 3y ago
The funny thing is that "security" means something different to openbsd heads as well. 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)
- SoftTalker 3y ago
  I think in OpenBSD heads, "works correctly" implies "no unauthorized access"
eddieroger 3y ago
> I am really not cut out for running an OpenBSD desktop 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.

sidkshatriya 3y ago

OpenBSD emphasises security, simplicity and a whole system approach and has a devoted following. 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.

zvmaz 3y ago
> 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?
- sidkshatriya 3y ago
  > 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.

somat 3y ago

There is also the very useful project fauxstream which encapsulates this knowledge. https://github.com/rfht/fauxstream 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.

prmoustache 3y ago

The fact there is a need of a guide means it is not effortless.

amatecha 3y ago
I think the "effortless" part is once you've altered your system config to allow recording these sources. Once it's set up (simply/clearly described in the post), you'll have a setup that allows effortless recording.

dartharva 3y ago

Excuse my ignorance but don't BSD distros have Linuxulator that allows running Linux binaries on them? Why can't you just use Linux software for the actual recording part once you have set up the hardware?

amatecha 3y ago
I believe FreeBSD has some kind of Linux compatibility layer, but OpenBSD doesn't.

idatum 3y ago

I'm happy to not see the term "daily driver" (yet again) used so far -- usually seen in discussions near the term "desktop". OpenBSD is my behind-the-scenes, CLI focused, rock solid, lab project driver. It delivers when used correctly.

amatecha 3y ago
I daily-drive OpenBSD :) typing this msg from that OS on a ThinkPad X230. I use i3wm though, not really a "desktop". I use the terminal emulator heavily of course. I actually do the majority of my personal computing on this machine these days.