4 ms·

Be careful when updating packages. As an OS X user used to blithely updating anything and everything because it always "just works," I've gotten into shocking s

Be careful when updating packages. As an OS X user used to blithely updating anything and everything because it always "just works," I've gotten into shocking situations where I've actually bricked my Elementary install simply by doing an update. When I approached Linux users about this, their response was something along the lines of "Yeah... don't do that." (Seriously?) As a result I've had to run Elementary in a VM with snapshotting, and I roll back the snapshot if an update hoses the install. Kinda shitty, if you ask me.

yellowapple 12y ago
It depends on the distro. Some distros can and will mangle themselves if you blindly upgrade everything without doing at least some research beforehand (Ubuntu and Arch are notorious for this; Arch because it's bleeding-edge and has absolutely zero consideration for compatibility between packages, and Ubuntu because... well... who the hell knows). Others do a much better job of making sure all packages are well-tested both in isolation and in integration before making them available as upgrades; Debian Stable, Slackware, and openSUSE are good examples of systems where you can usually do a blind upgrade of everything without problems. And then you have NixOS, which - while not really mainstream yet - is probably a good indicator of the future of configuration and package management, and - I think - will someday be the gold standard here. Upgrade fucked up your system? No problem; just select your last-known-good configuration at boot, then try again (or don't try again, if that's your prerogative).
- lectrick 12y ago
  > No problem; just select your last-known-good configuration at boot, then try again This sounds like a configuration that could potentially be applied to other Linux OS'es, no?
  - yellowapple 12y ago
    In theory, yes. In practice, this tends to be a difficult problem to solve because most Linux environments are managed imperatively/procedurally rather than declaratively, meaning that in order to revert to a previous state, you have to be able to run the exact commands required to do so. The traditional answer is to manage such a system with Puppet or Chef - thus allowing an administrator to tell the system what it should look like rather than how it should go about it - but that's generally yet another layer of logical overhead to be considered. NixOS - in theory, at least - addresses this more fully by integrating declarative configuration rather pervasively throughout the operating system itself, rather than trying to just add a layer on top of the operating system in order to manage it. It relies heavily on the Nix package manager - instead of installing a program directly to the filesystem hierarchy, it installs it to an isolated folder named with a theoretically-unique hash, allowing multiple versions of the same program to coexist without conflicting (and allowing users to pick which version they want), making it painless to roll back software upgrades (just go back to a different selection of which package folders should be linked to, rather than having to manually remove and revert each package), etc.; NixOS leverages this package management system for everything, rather than just the software installed, and will create GRUB entries whenever you commit your configuration changes (by running `nixos-rebuild switch` or `nixos-rebuild boot`, causing an instant configuration switch or a configuration switch on next boot, respectively). Other operating systems can hypothetically do this, too, and they'd end up looking similar to NixOS in terms of how things are organized and configured. As I said, I think that's probably the direction where most operating systems will eventually go.
    - lectrick 12y ago
      So all the actual filesystem entries are basically soft or hardlinks to the most recently selected version? Time Machine on OS X works that way (as do a few other incremental backup solutions, I believe). Notably in Time Machine's case, it hacks a way to hardlink to entire directories which haven't changed, which is normally not possible. (There's a parallel here with how immutable data structures are managed.)

yellowapple 12y ago

It depends on the distro. Some distros can and will mangle themselves if you blindly upgrade everything without doing at least some research beforehand (Ubuntu and Arch are notorious for this; Arch because it's bleeding-edge and has absolutely zero consideration for compatibility between packages, and Ubuntu because... well... who the hell knows). Others do a much better job of making sure all packages are well-tested both in isolation and in integration before making them available as upgrades; Debian Stable, Slackware, and openSUSE are good examples of systems where you can usually do a blind upgrade of everything without problems. And then you have NixOS, which - while not really mainstream yet - is probably a good indicator of the future of configuration and package management, and - I think - will someday be the gold standard here. Upgrade fucked up your system? No problem; just select your last-known-good configuration at boot, then try again (or don't try again, if that's your prerogative).

lectrick 12y ago
> No problem; just select your last-known-good configuration at boot, then try again This sounds like a configuration that could potentially be applied to other Linux OS'es, no?
- yellowapple 12y ago
  In theory, yes. In practice, this tends to be a difficult problem to solve because most Linux environments are managed imperatively/procedurally rather than declaratively, meaning that in order to revert to a previous state, you have to be able to run the exact commands required to do so. The traditional answer is to manage such a system with Puppet or Chef - thus allowing an administrator to tell the system what it should look like rather than how it should go about it - but that's generally yet another layer of logical overhead to be considered. NixOS - in theory, at least - addresses this more fully by integrating declarative configuration rather pervasively throughout the operating system itself, rather than trying to just add a layer on top of the operating system in order to manage it. It relies heavily on the Nix package manager - instead of installing a program directly to the filesystem hierarchy, it installs it to an isolated folder named with a theoretically-unique hash, allowing multiple versions of the same program to coexist without conflicting (and allowing users to pick which version they want), making it painless to roll back software upgrades (just go back to a different selection of which package folders should be linked to, rather than having to manually remove and revert each package), etc.; NixOS leverages this package management system for everything, rather than just the software installed, and will create GRUB entries whenever you commit your configuration changes (by running `nixos-rebuild switch` or `nixos-rebuild boot`, causing an instant configuration switch or a configuration switch on next boot, respectively). Other operating systems can hypothetically do this, too, and they'd end up looking similar to NixOS in terms of how things are organized and configured. As I said, I think that's probably the direction where most operating systems will eventually go.
  - lectrick 12y ago
    So all the actual filesystem entries are basically soft or hardlinks to the most recently selected version? Time Machine on OS X works that way (as do a few other incremental backup solutions, I believe). Notably in Time Machine's case, it hacks a way to hardlink to entire directories which haven't changed, which is normally not possible. (There's a parallel here with how immutable data structures are managed.)