6 ms·

I agree with a lot of this. GNU/Linux distros are going down a very dangerous path with Snappy, Docker, Flatpak, Atomic, etc. I think a lot of this is respond

I agree with a lot of this. GNU/Linux distros are going down a very dangerous path with Snappy, Docker, Flatpak, Atomic, etc. I think a lot of this is responding to the fact that traditional systems package managers are quite bad by today's standards. They are imperative (no atomic transactions), use global state (/usr), and require root privileges. Snappy and co. take the "fuck it, I'm out" approach of bundling the world with your application, which is terrible for user control and security. Instead, I urge folks to check out the functional package managers GNU Guix[0] and Nix[1], and their accompanying distributions GuixSD and NixOS. Both Guix and Nix solve the problems of traditional systems package managers, while adding additional useful features (like reproducible builds, universal virtualenv, and full-system config management) and avoiding the massive drawbacks of Snappy and friends. [0] https://gnu.org/s/guix https://gnu.org/s/guix [1] http://nixos.org/ http://nixos.org/

ramblenode 10y ago
Snappy, Docker et al. are the newest beasts in the evolution of packaging solutions. Nix and Guix decided evolution was too slow and to skip ahead an epoch or two.
- thinkingkong 10y ago
  Nix was started before docker
- tobltobs 10y ago
  Docker isn't a packaging solution. It is an excuse to avoid packaging.
yenda 10y ago
I started reading your comment and around the 3rd line I already knew it was you without looking at your nick :D I am thinking about going back to Guix soon, this was an awesome experience for me even though the philosophy was a bit too "free" for my hardware.
mwcampbell 10y ago
I wonder if the Nix approach would be more popular if a schism (between Nix and Guix) hadn't developed so early. When you talk about Nix and Guix, a novice's natural first question is, "Which one do I use?"
- endgame 10y ago
  Is there a good heuristic to answer this question?
  - Avshalom 10y ago
    Nix until some intrepid souls set up a large supplemental non-free repo for guix
    - digi_owl 10y ago
      Heh, my thinking basically. As Guix is a GNU project, it adheres to FSF definitions of freedom. That means there will be no proprietary drivers or similar in the official repositories.
      - rekado 10y ago
        This is true. We offer deblobbed Linux (linux-libre) by default. However, it is very simple to customise packages, including the kernel package, e.g. to apply patches, use different sources, or to exercise your right to disagree with the Linux libre upstream on what blobs should be deleted from the kernel. That said, I consider freedom by default a feature and it works very well on most of the hardware I use (an exception is an on-board Radeon graphics chip in a desktop machine I don't use much). Creating package variants is almost trivial; it's certainly no harder than, say, customising Emacs. Guix blurs the lines between user and maintainer, so using custom package definitions is a supported use-case. At work even our scientist users create custom packages in case they are not available in Guix upstream yet.
        digi_owl 10y ago
ashitlerferad 10y ago
You're forgetting GoboLinux, which had these issues solved long before NixOS/Guix existed.
- digi_owl 10y ago
  To be fair, Nix takes it one step further. In Nix, if you recompile the same version lib with new options, it will get a new branch in the Nix tree. While it will replace the existing one in Gobolinux. I think there is a option for the Gobolinux Compile tool to behave more like Nix, but i have not explored its behavior much.
mercurial 10y ago
As a happy nixos user, I have to say that it's conceptually great, but that right now, the management tools are abysmal. Not only are the command line utilities unintuitive to use and pretty slow, but there is simply no graphical frontend, which means that I'm unable to switch family members to it.
- keithpeter 10y ago
  Do you find a good range of packages available? I'm downloading the live image to have a look/play
  - roblabla 10y ago
    Most of the "standard" packages are already in it, and those that aren't are fairly easy to add in. I created and maintain the Matrix.org Synapse package, for instance, and it was a breeze to package myself, even without any prior experience of nixos packaging.
- roblabla 10y ago
  Your complaints have been heard, and there are a lot of efforts to address them :) There's currently an effort to make the command line utilities easier to use[0]. There's also an effort to bring PackageKit to NixOS, which should make a few GUI package managers work[1]. [0]: https://github.com/NixOS/nix/issues/779 https://github.com/NixOS/nix/issues/779 [1]: https://github.com/NixOS/nix/issues/233 https://github.com/NixOS/nix/issues/233
  - mercurial 10y ago
    That's really good to hear, I'm looking forward to it.
