[HN Gopher] Effortless OpenBSD Audio and Desktop Screen Recordin...
___________________________________________________________________
Effortless OpenBSD Audio and Desktop Screen Recording Guide
Author : peter_hansteen
Score : 51 points
Date : 2024-01-15 17:08 UTC (5 hours ago)
(HTM) web link (www.undeadly.org)
(TXT) w3m dump (www.undeadly.org)
| CharlesW wrote:
| Direct link: https://rsadowski.de/posts/2024-01-14-openbsd-video-
| audio-sc...
| jiripospisil wrote:
| Is it just me or is the audio in the YouTube demonstration a bit
| broken?
| CharlesW wrote:
| Definitely broken, buffer under-runs?
| fransje26 wrote:
| 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?)
| echelon_musk wrote:
| Ah yes. This will be useful for the 5 people who use OpenBSD on
| the desktop.
| scrps wrote:
| It is nostalgic to see it is still painful.
|
| Edit: I say that with love
| toyg wrote:
| 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.
| pengaru wrote:
| 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
| Aaronstotle wrote:
| 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 wrote:
| 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 wrote:
| I think in OpenBSD heads, "works correctly" implies "no
| unauthorized access"
| eddieroger wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| toyg wrote:
| I don't necessarily agree on the libc thing but I do agree
| that OpenBSD have missed the boat on Rust. It should be the
| natural platform for it, and sadly it's anything but.
|
| 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.
| greyw wrote:
| Speaking of fossilized, OpenBSD still uses cvs for
| version control supposedly because it works well enough.
|
| Cvs "works", but then again I haven't yet seen a worse
| version control system.
| somat wrote:
| There is also the very useful project fauxstream which
| encapsulates this knowledge.
|
| 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 wrote:
| The fact there is a need of a guide means it is not effortless.
___________________________________________________________________
(page generated 2024-01-15 23:01 UTC)