Hacker News Reader

Comment by vbrandl | Hacker News Reader

I'd love to use Guix (or Nix for that matter) as my day-to-day system but (and correct me, if I'm wrong) the package maintainer story is a bit off putting for me. From what I've understood, packages are maintained in a public git repository (GitHub [0] for Nix and savannah.gnu.org [1] for Guix), which might be great if there are enough people submitting updates, but at least for critical system components there should be clearly defined maintainers to make sure all security patches are applied in time.

Also I'm not sure how I feel about a core part of my potential operating system being hosted by a now Microsoft-owned company. On the other hand GitHub might be more reliable and better fit to server a huge amount of users than savannah...

[0]: https://github.com/NixOS/nixpkgs

[1]: https://git.savannah.gnu.org/cgit/guix.git/

View on HN

1. Each package in Nixpkgs repo has assigned maintainer mentioned in source. 2. Nothing prevents you from using your own repo/hosting solution for Nix channel. 3. Writing or overwriting packages in Nix is dumb easy, so I do not see a problem here as well.

I started using Nix exclusively on macOS and I couldn't be happier. The best part IMHO is the fact that I can easily test different packages without permanently changing my system and dealing with clutter left by these.

So in general, this is less of the problem that you think it is, especially as you clone that repo locally, so you do not hit GH/Savannah on each installation.

I have the same experience. Using NixOS, not just NixPkgs, but it shouldn't matter.

Nix takes security very seriously. See e.g. [1]. Plus, a distribution that defines packages declaratively and makes things so reproducible is the ultimate tool to avoid many security issues.

[1] https://github.com/flyingcircusio/vulnix

> [1] https://github.com/flyingcircusio/vulnix

Similarly, ‘guix lint’ has a CVE “checker” that reports CVEs that affect a given package [0]. Since the Guix package name might differ from the “CPE name” (the naming scheme devised by NIST), Guix package definitions can include the CPE name to make sure ‘guix lint’ will look for the right thing. ‘guix lint’ is also able to determine whether a vulnerability is already patched in the Guix package definition.

There’s also work on a ‘guix health’ program in the pipe [1], which is again complicated by this whole CPE story (which Vulnix seems to ignore.)

Last but not least, Guix has “grafts”, a mechanism that allows for fast security update deployment, meaning that rebuilding the world is unnecessary when applying a security update on a package deep down in the dependency graph [2, 3].

[0] https://gnu.org/s/guix/manual/en/html_node/Invoking-guix-lin...

[1] https://issues.guix.info/issue/31442

[2] https://www.gnu.org/software/guix/blog/2016/timely-delivery-...

[3] https://www.gnu.org/software/guix/manual/en/html_node/Securi...

And `guix challenge`, which is very interesting to avoid MIM attacks:

https://www.gnu.org/software/guix/manual/en/html_node/Invoki...

> the package maintainer story is a bit off putting for me.

I actually added the per-package ‘maintainers’ field in Nixpkgs [0] and removed it in Guix [1]. :-)

[0] https://github.com/NixOS/nixpkgs/commit/7b7ed8f1af447f7d2ddb...

[1] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=154f1f...

In Guix we came to the conclusion [2] that having shared package “ownership”—or, to put it differently, not having explicit ownership—is a solution that works best for us. In practice, most packages have a few associated experts who take care of most updates and fixes to them. However, as a group, the fact that there’s no name explicitly attached to the package means that every committer can feel empowered to modify it.

The pros and cons of per-package maintainers are often debated, notably in the context of Debian where strong ownership has shown its limits [3].

[2] https://lists.gnu.org/archive/html/guix-devel/2015-12/msg000...

[3] https://lwn.net/Articles/708163/

I actually see the just-a-git-project aspect of the Nix/Guix distribution maintenance a massive win on transparency grounds. I agree that I'd like to see a bit more dedicated "ownership" of key components, but I see that more as a lack of manpower meaning that many people have to spread themselves quite broadly.

But at the same time I'm quite hopeful that this model can produce a maintenance culture that's less territorial, arcane and officious than is my impression of e.g. Debian's methods and processes. As much as I love Debian, of course - but it definitely feels like yesterday's approach.

I also guessed that the lack of dedicated maintainers is due to a lack of volunteers, but that's something that stops me from using either guix or Nix at least from handling the critical part of my OS (kernel and base system).

For development environments and other stuff, both are great tools, but I guess the real power comes when you manage the whole system through any of these managers.

NixOS/nixpkgs [1] was at some point last year one of the most active projects in GitHub. I can't find the ranking right now, but it should suffice to say it has 2083 contributors and 178334 commits right now. For a relatively young project, that is a lot.

There are tons of dedicated maintainers. You can see that in the maintainers attribute of most packages. So I don't get your point regarding the lack of dedicated maintainers.

I maintain several packages there, and a bot sends me an automated message every time upstream updates the source, and auto-generates a new package definition for me. Things are really streamlined and bleeding edge. The unstable channel is often more up-to-date than Arch Linux even, due to the high number of Nix developers.

[1] https://github.com/NixOS/nixpkgs

Wow that's pretty impressive.

Thanks for the insight in the maintainer story of Nix. I guess it is kinda the same for guix and this more or less invalidates my concerns. So maybe the next time, I reinstall my OS, it's gonna be one of those :)

> Also I'm not sure how I feel about a core part of my potential operating system being hosted by a now Microsoft-owned company.

If it brings any solace: your current OS is using code hosted on GitHub.

What you say is akin to disliking HTTPS and the CA system. People on whom you depend, depend on it. The internet depends on it. Therefore, you are using it. Same with BGP. Same with IPv4. Same with 2G.

Aren't Debian or Arch Linux packages in public git repos?

No "core part" of Guix is hosted on Github. If you're referring to the daemon: it's being replaced with a Guile implementation (it's an ongoing student project). It's not fetched from Github; our old copy of the daemon is part of the Guix git repository.

Sorry for being unclear. The part about being hosted on GitHub actually referred to Nix. That's the point where I'm unclear about what seems to be the better solution. GitHub could take a turn for the worse but at least for now, GitHub might be able to handle more users than savannah.

I don't think it matters much. You can use any git mirror in your ~/.config/guix/channels.scm file (including a local clone); you only need access to the git repo when running "guix pull" to upgrade your copy of Guix. I don't think that Savannah will become a bottleneck even with three times the users we have now. If it ever becomes a problem it's trivial to move to something else or to host dedicated infrastructure.

Yeah I just realized that. The binary caches might experience higher load but it the worst case you would have to build the binary yourself.

I just had to reinstall guix since `guix pull && guix package -u` didn't seem to upgrade guix itself but I think I will play around with it, at least for non critical stuff in my OS.

"guix pull" upgrades Guix itself. It installs the latest version as ~/.config/guix/current/bin/guix. If you ran the "guix" command from a different location before Bash's caching of command names can trick you. Guix prints a recommendation to run "hash guix" to refresh this command cache.

Reply on news.ycombinator.com