The 6-month release cycle makes the most sense to me on desktop. Except during the times I choose to tinker with it at my own whim, I want my OS to stay out of my way and not feel like something I have to maintain and keep up with, so rolling (Arch, Tumbleweed) is too often. Wanting to use modern hardware and the current version of my DE makes a 2-year update cycle (Debian, Rocky) feel too slow.

That leaves Ubuntu, Fedora, and derivatives of both. I hate Snap and Ubuntu has been pushing it more and more in recent years, plus having packages that more closely resemble their upstream project is nice, so I use Fedora. I also like the way Fedora has rolling kernel updates but fixed release for most userspace, like the best of both worlds.

I use Debian stable on my home server. Slower update cycle makes a lot more sense there than on desktop.

For work and other purposes, I sometimes touch Ubuntu, RHEL, Arch, Fedora Atomic, and others, but I generally only use each when I need to.

If the only problem is that you can’t use dynamic linking (or otherwise make relinking possible), you still can legally use LGPL libraries. As long as you license the project using that library as GPL or LGPL as well.

However, those platforms tend to be a problem for GPL in other ways. GPL has long been known to conflict with Apple’s App Store and similar services, for example, because the GPL forbids imposing extra limits that restrict user freedom and those stores have a terms of service that does exactly that.

If it was a community addition why would it matter? And why would they remove the codecs.

You don’t have to be a corporation to be held liable for legal issues with hosting codecs. Just need to be big enough for lawyers to see you as an attractive target and in a country where codec patent issues apply. There’s a very good reason why the servers for deb-multimedia (Debian’s multimedia repo), RPM Fusion (Fedora’s multimedia repo), VLC’s site, and others are all hosted in France and do not offer US-based mirrors. France is a safe haven for foss media codecs because its law does not consider software patentable, unlike the US and even most other EU nations.

Fedora’s main repos are hosted in the US. Even if they weren’t, the ability for any normal user around the world to host and use mirrors is a very important part of an open community-friendly distro, and the existence of patented codecs in that repo would open any mirrors up to liability. Debian has the same exact issue, and both distros settled on the same solution: point users to a separate repo that is hosted in France which contains extra packages for patent-encumbered codecs.

I stopped using Arch a long time ago for this same reason. Either Fedora (or derivatives like Nobara) or an atomic/immutable distro (like Bazzite, Silverblue, Kinoite) is probably the way to go.

I used to feel like Ubuntu was a good option for this, but it no longer is: too often they try to push undesirable changes that need manual tweaking to fix after release upgrades. Debian Stable is generally good for low-maintenance use but doesn’t keep up as well with newer hardware or newer updates to video drivers and mesa, which makes it suboptimal for typical gaming use. Debian Testing can be prone to break things in updates (in my experience, worse than Arch does).

I saw another comment recommend Rocky/RHEL, but note that their kernel doesn’t support btrfs. Since you mentioned a root snapshot, I expect you probably use it.

Btrfs doesn’t have encryption, so you need to do it with luks to an mdadm raid, and build btrfs on top of that. Luks on mdadm raid is known to be slow, and in general not a great idea.

Why involve mdadm? You can use one btrfs filesystem on a pair of luks volumes with btrfs’s “raid1” (or dup) profile. Both volumes can decrypt with the same key.

A standard called SystemReady exists. For the systems that actually follow its standards, you can have a single ARM OS installation image that you copy to a USB drive and can then boot through UEFI and run with no problems on an Ampere server, an NXP device, an Nvidia Jetson system, and more.

Unfortunately it’s a pretty new standard, only since 2020, and Qualcomm in particular is a major holdout who hasn’t been using it.

Just like x86, you still need the OS to have drivers for the particular device you’re installing on, but this standard at least lets you have a unified image, and many ARM vendors have been getting better about upstreaming open-source drivers in the Linux kernel.

To the contrary, I would expect the sample to skew more towards people who have a heavily customized X session and strong opinions about window managers while drastically underrepresenting average GNOME users who stick with the default Wayland session. Someone who likes their custom setup can still be waiting for a Wayland equivalent while casual Ubuntu users have been defaulted to Wayland on new non-nvidia installs since early 2021.

I tried to do this a while ago with a GNOME system, setting GDM to automatically log me in, but I ended up always getting prompted for my password from gnome-keyring shortly after logging in which seemed to defeat the point. If you use GNOME, you might want to look at ArchWiki’s gnome-keyring page which describes a couple solutions to this problem (under the PAM section) which should be applicable on any systemd distro.

In 2014, MS-DOS 1.25 and 2.0 were released under a Microsoft shared-source license (Microsoft Research License) which forbids redistribution

In 2018, both versions were published to GitHub and relicensed as MIT, making them properly open-source

Today, MS-DOS 4.00 was added to that repo, also under MIT.

For years I’ve been using KeepassXC on desktop and Keepass2Android on mobile. Rather than sync the kdbx file between my devices, I have each device access it through the network. Either via sftp, smb, or nfs, but regardless I need to connect to my home’s VPN to access it when away from home since I don’t directly expose those things to the outside world.

I used to also keep a second copy of the website-tied passwords in Firefox Sync, but recently tried migrating that to Proton Pass because I thought the PIN feature might help, then ultimately decided to move away from that too and start using the KeepassXC-Browser plugin instead. I considered Bitwarden too but haven’t tried it out yet, was somewhat deterred by seeing people say its UI seems very outdated.