d3Xt3r

Why though? Mobiles can word-wrap just fine, you don't need to manually do it.

Is there some trick that can request grub not to install?

That really depends on your distro's installer, so there's no simple answer to your question. If you're using Arch for instance, you have complete control over that process. For other distros, you'll need to do your homework.

In saying that, one option could be to do a manual partition restore - like install your distro inside a VM (but don't reboot after the install, just shutdown the VM), and then clone the partition from the VHD to your real drive. After that you can just create an entry in rEFInd. But that's more effort than simply just changing the default bootloader.

But, how about backing up just the boot sectors / EFI partition with a dd command and then just restoring it again? Not a slick solution, I agree

Unfortunately that does nothing on a UEFI system. There's no boot record any more (just a partition table) and even if there were (ie it's an MBR drive instead of GPT) it would be ignored under UEFI.

But in the case of rEFInd and GRUB, both would actually happily live side by side, what's changing is just the default bootloader selection in the UEFI. So all you need to go into your UEFI settings and point it back to your choice of bootloader. No need to worry about reinstalling the bootloader, messing with config files, etc.

ULWGL-protonfixes renamed to umu-protonfixes

So it looks "uwu" is now the official name for this. Not sure if I like it or not, but at least it's much better than "ULWGL".

Essentially, an updated dependency requirement in Mesa (updated Zlib) broke an important benchmarking tool (SPECViewPerf) used by hardware vendors. Subsequently, this change was reverted. This caused a debate in the Mesa dev community, with some devs claiming it's not Mesa's fault, it should be treated as a bug in SPECViewPerf instead. In response, AMD's Mesa dev said this isn't a technical issue, but rather a political/strategic issue - you don't want to anger important workstation vendors and other high-level parties who use this tool, especially since they contribute so much to the Linux ecosystem. That would make the Mesa project seem very immature/unreliable.

As an example, imagine if this change broke something more popular like Steam - Valve and all Linux gamers would be out for blood and you bet the Mesa change would be reverted without debate - even if they were technically in the right (that it's not a bug).

So this incident serves as an important reminder for those who work on big opensource projects like this - just because your actions are technically correct, it doesn't mean it's okay to break everyone else's stuff, expecting they'll fix it. This is in fact something Linus preaches when it comes to kernel dev - "don't break userspace".

And a non-gaming focused equivalent would be Bluefin.

Have you tried using the latest git version of Waybar? They fixed a segfault a few days ago which might be the same one you're facing.

And the ones who install Arch on a MacBook need extra special therapy.

"Life moves pretty fast. If you don't stop and look around once in a while, you could miss it."
    - Ferris Bueller, from the movie Ferris Bueller's Day Off.

It's easy enough to containerize an entire DE - but if you did that, you be basically running everything from inside the container - at which point you're back to square one. You're just shifting the problem from the host to the container, and the solution to fix both is the same: restore from a snapshot, reinstall, or actually try and fix the issue.

Also, a DE shouldn't bring down the whole system btw - you should always be able to switch to a second TTY to recover, and/or have a backup lightweight DE that you can switch to from your logon screen. Unless of course something really broke and caused a kernel panic and your system is fully frozen (which should be a rare occurrence on Linux-friendly hardware).

Anyways, a realistic solution would be to use an immutable distro, such as one of the Fedora Atomic/uBlue distros. The kind of breakage mentioned by OP won't be possible in such a distro, because your entire system gets updated as a single image, so it either works or it doesn't (an atomic operation), and in the event it doesn't work, you can always switch back to a previous image from the boot menu instantly. You can "pin" known good images, and this sort of image operations makes it easy to switch between latest testing/stable image version, or even switch between entire DEs with a single command. So if your KDE 6 is broken, not only can you just go back to KDE 5 with a single reboot, you can also switch to a GNOME image, or rebase to something else entirely, without messing up anything, without creating a dependency hell.

It's not quite the same but the basic idea is similar. The Indian version also adds lentils, cumin and coriander seeds, maybe other stuff too (like curry leaves) depending on the recipe/brand.

Here's a basic recipe: https://cookwithrenu.com/wprm_print/7215

Advanced version: https://www.myspicykitchen.net/ellipaya-karam-garlic-dry-chilies-powder/#:~:text=Source%3A%20here-,Preparation,-%3A%2010%20%2D%2015