4 ms·

I think the future is probably something more NixOS-like. Now, personally, I've tried it and found it a bit wanting UX-wise (and for really niche stuff), but fo

I think the future is probably something more NixOS-like. Now, personally, I've tried it and found it a bit wanting UX-wise (and for really niche stuff), but for providing cutting edge and the ability to roll back safely I don't think it can be beaten. If you have databases, etc. that might need to be rolled back things get more complicated, ofc. Right now, I'm running Arch Linux with a small smattering of self-compiled stuff. Arch seems to actually be pretty stable, unless you're using their 'testing' repos... and it's very close to bleeding edge. Their secret, I think, is staying as-close-as-possible to upstream -- the trouble usually starts when distros start to add large patches. This has been a huge issue for me with Debian/Ubuntu.

mvanbaak 6y ago
With zfs and boot environments the whole rollback issue is solved. No need for nixos for that.
- Quekid5 6y ago
  Definitely for most cases, yes... but 'data' is still an issue (if you care about the data). NixOS has an interesting mechnanism for separating "package" upgrades from "data" upgrades, tho, so that's a slight advantage. (They basically keep around old binaries to be able to run and back up an old database and restore it on a newer version. Straightforward file system snapshots don't really do that.) EDIT: Sorry, I feel I didn't explain this very well. The main point is: You can have multiple versions of all the software on your system, including stuff like PostgreSQL. That's actually very powerful. Another potential problem is the licensing and root-on-ZFS. Personally, I'm really looking forward to an in-upstream-kernel FS like bcachefs. (I'm actually a fan of ZFS, we use it on our servers, etc. I still feel a bit uneasy about the licensing issues and the fact that it's not in-kernel.)
- ducktective 6y ago
  AFAIK, nixos isn't about just rollbacks...Things like ability to declare the state of your system (with all your apps) in a single file and possibility of having two different build of the same program in the system seems very futuristic and productive to me...I mean, this thing frees us from docker/vbox. I think even the Linux kernel would be a component of NixOS and could be substituted with something else. The whole idea is just an enterprise-proposal away from getting polished around the edges.
- m463 6y ago
  seems like zfs would be a low-level solution and nix would be a high-level solution.
jez 6y ago
I’ve been using Linuxbrew with Ubuntu (actually Pop!_OS). Linuxbrew is macOS’s Homebrew but for Linux, maintained by the same organization and using the same codebase. If something needs to be installed system-wide, like dev headers for ncurses or something, I’ll install it through apt. But for nearly everything else (git, Neovim, fzf, tmux, htop, ripgrep, ...) I install it though Linuxbrew. Linuxbrew formulas are up to date, not ancient. I have yet to run into a problem where a formula only worked on macOS and not Linux. Also for homebrew core packages they publish pre-built bottles so that I don’t have to build everything from source. It’s pretty great. Pop!_OS is pretty much zero-upkeep, and Linuxbrew has everything I need. I’ve said it before but the only thing really missing to keep me from using Linux as my main OS with this combo is better desktop mouse sensitivity and keybindings that mimic macOS system-wide (Cmd-C, Cmd-V, ...)
m463 6y ago
> Their secret, I think, is staying as-close-as-possible to upstream I've wondered about this. This would depend on upstream being sane about how it does things or puts things. Is this always the case?
- Quekid5 6y ago
  Usually, yes, it appears. Maintainers of projects are generally pretty invested in getting their software into popular distros... and so they tend to follow the patterns that would allow that. (I mean, stuff like 'where do I put the binaries' is still often configured in Arch and other distros, so we're talking about stuff outside of that kind of thing. Most packages aren't complicated enough to require anything outside of simple configure flags.)
  - josephg 6y ago
    I wish there were more standards & conventions here. It seems silly that every package needs to be manually packaged for Debian/red hat/arch/etc, FreeBSD, homebrew, and maybe Cygwin/whatever people use now. That’s a whole lot of work, often for every new version of the program! And all that work could vanish if there was a standard bundler. I think modern package managers for programming languages show us the right approach here. A cargo binary crate can be built on any platform that rust supports, it knows it’s dependencies and the compiler flags are passed in in a consistent way. I could imagine cargo having a 1 button “publish crate to dpkg/homebrew/ etc etc” button. Or alternately, I could imagine Debian allowing crates.io to exist as part of the package namespace. Then you could “apt install crate/foo” and the “foo” package author wouldn’t have to think about dpkg at all. (Maybe this already exists? It would be a sweet way to use the ppa system.)
    - rrdharan 6y ago
      > And all that work could vanish if there was a standard bundler. The same balance of forces that mandate all of that toilsome work are exactly what would prevent any standard bundler from succeeding. You can follow https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaksReasonsWhy https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaks... and https://www.techrepublic.com/article/why-snap-and-flatpak-are-so-important-to-linux/ https://www.techrepublic.com/article/why-snap-and-flatpak-ar... and various related discussions around this and eventually I am confident you will conclude that while things may change (today there's docker in the mix as well, tomorrow there will be something else), the one-true-packaging-solution will never be invented. There are simply far too many fundamentally conflicting interests to ever prevent that level of standardization. What you see now is more or less what you will always get. Or, perhaps, we'll see something worse (i.e. only fully locked down computing devices, only app stores with no sideloading capabilities, various other dystopian outcomes). I'm pretty sure we're not going to see something better though; we've had plenty of time...
