![](https://programming.dev/pictrs/image/385658d9-e355-4571-a811-b0d61d6dbc9d.jpeg)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
64 for the wan interface
Nitpicking, but the address for the wan interface wouldn’t have a prefix, so the host would just set it as a /128 (point-to-point)
64 for the wan interface
Nitpicking, but the address for the wan interface wouldn’t have a prefix, so the host would just set it as a /128 (point-to-point)
I used to use it, but then I switched to MPV, as it works a lot better with hardware acceleration. MPV supports more methods for hardware decoding (e.g. nvdec), and also MPV will keep the frames in VRAM when doing hardware decoding, and do additional processing and presentation using the GPU, while VLC copies everything back to system RAM and processes the frame on the CPU.
At the time I switched hardware decoding with copy-back would actually result in twice the CPU usage compared to software decoding, but that was a long time ago. Also, I would get tearing in VLC and not in MPV.
Something with OpenWRT. Turris Omnia is pretty good.
You’re right, that might work
That requires root
Speaking of which, nowadays KDE hides files with these extensions for some reason
Sounds like a typical COBOL dev
A310 is the cheapest.
I wonder how well it does for transcoding on older computers without ReBAR, since apparently gaming on it is straight out broken without ReBAR. As in, it would actually freeze for a second or so every now and then.
It’s better in one way, in that updates are applied on reboot rather than pulling the rug put from under running applications. But I agree that it doesn’t go all the way, as it doesn’t provide a verifiable base system with clearly separated modifications. OSTree would be great.
Another possibility would be to distribute a base image as a btrfs send stream (possibly differential against previous versions) containing a compose-fs image and associated files. And then OS extensions could be installed with systemd-sysext.