You could run a 2nd sshd service with systemd where you use namespacing, chroot & drop most capabilities. (Basically a container) You can also change the default logindir of sftp. Look at https://www.redhat.com/sysadmin/mastering-systemd and man sftp-server.

I’d definately would encode to x264 and use ffmpeg’s Intel QuickSync support to save power. Encoding vp9 must be a hard workload for your small machine. Probably the video only doesn’t stutter due to interlacing. If you’d want to go hardcore, you could try to profile your task with minimal overhead by using perf record.

chezmoi.io is one of the best dotfile managers available. Great template language if you need different, many ways to distribute secrets safely, merging works well even with templates, not limited to homedir.

I absolutely dislike the hate for systemd. Especially if there’s bullshit claims like

having both sets of tools installed can increase the attack surface.

in there.

larger attack surface compared to runit, openrc, or sysVinit.

Because they don’t execute million lines super thoroughly checked shell code or why exactly? Without any explanation total FUD.

Some independent binaries from the systemd project, e.g. systemd nspawn, can even used on OpenRC and the systemd project explicitly didn’t change the way to launch udev in debug mode because the Gentoo non-systemd udev pkg maintainer asked to not do so (nicely).

You should instead tell people why OpenRC/runit is (more) awesome in your opinion and maintain initscripts for them. Maybe you can volunteer at the Debian project and get them to adopt OpenRC aside systemd instead of only removing the remnants of sysVinit support. This would also be beneficial for pragmatic pro-systemd users that have to deal with docker or chroot environments.

Thx a lot for checking this, you gave me the missing part in the puzzle.

It was hard to find the actual patch increase, but the latest commit lists the current patch level:

+      - New microcodes:
+      + Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes   <--- Your processor, higher patch version
+      + Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes
+    - Updated microcodes:
+      + Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes
+      + Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes
+    - CVE-2023-20593

I guess that pretty much confirms the theory, AMD only rolls microcode for Epyc and there is no magic sauce why the patch version are all over the place on their consumer chips. For me, the worst thing is their lack of transparency. Guess they’re justification is ridiculous and incomprehensible from a customer standpoint, otherwise they would have communicated it.

Also funny that Ubuntu 22.04 doesn’t ship microcode for Zen3 and higher, why don’t they backport such things?

Anyone having hardware access to an epic CPU ? Could you please report the numbers from zstdcat /lib/firmware/amd-ucode/README.zst vs the patch level reported by grep microcode /proc/cpuinfo, even if you run a different distro ?

If Linus would be a non-techie, he would have tried to install it with a graphical AppStore, it wouldn’t have worked and he’d either given up or found the flatpak version of Steam, which would have worked. Not restricting power users is a good aspect. If I play around with Windows registry to force the removal of edge, Linus would blame me, not Windows. You have to differentiate between things normal users tried and things Linus attempted because he has some technical knowledge.

Some random user saying anything doesn’t make anything true, you don’t believe flat-earthers on the internet, either.

The bug was that you couldn’t install steam without faking a the installation of a dep that went down the dependency chain ending in a conflict of essential packages. The functionality to still proceed is a feature. Linus could also just have copied rm -rf --no-preserve-root / from the internet as solution and would have trusted it blindly. If you want to be nannied all the way, I’d suggest you switch to iOS for everything.

IIRC it was already fixed when Linus did this, just not distributed. It was caused by the bluntness Linus developed due to unmeaningful Windows warnings in the 1st place.