nyan

My first step is usually to figure out whether the package should exist as a separate entity under Gentoo (which, for instance, doesn't have separate dev packages). Then I check the overlay masterlist to see if there's an unofficial package (which there often is).

If there is no package, I can package it myself (since I've been working with the same distro for years and can handle the basic packaging cases), install from source, get the .deb and apply alien or deb2targz and proceed from there, or give the whole thing up as a bad job.

Wayland has better support for some newer in-demand features, like multiple monitors, very high resolutions, and scaling. It's also carrying less technical debt around, and has more people actively working on it. However, it still has issues with nvidia video cards, and there are still a few pieces of uncommon software that won't work with it.

The only alternative is X. Its main advantage over Wayland is network transparency (essentially it can be its own remote client/server system), which is important for some use cases. And it has no particular issues with nvidia. However, it's essentially in maintenance mode—bugs are patched, but no new features are being added—and the code is old and crufty.

If you want the network transparency, have an nvidia card (for now), or want to use one of the rare pieces of software that doesn't work with Wayland/XWayland, use X. Otherwise, use whatever your distro provides, which is Wayland for most of the large newbie-friendly distros.

Sometimes raising the barrier to entry is a good thing.

Many Electron applications I've run across don't make even a try at loading system settings. For me, that causes accessibility issues related to photosensitivity. For some reason, feeling like I've been stabbed in the eyeball when I try to open a program does not endear me to it or its framework.

No application at all is actually better than something built on Electron, as far as I'm concerned, because then there's a chance that someone, somewhere, might fill in the gap with software I can actually use.

Electron needs to either actually provide the basics of native functionality, or go away.

Which is why Electron reminds me of a little kid who's just done some extremely difficult but utterlly pointless thing.

Websites belong in a browser. If it doesn't work in any random standards-compliant browser, then you should be delivering it as a true native application, not some horrific fiji-mermaid-esque hybrid.

In the specific case of xz-utils, many lazy people would never have been at risk because the issue is limited to xz-utils 5.6.x (a quite recent version). Not updating provided (unusually) a mitigation in this case.

Six months is the max that's supposed to be supported. (Longest no-update period I've ever sorted out was twelve months. Possible, but time-consuming.)

Well, I can still boot my system without an initram (although that isn't just due to the kernel config)—does that count?

Other than that, custom kernels free up a small amount of disk space that would otherwise be taken up by modules for driving things like CANbus, and taught me a whole lot about the existence of hardware and protocols that I will never use.

Gentoo + OpenRC + TDE (therefore X) on both a first-gen Threadripper desktop with 96GB RAM and a laptop from 2008 with an Athlon64x2 processor and 2GB RAM. Updating gcc on the laptop can take a while, but it still serves well enough. Plus a couple of headless Pis that are also running Gentoo. Not overly unusual, but I may well have the only Threadripper of that gen running that specific distro and DE combination anywhere in the world, since each individual item is kind of low probability.

Well, you do have to feed, er, update it at least every six months if you don't want to be left with an unholy mess to clean up.

It may help to know a bit of history: KDE3 themes could include a bespoke widget style, and QT3 widget styles were always implemented as executables (you can look at modified versions of the C++ code in the TDE git repository, if you're really bored). So keeping code out of the themes hasn't been important to KDE for at least the past 20 years. If I'm not mistaken, far more things are stylable in current versions of KDE. That doesn't mean that every theme will style all of them, though—you can have codeless styles like the one you found, that make use of the built-ins rather than trying to change All The Things.