vetinari 10y ago
Atomic actually solves somewhat different problem as you think. It uses rpm-ostree[0] as a basis "to bring together a hybrid of image-like upgrade features (reliable replication, atomicity), with package-like flexibility (introspecting trees to find package sets, package layering, partial live updates)". rpm-ostree itself is a layer above OSTree[1], which describes itself as a "git for operating system binaries" - "OSTree is a tool for managing bootable, immutable, versioned filesystem trees." Yes, it can run docker images; but so does CoreOS or any normal distribution and they are not based on rpm-ostree at all. [0] https://github.com/projectatomic/rpm-ostree https://github.com/projectatomic/rpm-ostree [1]https://wiki.gnome.org/Projects/OSTree https://wiki.gnome.org/Projects/OSTree

ramblenode 10y ago

Snappy, Docker et al. are the newest beasts in the evolution of packaging solutions. Nix and Guix decided evolution was too slow and to skip ahead an epoch or two.

thinkingkong 10y ago
Nix was started before docker
tobltobs 10y ago
Docker isn't a packaging solution. It is an excuse to avoid packaging.

yenda 10y ago

I started reading your comment and around the 3rd line I already knew it was you without looking at your nick :D I am thinking about going back to Guix soon, this was an awesome experience for me even though the philosophy was a bit too "free" for my hardware.

mwcampbell 10y ago

I wonder if the Nix approach would be more popular if a schism (between Nix and Guix) hadn't developed so early. When you talk about Nix and Guix, a novice's natural first question is, "Which one do I use?"

endgame 10y ago
Is there a good heuristic to answer this question?
- Avshalom 10y ago
  Nix until some intrepid souls set up a large supplemental non-free repo for guix
  - digi_owl 10y ago
    Heh, my thinking basically. As Guix is a GNU project, it adheres to FSF definitions of freedom. That means there will be no proprietary drivers or similar in the official repositories.
    - rekado 10y ago
      This is true. We offer deblobbed Linux (linux-libre) by default. However, it is very simple to customise packages, including the kernel package, e.g. to apply patches, use different sources, or to exercise your right to disagree with the Linux libre upstream on what blobs should be deleted from the kernel. That said, I consider freedom by default a feature and it works very well on most of the hardware I use (an exception is an on-board Radeon graphics chip in a desktop machine I don't use much). Creating package variants is almost trivial; it's certainly no harder than, say, customising Emacs. Guix blurs the lines between user and maintainer, so using custom package definitions is a supported use-case. At work even our scientist users create custom packages in case they are not available in Guix upstream yet.
      - digi_owl 10y ago

ashitlerferad 10y ago

You're forgetting GoboLinux, which had these issues solved long before NixOS/Guix existed.

digi_owl 10y ago
To be fair, Nix takes it one step further. In Nix, if you recompile the same version lib with new options, it will get a new branch in the Nix tree. While it will replace the existing one in Gobolinux. I think there is a option for the Gobolinux Compile tool to behave more like Nix, but i have not explored its behavior much.

mercurial 10y ago

As a happy nixos user, I have to say that it's conceptually great, but that right now, the management tools are abysmal. Not only are the command line utilities unintuitive to use and pretty slow, but there is simply no graphical frontend, which means that I'm unable to switch family members to it.

keithpeter 10y ago
Do you find a good range of packages available? I'm downloading the live image to have a look/play
- roblabla 10y ago
  Most of the "standard" packages are already in it, and those that aren't are fairly easy to add in. I created and maintain the Matrix.org Synapse package, for instance, and it was a breeze to package myself, even without any prior experience of nixos packaging.
roblabla 10y ago
Your complaints have been heard, and there are a lot of efforts to address them :) There's currently an effort to make the command line utilities easier to use[0]. There's also an effort to bring PackageKit to NixOS, which should make a few GUI package managers work[1]. [0]: https://github.com/NixOS/nix/issues/779 https://github.com/NixOS/nix/issues/779 [1]: https://github.com/NixOS/nix/issues/233 https://github.com/NixOS/nix/issues/233
- mercurial 10y ago
  That's really good to hear, I'm looking forward to it.

vetinari 10y ago

Atomic actually solves somewhat different problem as you think. It uses rpm-ostree[0] as a basis "to bring together a hybrid of image-like upgrade features (reliable replication, atomicity), with package-like flexibility (introspecting trees to find package sets, package layering, partial live updates)". rpm-ostree itself is a layer above OSTree[1], which describes itself as a "git for operating system binaries" - "OSTree is a tool for managing bootable, immutable, versioned filesystem trees." Yes, it can run docker images; but so does CoreOS or any normal distribution and they are not based on rpm-ostree at all. [0] https://github.com/projectatomic/rpm-ostree https://github.com/projectatomic/rpm-ostree [1]https://wiki.gnome.org/Projects/OSTree https://wiki.gnome.org/Projects/OSTree