nanna 6y ago
It doesn't have to be one or the other. I've been very happily using Guix as a package manager inside my Debian, thereby having a Debian with up-to-date versions of packages and access to all the other benefits of using a next-generation package manager (specifying release candidates, docker-like portable builds, plus emacs integration). Just have to be slightly careful not to install packages via Guix that might cause conflicts, especially with Gnome. But if you do you can always just hop into a tty and `guix package --roll-back` to get back to a working build. Maybe one day I'll migrate to Guix as a distro in itself rather than just a package manager within a foreign distro (Debian), but for now the setup works well, and it's also a nice way to get experience with Guix before diving into the deep end.
- Quekid5 6y ago
  I have done this as well (with Nix rather than Guix, but it doesn't matter). You do run into some friction sometimes, e.g. the UI themes from your main distro not applying properly (because paths are all wrong). It does basically work, but it can be a bit jarring, depending on exactly what you're trying to do.

mvanbaak 6y ago

With zfs and boot environments the whole rollback issue is solved. No need for nixos for that.

Quekid5 6y ago
Definitely for most cases, yes... but 'data' is still an issue (if you care about the data). NixOS has an interesting mechnanism for separating "package" upgrades from "data" upgrades, tho, so that's a slight advantage. (They basically keep around old binaries to be able to run and back up an old database and restore it on a newer version. Straightforward file system snapshots don't really do that.) EDIT: Sorry, I feel I didn't explain this very well. The main point is: You can have multiple versions of all the software on your system, including stuff like PostgreSQL. That's actually very powerful. Another potential problem is the licensing and root-on-ZFS. Personally, I'm really looking forward to an in-upstream-kernel FS like bcachefs. (I'm actually a fan of ZFS, we use it on our servers, etc. I still feel a bit uneasy about the licensing issues and the fact that it's not in-kernel.)
ducktective 6y ago
AFAIK, nixos isn't about just rollbacks...Things like ability to declare the state of your system (with all your apps) in a single file and possibility of having two different build of the same program in the system seems very futuristic and productive to me...I mean, this thing frees us from docker/vbox. I think even the Linux kernel would be a component of NixOS and could be substituted with something else. The whole idea is just an enterprise-proposal away from getting polished around the edges.
m463 6y ago
seems like zfs would be a low-level solution and nix would be a high-level solution.

jez 6y ago

