Readit NewsMy ~/.config/mpv/config:
#inicio
ytdl-format=bestvideo[height<=?480][fps<=?30]+bestaudio/best
vo=gl
audio-pitch-correction=no
quiet=yes
pause=no
vd-lavc-skiploopfilter=all
demuxer-cache-wait=yes
demuxer-max-bytes=4MiB
#fin
#inicio de fichero
--format=bestvideo[height<=?480][fps<=?30]+bestaudio/best
#fin de fichero
yt-dlp wrapper
#!/bin/sh
. $HOME/src/yt-dlp/bin/activate
$HOME/src/yt-dlp/bin/yt-dlp "$@"
#!/bin/sh
. $HOME/src/streamlink/bin/activate
$HOME/src/streamlink/bin/yt-dlp "$@"
mkdir -p ~/src/streamlink
cd ~/src/streamlink
virtualenv .
. bin/activate
pip3 install -U streamlink
mkdir -p ~/src/yt-dlp
cd ~/src/yt-dlp
virtualenv .
. bin/activate
pip3 install -U yt-dlp
Overall it's a really fast machine. CWM+XTerm+Tmux it's my main environment. I have some SSH connection open to somewhere else at the 3rd tag (virtual desktop), and the 2nd one for Dillo.
So nothing critical. But something they are still good at, and being very small makes them a natural fit for these use cases.
Fortunately, bookworm will continue to receive updates for almost 3 years, so I am not in a hurry to look for a new OS for these relics. OpenBSD looks like the natural successor, but I am not sure if the wifi chips are supported. (And who knows how long these netbooks will continue to work, they were built in 2008 and 2009, so they've had a long life already.)
EDIT: Hooray, thanks to everyone who made this possible, is what I meant to say.
But the sad reality is that many developers (myself included earlier in my career) will do insane things to fix a critical bug or performance problem when faced with a tight deadline.
OTOH, when coding, I consider FILE to be effectively opaque in the sense that it probably is not portable, and that the implementers might change it at any time.
I am reminded of this fine article by Raymond Chen, which covers a similar situation on Windows way back when: https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...
This hasn't been virtualized?
Worth pointing out, maybe, that there is an emacs package, too - more than one, actually, the one I am using (occasionally, at least) is https://github.com/cjennings/emacs-wttrin which is available from melpa.
this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user (I've yet to see maintainers embrace shipping locked down files). Maybe they will? But this same approach hasn't worked with apparmor so why should it work with systemd? Who will do the job?
If you consider apparmor maintainers provide skeleton-templates in many cases that will make the parser stop complaining. ("look I have a profile so apparmor shuts up, but don't take too close a look OK")
Then there is firejail, which some argue[2] is snake-oil considering the high level of administrative glue compared to its massive attack-surface (also it's a setuid binary).
I didn't mention SElinux since I don't know a single person who had the joy (or pain depending on perspective) of working with it. But again, seems the expectation to implement security with it is shifted to the user.
[1] https://news.ycombinator.com/item?id=22993304
[2] https://github.com/netblue30/firejail/issues/3046