If I build a shell, unwittingly fuck up the build configuration, and make install it into /usr; then fixing it will be... well it'd be easy because I have Snapper set up so I can just roll back a snapshot, but if I didn't have that fixing the system could be quite annoying.
If I install the borked shell into my $HOME then fixing it is as easy as removing the broken binary so I fall back on the underlying working shell.
That's the value of immutable /usr, having a reliable underlying fallback system which my fallible human self won't fuck up due to carelessness or hubris.
And yeah, I think most people only modify /usr to put library symlinks in for applications that have particular dependencies. But you can put those where ever as long as they're on your load path.
I dunno. I'm not afraid of breaking /usr. If I screw up, I'll fix it. I don't screw up often enough to have to also deal with setting up backups.
Being in the storage business, I have a sense of how hard it is to have functional / useful backups, how much you need to test that the backups will actually work, that they will do what you want them to do... I.e. if you think that setting up Snapper is going to solve your problems with bad installs, you probably didn't investigate the subject in depth. It covers but one of many potential failure scenarios. Anecdotally, one of my first experiences with immutable snapshots was with Btrfs, which... actually, I don't know what happened to it beside knowing it was a software error (the physical storage outlasted Btrfs by many years). So, once upon a reboot I discovered that Btrfs simply won't mount, and then I had a week-long process of trying to understand the failure, trying to restore from snapshot etc. And, eventually, I reformatted the disk with Ext4. The data wasn't salvageable at all (layered filesystem aren't your best friend if you want to recover data...).
It's really easier for me, individually to try and deal with the consequences than to have to set up and supervise a system that might help me if I screw up.
Again, this is all said from a perspective of individual usage. I have a different approach to computers that need to be used for business / organizations. There, I think, it's justified to spend the extra effort on backups, recovery protocols, data consistency etc.
So, to rephrase: I don't think that immutable /usr doesn't have value. It's just the effort for individual users isn't justified by the value it provides to them.
> It's really easier for me, individually to try and deal with the consequences than to have to set up and supervise a system that might help me if I screw up.
Aye, there's the rub: you're you: smart, handsome, successful. You're intelligent enough to know what you're doing or at least to figure out how to fix something if you do happen to make a mistake.
Conversely, I'm me: the average user. It's a miracle I can think (for a broad definition of think) and breathe at the same time. For the one time in a decade that my one brain cell overexerts itself and I try to do something 'clever' it's really helpful if the system can limit the amount of damage I cause. And I think that for the average pseudo-sentient troglodyte like myself it's better to have a system which is awkward to use but hard to break rather than something that gives enough rope.
It's kinda like the difference between a programming language with manual memory management and something like Rust (with the borrow checker) or Lisp (with garbage collection). For someone with a modicum of intelligence C is fine, but the majority of people are better off with a language that keeps the sharp objects locked safely (if you'll pardon the pun) away.
If I install the borked shell into my $HOME then fixing it is as easy as removing the broken binary so I fall back on the underlying working shell.
That's the value of immutable /usr, having a reliable underlying fallback system which my fallible human self won't fuck up due to carelessness or hubris.
And yeah, I think most people only modify /usr to put library symlinks in for applications that have particular dependencies. But you can put those where ever as long as they're on your load path.