8 ms·
Obligatory comparison to Nix [1]: Pros: * Better, more coherent and unified tooling * Better docs * Built with LISP (edit: Scheme), A standard language that
by the_duke 5y ago
Obligatory comparison to Nix [1]:
Pros:
* Better, more coherent and unified tooling
* Better docs
* Built with LISP (edit: Scheme), A standard language that is not project-specific. Nix lang is somewhat quirky and takes some getting used to. It's pretty decent though for a narrowly focused domain language.
Cons:
* Tiny community that is much smaller than Nix. nixpkgs is the largest package repository out there, providing most software that you could want.
* Really slow every time I tried it. Nix is written in C++ and actually performs quite well, even when building many hundreds of pacakges.
* Not systemd based. Say of systemd what you will, but there is a reason almost every distro has adopted it. It's just better. Also: most Linux users are familiar with systemd tooling by now, so that makes adoption even harder.
* Strong focus on freedom and not packaging proprietary software. Understandable, given the project origins. But awkward to the point of being mostly impractical for personal use - I can't package everything myself.
* No equivalent to home-manager [1], which is amazing for declarative user environments
[1] nixos.org/
[2] https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager
- medstrom 5y agoMany design decisions are different. Nix and Guix are each other's Bizarro. It's a common misconception that Guix is just "Nix with Scheme" or "Nix without systemd" but those are frankly the least interesting differences. An example is that the package definitions sit in the same repo as the package manager, freeing the definition language to evolve without regard for compatibility (because they will always be read by the correct version of Guix) whereas Nix has to freeze the definition language and always test that old definitions work. Obviously there are pros and cons to each approach. https://guix.gnu.org/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/ https://guix.gnu.org/blog/2018/multi-dimensional-transaction...
- the_duke 5y agoCan you elaborate on those differences? The concepts seemed pretty similar to me.
- medstrom 5y agoAdded an example. Also the dev communities care about slightly different things. They match my tastes, we find the same kinds of things cool, so I've found nothing but joy in Guix. One matter of practical impact is how they prioritize blurring the line between user and contributor -- "uplifting" users into contributors as much as possible. I saw that as the biggest flaw of Gentoo, it was very hard to even know how to start contributing.
- Blikkentrekker 5y agoPerhaps you should try Exherbo then. They take the opposite approach and insist that all users be contributors and are often unwilling to provide support to users that aren't at least somewhat contributing back. Their dream is a system where all users are contributors.
- medstrom 5y agohttps://www.exherbo.org/ https://www.exherbo.org/ That does sound nice. I'd like to know how it differs from Guix.
- Blikkentrekker 5y agoIt's package manager is more so similar to Portage; and it can in fact be used on Gentoo as an alternative thereto.
- geeksix 5y ago> they prioritize blurring the line between user and contributor -- "uplifting" users into contributors as much as possible Can you explain more about this? How do they uplift?
- civodul 5y agoFor a detailed "Guix vs. Nix" comparison, see: https://news.ycombinator.com/item?id=16490027 https://news.ycombinator.com/item?id=16490027 and https://news.ycombinator.com/item?id=23529932 https://news.ycombinator.com/item?id=23529932. In a nutshell, these are two different projects, with common foundations, but also different technology and different focuses--just like Julia and Clang are different, even though they both use LLVM. The project blogs and documentation should already give a feel of how those differences play in practice!
- mwill 5y agoAs someone who lives in nixos about 90% of the time, I really do just want Nix but LISP, and if thats what Guix was I would have switched a long time ago
- georgyo 5y agoThe embedded package repository is actually a major con IMHO. Making backwards incompatible changes is easy inside your monorepo, but if you a user building software it means that your code now depends on specific guix reversions as well as a specific commit. In nix land, the more stable API means we are moving further into composible modules. Meaning you can now very easily have all your companies code in different (or one big) repositories that can reference each other easily. However having used both guix and nix for several years now, I am firmly in camp they are the same. The porcelain of guix is much nicer, but each can do everything the other does. To me guix and nix are similar to a comparison of fedora and ubuntu. Both fedora and ubuntu are fairly different, but there is there is a 1:1 method to do everything in one in the other. Having only used fedora, you could easily figure out ubuntu. Everything is essentially done the exact same way, but different tools. The same is true with guix and nix.
- medstrom 5y agoThe Guix way moves more contribution upstream (it's very easy to get your PR accepted) and less people having their own untested "PPAs" everywhere. People have this image that having a private channel is simpler/faster somehow as it skips hoops but in Guix it's just not true (what hoops?). You can submit PR after PR after PR for something only you would ever care about. The main reason not to is when you want to keep your codebase secret, right? Composible modules are certainly another solution. I don't know what's ultimately best but I think we could perhaps make it easier to pin a specific Guix revision. Perhaps require it. It already runs different versions of itself so often, it's part of the way it should work.
- mrslave 5y ago> less people having their own untested "PPAs" everywhere This is not my experience with Nix. 1. My system configuration pulls in a couple of programs in from unstable for my convenience and it was incredibly easy. 2. I don't do any serious 3rd-party packages or package configuration at the system level. Instead, any package configuration (e.g. overrides, Docker images) and 3rd-party packages absent from Nixpkgs - usually pretty easy to write, if not trivial - are defined in the repository where they are required. They are used - and tested - and reproducable to the pinned Nixpkgs in that repository. It has been incredibly easier than PPAs and Gentoo overlays. Presumably safer too (though this is an incomplete thought). To be fair the learning curve was medium, and I didn't invest any serious effort. Instead I made progress until frustrated and asked colleagues to help a few times until I grokked it. From the perspective of a simple user, the single system configuration file is a killer feature even if you don't venture any further.
- shakow 5y ago> Built with LISP *Scheme
- capableweb 5y agoRisking starting a flame-war but I really don't want to, this is a question of curiosity, not looking down/up on any languages: Isn't Scheme "a lisp" even though most people usually distinct them? The similarities between Scheme and Common Lisp seems to be greater than any of the two and Clojure, and usually people refer to Clojure as a Lisp but it's hearsay to claim Scheme is a Lisp. Of course, C2 already have a page on the subject (https://wiki.c2.com/?IsSchemeLisp https://wiki.c2.com/?IsSchemeLisp) so if you want to share a new opinion on the subject, make sure it hasn't already been said :)
- medstrom 5y ago(Offtopic) C2 has a really good <noscript>.
- shakow 5y ago> Isn't Scheme "a lisp" even though most people usually distinct them? I would agree on a broad scale. But GP wrote LISP in capitals, which I often see used to mean Lisp-the-language rather than Lisp-the-concept, hence my precision.
- deleted 5y ago[deleted]
- mbakke 5y agoThere is a home manager for Guix: https://git.sr.ht/~abcdw/rde https://git.sr.ht/~abcdw/rde It will likely be included in the next version of Guix. Note that declarative environments are already well-supported with "manifests" (I have a lot of them). It's curious that you list "strong focus on freedom" as a con. I love that I can exercise my "four freedoms" on any package in Guix, and be certain that there are no binary or proprietary bits. There are several third party channels covering non-free software needs.
- imiric 5y agoThanks for the manager link. > There are several third party channels covering non-free software needs. Can you link some of them? I've kept a list over the years for when I decided to try Guix again, but it's not up to date. And some like [1] aren't being maintained anymore. While I support this strong stance on free software from a philosophical standpoint, it's practically unusable as my main distro because of my current hardware. I'd love to see a distro based on Guix that breaks this GNU principle and focuses on general ease of use. [1]: https://github.com/guix-users/guix-nonfree https://github.com/guix-users/guix-nonfree
- shakow 5y ago> It's curious that you list "strong focus on freedom" as a con Not OP, but I see the two sides of it. On the one hand, I totally understand your position. On the other hand, if I take my personal case as an academia user, I can't use Guix just because I can't get e.g. CUDA with it. And neither I nor my lab will ever have the time and means to reimplement a free CUDA, so we can only suck it up.
- swiley 5y agoThere is a home manager people are testing out, it was on the mailing list the other week. I wish they had gone with OpenRC as the initd. It's fairly popular but doesn't go overboard the way systemd does. Shepherd is pretty slow.
- nanna 5y agoAnother Pro for Guix, first class support in Emacs. If that's your kinda thing.
- spindle 5y ago> Strong focus on freedom and not packaging proprietary software. Yes, and I like that BUT Guix, unlike NixOS, does not have an easy to install and well-tested ZFS implementation, even though ZFS IS free (and non-proprietary, and copyleft to boot (pun not intended)). For me at least, this is a dealbreaker.
- deleted 5y ago[deleted]
- Blikkentrekker 5y ago> Not systemd based. Say of systemd what you will, but there is a reason almost every distro has adopted it. It's just better. Also: most Linux users are familiar with systemd tooling by now, so that makes adoption even harder. Yet, the only reason you are most likely giving this one piece of software special treatment, among the many other different pieces of software in NixOS and GuixSD, is as reactionism to the many, just as vocal voices, that chose not to adopt it, with just as much fanfare to the mention of not doing so. It strikes me as odd to list as an objective advantage the one piece of software that has been the most controversial in the last decade, and it's controversy is most likely the reason you decided to mention it.
- deleted 5y ago[deleted]
- zxzax 5y agoI can't say I agree with your assessment. As someone who has used both, there are a lot of nice things in systemd that aren't really present in GNU shepherd (yet?)
- Blikkentrekker 5y agoWhat does that have to with my assessment? Nothing in my post compared systemd with shepherd or talked about any of the features of either. — it simply pointed out that systemd was specifically chosen of all software that GuixSD does not have because there's often debate about it, not for technical reasons.
- zxzax 5y agoI don't know about other places, but here I don't agree that it wasn't for technical reasons. To me it seems like one of the key differences between them. Guix wants to have all the package and service definitions written in Scheme. Otherwise systemd would probably work well for them, judging by the usage in Nix anyway.
- 5y ago
- wrycoder 5y agoCon (for me): The team is strongly anti-RMS, including wanting him to resign as GNU project leader.
- deleted 5y ago[deleted]
- rekado 5y agoThis is off-topic, but I have to bite: "anti-RMS" is such a reductionist way to express this. Is our language so impoverished that we must be reduced to "anti-this" and "pro-this"? Who's "the team", by the way? There is a maintainer collective and hundreds of contributors, and it should be no surprise that they don't all have the same opinion on everything. For what it's worth: I'm a GNU maintainer and I don't want RMS to be the leader of the GNU project. I'm not "anti-RMS", just "anti-RMS-as-GNU-project-leader". I do think RMS has a voice that should be heard when it is about free software philosophy.
- wrycoder 5y agohttps://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/ https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-pr... I would call that post on the GUIX blog strongly anti-RMS.
- zxzax 5y agoThat seems like a strange interpretation. That post says he is owed a debt of gratitude.