4 ms·

For me, the "borking" issue is largely resolved by running Btrfs. Just make a snapshot shortly before updating, and then I can revert to it if needed.

unshavedyak 4y ago
My problem is i don't know what gets borked immediately after updating unless it's catastrophic. Ie i've gone a fair bit of time before i realized some specific functionality of some program no longer works due to some unrelated change in an underlying dependency that i was unaware of. Oof. Granted Btrfs sounds great though, i've not used that. It would certainly help.
- seanw444 4y ago
  Yeah that's true. That's where the "largely" part of my comment does some work. I just take occasional snapshots before I do things that I'm concerned may be catastrophic. But it definitely won't catch everything. It helps that I run Arch, and I update packages once a day, which only leaves me with under 40 (small) packages usually. So a quick cursory glance at which ones are updating usually tells me what to be cautious of. Display driver update, kernel update, etc. If I'm not sure what went wrong, but I at least have a working snapshot, then I can get done what I need to get done, and then go back to troubleshooting. Rather than just having a broken system regardless.
tripdout 4y ago
I used to employ ZFS for this, but if it took me a while to notice something was broken, or I updated multiple times, it was annoying to figure out which snapshot was the issue, and which changes actually caused the problem. On NixOS, I just have to select a different generation in systemd-boot, and since my configuration is stored in a Git repo, they're all tagged with the data and commit hash they were built at, so it's very quick to a) find a working generation to just use for now, and b) actually find where the issue is and solve it.

4 ms·

For me, the "borking" issue is largely resolved by running Btrfs. Just make a snapshot shortly before updating, and then I can revert to it if needed.

by seanw444 4y ago

unshavedyak 4y ago
My problem is i don't know what gets borked immediately after updating unless it's catastrophic. Ie i've gone a fair bit of time before i realized some specific functionality of some program no longer works due to some unrelated change in an underlying dependency that i was unaware of. Oof. Granted Btrfs sounds great though, i've not used that. It would certainly help.
- seanw444 4y ago
  Yeah that's true. That's where the "largely" part of my comment does some work. I just take occasional snapshots before I do things that I'm concerned may be catastrophic. But it definitely won't catch everything. It helps that I run Arch, and I update packages once a day, which only leaves me with under 40 (small) packages usually. So a quick cursory glance at which ones are updating usually tells me what to be cautious of. Display driver update, kernel update, etc. If I'm not sure what went wrong, but I at least have a working snapshot, then I can get done what I need to get done, and then go back to troubleshooting. Rather than just having a broken system regardless.
tripdout 4y ago
I used to employ ZFS for this, but if it took me a while to notice something was broken, or I updated multiple times, it was annoying to figure out which snapshot was the issue, and which changes actually caused the problem. On NixOS, I just have to select a different generation in systemd-boot, and since my configuration is stored in a Git repo, they're all tagged with the data and commit hash they were built at, so it's very quick to a) find a working generation to just use for now, and b) actually find where the issue is and solve it.