Guix Further Reduces Bootstrap Seed to 25%
guix.gnu.org
guix.gnu.org
Just compare the difficulty of trying to use the third party nix-bundle to produce a binary for another system versus guix pack.
In Nixpkgs there are quite a few generated packages, some of which cannot be built. I'm maintaining R packages (from CRAN and Bioconductor) in Guix and I see that the equivalent packages in Nixpkgs do not accommodate some of their quirks, so they cannot actually be built.
Another example where Nixpkgs does not build packages from source is TeX Live. The SVN repository of TeX Live contains countless generated files, and all of the TeX Live packages in Nixpkgs merely copy the generated files from SVN instead of building them from source.
Java packages in Nixpkgs often seem to include pre-built jars whereas in Guix we're going to great lengths to build everything from source. This comes at a cost, of course: Guix has fever Java packages because of that, but those that it has are actually built from source.
Of course, I'm biased towards Guix, but I must say that I'm very fond of the level of integration that Guix achieves. When I look at Nix I see a bunch of seemingly separately developed tools that are written in a mix of languages (with Shell code being rather common). In Guix all tools are written in Scheme, use the same API, behave similarly, etc. It just feels much more polished to me.
That said, there is no animosity between these communities, and I think we would all be better off avoiding the mental pitfall of competition; we work on the same problems with different values and thus our approach differs. This leads to diversity rather than duplication of work.
Here are some more things I wrote comparing Nix and Guix in the past: https://news.ycombinator.com/item?id=19807042
Truly this is much more valuable than actually being able to use the software.
Also for clojure heads the Nonguix[1] repository includes a leiningen package.
I think as time goes on and guix matures we will start to see more third party repositories that provide convenient builds of things. For instance I run guix system on a 2015 Chromebook Pixel and to do that I used the installation image provided at Nonguix to make sure I had all of the nonfree drivers I needed.
That's right, but 13,800 packages is not exactly bad. I believe that is more packages than Ubuntu had a few years ago.
While freedom zero (the most important!) is the ability "to use the software" - being able to improve, patch and adapt the software is also very important!
If it were that simple, why would we need package managers at all? Sadly, the Linux community as a whole have dedicated themselves to a structure that makes this seemingly simple task remarkably difficult.
It is that simple.
> why would we need package managers at all? Sadly, the Linux community as a whole have dedicated themselves to a structure that makes this seemingly simple task remarkably difficult.
Because there's a huge difference between a user downloading/running a binary, and software package management in an OS. The former is not maintainable, your binaries will be out of date soon, etc. But, if you insist on wanting to do this, there's absolutely nothing preventing you from doing it. Have fun.
I really do want to do this, precisely because the software in the repo is often out of date, if it is even there at all! I really don't like the idea of a mandatory middleman between the developer and the user.
And since I really do want to do this, and do it often, I can say with quite a bit of certainty that
> It is that simple.
Is complete and utter bullshit! Sometimes you get lucky and the developer produces AppImages or a static binary, sometimes you're less lucky and have to grab the binary and its dependencies and write a startup script that sets LD_LIBRARY_PATH, sometimes you're even less lucky than that and get to use patchelf to force it to use a compatible ld.so, but most of the time you end up having to compile the damn thing from source like it is 1975.
That depends much on the distribution you use (if recentness is most important, why do you don't use Arch), and being out of date is definitely not the case for Guix System:
http://distrowatch.org/dwres.php?firstlist=guixsd&firstversi...
Sp, why are you bringing an argument that does not apply to Guix?
And if package managers really solved the problem, why do so many projects deploy with Docker? Why do FlatPak and Snap exist, let alone my preferred AppImage?
Guix allows you to easily write own package definitions which are treated as part of the whole system. If you submit them and they are accepted, they simply become part of Guix.
> why must said repo prevent me from installing older versions,
Precisely this is a case that Guix solves extremely well: One can start environments with specific versions of packages, like in Pyhon's virtualenv.
And by the way, the complexity is caused by the issue that many many components need to fit together. That does not happen by chance, it is a massive amount of work to make it fit in a manageable way, and check that it works. That's what distributions do.
I believe a higher proportion of Nixpkgs don't build all or some of the software/artifacts from source. I picked a random example, JOSM. The nixpkgs package definition is quite short [1], but I don't think it's actually building the software? The Guix package definition is much longer [2] but I think that's because it's actually building the software from source.
1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... 2: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
Personally, I like binary packages, which is why I use Guix, but I also value the security and flexibility of having these packages actually build the software from source.
Nixpkgs also contains non-free software. This is sort of related to the previous point, as it's much harder to tell if software is free or not if you're not building it from source, but Guix everything should be free software which takes away a worry when using it. With nixpkgs, I believe there are some bits of non-free software that are marked as such, but not taking a strong stance on attempting to build everything from source makes me generally unsure about the quality assurance in this area.
That said, downloading a jar instead of compiling the jar from source is definitely a notable difference and potentially is unfree software despite the license stating otherwise and the flag previously mentioned set.
While there is nothing inherent about NixOS To prevent non-free software from entering the ecosystem, there is also nothing inherent to Guix either that would prevent any non-free software. Ultimately it comes down to community curation of the packages and while Guix almost definitely is more vigilant about free software both have focus on free-software
NixOS has the option to install non-free (which you need to explicitly enable to install non-software) and Guix is more strict where their official packages don’t intentionally support any non-free software and they employ practices that are more likely to catch oversights.
Another feature that is very nice is that there is no difference between a package definition in a local development environment, and a definition in the official channel. What you put together as a build recipe of a tool that is useful for your quirky local project will also work as part of the distribution.
Personally I have used Guix to convert a CentOS "appliance" into a full-blown desktop system, on a professional contract[2].
0: https://guix.gnu.org/blog/2018/gnu-guix-receives-donation-fr...
2: https://guix.gnu.org/blog/2019/running-a-guix-xfce-desktop-o...
The article mentions: "We are excited that the Nlnet Foundation has sponsored this work!"
https://nlnet.nl/project/GNUMes/ mentions "This project was funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme".
So this is funded by the EU.
And I am unsure how 'active' development is, I have no insight, but it has been in existence for so long and still no one I know has ever used it. On the other hand NixOS[2] (or Nix as a package manager in similar vein) seems to be used heavily by some Power Users.
[0] http://www.gnu.org/software/software.html
The FSF is GNU's sponsor, and provides some infrastructure, but generally hasn't done too much in terms of funding the project. However other funding has happened in terms of NLNet, Outreachy, GSoC, and some stuff with the Guix HPC project. But far and away the majority of contributions are from unpaid contributors.
As an Emacs user who contributes packages occasionally - yup, that's about right! It's a really natural combination. Every so often I'll run across something I want that's not yet packaged for Guix, and if you're used to hacking on elisp the Guix package definitions aren't too hard to get the hang of.
I think it's the only distro I've used that readily accepts new packages from the community (with review of course) - haven't used it myself but I think NixOS/nixpkgs is similar in that regard.
Here is their git repository: https://savannah.gnu.org/projects/guix
Here is the web interface to their issues and patches mailing list: https://issues.guix.gnu.org/
As you can see although the project is less popular, it is no less actively developed and you can easily find system configurations by searching git{hub,lab}.
'GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom.'[0]
NixOS is developed using the MIT license and does seem to just want things to work.
I am bringing this up purely as a question, is that fear justified or am I missing something? Would be glad for a take on this from someone who knows more.
At any rate, the choice to go "have a pure base" is the right one IMO: it's nice to have a system where I know I have the right to use/modify/distribute changes to the entire thing. It's easier to start with that pure base and add impurities if you need them (eg if your hardware requires blobs to operate it) than the reverse.
That said I think it would be helpful if there was a place to direct users who need to figure out how to install such blobs, even though I agree that the official mailing lists and project repository should not be it. (I am running a blobbed kernel on my current machine because I have to, but I previously was able to run with the linux-libre kernel Guix ships with. It's definitely possible to do if you need to, just not well documented.)
For one nix simply doesn't have a project focused on bootstrapping. As another example compare rust bootstrapping[0] versus using a rust binary[1]. Nix also has no alternative to guix challenge[2] or guix pack[3]. Even a comparison of their documentation shows this difference.
The question is if you consider these measures useful, and if you think bootstrapping is even an issue in the first place. To me this is the bigger question when comparing the two projects, as depending on your philosophy guix is either taking necessary precautions or unnecessary mitigations.
Given posts like this their marketing is okay, I haven't seen much unnecessary childishness - but both projects are fundimentally complicated thus have to invent words for concepts and there's nonguix[4] and most people run nix on GuixSD for their non free software needs.
I doubt guix will be more popular than nix anytime soon, but I don't think NixOS will be more popular than Arch anytime soon either.
[0]: https://guix.gnu.org/blog/2018/bootstrapping-rust/
[1]: https://github.com/NixOS/nixpkgs/pull/85542
[2]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
[3]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
It seems to already have more packages though (60,000 vs 11,000).
I guess NixOS, and also Guix, will be used first in domains where both recentness of tools and libraries, as well as the capability to exactly reproduce software and results are important, such as in science, AI and commercial data analysis.
"guix challenge" challenges different substitute servers and also compares what they offer with what you may have installed (whether you built it locally or downloaded it from elsewhere). It's really quite different from "guix build --check".
There are a few unofficial channels that do package proprietary software for Guix, though they're of course not advertised on the official Guix site, etc.
That said I really want to learn more about Guix. It seems like a more pure impl of a functional package manager but haven’t worked with it enough to know the difference.
You seem to be a bit new to this issue.
Building software from source and using FLOSS licenses makes sure that the software is available in the long term and can be developed further (even if the original developers lose interest or run out of time for that).
There are many more advantages in using free (copyleft) software which can be build from source, and making this capability available to the end user as Guix does:
- better privacy protection (the software does not phone home or leaks your private data, as does, for example, Zoom)
- a working software which is used will not be simply withdrawn and be forbidden to use (as many Google software projects).
- useful standards and file formats, such as markup in text documents are available in the long term (I still have latex sources from 1993 around which I wrote in another language that uses different char sets, and which I can today compile without any problem).
- FLOSS software also has the advantage that it is more economical with attention (a very precious human resource), as it only display useful stuff and does not extra things that only have the purpose to capture the attention of the user. For example, I really hate it when I open a web browser with a blank page, to look up something I am working with, and it is full of advertisements for news for completely unrelated stuff up to sexual gossip and celibrity trash, when what I need to do is concentrated work. Once you have become aware of how much many nonfree software wastes your attention, and that this is actively against your interests, it is difficult to ignore that.
- it does not need to assume unrelated features to compete, which prevents feature bloat and improves usability (your picture viewing program does not need to be a file manager, and your image editing program not a publishing platform)
- preventing feature bloat and open interfaces also improves its interopoeration with other software (who does really believe that MS Word is usable?)
- preventing commercial-driven featuritis is also good for long-term usability. I learned to use Unix in 1994 I believe, and I can still navigate and inspect the file system using cd and ls.
- Using open standards also means, for software developers, that their knowledge does not goes out of date quickly or becomes unusable when they change employers. Non-free software tools have a much shorter half-life (anyone still using Silverlight or Visual Basic?), and this means a lot of your learning effort becomes useless after a few years. This might be a minor advantage for somebody who has worked one year or two but it makes a big big difference after many years of working.
- As a lot of innovation happens incrementally and evolutionary, and innovation is based on open exchange of ideas, free software is very open to innovation. At the same time, as working code can always be shared (as, for example, the code for the build daemon in NixOS and Guix), innovation is better conserved than in closed-source software with usual commercial licenses. At a previous employer, I mighhjt have done a really good job with some kind of signal processing which would be useful for things like making wind energy more reliable, but the project manager fucked that up, the software is closed source, and the effort is lost to humanity. I would very much prefer the generation of my niece to get the returns of the work I did.
I could go on for half an hour but I have something else to do :)
But, all of this boils down to that the software on somebody's computer is controlled by its user, not somebody else or a big company which has interests very different from him (or her), and this is what the GPL is about. And yes, the GPL is a means to some end, one could discuss how to reach its specific goal in a different way, but simply labeling its intention as "childish" is just FUD (https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt).
> We are excited that the Nlnet Foundation has sponsored this work!
I'm not sure I love Hurd so much. Admittedly, I have not used it, but would be hesitant to rely on it for any important work. Maybe it will prove me wrong. It just seems like it has been an awful lot of work to get Linux to where it is, and it was a pretty bumpy ride at times.
Edit: I guess I'm pretty dense. I hate April fools jokes! But now I'm happy I can start using Guix without fear of being forced into Hurd. That said, I will try out Hurd just for the fun of it.
And how's the GUI integration with KDE and gnome? Is there a backend for KDE Discover or the Gnome Software Center?
Finally, I see that installation goes over a "curl | bash", which imo is a pretty insecure method of installation. I can understand why such an insecure method exists (so many different ways of installing software on linux), but that's like saying HTTP is a good idea because it's easier than HTTPS.
So comparing https://nixos.org/download.html and https://guix.gnu.org/manual/en/html_node/Binary-Installation... - nix is curl | sh from a https address; guix is wget && chmod +x && run shell script. Both also have a trivially-available way to do GPG verification before running anything. So I'd call them pretty close.
In absolute terms, honestly I'm not sure it is that big of a deal; default protection is HTTPS, and GPG is easily available. The only obvious issue that I see is that nix might be vulnerable to the truncated-stream issue; I forget whether that can happen over HTTPS or not.
At the moment neither have gui integration and unfortunately both could use a lot of work with onboarding and beginner (I'm taking non programmers) friendliness.
[0]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
I think non-programmer friendliness can wait till there are enough technical users that the superficial daily-experience bugs get ironed out, and also the newbies have a social support system for onboarding. Trying to jump that curve will prove painful in the long term.
I would love to see the guidance and tools for technical users to try this out and start switching over the next few years.
AFAIK, Gnome/KDE or some other DE can be built/installed like any other package, so one can certainly have pretty much any GUI, just like any other Linux distribution.
I’ve been using the NixOS container support which has drastically streamlined and unified the largely similar but many small variations of containers that I use https://nixos.org/nixos/manual/#ch-containers
On the other hand I believe the package repo for Nix is much more comprehensive and kept more up to date.
Although GNU Guix is my personal preference, I believe that NixOS is an excellent choice and for the most part we have a shared vision.
If you are still using a legacy system, you'll want to try NixOS or GNU Guix!
What makes you say so?
(disclaimer: I'm a contributor to Guix and just upgraded several hundred R packages.)
That being said, at the time I had wanted to choose Guix over Nix. The channels seemed a bit better thought-out and grafts sounded like a good idea.
Not having a lisp background though, it was just easier for me to get into Nix.
Not to mention that "bash" sounds like a concussive injury; "gash" sounds like a slicing injury. So follows that theme also.
I would be very surprised if genitalia slang came up in the author's mind as a choice of names but I guess I don't know them.
According to your reasoning, I can name an alarm program "cock", just as long as what was going through my mind at the time was a rooster crowing in the morning. ("Get woken up by cock!") What anyone else chooses to read into it is their problem?
But all these anecdotes counteract what Wikipedia says, which is that Coq was named for one of its authors, Thierry Coquand, and for his "calculus of constructions" (CoC).
It being named after Coquand is unsourced and even states something that is outright wrong (Coquand is not Coq's "principal author", the best fit would be Huet and Christine Paulin, but even then it was developed by a team, they just lead it. Source: Coq's history page).
Not everyone will be familiar with slangs in various countries.
Oh my, then you better not ever venture into the humanities! At least in musicology they spent the past 3 decades wresting free from the idea that evidence of the author's intentions are the only relevant thing.
Not a good name for a project.
I like gash though. Where bash is a bludgeoning shell gash is more of a cutting one, if we want to be cute about it.
The ease by which you can manage and roll-out new configurations means that it's slowly spreading to other systems I manage.
It's also interesting to work on a distribution that takes the GNU project seriously: the developers default to using GNU software where possible, and are clearly striving to make a coherent operating system out of its parts. This is less an ideological position than it sounds -- there's a lot of gold buried in nearly half a century of GNU work, and I've enjoyed learning about it all, and seeing how the Guix team go about improving and modernising it.
I think the fear of missing drivers when using Linux without blobs is extremely overstated. Yes, certain WiFi cards won't work without blobs, and yes, the 3D graphics situation is not great thanks to NVIDIA and AMD.
> What do you like about it versus a more typical linux or unix?
Oh, so many things... But most important for me is stateless configuration, reproducible builds, no-nonsense application bundles without all that Dockeresk cruft via "guix pack", ad-hoc environments, etc.
AMD is now one of the good guys when it comes to open source:
https://en.wikipedia.org/wiki/AMDGPU
Basically, since 2015, AMD has offered an official driver under an MIT license for Linux and *BSD. Personally, I'm definitely choosing AMD for my next laptop :).
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
Since three years our development team at work uses Guix; the reproducible offload builds are awesome. Extending the package graph with your own version of packages is very helpful. Since about a year we also use server(s) at Digital Ocean running GNU Guix.
I've also experimented recently with using it for creating environments (actually called profiles in GUIX) for programming projects. That also works.
There is a lot more to discover for me, once I get around to it.