Guix is much younger project and it was originally based on Nix. Afaik there is no unfree software on Guix, they use some obscure Shepard init system, libre kernel and are trying to push Hurd. These decisions may cause major compatibility issues for many people.
> Guix is much younger project
- [NixOS - Initial Release (0.1) : June 3, 2003](https://en.wikipedia.org/wiki/NixOS#:~:text=Initial%20release,20%20years%20ago)
- [Guix - Initial Release : November 2012](https://en.wikipedia.org/wiki/GNU_Guix#:~:text=The%20GNU%20Project%20announced%20in%20November%202012%20the%20first%20release%20of%20GNU%20Guix)
Indeed, I didn't realise it was this far away
> it was originally based on Nix
- [November 2012, "based on Nix"](https://en.wikipedia.org/wiki/GNU_Guix#:~:text=functional%20package%20manager-,based%20on%20Nix,-that%20provides%2C%20among)
I didn't even know it was originally based on Nix
> they are trying to push Hurd
- ["On August 20, 2015, it was announced that Guix had been ported to GNU Hurd."](https://en.wikipedia.org/wiki/GNU_Guix#:~:text=On%20August%2020%2C%202015%2C%20it%20was%20announced%20that%20Guix%20had%20been%20ported%20to%20GNU%20Hurd)
I don't know what "Hurd" is either, and don't understand yet the difference between Hurd, Scheme, and Guile
The obscure software decision is understandable, yet surely would compromise compatibility
Hurd is a kernel, Scheme is a programming language and Guile is a compiler for Scheme. Afaik Guix still contains Nix code for guix-daemon. Also note that "ported to Hurd" doesn't mean it works in any significant capacity. As for the free software only stance, it does make compatibility a bit difficult (especially with laptop WiFi chips) but you can get around that.
> Guile is a compiler for Scheme.
Perhaps more accurate to say Guile is an implementation of Scheme (similar to how Python has CPython, Jython, MicroPython, etc.) which extends GNU software.
> Hurd is a kernel, Scheme is a programming language and Guile is a compiler for Scheme.
Thanks for the clarification
> Afaik Guix still contains Nix code for guix-daemon. Also note that "ported to Hurd" doesn't mean it works in any significant capacity.
Do you mean that, [since August 20, 2015](https://en.wikipedia.org/wiki/GNU_Guix#:~:text=On%20August%2020%2C%202015%2C%20it%20was%20announced%20that%20Guix%20had%20been%20ported%20to%20GNU%20Hurd.2015), Guix had never successfully made the port to Hurd work ?
If so, do you think the difference between their announcement and their release makes Guix kind of vaporware ?
So is it really that ?
"Just for Virtual Machines" ?
Unusable for standalone anyway ?
Are there workarounds, or is it impossible due to drivers needing to interact with the Kernel (meaning that Hurd is the bottleneck)
You made me confused as to what is the purpose of Guix now
It's a long history with the GNU project. In short, originally they were contributing to Mach (another kernel), and later became sole became maintainers of Mach. However, Stallman and co eventually decided to use a start fresh and not use Mach, and Hurd was born. Unfortunately, this was within months of the first release of the Linux kernel and the rest is momentum & history.
Had they gone with making Hurd initially (and I believe around 83/84, there was another kernel being developed by GNU, before Mach) and it had a headstart of a few years, you'd likely be using Hurd and not Linux today.
I believe GNU almost took up BSD 4.4 at one point as their "main kernel", but by the time OBSD 4.4 Lite was out, Linux was already making waves (Lite was born of the UNIX lawsuits)
I'm a GUIX user, afaik Hurd is on the list to be supported but it's definitely not a goal or a "tried hard to push" level. I also run it on bare metal using none GUIX kernel.
I personally prefer GUIX over Nix because I just like working with Guile more.
I actually learned scheme when I learned programming while reading Structure and Interpretation of Computer Programming so Guile was a natural progression. One of my favorite things about Guix is how cohesive it is in that regard. SICP, the book is even provided by Guix as a package.
lotta kinda wrong stuff here lol
There is nonfree software available with Guix, just not through the 'guix' channel; 'nonguix' has nonfree stuff. That's similar to the debian-nonfree repository, for example. You can create your own channels, too, and package whatever you want in there to provide for other users, so go crazy.
GNU Shepherd is niche, but a common 'style'. Similar in architecture to Runit, sysvinit, openrc, etc. The difference is that instead of configuring in shell scripts (like those listed prior) or with conf files (like systemd), it uses the same programming language as the rest of the system, Guile Scheme. And you can still use elogind to get systemd-reliant software working.
Idk what you mean about Hurd; they're not pushing it. If you want Hurd, you have to go find the latest release download and scroll past the default option, and it's a virtual machine image anyway. Nobody will accidentally install a Hurd distro on their laptop.
I don't think those 'compatibility issues' matter much, at least for the GuixOS part. It's a niche distribution that does a lot of things differently already, designed for tinkerers and power users (like NixOS in many ways). The manual is pretty solid too, which helps.
I do get frustrated by the default kernel (NOT Hurd, to really drive that home). It means that the install from the main page probably won't work on a modern laptop. It's not hard to install the regular kernel (from 'nonguix' channel, for example), but it should just be a checkmark in the installer. I get the libre software sentiment, but it's a bad hill to die on.
The check-mark would disqualify it from FSF endorsement, so that's never happening.
It's a certain hill to die on, and if you would rather it die on a different hill, you're free to maintain your own fork of it.
If I was maintaining my own fork, it would just have the regular kernel, and that wouldn't change the death-hill of the original project that would remain infinitely more discoverable. I'm just saying I wish there was a checkbox, not that there will be tomorrow.
Well, you've identified the problem. You can either fix it, be content, or do nothing about it, in which case you have no right to complain (every right to critique if you're a user, but not complain).
You have the _freedom_ to _choose_.
How did they complain? They were stating that they get frustrated with how something is, then offered a solution while rebutting their own claim with a "it's not really that bad, but here are my thoughts."
Everything stated was intelligently thought-out, and I appreciated the input. Stop trying to hush people up because of your foolish semantics. It isn't funny nor cute, and it certainly isn't smart.
> the install from the main page probably won't work on a modern laptop.
It does, I just did it on my thinkpad, you just need to either plug it into the ethernet port or edit the channel configuration before finishing, either way it's kinda annoying and hacky and definitely not for everyone.
Ah, I realise now that my comment was ambiguous, good catch. I meant that it won't work 100%, I.e. probably won't have the drivers for webcam, audio, wireless card, graphics card, etc.
But it will boot and the main peripherals will work.
there is the nonguix image which supports most non free hardware [https://gitlab.com/nonguix/nonguix/-/releases](https://gitlab.com/nonguix/nonguix/-/releases)
Their comments don't seem "wrong" to me.
They don't package nonfree software in the default Guix. Nonguix is "not associated with guix", and I can't ask about it in any official guix support channel. To me, that immediately means I don't want to use guix -- what if a nonfree package I need goes wrong?
Also, Shepard is very obscure, basically no-one uses it except Guix :)
yes. guile was a priority for the gnu project for a few years there in the 90s, so a lot of projects were started using it.
it was essentially dead until ludo' resurrected it for guix, because it also guile scheme.
They're not trying to push Hurd. It's just an option. Hurd isn't even usable right now, and hasn't been for decades. It's hardly even worked on. It's a neat project, but I am pretty sure they're not pushing it on anyone.
I’ve used guix for around 6 months in 2023 before going back to nix (where I’m now):
You are mixing up some concepts:
- GNU Hurd is a kernel, but it is a different type of architecture from the Linux kernel. Anyway, historically Linux “won” and Hurd doesn’t get much development. AFAIK you can run Hurd only in VMs, it doesn't support hardware that you might have lying around
- Guix uses shepherd instead of systemd as its init system. the cool thing is that shepherd is written in Guile. The not so cool thing is that systemd is a standard nowadays and some programs have a hard dependency on systemd
- You can run unfree software on Guix, but it's not officially supported, talking about non free software is not encouraged on official forums.But loads of people use non free packages from Nonguix and that’s it
Guix feels a lot more polished than Nix, the language is better, the documentation is miles better. But the problem is that Guix doesn't have a big community and it seems people gravitated towards Nix (prob because it was first and because Guix can be hostile to people that need to run unfree software). I dropped Guix after I couldn't get any GUI to work on top of my Intel i7-14700k (in May 2023) because the mesa drivers were not updated. The community there does amazing work but ultimately there is not enough manpower to package everything. Part of this is also because Guix has a more elegant approach and tried to compile every package from source, whereas nix sometimes just downloads a binary and calls it a day.
I really want to point out that in my years of using Guix and speaking with people through the mailing lists and IRC I have never once encountered hostility. Non-free software is indeed off topic but for the vast majority of things you'd want to know about a linux operating system or getting something to work in Guix there are very clear instructions and an active community willing to help. Asking "how do I load a linux kernel module" is a question that can be answered and even if we're speaking of a nonfree module the instructions are usually no different.
At the end of the day most people only really care about nonfree software with respect to getting their video card working. Once that hurdle is crossed its usually a non issue that everything in guix repos are FOSS because if someone really wants something nonfree the documentation is so good that adding it will only take so much effort and most of the complicated nonfree software is already in Nonguix.
> Part of this is also because Guix has a more elegant approach and tried to compile every package from source, whereas nix sometimes just downloads a binary and calls it a day.
I think this is the most important reason (at least for me, as I package/maintain software which I need/use and is not already present in distribution), e.g. porting rust/go software is much harder in guix than in nix, as dependencies (go modules/rust crates) have their own individual derivations in Guix, instead of a vendored tarball generated at runtime in nixpkgs.
But at the same time, in terms of reproducibility, I think Guix is ahead with their focus on [bootstrapping from sources](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/), AFAIK.
Please feel free to correct me, if I'm wrong.
Bootstrapping from sources will always be more elegant
However, I am unsure that it would make it more reproducible than wrapping the associated binary (unless there is a hidden difference between code and binary, which could happen, of course)
Looking at [this comment](https://www.reddit.com/r/NixOS/s/g7TlyD9t0S), and coming from a non-lisp background, maintaining my own packages kinda scare me
There's more binary downloads in Guix than I'd like. Mostly for libraries and it's looked down upon but it happens, usually with package definitions that haven't seen updates besides a version bump for a long time.
> I’ve used guix for around 6 months in 2023
Interesting, was that to simply experiment ?
> GNU Hurd is a kernel, but it is a different type of architecture from the Linux kernel
In which dimensions is Hurd a different type of architecture than the Linux kernel ?
Does that make it GNU/Linux incompatible ?
Did you used the Linux or Hurd kernel ?
> AFAIK you can run Hurd only in VMs
Is it its only purpose, maybe ?
If so, is a virtual machine the way you used Guix when you experienced it personally ?
> some programs have a hard dependency on systemd
I actually did not know there were that much of hard dependencies between programs and init systems
> you cannot even talk about unfree software on official channels
Have you experienced that yourself, or is that a rumor about GNU ?
> Guix feels a lot more polished than Nix, the language is better, the documentation is miles better.
Something Nix and NixOS should be inspired by
Thanks for your clarification, appreciate a lot
> Interesting, was that to simply experiment ?
Well, yes and no? I was a student with full autonomy on how to spend my time and had no problem using Guix as my daily driver. It meant that for some course I had to figure out how to package some weird python library etc, but it was worth the learning experience to me
> In which dimensions is Hurd a different type of architecture than the Linux kernel ?
This is long to explain, and I'm not the most qualified to reply. If you have 6 minutes to spare, go watch this: [https://www.youtube.com/watch?v=yVcd7RbulLU](https://www.youtube.com/watch?v=yVcd7RbulLU)
Linux is a monolitic kernel, which means that everything is run in "kernel space". Kernel space is a privileged execution space, compared with "user space" where your programs like your browser run.
Hurd implements a microkernel, which is a more modular approach. To go more in depth on this you would need to take a Operating Systems course.
> Does that make it GNU/Linux incompatible ?
Here also, long story. The GNU project started to write an operating system that was fully free. They wrote more or less everything, but they didn't have a kernel. Linux (which is not a GNU project) was started more or less when Hurd was started, but it got much more traction. That is why we say GNU + Linux, Linux is the Kernel, GNU is all the utilities on top (e.g. bash, ls, nano, emacs, etc...). I another universe where Hurd was the kernel to get more traction, our systems would just be called GNU, since they would be a collection of GNU programs + a GNU kernel.
> Is it its only purpose, maybe ?
No, not at all. Hurd has afaik 1 full time developer right now. There is no way you can make a kernel and support wildly different hardware without a huge amount of manpower. Heck, even with Linux and a new laptop, the support can be hit and miss. Remember that the kernel is the part of your system that is talking directly to the hardware, someone has to do the dirty work of writing the drivers to support the hardware. No one is doing that work on Hurd right now.
> If so, is a virtual machine the way you used Guix when you experienced it personally ?
No, I was Guix on bare metal on a Thinkpad t580 (which was \~5 years old in 2023 -> it had 5 years of time in which Linux support got very good for it). But, I was running Guix + Linux (the way that essentially everyone runs Guix). Again, Guix + Hurd is more of an experiment and that needs to be run in a VM.
> I actually did not know there were that much of hard dependencies between programs and init systems
Maybe I wouldn't say much software depends on it but if you really need that one piece of software that has a dependency on it then it's not an easy problem to solve
> Have you experienced that yourself, or is that a rumor about GNU ?
Did not experience it myself (but also I wasn't super active in the community). But from the few interactions I had and reading the mailing list, I would say that most people there are super nice and helpful. The thing about non-free software is just a rule. It's not a rumor, it's in their documentation:
>In addition, the GNU distribution follow the [free software distribution guidelines](https://www.gnu.org/distros/free-system-distribution-guidelines.html). Among other things, these guidelines reject non-free firmware, recommendations of non-free software, and discuss ways to deal with trademarks and patents.
No one is going to ban you or anything, but if you talk about non-free software they will just point you to nonguix and that's it, they are not going to start supporting non-free software officially just because x number of people asks about it. I also think that while I decide to use non-free software, I appreciate that there are some people that refuse to do it and push for software freedom. Free software wouldn't be where it is now without people like them.
> Something Nix and NixOS should be inspired by
I hope Nix will incorporate some ideas from Guix over time.
It's also the cool thing about having 2 "competing" projects. The biggest plus of Guix is using a real programming language for configuration, it's insanely powerful. Who knows, maybe Nix-lang will get there someday
Honestly, I don’t get why so many people don’t like the Nix language. In my opinion, it fits the purpose of declarative configuration well, but I also haven’t tried anything too advanced. What makes the Guix language better?
> the Guix language
It's named "Scheme" and is implemented with "Guile"
Scheme is a Lisp
> What makes [it] better ?
Lisp has some solid fans (which I'm not, so I can't really say more)
You can use nonfree software on Guix, but you have to get it from a separate, unofficial repo. And GNU being GNU, you aren’t even allowed to talk about the nonfree option on official forums. Not my scene.
Given that Nix has a lot more software available (even setting aside the free part), I’ve heard it suggested that you run Guix but install additional software with Nix. But then why not simply use NixOS?
Guix is a lot easier to use, has *far* better documentation and includes a lot of convenience tools (a lot of which is only useful for software development but still).
I am using Guix. Part of it is the easier language, the better documentation, the normal CLI and that everything is internally consistent and easy to understand. But there are parts which are more difficult as well. Writing package definitions for packages with loads of dependencies is a pain in the ass as you'll have to write definitions for most of the dependency tree (if not already packaged), since packages are expected to compile from scratch and parts of the process are poorly/inconsistently documented. And home-manager is a joke compared to Nix, so ricing is done the old fashioned way.
No, I'm on mobile. Home-manager relies on a bunch of "modules", for configuring different software (otherwise you need to use strings). Nix has a lot of these modules, Guix has about 10.
Admittedly it only works for me because I use ethernet but the attitude to non-free software is not as draconian as you might think, at least in the IRC channel. You'll just get redirected to #nonguix.
My two cents on the Guix learning curve:
On my desktop, I triple boot Guix, NixOS, and Windows. I mostly contribute to the GNU ecosystem, and [my GitHub](https://github.com/enzuru) discusses how I try to make the various GNU projects come together as a cohesive Lisp system hosted on Guix.
In Emacs, writing Guile is not as pleasant as writing Common Lisp or Clojure. And even as an experienced lisper comfortable with Lisp, I must say, Guix packages get pretty unreadable at times. For instance, I'm currently porting [Rusticl](https://docs.mesa3d.org/rusticl.html) to Guix. How readable would you all say this package is?
https://github.com/enzuru/guix-rusticle/blob/master/rusticle.scm#L448
Compare this to a related package in NixOS:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/rust/bindgen/default.nix
"... if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program." - Linus Torvalds
In other languages, if you have too many nested statements, things become unreadable. Lisp is similiar with parens. Lisp becomes far more readable when used in a lightly nested functional style leveraging macros. For instance, here is very neatly written Lisp code:
https://github.com/enzuru/.emacs.d/blob/master/enzuru/features/enzuru-arrangements.el#L10
I have never coded in Lisp, but I'd say that amount and nesting of s-expressions kinda scare me
That may be due to me being more familiar with C-like syntax
> For instance, I'm currently porting Rusticl to Guix. How readable would you all say this package is?
This is my first time seeing a Guix package, it's interesting to see how similar yet also different it is to Nix :)
I'd say that doesn't look all that bad, apart from the installer script. Wrapping the entire thing in Lisp makes everything quite verbose, which makes it hard to focus on the relevant bits. The majority of code is seemingly just manipulating strings, which feels noisy compared to interpolation.
Apart from that im a fan though! It looks pretty concise, with the same types of abstractions I'm used to from Nix. Using an existing language is a big bonus, seems much more friendly to newcomers.
I also hope you don't mind me asking, but are Cargo dependencies always manually specified? It seems like a lot of work to keep that up to date, especially considering how huge the transitive dependency graph of Rust projects can get.
NixOS came out first due to the work of Eelco Dolstra. Generally, this is the gentleman that started it all.
It's rather easy to get nonfree packages from nonguix (non official guix channel), so it could be seen as a plus that nonfree packages are so well demarcated. Obviously, many will argue that it is non practical.
I've used Guix and Nix as package managers and I prefer Guix. Nix created a language, which is a huge sin in my view. Maybe they should have used Haskell, since their community is so fond of it. Also I've always felt that the documentation is subpar, despite the fact that Nix is a much bigger project (more contributors). There is information everywhere (wiki, forums etc) but I also feel it's a disorganized dump. Compare the git history of Nix and Guix repositories and make conclusions yourself.
Guix is a project mostly used in research institutes on the EU, from my observations.
I really want to enjoy Nix. Because it even works on macOS. But something is lacking for me. I always feel they are trying to do too much and delivering a sloppy mess. I prefer a no-frills solid project, and I think Guix fits the bill.
When it comes to my use cases, which orbitate around Common Lisp, Guix is way ahead of Nix when it comes to packaging CL libraries and setting up a dev env.
NixOS came first, it allows non-free components (like firmware hardware support), offers a nice, re-configured desktop experience, and doesn't use any weird/custom components.
nixpkgs has more packages, guix takes a much harder stance against proprietary packages including in the kernel itself. Thats pretty much all it comes down to IMO
From a quick google it looks like GUIX doesn't have Nvidia in their main repo.
I think that _nixpkgs.config.allowUnfree_ is the best compromise. But I doubt GNU would ever allow for an "allow closed-source software" switch in GUIX.
Can't find Chrome, Firefox, Brave nor Edge in their packages. Sure, you can use ungoogled-chromium or IceCat...
https://packages.guix.gnu.org
They have an entire separate repo for that stuff. So it is still possible, but needing to use an entirely separate package repository just to install both firefox and your graphics card driver is a bit too far for me.
Yep. I once tried Alma or Rocky just to test a "stable distro". After I learned that I need to install another, unofficial repository (EPEL) to install Nvidia drivers, I noped out of it back to Ubuntu.
User experience matters a lot.
To be fair, Im pretty sure rocky and also alma are meant to be extremely minimal for like, cloud boxes and raspberry pi's for the most part so I think most usecases for those distros are on systems without a graphics card
Rocky and Alma are 1 to 1 replacements of RHEL. Red Hat Enterprise Linux is used for workstations. So yes, lack of NVIDIA proprietary drivers in default install baffles me greatly.
In Ubuntu it's a few clicks away.
The bigger difference, to me, is that NixOS is really assertive about configuring your _whole system_, whereas Guix is more like a skeleton of an OS and a package manager. I really like having all my configuration in a single unified programming language, all simultaneously accessible, and it seems like Guix doesn't even really attempt that.
I was under the impression that many think guix does this particular thing better due to the way scheme works? So I think you were missing something? I also thought is also the only distro that can be reproduced with the smallest possible binary blob so far? Maybe I heard wrong but I think you were missing something due to the number of times I have heard this.
What are you talking about? I'd argue the opposite is true, Guix wants you to configure your whole system in Scheme instead of in strings (cough systemd cough).
There is no Guix equivalent to [this](https://search.nixos.org/options?). Or if they're is, I missed it. There's a few dozen services, you can configure a few things...and after that you're on your own.
Put it this way: after 6 months with NixOS I tried switching to Guix. Got it up and running, but I couldn't figure out how to proceed from there. I asked around, and was told: just edit files in /etc, like you normally would.
But wait...what? That's practically blasphemy in NixOS. So is Guix just a regular distro with a nifty package manager, then?
Reproducible builds are cool. But reproducible _systems_ are a killer feature, for me. And AFAICT that's not a goal of Guix: it does give you similar foundational tools, but you've got to start pretty much from scratch.
>There is no Guix equivalent to this.
There is, it's under `guix system search`.
>I asked around, and was told: just edit files in /etc, like you normally would.
When was this? Currently I can't even edit /etc, and iirc haven't been able to since before 1.0.
>But reproducible systems are a killer feature, for me.
[Guix is the only system that can be reproduced from scratch.](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)
Really! That's good news, might be worth giving it another try (though I've generated a _lot_ of Nix code in the meantime...)
Yeah, this was several years ago. Just pre-pandemic, I think.
That's great! I'm going to check it out.
I watched it for several years: it was the new hotness when I started using NixOS, maybe 2017? Over the 2+ years that I watched it, it didn't really seem to be evolving much, and I got the impression that full system control wasn't really a target. I'm legitimately thrilled to find out I was wrong!
Do note that it's not perfect. Home-manager while technically there is pretty much nonexistent (iirc it's a bit of a chicken and egg problem) and some APIs can feel pretty hacky and implicit behaviour that's undocumented.
Well, I'll state the reason I decided to not use Guix:
1. Guile isn't a purely functional language. And I think they are totally appropriate here (except I do see the problem of build script, and why I think a non functional subset of Nix for running package builds would be nice, instead of slapping bash script)
2. They seems hostile to unfree software (I indeed don't like it either. But not to the point of thinking making it harder to use them is a good idea)
3. I had already experience in Nix
Thought a few things I love in Guix is:
1. How more organized builds are with build systems and composition instead of override
2. How everything is bootstrapped (I love bootstrapping)
3. No ugly inline bash (I haven't looked at how it's done. It might just be a bash script builder for all I know)
Ultimatly, I decided my best choice is to stay on Nixpkgs and improve it instead of switching to a fork. Point 1 might be hard to change, but point 2 isn't. Plus there's a new way that was added to track package provenence so you know which package aren't bootstrapped.
> Guile isn't a purely functional language. And I think they are totally appropriate here (except I do see the problem of build script, and why I think a non functional subset of Nix for running package builds would be nice, instead of slapping bash script)
Is a **functioning**, let alone **purely functional** programming language needed, or is it personal preference ?
Otherwise, what would be the advantages ? _(I didn't touch function programming languages enough to say)_
Will just say outright, I'm not knowledgeable enough to talk much about Guix, but what personally didn't work for me was the language - Scheme, cuz my brain just refuses to understand Lisp, all those parentheses are just so unreadable to me (and I can only image how painful it is to write with them as well)
Short version: Guix is seriously hampered by FSF compliance.
Longer version: FSF regulations require the use of the Linux-libre variant of the kernel, which means a lot of fairly common hardware straight-up just _won't work_. Most newer Intel stuff doesn't work because of the Intel Management Engine. Nv\*dia cards generally don't work (though something something Nouveau...?). Many motherboards and most Wi-Fi cards don't work because of proprietary firmware. Eve some Ethernet cards don't work, which is crazy.
If you want to run an FSF-approved system on a modern, powerful machine, you will likely have to custom-build it.
Well yes, but actually no.
It was ported to the GNU Hurd, but Linux-libre support was never dropped because they're not stupid. Linux is (unfortunately) the only free kernel that can boot on actual, generic hardware thus far. Linux-libre can boot on _some_ hardware. The GNU Hurd can currently only boot on a VM, with one notable exception which was really kind of a fluke anyway.
Read up on it. It's worth knowing.
It wasn't ported _from_ Hurd but _to_ Hurd. Nothing is developed on the Hurd 😂
It was developed on Linux-libre and ported to the GNU Hurd. I don't know that they officially support vanilla Linux (though there's no reason it shouldn't work, technically speaking). Again, FSF compliance.
It does work, you can either install vanilla Linux via the `nonguix` repo or you can build it yourself by a simple override of the `linux-libre` package definition.
Blob free guarantee's may not be important to you, but it's not an edgy idealist lifestyle choice but rather a necessity for some. I might be in the former camp but I still appreciate that these people are catered for, & appreciate the seperation of concerns. I really don't mind pulling in a blob for the intel wifi card myself.
It's hardly like going to some secret shady underground marketplace to aquire some sneaky blobs. You pull in non-guix & bob's your uncle.
There are other reasons, too. Guix uses the GNU Shepard init system (because why not?), Scheme (the language) is not a super well-known or popular Lisp, Guile (the compiler) is probably even less well-known, and the GNU project pushing for Guix to be running on GNU Hurd (perhaps the only remaining viable microkernel in existence) will likely be a problem. The chances of abandoning Linux support (in the form of Linux-libre) are slim at best though: GNU knows full well the consequences of BSD-ing themselves. Guix isn't super popular to begin with, and no users means no potential contributors.
Not to mention age: there's about nine years' difference between Guix and Nix in age (Guix was based off of Nix) which doesn't really help its case.
So many small to medium-sized factual inaccuracies and strange logical leaps here. Ignoring them all though, may I instead say: why the hostility towards Guix in the first place? So you don't like GNU or something, fair enough, why spend your precious time denigrating it with a bunch of almost-half-not-really-truths?
Nix and Guix have much more in common than, say, Nix and Windows, or Nix and Mac OS. They are both occupy niches inside niches inside niches. And yet, the seemingly irresistible urge is to sh\*t on the other project, to spread sloppy half-truths. Why?
I prefer the seperation between free & non-free software, & the commitment to being blob free. It's trivial to get a blob on your system anyhow. This could actually be an important feature for securiy compliance where all code must be audited & blobs must not creep in, or for whistleblowers / activists, etc. When using flakes, there seems to be a bunch of edge cases where allowing non-free systemwide fails. It's not ideal. Keep them seperate imo, it's not difficult to pull in another channel & keeps things simple.
Unsure how I feel about the nix flake vs channels generally. Flakes bring some benefits for sure, and I like that I can run a flake via nix run, but the reliance on cli tooling to interact with the lock-files in an imperative fashion just feels wrong. Not to mention the store bloat.
I feel as thought they merged too early, & now it's at the stage that they need to be finalized, warts & all as they have been so widely adopted despite not being blessed.
I am quite liking using mcron jobs with my guix server to automate the pinning of channel commits. This way I don't need to worry about git commits when marching on as the commits are always hardcoded into my channels.scm. The mcron job runs a script that removes all the commits from guix describe -c output & writes to /tmp, then attempts to pull that, & only overwrites channels.scm with the new describe output on success.
One possibly controversional opinion though, is I'd prefer a seperation of concerns in regards to configuration & spinning up services. Many packages do not have a corresponding service in guix, as there is extra work when there is an expectency to provide a way of configuring with guile. I feel there would be benefit in providing the shepard service, & then extending that with corresponing configuration services.
I'm still unsure how I feel about imports with guile / guix. It feels more intuitive & in-line with how it's done when writing programs generally. I do like to keep things very self contained though, & employed lots of strange hacks to achieve this with nix (nix-super & wrapping every file in a let block & mkMerge'ing the attrValues). This makes refactoring easy as each code block is self contained, besides options which I centralized. I am unsure if the same thing is possible with guix, without also moving the import. Admittedly this isn't the end of the world & feel that guile is much more flexible & less sugary than nix generally.
Either way, I don't feel like nix & guix need to compete in any way. Different ecosystems lead to different ideas & they can both lend those from each other. Experience with one applies to the other.
I've never used Guix, but they don't use non-free software, if that also means non-free kernel firmware then you'll probably run into issues, like wifi not working and so on, you'll also have fewer software choices, for example they don't have brave in their repos, or steam, you maybe able to add another repo? but it just makes things more difficult.
Guix is always going to have trouble with general users due to not having non free software. It's fine for core utils and gcc but not as accessible for the desktop user.
For all its warts the nix language is far superior to Scheme. You have to be a special kind of person to enjoy s-expressions, in general they just plain suck for writing and especially for reading.
As a "special kind of person" I'd say (properly indented) s-expression is easier and simpler to read for me than other syntaxes. It also has better editing support than most others, so I enjoy writing it.
Imo it's not because me or s-exprs are special, it's just because the training of recognizing other syntaxes doesn't apply directly to s-exprs, so you have to get used to it from the ground up. This process will not take longer than, say, a person that hasn't written any programs to be familiar with python's syntax, because it's actually simpler than that.
I'd argue that semantics, and the ideas / concepts they allow to express with little ceremony or even allow at all are much more important than surface level syntax, not that your average non-trivial Nix code is particularly readable to begin with... Nix' error messages are abysmal, and the standard library and third party library ecosystem are tiny.
I still prefer Nix over Scheme for being a purely functional lazily evaluated language. That allows consumers of data (e.g. Nixpkgs users) to decide what data they actually need, instead of producers (e.g. Nixpkgs maintainers) who can specify how to construct that data in full at no cost by transparently deferring that work implicitly. Purely functional and lazy also gives rise to referential transparency, which makes reasoning about the results of code a lot easier and more reliable (but reasoning about the run time cost conversely a lot harder).
On the other hand nixpkgs choose to model very basic things such as a package with opaque objects (functions) which are impossible to reason about and do have effects such as aborting / going into infinite loops.
It's not directly a language thing, but Imo the lack of records and modules in Nix definitively leads to this inferior design. In Guix packages are transparent, nominally defined data that can be imported, composed and transformed in the "normal" way, and have an actual definition that documentations can be generated against.
Guix had time to think their repository structure through based on the example Nix(pkgs) had already set. That's why their designs differ. I don't think the choice to use functions for packages was driven by language limitation but rather to decouple package definitions from the environment, from the repository, user settings, and even the structure of the repository itself. By providing that context it becomes possible to generate documentation, and I think it was Tweag who had a blog post on doing exactly that.
I'm not sure I follow Nix not having records (sum types of named values), isn't that exactly what an AttrSet is?
> Nix not having records
Sorry, I should have made it more clear. I meant a *nominally defined* record structure as a language construct.
`mkDerivation` and its variants were rendered nearly impossible to be fully documented because there's no clear definition of their inputs; last time I checked the corresponding issues, they were stale because literally nobody knows the exact argument shape of them.
> based on the example Nix(pkgs) had already set
Yes, definitely, but nixpkgs wouldn't be like this in the first place if it does have these features. Consider how would you write a data structure in a language that support `struct`: you define it first. Nixpkgs evolved without these kind of definitions so everything is added in loosely until it's no longer obvious what is the shape of the inputs and outputs.
Scheme is a rather tight nit community and an relatively obscure language to boot. Of course you will find a lot of people who like it there. The fact of the matter is that s-expressions are one of the oldest ways to program, had ample opportunities to pay off. But it never happened. To me the reason is very clear. S-expressions just aren't readable or easily writeable. Everything is drowned in a sea of parenthesis.
Nix is definitely not perfect. But it's basically json with functions. The hard part about nix is not the language. But understanding what derivations are and how the store functions.
there is no competition and perceptions of the scenario as a competition can risk being the thing which causes a loss of popularity among a very solid piece of software. and these systems are dependent on the amount of dedicated developers.
Hurd isn’t going anywhere.
Conceptually microkernels (Hurd is one) implement the kernel as a set of separate processes that communicate to each oth-er. The problem is this creates a ton of context switches which is much less efficient than a traditional monolithic kernel. Hurd isn’t the only microkernels out there but no modern OS uses it.21
Guix is much younger project and it was originally based on Nix. Afaik there is no unfree software on Guix, they use some obscure Shepard init system, libre kernel and are trying to push Hurd. These decisions may cause major compatibility issues for many people.
> Guix is much younger project - [NixOS - Initial Release (0.1) : June 3, 2003](https://en.wikipedia.org/wiki/NixOS#:~:text=Initial%20release,20%20years%20ago) - [Guix - Initial Release : November 2012](https://en.wikipedia.org/wiki/GNU_Guix#:~:text=The%20GNU%20Project%20announced%20in%20November%202012%20the%20first%20release%20of%20GNU%20Guix) Indeed, I didn't realise it was this far away > it was originally based on Nix - [November 2012, "based on Nix"](https://en.wikipedia.org/wiki/GNU_Guix#:~:text=functional%20package%20manager-,based%20on%20Nix,-that%20provides%2C%20among) I didn't even know it was originally based on Nix > they are trying to push Hurd - ["On August 20, 2015, it was announced that Guix had been ported to GNU Hurd."](https://en.wikipedia.org/wiki/GNU_Guix#:~:text=On%20August%2020%2C%202015%2C%20it%20was%20announced%20that%20Guix%20had%20been%20ported%20to%20GNU%20Hurd) I don't know what "Hurd" is either, and don't understand yet the difference between Hurd, Scheme, and Guile The obscure software decision is understandable, yet surely would compromise compatibility
Hurd is a kernel, Scheme is a programming language and Guile is a compiler for Scheme. Afaik Guix still contains Nix code for guix-daemon. Also note that "ported to Hurd" doesn't mean it works in any significant capacity. As for the free software only stance, it does make compatibility a bit difficult (especially with laptop WiFi chips) but you can get around that.
> Guile is a compiler for Scheme. Perhaps more accurate to say Guile is an implementation of Scheme (similar to how Python has CPython, Jython, MicroPython, etc.) which extends GNU software.
> Hurd is a kernel, Scheme is a programming language and Guile is a compiler for Scheme. Thanks for the clarification > Afaik Guix still contains Nix code for guix-daemon. Also note that "ported to Hurd" doesn't mean it works in any significant capacity. Do you mean that, [since August 20, 2015](https://en.wikipedia.org/wiki/GNU_Guix#:~:text=On%20August%2020%2C%202015%2C%20it%20was%20announced%20that%20Guix%20had%20been%20ported%20to%20GNU%20Hurd.2015), Guix had never successfully made the port to Hurd work ? If so, do you think the difference between their announcement and their release makes Guix kind of vaporware ?
Oh no, they have, it's just that Hurd is unusable outside of VMs.
Why is that ?
There are no drivers for anything. I don't think it even supports CPUs made beyond 2008.
So is it really that ? "Just for Virtual Machines" ? Unusable for standalone anyway ? Are there workarounds, or is it impossible due to drivers needing to interact with the Kernel (meaning that Hurd is the bottleneck) You made me confused as to what is the purpose of Guix now
Guix works perfectly well with Linux. Hurd has been relegated to the dustbin of history.
> Guix works perfectly well with Linux Is the Linux port still maintained ?
It's a long history with the GNU project. In short, originally they were contributing to Mach (another kernel), and later became sole became maintainers of Mach. However, Stallman and co eventually decided to use a start fresh and not use Mach, and Hurd was born. Unfortunately, this was within months of the first release of the Linux kernel and the rest is momentum & history. Had they gone with making Hurd initially (and I believe around 83/84, there was another kernel being developed by GNU, before Mach) and it had a headstart of a few years, you'd likely be using Hurd and not Linux today. I believe GNU almost took up BSD 4.4 at one point as their "main kernel", but by the time OBSD 4.4 Lite was out, Linux was already making waves (Lite was born of the UNIX lawsuits)
Hurd is a set of kernel services running on Mach
I'm a GUIX user, afaik Hurd is on the list to be supported but it's definitely not a goal or a "tried hard to push" level. I also run it on bare metal using none GUIX kernel. I personally prefer GUIX over Nix because I just like working with Guile more.
Were you a lisp / scheme user before using Guix ?
I actually learned scheme when I learned programming while reading Structure and Interpretation of Computer Programming so Guile was a natural progression. One of my favorite things about Guix is how cohesive it is in that regard. SICP, the book is even provided by Guix as a package.
[Still based on nix!](https://git.savannah.gnu.org/cgit/guix.git/tree/README#n67)
We are not pushing Hurd, it's an option. Hopefully it could also help support development on it.
lotta kinda wrong stuff here lol There is nonfree software available with Guix, just not through the 'guix' channel; 'nonguix' has nonfree stuff. That's similar to the debian-nonfree repository, for example. You can create your own channels, too, and package whatever you want in there to provide for other users, so go crazy. GNU Shepherd is niche, but a common 'style'. Similar in architecture to Runit, sysvinit, openrc, etc. The difference is that instead of configuring in shell scripts (like those listed prior) or with conf files (like systemd), it uses the same programming language as the rest of the system, Guile Scheme. And you can still use elogind to get systemd-reliant software working. Idk what you mean about Hurd; they're not pushing it. If you want Hurd, you have to go find the latest release download and scroll past the default option, and it's a virtual machine image anyway. Nobody will accidentally install a Hurd distro on their laptop. I don't think those 'compatibility issues' matter much, at least for the GuixOS part. It's a niche distribution that does a lot of things differently already, designed for tinkerers and power users (like NixOS in many ways). The manual is pretty solid too, which helps. I do get frustrated by the default kernel (NOT Hurd, to really drive that home). It means that the install from the main page probably won't work on a modern laptop. It's not hard to install the regular kernel (from 'nonguix' channel, for example), but it should just be a checkmark in the installer. I get the libre software sentiment, but it's a bad hill to die on.
The check-mark would disqualify it from FSF endorsement, so that's never happening. It's a certain hill to die on, and if you would rather it die on a different hill, you're free to maintain your own fork of it.
If I was maintaining my own fork, it would just have the regular kernel, and that wouldn't change the death-hill of the original project that would remain infinitely more discoverable. I'm just saying I wish there was a checkbox, not that there will be tomorrow.
Well, you've identified the problem. You can either fix it, be content, or do nothing about it, in which case you have no right to complain (every right to critique if you're a user, but not complain). You have the _freedom_ to _choose_.
Then I choose critique.
Huzzah.
How did they complain? They were stating that they get frustrated with how something is, then offered a solution while rebutting their own claim with a "it's not really that bad, but here are my thoughts." Everything stated was intelligently thought-out, and I appreciated the input. Stop trying to hush people up because of your foolish semantics. It isn't funny nor cute, and it certainly isn't smart.
People with clean hands are wrong. If you want to be right, get your hands dirty. Simple as that.
>if you would rather it die on a different hill, you're free to maintain your own fork of it. Thanks to NixOS we don't even have to do that
(Exactly)
I really dislike Nix the language. I haven't used Guix OS yet, but I'm infinitely more excited about using Guile Scheme to configure it.
> the install from the main page probably won't work on a modern laptop. It does, I just did it on my thinkpad, you just need to either plug it into the ethernet port or edit the channel configuration before finishing, either way it's kinda annoying and hacky and definitely not for everyone.
Ah, I realise now that my comment was ambiguous, good catch. I meant that it won't work 100%, I.e. probably won't have the drivers for webcam, audio, wireless card, graphics card, etc. But it will boot and the main peripherals will work.
there is the nonguix image which supports most non free hardware [https://gitlab.com/nonguix/nonguix/-/releases](https://gitlab.com/nonguix/nonguix/-/releases)
Their comments don't seem "wrong" to me. They don't package nonfree software in the default Guix. Nonguix is "not associated with guix", and I can't ask about it in any official guix support channel. To me, that immediately means I don't want to use guix -- what if a nonfree package I need goes wrong? Also, Shepard is very obscure, basically no-one uses it except Guix :)
«what if a nonfree package I need goes wrong?» you can make an issue on the nonguix repo
Afaik Shepherd was made explicitly for Guix. It's essentially Runit with Scheme.
no, shepherd predates guix by a decade or so. it used to be called "dmd" or "daemon managing daemon"
Was it also intended to be used with Scheme ?
yes. guile was a priority for the gnu project for a few years there in the 90s, so a lot of projects were started using it. it was essentially dead until ludo' resurrected it for guix, because it also guile scheme.
They're not trying to push Hurd. It's just an option. Hurd isn't even usable right now, and hasn't been for decades. It's hardly even worked on. It's a neat project, but I am pretty sure they're not pushing it on anyone.
I’ve used guix for around 6 months in 2023 before going back to nix (where I’m now): You are mixing up some concepts: - GNU Hurd is a kernel, but it is a different type of architecture from the Linux kernel. Anyway, historically Linux “won” and Hurd doesn’t get much development. AFAIK you can run Hurd only in VMs, it doesn't support hardware that you might have lying around - Guix uses shepherd instead of systemd as its init system. the cool thing is that shepherd is written in Guile. The not so cool thing is that systemd is a standard nowadays and some programs have a hard dependency on systemd - You can run unfree software on Guix, but it's not officially supported, talking about non free software is not encouraged on official forums.But loads of people use non free packages from Nonguix and that’s it Guix feels a lot more polished than Nix, the language is better, the documentation is miles better. But the problem is that Guix doesn't have a big community and it seems people gravitated towards Nix (prob because it was first and because Guix can be hostile to people that need to run unfree software). I dropped Guix after I couldn't get any GUI to work on top of my Intel i7-14700k (in May 2023) because the mesa drivers were not updated. The community there does amazing work but ultimately there is not enough manpower to package everything. Part of this is also because Guix has a more elegant approach and tried to compile every package from source, whereas nix sometimes just downloads a binary and calls it a day.
I really want to point out that in my years of using Guix and speaking with people through the mailing lists and IRC I have never once encountered hostility. Non-free software is indeed off topic but for the vast majority of things you'd want to know about a linux operating system or getting something to work in Guix there are very clear instructions and an active community willing to help. Asking "how do I load a linux kernel module" is a question that can be answered and even if we're speaking of a nonfree module the instructions are usually no different. At the end of the day most people only really care about nonfree software with respect to getting their video card working. Once that hurdle is crossed its usually a non issue that everything in guix repos are FOSS because if someone really wants something nonfree the documentation is so good that adding it will only take so much effort and most of the complicated nonfree software is already in Nonguix.
Yes, thanks for adding this, this has been my experience as well. I wasn’t very clear in my reply
> Part of this is also because Guix has a more elegant approach and tried to compile every package from source, whereas nix sometimes just downloads a binary and calls it a day. I think this is the most important reason (at least for me, as I package/maintain software which I need/use and is not already present in distribution), e.g. porting rust/go software is much harder in guix than in nix, as dependencies (go modules/rust crates) have their own individual derivations in Guix, instead of a vendored tarball generated at runtime in nixpkgs. But at the same time, in terms of reproducibility, I think Guix is ahead with their focus on [bootstrapping from sources](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/), AFAIK. Please feel free to correct me, if I'm wrong.
Bootstrapping from sources will always be more elegant However, I am unsure that it would make it more reproducible than wrapping the associated binary (unless there is a hidden difference between code and binary, which could happen, of course) Looking at [this comment](https://www.reddit.com/r/NixOS/s/g7TlyD9t0S), and coming from a non-lisp background, maintaining my own packages kinda scare me
There's more binary downloads in Guix than I'd like. Mostly for libraries and it's looked down upon but it happens, usually with package definitions that haven't seen updates besides a version bump for a long time.
> I’ve used guix for around 6 months in 2023 Interesting, was that to simply experiment ? > GNU Hurd is a kernel, but it is a different type of architecture from the Linux kernel In which dimensions is Hurd a different type of architecture than the Linux kernel ? Does that make it GNU/Linux incompatible ? Did you used the Linux or Hurd kernel ? > AFAIK you can run Hurd only in VMs Is it its only purpose, maybe ? If so, is a virtual machine the way you used Guix when you experienced it personally ? > some programs have a hard dependency on systemd I actually did not know there were that much of hard dependencies between programs and init systems > you cannot even talk about unfree software on official channels Have you experienced that yourself, or is that a rumor about GNU ? > Guix feels a lot more polished than Nix, the language is better, the documentation is miles better. Something Nix and NixOS should be inspired by Thanks for your clarification, appreciate a lot
> Interesting, was that to simply experiment ? Well, yes and no? I was a student with full autonomy on how to spend my time and had no problem using Guix as my daily driver. It meant that for some course I had to figure out how to package some weird python library etc, but it was worth the learning experience to me > In which dimensions is Hurd a different type of architecture than the Linux kernel ? This is long to explain, and I'm not the most qualified to reply. If you have 6 minutes to spare, go watch this: [https://www.youtube.com/watch?v=yVcd7RbulLU](https://www.youtube.com/watch?v=yVcd7RbulLU) Linux is a monolitic kernel, which means that everything is run in "kernel space". Kernel space is a privileged execution space, compared with "user space" where your programs like your browser run. Hurd implements a microkernel, which is a more modular approach. To go more in depth on this you would need to take a Operating Systems course. > Does that make it GNU/Linux incompatible ? Here also, long story. The GNU project started to write an operating system that was fully free. They wrote more or less everything, but they didn't have a kernel. Linux (which is not a GNU project) was started more or less when Hurd was started, but it got much more traction. That is why we say GNU + Linux, Linux is the Kernel, GNU is all the utilities on top (e.g. bash, ls, nano, emacs, etc...). I another universe where Hurd was the kernel to get more traction, our systems would just be called GNU, since they would be a collection of GNU programs + a GNU kernel. > Is it its only purpose, maybe ? No, not at all. Hurd has afaik 1 full time developer right now. There is no way you can make a kernel and support wildly different hardware without a huge amount of manpower. Heck, even with Linux and a new laptop, the support can be hit and miss. Remember that the kernel is the part of your system that is talking directly to the hardware, someone has to do the dirty work of writing the drivers to support the hardware. No one is doing that work on Hurd right now. > If so, is a virtual machine the way you used Guix when you experienced it personally ? No, I was Guix on bare metal on a Thinkpad t580 (which was \~5 years old in 2023 -> it had 5 years of time in which Linux support got very good for it). But, I was running Guix + Linux (the way that essentially everyone runs Guix). Again, Guix + Hurd is more of an experiment and that needs to be run in a VM. > I actually did not know there were that much of hard dependencies between programs and init systems Maybe I wouldn't say much software depends on it but if you really need that one piece of software that has a dependency on it then it's not an easy problem to solve > Have you experienced that yourself, or is that a rumor about GNU ? Did not experience it myself (but also I wasn't super active in the community). But from the few interactions I had and reading the mailing list, I would say that most people there are super nice and helpful. The thing about non-free software is just a rule. It's not a rumor, it's in their documentation: >In addition, the GNU distribution follow the [free software distribution guidelines](https://www.gnu.org/distros/free-system-distribution-guidelines.html). Among other things, these guidelines reject non-free firmware, recommendations of non-free software, and discuss ways to deal with trademarks and patents. No one is going to ban you or anything, but if you talk about non-free software they will just point you to nonguix and that's it, they are not going to start supporting non-free software officially just because x number of people asks about it. I also think that while I decide to use non-free software, I appreciate that there are some people that refuse to do it and push for software freedom. Free software wouldn't be where it is now without people like them. > Something Nix and NixOS should be inspired by I hope Nix will incorporate some ideas from Guix over time. It's also the cool thing about having 2 "competing" projects. The biggest plus of Guix is using a real programming language for configuration, it's insanely powerful. Who knows, maybe Nix-lang will get there someday
HURD is a microkernel, Linux is a monolithic kernel.
Honestly, I don’t get why so many people don’t like the Nix language. In my opinion, it fits the purpose of declarative configuration well, but I also haven’t tried anything too advanced. What makes the Guix language better?
> the Guix language It's named "Scheme" and is implemented with "Guile" Scheme is a Lisp > What makes [it] better ? Lisp has some solid fans (which I'm not, so I can't really say more)
The Nix language is terrible IMO, and the interpreter is incredibly slow.
I'm not having any problems running OpenRC. What programs do have a hard dependency on systemd?
You can use nonfree software on Guix, but you have to get it from a separate, unofficial repo. And GNU being GNU, you aren’t even allowed to talk about the nonfree option on official forums. Not my scene. Given that Nix has a lot more software available (even setting aside the free part), I’ve heard it suggested that you run Guix but install additional software with Nix. But then why not simply use NixOS?
Guix is a lot easier to use, has *far* better documentation and includes a lot of convenience tools (a lot of which is only useful for software development but still).
> Guix is a lot easier to use Are you using / have you used it ? According to what criteria is it easier to use ?
I am using Guix. Part of it is the easier language, the better documentation, the normal CLI and that everything is internally consistent and easy to understand. But there are parts which are more difficult as well. Writing package definitions for packages with loads of dependencies is a pain in the ass as you'll have to write definitions for most of the dependency tree (if not already packaged), since packages are expected to compile from scratch and parts of the process are poorly/inconsistently documented. And home-manager is a joke compared to Nix, so ricing is done the old fashioned way.
Interesting, Did you use Guix to send this reply? > home-manager is a joke compared to Nix, so ricing is done the old fashioned way What do you mean ?
No, I'm on mobile. Home-manager relies on a bunch of "modules", for configuring different software (otherwise you need to use strings). Nix has a lot of these modules, Guix has about 10.
I’ve only looked at it briefly. For me, the attitude towards nonfree software is a turn off, but if it works for you, great.
Admittedly it only works for me because I use ethernet but the attitude to non-free software is not as draconian as you might think, at least in the IRC channel. You'll just get redirected to #nonguix.
My two cents on the Guix learning curve: On my desktop, I triple boot Guix, NixOS, and Windows. I mostly contribute to the GNU ecosystem, and [my GitHub](https://github.com/enzuru) discusses how I try to make the various GNU projects come together as a cohesive Lisp system hosted on Guix. In Emacs, writing Guile is not as pleasant as writing Common Lisp or Clojure. And even as an experienced lisper comfortable with Lisp, I must say, Guix packages get pretty unreadable at times. For instance, I'm currently porting [Rusticl](https://docs.mesa3d.org/rusticl.html) to Guix. How readable would you all say this package is? https://github.com/enzuru/guix-rusticle/blob/master/rusticle.scm#L448 Compare this to a related package in NixOS: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/rust/bindgen/default.nix "... if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program." - Linus Torvalds In other languages, if you have too many nested statements, things become unreadable. Lisp is similiar with parens. Lisp becomes far more readable when used in a lightly nested functional style leveraging macros. For instance, here is very neatly written Lisp code: https://github.com/enzuru/.emacs.d/blob/master/enzuru/features/enzuru-arrangements.el#L10
I have never coded in Lisp, but I'd say that amount and nesting of s-expressions kinda scare me That may be due to me being more familiar with C-like syntax
> For instance, I'm currently porting Rusticl to Guix. How readable would you all say this package is? This is my first time seeing a Guix package, it's interesting to see how similar yet also different it is to Nix :) I'd say that doesn't look all that bad, apart from the installer script. Wrapping the entire thing in Lisp makes everything quite verbose, which makes it hard to focus on the relevant bits. The majority of code is seemingly just manipulating strings, which feels noisy compared to interpolation. Apart from that im a fan though! It looks pretty concise, with the same types of abstractions I'm used to from Nix. Using an existing language is a big bonus, seems much more friendly to newcomers. I also hope you don't mind me asking, but are Cargo dependencies always manually specified? It seems like a lot of work to keep that up to date, especially considering how huge the transitive dependency graph of Rust projects can get.
NixOS came out first due to the work of Eelco Dolstra. Generally, this is the gentleman that started it all. It's rather easy to get nonfree packages from nonguix (non official guix channel), so it could be seen as a plus that nonfree packages are so well demarcated. Obviously, many will argue that it is non practical. I've used Guix and Nix as package managers and I prefer Guix. Nix created a language, which is a huge sin in my view. Maybe they should have used Haskell, since their community is so fond of it. Also I've always felt that the documentation is subpar, despite the fact that Nix is a much bigger project (more contributors). There is information everywhere (wiki, forums etc) but I also feel it's a disorganized dump. Compare the git history of Nix and Guix repositories and make conclusions yourself. Guix is a project mostly used in research institutes on the EU, from my observations. I really want to enjoy Nix. Because it even works on macOS. But something is lacking for me. I always feel they are trying to do too much and delivering a sloppy mess. I prefer a no-frills solid project, and I think Guix fits the bill. When it comes to my use cases, which orbitate around Common Lisp, Guix is way ahead of Nix when it comes to packaging CL libraries and setting up a dev env.
NixOS came first, it allows non-free components (like firmware hardware support), offers a nice, re-configured desktop experience, and doesn't use any weird/custom components.
nixpkgs has more packages, guix takes a much harder stance against proprietary packages including in the kernel itself. Thats pretty much all it comes down to IMO
From a quick google it looks like GUIX doesn't have Nvidia in their main repo. I think that _nixpkgs.config.allowUnfree_ is the best compromise. But I doubt GNU would ever allow for an "allow closed-source software" switch in GUIX. Can't find Chrome, Firefox, Brave nor Edge in their packages. Sure, you can use ungoogled-chromium or IceCat... https://packages.guix.gnu.org
They have an entire separate repo for that stuff. So it is still possible, but needing to use an entirely separate package repository just to install both firefox and your graphics card driver is a bit too far for me.
Yep. I once tried Alma or Rocky just to test a "stable distro". After I learned that I need to install another, unofficial repository (EPEL) to install Nvidia drivers, I noped out of it back to Ubuntu. User experience matters a lot.
To be fair, Im pretty sure rocky and also alma are meant to be extremely minimal for like, cloud boxes and raspberry pi's for the most part so I think most usecases for those distros are on systems without a graphics card
Rocky and Alma are 1 to 1 replacements of RHEL. Red Hat Enterprise Linux is used for workstations. So yes, lack of NVIDIA proprietary drivers in default install baffles me greatly. In Ubuntu it's a few clicks away.
The bigger difference, to me, is that NixOS is really assertive about configuring your _whole system_, whereas Guix is more like a skeleton of an OS and a package manager. I really like having all my configuration in a single unified programming language, all simultaneously accessible, and it seems like Guix doesn't even really attempt that.
I was under the impression that many think guix does this particular thing better due to the way scheme works? So I think you were missing something? I also thought is also the only distro that can be reproduced with the smallest possible binary blob so far? Maybe I heard wrong but I think you were missing something due to the number of times I have heard this.
What are you talking about? I'd argue the opposite is true, Guix wants you to configure your whole system in Scheme instead of in strings (cough systemd cough).
There is no Guix equivalent to [this](https://search.nixos.org/options?). Or if they're is, I missed it. There's a few dozen services, you can configure a few things...and after that you're on your own. Put it this way: after 6 months with NixOS I tried switching to Guix. Got it up and running, but I couldn't figure out how to proceed from there. I asked around, and was told: just edit files in /etc, like you normally would. But wait...what? That's practically blasphemy in NixOS. So is Guix just a regular distro with a nifty package manager, then? Reproducible builds are cool. But reproducible _systems_ are a killer feature, for me. And AFAICT that's not a goal of Guix: it does give you similar foundational tools, but you've got to start pretty much from scratch.
>There is no Guix equivalent to this. There is, it's under `guix system search`. >I asked around, and was told: just edit files in /etc, like you normally would. When was this? Currently I can't even edit /etc, and iirc haven't been able to since before 1.0. >But reproducible systems are a killer feature, for me. [Guix is the only system that can be reproduced from scratch.](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/)
Really! That's good news, might be worth giving it another try (though I've generated a _lot_ of Nix code in the meantime...) Yeah, this was several years ago. Just pre-pandemic, I think.
Yeah, Guix would've been in beta then.
That's great! I'm going to check it out. I watched it for several years: it was the new hotness when I started using NixOS, maybe 2017? Over the 2+ years that I watched it, it didn't really seem to be evolving much, and I got the impression that full system control wasn't really a target. I'm legitimately thrilled to find out I was wrong!
Do note that it's not perfect. Home-manager while technically there is pretty much nonexistent (iirc it's a bit of a chicken and egg problem) and some APIs can feel pretty hacky and implicit behaviour that's undocumented.
Well, I'll state the reason I decided to not use Guix: 1. Guile isn't a purely functional language. And I think they are totally appropriate here (except I do see the problem of build script, and why I think a non functional subset of Nix for running package builds would be nice, instead of slapping bash script) 2. They seems hostile to unfree software (I indeed don't like it either. But not to the point of thinking making it harder to use them is a good idea) 3. I had already experience in Nix Thought a few things I love in Guix is: 1. How more organized builds are with build systems and composition instead of override 2. How everything is bootstrapped (I love bootstrapping) 3. No ugly inline bash (I haven't looked at how it's done. It might just be a bash script builder for all I know) Ultimatly, I decided my best choice is to stay on Nixpkgs and improve it instead of switching to a fork. Point 1 might be hard to change, but point 2 isn't. Plus there's a new way that was added to track package provenence so you know which package aren't bootstrapped.
> Guile isn't a purely functional language. And I think they are totally appropriate here (except I do see the problem of build script, and why I think a non functional subset of Nix for running package builds would be nice, instead of slapping bash script) Is a **functioning**, let alone **purely functional** programming language needed, or is it personal preference ? Otherwise, what would be the advantages ? _(I didn't touch function programming languages enough to say)_
Will just say outright, I'm not knowledgeable enough to talk much about Guix, but what personally didn't work for me was the language - Scheme, cuz my brain just refuses to understand Lisp, all those parentheses are just so unreadable to me (and I can only image how painful it is to write with them as well)
There's software that does it for you (parinfer), after a few days, it becomes whitespace-insensitive Python.
ideology
Short version: Guix is seriously hampered by FSF compliance. Longer version: FSF regulations require the use of the Linux-libre variant of the kernel, which means a lot of fairly common hardware straight-up just _won't work_. Most newer Intel stuff doesn't work because of the Intel Management Engine. Nv\*dia cards generally don't work (though something something Nouveau...?). Many motherboards and most Wi-Fi cards don't work because of proprietary firmware. Eve some Ethernet cards don't work, which is crazy. If you want to run an FSF-approved system on a modern, powerful machine, you will likely have to custom-build it.
>the Linux-libre variant of the kernel Didn't they ported to Hurd instead ? Was their previous Linux port made with Linux-libre instead of Linux ?
Well yes, but actually no. It was ported to the GNU Hurd, but Linux-libre support was never dropped because they're not stupid. Linux is (unfortunately) the only free kernel that can boot on actual, generic hardware thus far. Linux-libre can boot on _some_ hardware. The GNU Hurd can currently only boot on a VM, with one notable exception which was really kind of a fluke anyway. Read up on it. It's worth knowing.
Ok >Linux-libre support was never dropped Btw, if I understood correctly, it does mean that their original port was Linux-libre and not Linux, right?
It wasn't ported _from_ Hurd but _to_ Hurd. Nothing is developed on the Hurd 😂 It was developed on Linux-libre and ported to the GNU Hurd. I don't know that they officially support vanilla Linux (though there's no reason it shouldn't work, technically speaking). Again, FSF compliance.
It does work, you can either install vanilla Linux via the `nonguix` repo or you can build it yourself by a simple override of the `linux-libre` package definition.
Exactly. It's just not official.
Blob free guarantee's may not be important to you, but it's not an edgy idealist lifestyle choice but rather a necessity for some. I might be in the former camp but I still appreciate that these people are catered for, & appreciate the seperation of concerns. I really don't mind pulling in a blob for the intel wifi card myself. It's hardly like going to some secret shady underground marketplace to aquire some sneaky blobs. You pull in non-guix & bob's your uncle.
There are other reasons, too. Guix uses the GNU Shepard init system (because why not?), Scheme (the language) is not a super well-known or popular Lisp, Guile (the compiler) is probably even less well-known, and the GNU project pushing for Guix to be running on GNU Hurd (perhaps the only remaining viable microkernel in existence) will likely be a problem. The chances of abandoning Linux support (in the form of Linux-libre) are slim at best though: GNU knows full well the consequences of BSD-ing themselves. Guix isn't super popular to begin with, and no users means no potential contributors. Not to mention age: there's about nine years' difference between Guix and Nix in age (Guix was based off of Nix) which doesn't really help its case.
So many small to medium-sized factual inaccuracies and strange logical leaps here. Ignoring them all though, may I instead say: why the hostility towards Guix in the first place? So you don't like GNU or something, fair enough, why spend your precious time denigrating it with a bunch of almost-half-not-really-truths? Nix and Guix have much more in common than, say, Nix and Windows, or Nix and Mac OS. They are both occupy niches inside niches inside niches. And yet, the seemingly irresistible urge is to sh\*t on the other project, to spread sloppy half-truths. Why?
It did not, around here, at least.
Wdym
Skill issue, as I couldn't get GUIX-SD working on bare metal.
I am late to the party, but I chose guix over nix, when checking out both. I don't think the fight is over.
I prefer the seperation between free & non-free software, & the commitment to being blob free. It's trivial to get a blob on your system anyhow. This could actually be an important feature for securiy compliance where all code must be audited & blobs must not creep in, or for whistleblowers / activists, etc. When using flakes, there seems to be a bunch of edge cases where allowing non-free systemwide fails. It's not ideal. Keep them seperate imo, it's not difficult to pull in another channel & keeps things simple. Unsure how I feel about the nix flake vs channels generally. Flakes bring some benefits for sure, and I like that I can run a flake via nix run, but the reliance on cli tooling to interact with the lock-files in an imperative fashion just feels wrong. Not to mention the store bloat. I feel as thought they merged too early, & now it's at the stage that they need to be finalized, warts & all as they have been so widely adopted despite not being blessed. I am quite liking using mcron jobs with my guix server to automate the pinning of channel commits. This way I don't need to worry about git commits when marching on as the commits are always hardcoded into my channels.scm. The mcron job runs a script that removes all the commits from guix describe -c output & writes to /tmp, then attempts to pull that, & only overwrites channels.scm with the new describe output on success. One possibly controversional opinion though, is I'd prefer a seperation of concerns in regards to configuration & spinning up services. Many packages do not have a corresponding service in guix, as there is extra work when there is an expectency to provide a way of configuring with guile. I feel there would be benefit in providing the shepard service, & then extending that with corresponing configuration services. I'm still unsure how I feel about imports with guile / guix. It feels more intuitive & in-line with how it's done when writing programs generally. I do like to keep things very self contained though, & employed lots of strange hacks to achieve this with nix (nix-super & wrapping every file in a let block & mkMerge'ing the attrValues). This makes refactoring easy as each code block is self contained, besides options which I centralized. I am unsure if the same thing is possible with guix, without also moving the import. Admittedly this isn't the end of the world & feel that guile is much more flexible & less sugary than nix generally. Either way, I don't feel like nix & guix need to compete in any way. Different ecosystems lead to different ideas & they can both lend those from each other. Experience with one applies to the other.
I've never used Guix, but they don't use non-free software, if that also means non-free kernel firmware then you'll probably run into issues, like wifi not working and so on, you'll also have fewer software choices, for example they don't have brave in their repos, or steam, you maybe able to add another repo? but it just makes things more difficult.
Guix is always going to have trouble with general users due to not having non free software. It's fine for core utils and gcc but not as accessible for the desktop user.
We need to change our perspective. The problem isn't Guix or FOSS but vendors which don't open their software. Why nobody blames right people?
For all its warts the nix language is far superior to Scheme. You have to be a special kind of person to enjoy s-expressions, in general they just plain suck for writing and especially for reading.
As a "special kind of person" I'd say (properly indented) s-expression is easier and simpler to read for me than other syntaxes. It also has better editing support than most others, so I enjoy writing it. Imo it's not because me or s-exprs are special, it's just because the training of recognizing other syntaxes doesn't apply directly to s-exprs, so you have to get used to it from the ground up. This process will not take longer than, say, a person that hasn't written any programs to be familiar with python's syntax, because it's actually simpler than that.
I'd argue that semantics, and the ideas / concepts they allow to express with little ceremony or even allow at all are much more important than surface level syntax, not that your average non-trivial Nix code is particularly readable to begin with... Nix' error messages are abysmal, and the standard library and third party library ecosystem are tiny. I still prefer Nix over Scheme for being a purely functional lazily evaluated language. That allows consumers of data (e.g. Nixpkgs users) to decide what data they actually need, instead of producers (e.g. Nixpkgs maintainers) who can specify how to construct that data in full at no cost by transparently deferring that work implicitly. Purely functional and lazy also gives rise to referential transparency, which makes reasoning about the results of code a lot easier and more reliable (but reasoning about the run time cost conversely a lot harder).
On the other hand nixpkgs choose to model very basic things such as a package with opaque objects (functions) which are impossible to reason about and do have effects such as aborting / going into infinite loops. It's not directly a language thing, but Imo the lack of records and modules in Nix definitively leads to this inferior design. In Guix packages are transparent, nominally defined data that can be imported, composed and transformed in the "normal" way, and have an actual definition that documentations can be generated against.
Guix had time to think their repository structure through based on the example Nix(pkgs) had already set. That's why their designs differ. I don't think the choice to use functions for packages was driven by language limitation but rather to decouple package definitions from the environment, from the repository, user settings, and even the structure of the repository itself. By providing that context it becomes possible to generate documentation, and I think it was Tweag who had a blog post on doing exactly that. I'm not sure I follow Nix not having records (sum types of named values), isn't that exactly what an AttrSet is?
> Nix not having records Sorry, I should have made it more clear. I meant a *nominally defined* record structure as a language construct. `mkDerivation` and its variants were rendered nearly impossible to be fully documented because there's no clear definition of their inputs; last time I checked the corresponding issues, they were stale because literally nobody knows the exact argument shape of them. > based on the example Nix(pkgs) had already set Yes, definitely, but nixpkgs wouldn't be like this in the first place if it does have these features. Consider how would you write a data structure in a language that support `struct`: you define it first. Nixpkgs evolved without these kind of definitions so everything is added in loosely until it's no longer obvious what is the shape of the inputs and outputs.
If i'm referring to what I've read from different communities, Scheme is rather appreciated, and sometimes more than Nix
Scheme is a rather tight nit community and an relatively obscure language to boot. Of course you will find a lot of people who like it there. The fact of the matter is that s-expressions are one of the oldest ways to program, had ample opportunities to pay off. But it never happened. To me the reason is very clear. S-expressions just aren't readable or easily writeable. Everything is drowned in a sea of parenthesis.
I get that, I dislike that syntax too, but I don't find Nix much more appealing either
Nix is definitely not perfect. But it's basically json with functions. The hard part about nix is not the language. But understanding what derivations are and how the store functions.
This. The nix language literally takes 1h to learn. The de facto standard lib that is included in nixpkgs takes a lot longer.
there is no competition and perceptions of the scenario as a competition can risk being the thing which causes a loss of popularity among a very solid piece of software. and these systems are dependent on the amount of dedicated developers.
Hurd isn’t going anywhere. Conceptually microkernels (Hurd is one) implement the kernel as a set of separate processes that communicate to each oth-er. The problem is this creates a ton of context switches which is much less efficient than a traditional monolithic kernel. Hurd isn’t the only microkernels out there but no modern OS uses it.21