4 ms·

For me, i use it on my Desktop because i love things being stable for my work environment. I don't want an upgrade over the weekend to cause problems come Monda

For me, i use it on my Desktop because i love things being stable for my work environment. I don't want an upgrade over the weekend to cause problems come Monday morning. I've had my system get "borked" on updates in the past, and Nix lets me revert very very easily. Also upgrading libraries for one App can easily be isolated from breaking other applications and etc. It's got tons of flaws (to me), but the core idea to me is a foundation for a super stable system. I both love Nix and hate it. It's so good that myself, a large critic of the OS, still uses it.

seanw444 4y ago
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.

seanw444 4y ago

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.