It doesn't necessarily take much hackability away. You might find it makes it easier.

You can overlay changes to the read-only rootfs using the sysext mechanism. You can load and unload these extensions. This makes experiments or juggling debug stuff a lot easier than mucking about in /usr used to be.

A lot of KDE Linux is about making updates and even hackability safe in terms of making things trivial to roll back or remove. A goal is to always be able to unwedge without requiring a reinstall.

If you know you can overlay whatever over your /usr and always easily return to a known-good state, hackability arguably increases by lowering the risk.

▲

RossBencina 4 days ago | parent | next [-]

This overlay feature sounds attractive. It bothers me that there is no easy traceability or undoability when I perform random system-level Ubuntu configuration file edits to make things work on my system. Maybe I'm doing it wrong. Sure I could do the professional sysadmin thing and keep a log book of every configuration change, or maybe switch to NixOS and script all my configuration changes, but something with lower effort would be welcome. Ideally you want the equivalent of "git commit -m<explanation>", "git diff" and "git log" for every change you make to system configuration.

▲

stakhanov 3 days ago | parent | next [-]

CachyOS and openSUSE have you covered with btrfs and snapper pre-configured to take snapshots before/after doing potentially damaging things (and, of course, you can make them manually, whenever the thought occurs to you that you're entering the "danger zone"). You can boot into a snapshot directly from the boatloader, then rollback if you need to.

Immutable distros just one-up that by trying to steer the system in a direction where it can work with a readonly rootfs in normal operation, and nudging you to take a snapshot before/after taking the rootfs from readonly to read-write. (openSUSE has you covered there as well, if that's your thing; it's called MicroOS).

Both of those distros use KDE by default, so the value-add of KDE having its own distribution is basically so they can have a "reference implementation" that will always have all the latest and greatest that KDE has to offer, and showcase to the rest of the Linux world, how they envision the integration should be done.

If I were to set up a library computer or a computer for my aging parents, I would choose openSUSE Leap Micro with KDE, as that would put the emphasis on stability instead.

	▲	vanviegen 3 days ago \| parent [-]
		There's also https://getaurora.dev/ - another immutable KDE-based distro. I've been using it as my daily for ~half a year now. It just works.

▲

codethief 3 days ago | parent | prev | next [-]

> Ideally you want the equivalent of "git commit -m<explanation>", "git diff" and "git log" for every change you make to system configuration.

If you already commit all your changes, anyway, what keeps you from using Nix and running one more command (`nixos-rebuild switch`)?

▲

albertzeyer 3 days ago | parent | prev | next [-]

I keep my /etc under Git. When the system does changes automatically (via an update or whatever), I make a Git commit with a special distinct message, and so I can easily filter out all my own changes.

▲

mkesper 3 days ago | parent | prev | next [-]

Etckeeper does that for changes to /etc https://wiki.archlinux.org/title/Etckeeper

▲

mikae1 3 days ago | parent | prev [-]

> something with lower effort would be welcome

This is a major reason I ended up with https://getaurora.dev. I layer a few things, but it comes with bells and whistles (like NVIDIA drivers, if you need that).

I can't see myself going back to a "normal" distro. I don't want to spend time cosplaying a sysadmin, I have things to do on my computer.

▲

seba_dos1 3 days ago | parent | prev [-]

> It doesn't necessarily take much hackability away.

It doesn't, though - as evidenced by my Steam Deck - it adds enough friction to make me not bother most of the time.