254 karma · joined February 24, 2013
As a bonus, the resulting Docker image is bit-reproducible and recipients of the image can "map it back" to the original Guix revision.
https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
What you suggest in the second paragraph sounds great and definitely doable!
Guix 1.0 was released just two months ago. The announcement summarizes what it can do for you in these areas: https://guix.gnu.org/blog/2019/gnu-guix-1.0.0-released/ .
It's also much more than a matter of syntax: see the great explanation at https://news.ycombinator.com/item?id=18910683 .
So Guix gives you reproducibility, provenance tracking, and hackability, but you can still "speak Docker".
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...
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...
https://gnu.org/s/guix/manual/en/html_node/Invoking-guix-pac...
Because it's all Scheme, Guix has well defined APIs for all sorts of things. For instance, there's an API for search paths (environment variables you need to define when you install packages), one to create application bundles, one to create VMs containing GuixSD, etc.
That, in turn, leads to clean CLIs in my opinion: 'guix package --search-paths', 'guix pack', 'guix system vm', etc.
In particular, by writing that codes of conduct are "punitive spirit", RMS shows a misunderstanding of how these texts came into existence.
More importantly, by writing that he disagrees with "making diversity a goal", RMS seems to deny the role we free software people play in the demographics of our communities.
Many of us in Guix (and I think I can speak for my fellow Guix co-maintainer here) believe that free software should empower everyone. As such, correcting the biases, conscious or not, that have led to the poor diversity of our communities, must be part of our mission.
Guix includes free software packages of all sorts (more than 8k today), be it "GNU-friendly" (whatever that means) or not; you can browse them at https://guix-hpc.bordeaux.inria.fr/browse .
> I guess that my WiFi wouldn't work.
Maybe, maybe not; see https://gnu.org/s/guix/manual/en/html_node/Hardware-Consider... (the same issue applies to other distros that value user freedom.) Note that you're talking about GuixSD here, not Guix, which can be installed on top of other distros.
In the end the choice is up to each one of us. It's also up to us to determine what to do with hardware companies that deny us, collectively and individually, the right to control the devices they sell us.
User namespaces slowly but surely help retrofit the "principle of least privilege" to GNU/Linux, and that is good.
As for GuixSD, you are right that the Shepherd, for instance, is not as mature as systemd (it’s also much simpler though). My comment was referring to packaging QA.
I do think that the ability to statically check a number of properties on a GuixSD config before it’s even instantiated (something that using a general purpose language buys us) helps a lot, though.
Yet, it’s pretty obvious that today, traditional distros can no longer pretend to provide every single free software package that’s out there—let alone providing them with the level of QA and polishing that Debian, Fedora, Guix, and others provide.
In Guix we currently semi-automatically import package definitions from third-party repos like Hackage, PyPI, and the likes, for which we do some additional QA: https://gnu.org/s/guix/manual/html_node/Invoking-guix-import... .
One idea we discussed would be to offer as an option the ability to to “live imports”: users could install packages imported on the fly from these repos, while still taking advantage of the Guix user interface, transactional upgrades and rollback, and other goodies.
That could be a way to address user needs without throwing the baby with the water. There are technical challenges before we can get there, though…
Thus some of the issues that apply to Arch or Debian do not apply to Guix and Nix, but many apply to both (timestamps are an obvious example.)
For Guix we are currently at ~80% reproducible packages: https://gnu.org/software/guix/news/reproducible-builds-a-sta... . That's not an entirely fair comparison because, for example, Python packages in Guix include .pyc files whereas on Debian they don't (not sure about Arch).
I think the one-type-fits-all ("attribute sets") vs. strong typing (disjoing record types) axis matters more than the static vs. dynamic axis here because most of the code (OS config files, package definitions, etc.) is loaded dynamically.
Conversely in Guix most of the data structures are disjoint record types. Scheme (the implementation language of Guix) is dynamically-typed, but there are sanity checks we can do on records both at macro-expansion time and at run time, such as checking whether all the required fields are defined and no extra field is passed. Concretely, this means that users get clear syntax errors or run-time type errors.
Nix and Scheme are both dynamically typed, but they have a different typing story.
Disclaimer: Guix hacker here.
For cases where user namespaces are unavailable, Pjotr Prins wrote a neat hack that allows users to "relocate" binaries to a different file system location by rewriting file names in the binaries: https://github.com/pjotrp/gnu-install-bin . Scary to some, but definitely does the job. :-)
I work on Guix; it provides a 'guix environment' command, which is sort of a generic 'virtualenv', and IMO is a simple lightweight alternative: https://gnu.org/s/guix/manual/html_node/Invoking-guix-enviro... .
https://gnu.org/software/guix/news/reproducible-builds-a-mea...
Having this path is important from a security and user freedom viewpoint: we could build OpenJDK from source.
Not having such a bootstrap path means relying on huge opaque binary blobs, which is a net loss.