nyan
I ended up setting up custom themes for multiple different widget sets to get a true black background. It was easy for most QT variants, not too bad for GTK2, really awful for GTK3 because it doesn’t have proper documentation for manual theme creation, and I haven’t tried to tackle GTK4 yet.
Because they all need different configs (and the window manager title bar etc. may need yet another one), it’s difficult to give suggestions unless you tell us which terminal and window manager software you’re trying to theme—the requirements for a Gnome session are different from those for something like fluxbox. Some terminal software even has its own built-in theming support.
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.
I have at least four libraries, then, it seems. (My ex-librarian mother estimated ~3000 twenty years ago based on board-feet of occupied shelving, and I’ve only acquired more since.)
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.