I’ve been using Linuxbrew with Ubuntu (actually Pop!_OS). Linuxbrew is macOS’s Homebrew but for Linux, maintained by the same organization and using the same codebase. If something needs to be installed system-wide, like dev headers for ncurses or something, I’ll install it through apt. But for nearly everything else (git, Neovim, fzf, tmux, htop, ripgrep, ...) I install it though Linuxbrew. Linuxbrew formulas are up to date, not ancient. I have yet to run into a problem where a formula only worked on macOS and not Linux. Also for homebrew core packages they publish pre-built bottles so that I don’t have to build everything from source. It’s pretty great. Pop!_OS is pretty much zero-upkeep, and Linuxbrew has everything I need. I’ve said it before but the only thing really missing to keep me from using Linux as my main OS with this combo is better desktop mouse sensitivity and keybindings that mimic macOS system-wide (Cmd-C, Cmd-V, ...)

m463 6y ago

> Their secret, I think, is staying as-close-as-possible to upstream I've wondered about this. This would depend on upstream being sane about how it does things or puts things. Is this always the case?

Quekid5 6y ago
Usually, yes, it appears. Maintainers of projects are generally pretty invested in getting their software into popular distros... and so they tend to follow the patterns that would allow that. (I mean, stuff like 'where do I put the binaries' is still often configured in Arch and other distros, so we're talking about stuff outside of that kind of thing. Most packages aren't complicated enough to require anything outside of simple configure flags.)
- josephg 6y ago
  I wish there were more standards & conventions here. It seems silly that every package needs to be manually packaged for Debian/red hat/arch/etc, FreeBSD, homebrew, and maybe Cygwin/whatever people use now. That’s a whole lot of work, often for every new version of the program! And all that work could vanish if there was a standard bundler. I think modern package managers for programming languages show us the right approach here. A cargo binary crate can be built on any platform that rust supports, it knows it’s dependencies and the compiler flags are passed in in a consistent way. I could imagine cargo having a 1 button “publish crate to dpkg/homebrew/ etc etc” button. Or alternately, I could imagine Debian allowing crates.io to exist as part of the package namespace. Then you could “apt install crate/foo” and the “foo” package author wouldn’t have to think about dpkg at all. (Maybe this already exists? It would be a sweet way to use the ppa system.)
  - rrdharan 6y ago
    > And all that work could vanish if there was a standard bundler. The same balance of forces that mandate all of that toilsome work are exactly what would prevent any standard bundler from succeeding. You can follow https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaksReasonsWhy https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaks... and https://www.techrepublic.com/article/why-snap-and-flatpak-are-so-important-to-linux/ https://www.techrepublic.com/article/why-snap-and-flatpak-ar... and various related discussions around this and eventually I am confident you will conclude that while things may change (today there's docker in the mix as well, tomorrow there will be something else), the one-true-packaging-solution will never be invented. There are simply far too many fundamentally conflicting interests to ever prevent that level of standardization. What you see now is more or less what you will always get. Or, perhaps, we'll see something worse (i.e. only fully locked down computing devices, only app stores with no sideloading capabilities, various other dystopian outcomes). I'm pretty sure we're not going to see something better though; we've had plenty of time...

nanna 6y ago

It doesn't have to be one or the other. I've been very happily using Guix as a package manager inside my Debian, thereby having a Debian with up-to-date versions of packages and access to all the other benefits of using a next-generation package manager (specifying release candidates, docker-like portable builds, plus emacs integration). Just have to be slightly careful not to install packages via Guix that might cause conflicts, especially with Gnome. But if you do you can always just hop into a tty and `guix package --roll-back` to get back to a working build. Maybe one day I'll migrate to Guix as a distro in itself rather than just a package manager within a foreign distro (Debian), but for now the setup works well, and it's also a nice way to get experience with Guix before diving into the deep end.

Quekid5 6y ago
I have done this as well (with Nix rather than Guix, but it doesn't matter). You do run into some friction sometimes, e.g. the UI themes from your main distro not applying properly (because paths are all wrong). It does basically work, but it can be a bit jarring, depending on exactly what you're trying to do.