I have been distro hopping for about 2 weeks now, thereβs always something that doesnβt work. I thought I would stick with Debian and now I havenβt been able to make my printer work in it, I think I tried in another distro and it just worked out of the box, but thereβs always something thatβs broken in every distro.
Iβm sorry Iβm just venting, do you people think Ubuntu will work for me? I think I will try it next.
Ah. K, I think the differrence is that Iβm the outlier. Your system has far larger components, with more moving parts, which I think is more common:
On most of my systems, Iβm not running any graphical system; theyβre all servers. That eliminates a huge amount of stack that can fail. On all but non-servers I run X, which is very stable (in that upgrades almost never impact it) on non-Nvidia GPUs. And of those, all but one run herbstluftwm - Gnome and KDE are both large systems with a lot of moving parts, any of which can break (or be broken) β in your case, it was Plasma, a KDE component. And the last desktop is running Budgie which, while still Gnome, is a lighter one based on the older GTK3. All of these things tend to make for more stable systems.
But, most people are probably running fancier, full desktop software. Larger, more complex, more development, more frequent changes. And, consequently, more prone to cascading packaging breakages, like the Plasma one.
I think if I were using software like that, Iβd consider either giving up Arch and using an immutable distro, or using something like snapper or timeshift that allows boot-time system roll-backs.
Ah no no, maybe I was unclear, but the issue occurs during the initramfs stage, long before any of my KDE/Plasma nonsense had any chance to run! KMS has nothing to do with KDE. ^^
Edit: You still likely are an outlier though :)
Oh, that plasma. Yeah, that naming conflict is totally not confusing.
You could switch all your repos to the core Arch ones. I did that by accident once, and it was fine (although, I did switch them back eventually). Maybe itβd add release stability? Iβm not really clear how the EOS repos vary off the baseline, except by adding some custom packages.
Inspired by our discussion, I installed snapper on two boxen. I included snap-pac and snapper-support to get system change and grub integration; thereβs probably also a utility out there that adds visudo-like snapshot-before-manual-edit of anything in /etc. If not, itβd be an easy script. snapper-gui and btrfs-assistant both look useful. While Iβm comfortable with rescue SDs and restic backups, what Iβm seeing with Archβs snapper package is pretty nice, and super easy.
I suppose anything that borks grub is going to be a PITA no matter how immutable your OS, or how fancy your rollback. Or - god forbid - fucks up your BIOS firmware. I have never had that last happen, yet (knock on wood).
You could switch all your repos to the core Arch ones. I did that by accident once, and it was fine (although, I did switch them back eventually). Maybe itβd add release stability? Iβm not really clear how the EOS repos vary off the baseline, except by adding some custom packages.
They donβt afaik. EOS uses Archβs repos directly, unlike Manjaro. Just adds its own on top for all the fancy EOS stuff. Which is why EOS was immediately affected by the grub meltdown and not Manjaro. (which kinda digs a few holes in the stability hypothesis, though Manjaro is another kettle of fish tbf)
Snapper sounds really interesting, and I didnβt expect βsuper easyβ to be the feedback there. Sounds a bit overkill for my use case at home but I might look into it for work. Thanks for the info!
Oh god a borked BIOS is my nightmareβ¦ I donβt even know how youβd go about fixing that on a modern PC moboβ¦ Letβs not jinx it shall we?
