Hacker News Reader

Comment by davexunit | Hacker News Reader

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

[1] http://nixos.org/

View on HN

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 [1]https://wiki.gnome.org/Projects/OSTree

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.

Do you find a good range of packages available?

I'm downloading the live image to have a look/play

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.

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 [1]: https://github.com/NixOS/nix/issues/233

That's really good to hear, I'm looking forward to it.

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.

Nix was started before docker

Docker isn't a packaging solution. It is an excuse to avoid packaging.

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

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.

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.

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?"

Is there a good heuristic to answer this question?

Nix until some intrepid souls set up a large supplemental non-free repo for guix

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.

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.

Sounds very similar to my experience with Gobolinux. If the source is packaged sanely (proper support for --prefix or equivalent) a user can roll up a recipe ready for Compile with a single command and a url to the source needed.

Some software is promoted on its merits and some software exists just "because it's GNU" (e.g. Hurd, Guile, Guix, gNewSense, GnuTLS, Shishi, GNUstep, Gnash, etc.). It's pretty safe to ignore the latter kind.

GnuTLS is actually a good thing. OpenSSL has become a monoculture and there's a lot of good reasons to not use it (in addition, the license isn't GPL-compatible so it's a pain to link against in projects too).

Gnash, really? What other open alternative to Adobe's player would you recommend? For example, Gnash is the only way to get Flash support on the Raspberry Pi - is that not valuable?

As someone who works on Guile and Guix in good part because of their technical aspects and friendly community, this comes off as pretty insulting and ignorant.

I wouldn't call it a schism; this sounds much too negative. They are different implementations of the same idea. Nix uses an external DSL, Guix an embedded DSL (using Guile Scheme for everything). The projects are not competing against one another. Problems that are solved to make software packageable in Nix benefit Guix and vice versa.

As a Schemer and GNU person it was easy for me to pick Guix. I've been contributing to Guix for a few years now. I find the tooling of Guix to be more accessible and more hackable.

In my experience when packaging Java for Guix it seems to me that Guix is a little more principled, where Nix would more readily accept binaries for bootstrapping (e.g. prebuilt jars).

Considering how different functional package management is compared to the alternatives I think that novices could pick one or the other; once they are used to functional package management they can better make a decision to switch to another implementation.

For bioinformatics software, though, Guix is far ahead. It's used at our bioinfo institute and in big projects like GeneNetwork.

The thing is, they are competing for package maintainers and users. A Nix package can't be natively used by Guix, and vice-versa, so a package have to be written for both.

Reply on news.ycombinator.com