I hope this causes a surge of interest in gnu guix, nixpkgs, and package management systems with these nice features in general.
Introducing GNU Guix
31–40 of 113 posts
Re: Introducing GNU Guix
#32This could turn out way better than current package managers if GNU doesn't screw it up.
Well there is already nixpkgs which has existed for a while with core features that I saw mentioned. I would be happy if there was increased interest in both and their feature set.
Re: Introducing GNU Guix
#33It seems everyone reinvents package management poorly again and again. Some things that obviously stand out to me: * Why utilize scheme? It's declaritive utilize a markup like yaml, don't go off the deep end because you can. * Utilize OS specific features such as jails, bind mounts, namespaces, you can have the same NIX style separation without destroying FHS. * Parse the config files for options, it's easy cmake, au…
Please, utilise the word "use".
Re: Introducing GNU Guix
#34Documentation ?
Re: Introducing GNU Guix
#35> A distribution built by GNU hackers is a great opportunity to improve consistency and cohesion in GNU! Because the existing fragmentation of GNU package management is too confusing, so we need a new standard for everyone to rally round. [ http://xkcd.com/927/ ]
I thought of the exact same xkcd when I read this email. Let's just create more fragmentation on something already exaggeratedly fragmented..
Until the next "standard".
Re: Introducing GNU Guix
#36I suppose it's nice that GNU has a "GNU-branded" package manager... I guess...
Re: Introducing GNU Guix
#37It seems everyone reinvents package management poorly again and again. Some things that obviously stand out to me: * Why utilize scheme? It's declaritive utilize a markup like yaml, don't go off the deep end because you can. * Utilize OS specific features such as jails, bind mounts, namespaces, you can have the same NIX style separation without destroying FHS. * Parse the config files for options, it's easy cmake, au…
Why utilize scheme?
If emacs has thaught us anything, it is that when you give people a fully featured language to fool around with, things you could never imagine can start happening.
Why not scheme? It's liberally licensed and already has mind-share. It's a simple, no fuzz language with little obfuscating magic and great expressive power.
It allows you to build your solutions as bare-bones as you like or go on full architect should you need to. Sounds like just what the doctor ordered.
Re: Introducing GNU Guix
#38> A distribution built by GNU hackers is a great opportunity to improve consistency and cohesion in GNU! Because the existing fragmentation of GNU package management is too confusing, so we need a new standard for everyone to rally round. [ http://xkcd.com/927/ ]
That particular Xkcd comic has been posted 79 times in the past year or so† and has quickly become a cliché. The authors' stated goals are to make a "purely functional" and "practical 100% free" package manager.†† They don't mention competition, proliferation, or winning market share. A vague hope of consistency and cohesion accompanying the announcement of a program "approaching its first alpha release" isn't a rallying cry. I think they made this announcement simply so that people interested in this sort of thing might take a look.
† http://www.hnsearch.com/search#request/all&q=http%3A%2F%...
Re: Introducing GNU Guix
#39What problem does it solve?
Ever tried to build distribution packages? If it works for you, doesn't mean it works everywhere. Slight errors in the dependency specifications of a package may make it fail if you have wrongly versioned/missing libraries etc. It's often very difficult to verify that package dependencies are 100% correct. Sometimes package builds are not reproducable, as autoconf doesn't care about the build dependencies you defined but just adds any dependency it can auto-detect at compile-time. So you have to double-test your package when build on a build server etc. etc.
AFAIU the Nix package manager fixes that by trying to assure bit-for-bit matching dependant packages are present by making every package version a hash of the installed files, hashed with the hash of all dependencies (similar somehow to how the filesystem/history data are managed in Git, BTW).
The Nix package builder (named hydra) on the other hand makes sure that builds are performed in complete isolation via enhanced chroots, so that every build is 100% reproducible. It locks the build process down so much that it can't even access the network nor would the process be able to observe varying host names. [1]
This is why they call it a "purely functional" build system. As in purely functional programming: there's no state at all. Inputs completely define the output.
Now Guix sits on top of Nix and somehow attempts to make its features available on a higher level via a Scheme API (Nix uses its own language for package dependency and build descriptions)
I haven't used Nix before, just read about it, but having suffered through writing complex package build recipies for OpenWrt, I very much appreciate the approach.
[1] http://hydra.nixos.org/build/2860022/download/3/release-note...
Re: Introducing GNU Guix
#40It seems everyone reinvents package management poorly again and again. Some things that obviously stand out to me: * Why utilize scheme? It's declaritive utilize a markup like yaml, don't go off the deep end because you can. * Utilize OS specific features such as jails, bind mounts, namespaces, you can have the same NIX style separation without destroying FHS. * Parse the config files for options, it's easy cmake, au…
It is probably the Guile extension language variety of scheme which is the "official GNU extension language". It makes sense really.