I suggest to take a look at Gentoo. Gentoo doesn’t need/use DKMS, it just recompiles modules after a kernel update as a part of regular package management. You can mask arbitrary package versions or version ranges to reliably stay on an older kernel, driver version (for example on my desktop I currently mask >=x11-drivers/nvidia-drivers-590, meaning “give me the newest 580 version”). I think all version lines that Nvidia updates still get package updates on Gentoo, including 390. And if you need some really old stuff it’s easy to roll your own repo (overlay) and keep discontinued versions/packages around for however long you need them. And once set up, this is essentially maintenance free, and if it does require intervention, you’ll likely get notified directly through the package manager before something breaks, either via a news item or an error during dependency resolution.

PS: And in case you’re wondering, it’s possible to run Gentoo entirely without compiling, or with only compiling packages selectively when you want to change the default flags.

PPS: Oh and maintaining custom patches (as long as they apply cleanly) is as easy as dropping them into a specific subdirectory of /etc/portage/patches and rebuilding the package.

If there’s still wayland protocol extensions required for this functionality (which I don’t think, kwin should have everything it needs, protocols would only be necessary if you’d want a DE-agnostic client application to manage the hotkeys), then KDE is in the best position to get things moving. With wayland development, nothing gets done without a reference implementation and vote from a big compositor, so sitting back and waiting “until things improve” is rarely a valid strategy.

I don’t know about the accessibility side of this, but from how uninterested the devs are every time it’s brought up I can only assume that a keyboard-centric workflow is no longer a focus for KDE. Which is a shame, because with khotkey, KDE previously did provide the best experience out of all major DEs. Now it’s down among worst, when even Gnome(!) has retained some kind of custom hotkey functionality on wayland.

A replacement for what we had with khotkey that allows to intercept and replace key codes, both globally and for specific applications. Bonus points if it also has global mouse gestures.

Issues here and here.

Also note that modal editing isn’t for everyone. I’m happy to learn hotkeys, I even got far enough to build musclememory for vim’s normal mode. What never went away though was my confusion about what mode the editor is in. I would constantly input text in normal mode and input commands in insert mode, leading to costly mistakes that tore down any speed advantage vim would have given me. I really tried, but never built muscle memory for this kind of context switching^[1], maybe it’s an ADHD thing.

These days I’m on Emacs with an always improving custom command scheme of non-modal but context sensitive commands that do similar things in all major and minor modes.

With compress=zstd ZFS reports a 1.30 compression ratio on my Steam dataset, compressing it from ~1.2TB (reported by the file manager) down to 904GB (reported by zfs list -o name,usedds). Pretty good I think.

Obviously it depends on the games. AAA crap will probably add tens/hundreds of GBs of pre-compressed asset blobs, while indie and older games will often have more loose file structures with config files, scripts, runtimes etc. that all compress extremely well. And with older games, even when compressed the algorithms are often far from ideal and zstd can still get a few more percent out of them.

Firstly, Emacs is not an alternative to any terminal based text editor, it’s an alternative to the terminal based workflow in general.

Secondly, Emacs users can live without the hype, churn and elitism of the vim ecosystem and with a better editor instead.

Long before WSL there was coLinux. Back when I still dual-booted (i.e. around 2010) I used it extensively to access my Linux filesystems from within Windows, including assembling the mdadm RAID5. It booted in around 10s, much faster than a full VM and had the filesystems available via SMB-share almost as soon as Windows 7 was done lagging after login.

sysV init or sysV rc? OpenRC can work with any basic /sbin/init or provide its own. If you rely on sysV rc scripts there is probably some backwards compatibility, or at least was in older versions, but I don’t really see the point in it. What distro does even still use sysV rc?

These days OpenRC even has user-services. And writing a simple OpenRC service file is barely more complex than a systemd unit file, maybe even simpler, because it’s readable bash, not some declarative DSL.

Obviously there is in no way feature parity between those two, that’s the point, personally the one thing I’d like to have is something similar to systemd’s timers (which I actually prefer to old-school cron) built into OpenRC, but most other things I can live without.