3 ms·

Even just immutable /usr is still bad for individual users. Eg. I build a few projects myself. And sometimes I also need to debug them, after they are install

Even just immutable /usr is still bad for individual users. Eg. I build a few projects myself. And sometimes I also need to debug them, after they are installed. Also, very frequently used programs, like Web browsers end up there. So, if I had to use an immutable system, I would either not put anything useful in /usr, or would not use an immutable system at all. This is, of course, not true for systems that are meant to be deployed and changed very infrequently, where stability of operation and ability to cleanly undo an upgrade are much more valuable than the convenience of changing whatever you need. ---- I think, a lot of such systems also very quickly earned a bad reputation because they also tried to ship with common applications for interactive use that don't work well (or at all) on such systems (eg. code editors). So, the first people to try such systems were programmers, who spend most of their time using the system in the code editor, and seeing how that doesn't work saw such a system as worthless.

tmtvl 3y ago
By 'I build a few projects myself', do you mean you install binaries to /usr/bin (or /usr/local/bin)? If so, why don't you just put them in $HOME/bin? And about the web browsers, aside from the fact that immutable distributions tend to ship one by default, can't you just install them via Flatpak?
- crabbone 3y ago
  If I put my binaries in a place other than the "immutable" one, what's the point in having the immutable place if I don't use it? If I put my binaries in the "immutable" place, it's no longer immutable. I mean, if, say, I don't build my shell myself -- I'm also not going to modify it anyways. So, expending extra efforts on ensuring immutability is just making my system more complex for no reason. But, if I do build my shell myself, then immutability only gets in the way. There isn't a situation where I gain something tangible from immutability (again, as an individual user). ---- Actually, from my history, the most common thing I need to do in /usr is to create symlinks for various shared objects. Didn't even think about it at first.
  - tmtvl 3y ago
    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.
    - crabbone 3y ago
      This is a kind of fear-induced approach. 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.
vrighter 3y ago
eh, in a couple of years the recommended practice would probably be to keep /usr as minimal as possible, and install stuff to /opt. Then we'll have come around full circle. \s

tmtvl 3y ago

By 'I build a few projects myself', do you mean you install binaries to /usr/bin (or /usr/local/bin)? If so, why don't you just put them in $HOME/bin? And about the web browsers, aside from the fact that immutable distributions tend to ship one by default, can't you just install them via Flatpak?

crabbone 3y ago
If I put my binaries in a place other than the "immutable" one, what's the point in having the immutable place if I don't use it? If I put my binaries in the "immutable" place, it's no longer immutable. I mean, if, say, I don't build my shell myself -- I'm also not going to modify it anyways. So, expending extra efforts on ensuring immutability is just making my system more complex for no reason. But, if I do build my shell myself, then immutability only gets in the way. There isn't a situation where I gain something tangible from immutability (again, as an individual user). ---- Actually, from my history, the most common thing I need to do in /usr is to create symlinks for various shared objects. Didn't even think about it at first.
- tmtvl 3y ago
  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.
  - crabbone 3y ago
    This is a kind of fear-induced approach. 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.

vrighter 3y ago

eh, in a couple of years the recommended practice would probably be to keep /usr as minimal as possible, and install stuff to /opt. Then we'll have come around full circle. \s