nyan

TDE. Functional, stays out of my way, but still reasonably full-featured. The development team is dedicated to adding useful features while keeping the original look and feel, so I don't have to go hunting for settings that have inexplicably moved or changed defaults every time I update. It doesn't support Wayland, but I'm Wayland-neutral (that is, I have nothing against it, but I have nothing against X either).

Yet another, "well, yeah, technically it has security ramifications, but I'm not admin'ing any multiuser machines, so I'm not losing any sleep over it" bug.

Gentoo supports either configuration, as it does with a lot of things. My systems were installed with split /usr and I have no intention of changing that, because the merge adds no value for me.

Um, if your primary use is typing accented letters, why don't you just set a compose key? The character sequences you need to type are much more intuitive, and you don't get this type of problem.

In my case, I have scroll lock (the most useless key on the keyboard) set as a compose key. To get "é", I type scroll lock, then e, then '.

You can set a compose key using setxkbmap, for instance setxkbmap -option compose:sclk. (If scroll lock isn't to your liking, there are a number of other modifier keys that can be used instead—list here, starting around line 810.) You can also specify it permanently using X configuration files, although I don't know the exact method.

The GPU doesn't care about the CPU, or vice-versa. AMD is probably better value for money right now if you're intending to replace both CPU and mobo, but Intel will work.

The reason you don't see AMD CPU + nVidia GPU in premade machines these days has to do with corporate contracts, not interoperability. Before AMD bought out ATI, it wasn't an uncommon combination.

Even if the original issue had anything to do with ISOs, he's way overestimating the level of protection on many install ISOs, in my experience—they're just disk images, and presumably all the files read off them are passing through Ventoy itself. Even if you find one that performs some kind of verification, easy enough to change a jump instruction to a no-op somewhere in the machine code guts of a file as it passes through Ventoy, and prevent the verification from executing. (The difficult part is figuring out which instruction to change, but people have done it before.)

It can’t inject anything into the ISO files at rest without bricking then, and I don’t know if an OS that doesn’t verify it’s own image before booting.

As far as I can tell, this is not talking about ISOs installed using Ventoy, but precompiled blobs of things like Busybox that are included in the Ventoy install package. It's an important distinction. The developer could bundle a tampered blob, include in the documentation the checksum that matches that blob, and then if someone checks with the upstream project and calls them out, say something along the lines of, "Oh, they must have withdrawn that release," and replace it with an untampered blob. If they don't fight to preserve the tampered blob, they might even get away with it.

-o PubkeyAuthentication=no should only work if the server is configured to allow password auth at all. I believe the advice these days is to disable password auth completely for security.

Configuring captive portal wifi without network manager or any aids beyond what's provided by wpa-supplicant. Eventually I gave up, since it wasn't really that important.

Adjusting freetype so that it works more-or-less the way I want it to, because the maintainers hate anyone who disagrees with their current hinting algorithm and make the setting as opaque as possible. I would prefer it if they allowed me to have hinting on some fonts and exclude only the ones that were designed to be pixel-aligned, but unless something's changed recently, that option isn't even offered.

Gentoo is its own thing. You can bump packages yourself a lot of the time with a few commands. Or have the package manager install directly from upstream source control, if that's your bag. Or you can hold on to older package versions for periods ranging from months to years, by stashing ebuilds in a local repository. At the same time, portage has reached the point where it bends over backwards to keep you from breaking stuff by accident. If you've done your setup right and use primarily stable keywords, breaking changes are very rare. And you're free to install things outside the protection of the package manager, or package things yourself if you don't mind working with bash scripting.

The tradeoff for all of this is that you have to spend a fair amount of time setting up and configuring stuff, and a fair amount of time compiling software if you want a USE flag combination other than what's on the binhost. It also helps to spend time learning the ins and outs of the portage/ebuild ecosystem if you're going to do anything unusual.

As for the proprietary nvidia drivers specifically, Gentoo currently has versions 390.157, 470.256.02, 525.147.05, 535.183.01, and four different 550+ available, which should cover most hardware of the past several years.

If you want to see whether certain software has been packaged without installing Gentoo, the best place to check is gpo.zugaina.org. The search function isn't all that bright, but it's the only site I know of that indexes all the official overlays and the Gentoo bugzilla along with the main repository.

I don't know how Debian's solution works, so I couldn't say for certain. Gentoo usually installs the different package versions to their own directories, and there are methods for selecting a "system python" (or lua, etc) which is the target of the /usr/bin/python symlink. Other versions have to be called with qualifiers (for instance, python3.10). Python libraries installed through the package manager may install to one or several versions depending on the content of a couple of environment variables, and applications that need python can request a specific version if they need to, or accept the system python if they don't care. (Note that python2 is no longer eligible to be the system python—you need at least one python3, although 2.7.18 remains in the package repository and can be installed as well if you really need it.)

Of course, if you're not a programmer, you can leave the defaults for everything alone, and most of the time it should Just Work.

One problem with distro packages is that you can only install one version.

This isn't technically true for all distros—Gentoo has a mechanism that will allow multiple package versions to be installed in parallel. I have multiple distro-packaged Python and Lua interpreter versions on my system, for instance. But it does require some extra work by the packager, so it isn't done universally for all packages.