> Big fan of Guix, though I've only tested it in VMs, via Vagrant[1], for lack of disposable hardware.
Slightly off-topic but this is why I really enjoy NixOS currently, and I'm assuming you can have a similar setup with Guix as the principles seems to be the same more or less, but different implementation.
So the first time I tried Nix I did it in VMs as well. Found it worked out great for me, so I just copied all my configuration files to my laptop after installing NixOS, and now I had a identical copy running both on my desktop in VM and on my laptop "on metal". Great onboarding setup that doesn't waste anyone's time by having to do everything twice, and you get to play around with something you can keep afterwards.
Modelling a desktop OS after reproducible builds is just so nice. Wanna try out a new desktop manager? Just install it, change everything and when you want to go back, simply rollback and everything is back to normal.
Will it avoid the following issues? Will it know if it should keep/delete/regenerate file manager indexes for each DE for install or uninstall? How will it roll back the app launcher icons, which is shared by all DEs? Each DE inserts stuff like system monitor, settings etc. Will it be possible to install/remove Firefox integration with KDE and Gnome, which is currently packaged by distro? Firefox by itself can disable/remove that extension too. If the OS needs Python, can we upgrade Python via PPA so that OS won't use an untested Python?
I'm no expert but I'll try my best to answer your questions.
> Will it know if it should keep/delete/regenerate file manager indexes for each DE for install or uninstall?
Yes
> How will it roll back the app launcher icons, which is shared by all DEs?
If they are shared, they won't be rollbacked as they are used by other DEs.
> Each DE inserts stuff like system monitor, settings etc.
Yes?
> Will it be possible to install/remove Firefox integration with KDE and Gnome, which is currently packaged by distro?
Possibly, as long as the install is proper, it'll rollback everything it did to install it.
> If the OS needs Python, can we upgrade Python via PPA so that OS won't use an untested Python?
No, PPA is for Ubuntu so it's not relevant here. You'd install Python from NixPKGs, and each tool would declare which version it needs, and you'll have all versions installed locally and each program pointed to the version they need. If you need a different version for a local project, just that local project will use that version.
Overall, I'm mainly using AwesomeWM as my window manager. But some weeks/months ago, I wanted to try the full KDE setup. First I tried this on my Arch setup (big mistake) and I still have stray files and things from KDE that I can't seem to figure out how to remove when I wanted to go back.
But, did the same thing on NixOS (from AwesomeWM -> KDE -> AwesomeWM) and I had nothing left from KDE when I went back, as I rolled back the entire system to before it even knew about KDE. Pleasure to try out new DE/WMs now.
> Will it know if it should keep/delete/regenerate file manager indexes for each DE for install or uninstall?
No
> How will it roll back the app launcher icons, which is shared by all DEs? Each DE inserts stuff like system monitor, settings etc.
Application resources like .desktop files and icons are aggregated into _profiles_ via symlinking from the packages, and each state your profile has ever been in is stored as a _generation_. For example:
Guix rolls back application icons the same way it rolls back the applications: your Guix profile's symlink gets rolled back to an earlier generation.
When a desktop environment picks up on that change will depend on how it watches its XDG paths and updates its caches. Afaik Guix (and Nix) don't currently do anything to manage the state of those caches, but logging out and logging back in will suffice. On Plasma, I sometimes run `kbuildsycoca5 --noincremental` to manually refresh my icon and .desktop definition caches.
> Will it be possible to install/remove Firefox integration with KDE and Gnome, which is currently packaged by distro?
WebExtensions and native messaging hosts are packaged in Guix. I wouldn't install them with Guix for use by your base system's browser package, even though that will most likely work. Instead, I'd tell Guix to install both, or to install a browser configured to use whatever extensions.
If you install a browser via Guix, it will not see the extensions that your base system has installed into /usr/share or wherever.
I'm not sure if Guix currently has a package for Plasma's browser integration, but Nix does. In that case, by default it happens to be off, but it is easy to toggle. Whether that integration is enabled is considered a property of your Firefox package, but switching to a new Firefox package where you've changed that option (and perhaps others) doesn't require rebuilding Firefox. So in a word, yes, I think it does solve that problem.
> Firefox by itself can disable/remove that extension too.
This happens at the level of configuration files in your home directory, stuff under `~/.mozilla/firefox/...`. Managing such files is not part of Guix package installation or removal, so Guix won't affect that functionality one way or the other. (There are optional Guix-based tools that you can use to manage such files if you choose, though.)
> If the OS needs Python, can we upgrade Python via PPA so that OS won't use an untested Python?
It's not clear to me what it means for an OS to need Python in this context.
If you're using Guix on a ‘foreign distro’, Python installations managed by Guix will ignore all of the base system's Python packages, and the base distro will pull in its own copies of Python and Python libraries to satisfy the dependencies of its packages according to its own package management system. Guix makes no difference here.
If you're asking about GuixSD, the Guix-based operating system, the OS itself doesn't need you to supply anything external to it— there is no installable package or service in GuixSD that depends on Python which will look for and pick up whatever `python` executable it finds on the PATH. Packages and services that need Python come bundled with their own Python environments, which are fixed as part of the definition of the package or service.
If you're talking about GuixSD and by ‘the OS needs Python’, you mean ‘I want a Python installation and environment to be available to all users system-wide so that anyone can invoke it at the command line with `python` and write scripts that use it when invoked with a `#!/usr/bin/env python` shebang’: yes, it is easy to install a copy of Python which is newer or otherwise different from those included in the default package collection.
If the most recent version of a given package included with Guix is not recent enough for you, you probably don't need to resort to adding an entire third-party package repository to install a more recent one on your system. However, Guix does support third-party package repositories and if one provided a version of Python that you liked, you could install it system-wide.
I'm a NixOS user and seriously considering at least trying out GuixSD.
Does GuixSD come with Plasma desktop and other KDE assortments? My lazy google-fu is failing me, and the installer video does not list is as option.
I also have an Nvidia Optimus laptop so I assume I'll be using nonguix repo and building non free kernel, but that can be tolerated. If anyone uses nonguix kernel/nvidia, can you please tell me how long of build times I should be expecting? I have an i5 8th gen.
Guix is one of the most important software projects today. It can be bootstrapped from an auditable 357-byte binary seed [0]. No other package manager can claim that. It is also a unifying force for much of the GNU ecosystem.
That is very cool. I hadn't seen this update on the stage0 project. Didn't realize he got a working example all the way down to the hex monitor already!
I really would like to see a Gentoo equivalent based on Lisp/Scheme, but as far Guix seems to be not even near. I just looked for no-multilib option (only 64bit of libc), custom compile flags or similar, but didn't find anything.
If you wanted one based on Scheme, I'd actually just point straight at Guix. In our communities we often consider Nix/Guix an improvement on Gentoo in most possible ways, so wanting a Gentoo sounds odd like wanting to downgrade from Rust to C (I should probably nuance this view)... Yes there's no global no-multilib flag, so you have to put in some legwork to get the equivalent, but frankly you have to ask why you want that in the first place in a paradigm where none of your programs share libraries anyway. Indeed USE flags as a concept feel superseded.
You can get pretty far by defining custom variants of packages and using "package-input-rewriting"[0]. There is also work underway to support "parameterized" packages akin to USE flags.
It is fairly easy to run a "forked" Guix channel if you want customization on a lower level (say, using '-march=native' everywhere), but I suppose that's a far cry from just editing /etc/make.conf.
1) Are these kind of systems overkill for the desktop user?
2) How easy is it to customize/tweak these systems in the manner that Gentoo does? So, building from source by tweaking the software options on build time?
1. There might be slightly more convenience for the desktop user because installing applications in their user environment doesn't require root permission. You can set the system to a full Gnome with it's networking/wifi configuration if you like that sort of thing, but understandably it's less popular and minimalism is en vogue.
2. There is no global equivalent to Gentoo's USE flags, however most derivations follow conventions and expose comparable options with sensible defaults. These are largely easy to override. You usually lose the benefit of the large cache of binary builds so the culture of micromanaging all the options is not as prominent as in Gentoo. E.g. removing X11 support because you're not using it on a server might result in the need to locally build a lot of packages, some of them slow, and hence most don't bother with this level of "optimization."
The single configuration file and rebuilding the whole system with one command (that actually runs quickly and is easily rolled back) is what caused me to finally leave Gentoo behind. I had way too much manual intervention with an almost vanilla Gentoo configuration when performing upgrades (e.g. newer profiles, but sometimes just a package update). I'm not sure if NixOS is resilient enough to allow such things as system-wide ABI changes (such as the last Gentoo profile bump) but I suspect it is, and it's mission is to provide a seamless user experience when rebuilding. Should a rebuild fail, it's not activated so you're not stuck with a partially working environment.
Gentoo (actually Funtoo) was the last distribution I used on my main laptop before switching to NixOS. (I have tried Guix, but not GuixSD, so won't talk about it.)
> 1) Are these kind of systems overkill for the desktop user?
There is more to learn to be free to do everything — for some this might be too much (even though it is easy to start and the learning is mostly gradual), for others this is fine (especially those viewing the obstacles as opportunities to learn rather than distractions), and many others can be satisfied with their systems before achieving such freedom. While efficient usage of NixOS requires more upfront involvement, once settled or learned it becomes the easiest to maintain, and brings the piece of mind I had with no other OS with its easy global configuration, nondestructive updates, and manageable malleability (adding and customizing packages, effortlessly offloading their build to your other machines with Nix, even without NixOS).
> 2) How easy is it to customize/tweak these systems in the manner that Gentoo does? So, building from source by tweaking the software options on build time?
Nixpkgs have close to optimal balance between the ability to use prebuilt packages and the ability to extend them, and it's more customizable (thanks to Nix and Nixpkgs designed to allow reaching into the old definition of a package, writing tweaks just for the parts you need, while keeping automatic updates!), although it's geared towards users that want most of their packages prebuilt (in particular it does not have cross-cutting USE-flags). You can either replace a package (and cause dependent ones to be rebuilt against it), or override under a new name (and install it alongside other packages that may depend upon and actually use the non-overridden one).
I think many (most?) Guix System users are desktop users. Having transactional upgrades and rollbacks, downgrade prevention, and secure updates is great whether you're a desktop user, a developer, or a server admin.
Some software will require a lot of patching because they hardcode locations or has some non-deterministic build process.
Other than that you will have to deal with a non-conventional language for which you may need to look at the manual when making changes depending on how much you use nix-shell.
I use nixos on a laptop. You have to watch space usage here to clean old generations.
Check out my Nix configuration repo; I manage a desktop, two laptops and a home server with it. The pkgs directory contains all my customized packages.
* 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
Many 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-transaction...
The 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 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.
> 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.
A system like Guix will have at least a magnitude more private manifests.
Form personal shell scripts and environment configs, over team development environments to custom software. Non of that can be upstreamed. Plus the proprietary software, which also can't be upstreamed.
I concur that not having a stable format is a potentially problematic design decision, not a benefit.
Can you explain again why it'd have more private manifests? I'm not that familiar with Nix, but don't you use scripts, configs and environments all the same?
As 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
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.
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.
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!
It's not just Nix lang it replaces, we use Scheme in place of a hodgepodge of languages (shell script, Nix, C and others). Almost all equivalents to C-hardcoded parts of Nix is inspectable and modifiable in Guix. There's code reuse across the stack. Even the systemd substitute is opened up for inspection and modification. Nix glues a lot of black boxes; Guix is a single white box. Both approaches are practical for different reasons.
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.
> 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.
> 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.
> 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.
Risking 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) so if you want to share a new opinion on the subject, make sure it hasn't already been said :)
> 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.
This 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.
> 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.
I 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?)
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.
I 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.
Guix has nothing to do with systemd, GuixSD does. — the two are distinct.
There is no reason why Guix can't be used to install systemd, but the software runs contrary to the GuixSD philosophy, in that it wants as much as possible to be an interpreter whose internals are hackable.
Again I don't think that's a correct assessment, Guix actually does have some overlap with systemd because they decided to put some containerization things there. In Nix, this would be delegated to systemd.
I also wouldn't say that that runs contrary to the GuixSD philosophy, as there are a lot of packages in Guix that are written in C and C++ and other compiled languages, and I don't believe they plan to replace them. Maybe I'm wrong about that? At some point it might be interesting to have a Lisp/Scheme-only distro. Of course the kernel would still pose a problem there.
>Opportunistic use of neighboring substitute servers is entirely safe, thanks to reproducible builds.
How does this work? Just because the builds are reproducible doesn't mean that the artifacts published by substitute servers are actually the outputs of the build process you expect.
But that SHA hash of the built artifact doesn't go in the package recipe. So how do I know what the SHA hash of the built artifact should be, if all I have is the Guix repo?
I can always rebuild the artifacts myself using "challenge", but that defeats the purpose of using the substitute server...
It means that if a server on your LAN advertises a substitute for a derivation that is bit-identical with one that is signed by an authorized substitute server (such as ci.guix.gnu.org), the build output will be downloaded from your network neighbor instead of over the internet.
Of course this requires that ci.guix.gnu.org has already built the same derivation.
It opens the door for more peer-to-peer distribution in the future.
Imagine if every Guix system published their builds (as an opt-out setting). Then even if you modify a package's build options, a few other people might have made the exact same modification and you can download the built artifact from them.
Sure, but what's the likelihood they're all compromised? Let's say 3 people have to build it (and publish the hash) before your client will download from one of them.
Just as a warning if you're considering Guix for server use: Switching generations (e.g., rolling back a system update) requires rebooting to take effect.
"Rolling forward" aka 'guix system reconfigure' can typically be done without a reboot (but you need to restart affected services manually -- Guix will tell you which).
"Rolling backward" aka 'guix system roll-back' is not as integrated IIRC and is easiest with a reboot. You can however "roll forward" to a previous generation (in this example generation 117):
cd /var/guix/profiles/system-117-link
guix time-machine -C channels.scm -- reconfigure configuration.scm
Why does anyone wants a Gui installer? It's a real question, not trolling. For example i would never use the Gui-Debian installer, instead i use the expert-text installer it's faster and not at all "expert'ish".
I am very comfortable on CLI, and will always prefer it over GUI for most tasks, but for OS installations, GUI is vastly superior. From the get go, if installer loads with GUI, you know that you likely won't see black screen on first boot. All the drives can be easily formatted (I always multi-boot) and there is no mental translation of how much space is used in which drive under what layout.
These 2 are my primary reasons. Apart from that, if something goes wrong during setup, GUI installer almost always comes with full browser available right there for looking IP errors, eliminating need for second device. With CLI installers, there usually isn't a DE included. (NixOS disk comes with full DE option, but CLI installer, making it a hybrid, not sure about GuixSD)
Except with NixOS the whole point is system configuration in one file. Assuming you're comfortable getting on a network and partitioning a disk, there's not much need for a GUI.
At work, with multiple machines with little difference, an experienced admin will just clone or fork a Git repository, format a full disk, and run the installation command.
I think most people would call a dialog driven installer running in a tty a GUI installer. They just don't want to be dumped into bash and told to set up GRUB on their own.
Alpine's installer is the best IMO: you get a GUI style wizard but it's contained in a set of shell scripts (setup-*) so if you need it again you can run it yourself.
OpenBSD is another goodie. Answer a number of prompts and then it installs and configs stuff in one go (no more prompts midway through or afterwards). Plus you can "preload" your answers by referring to a file, good if you admin many machines.
A gui installer would be fun, but an installation process that fixed all the weird quirks (like with LANG settings) by default would also go a long way to making it more approachable.
Guix installer was the first time I experienced the info documentation available "side-by-side" with the CLI (that is, `info` was already open on a separate tty). So obvious in retrospect. Gentoo is another nice installer but much clumsier as they make you actually connect to gentoo.org with `links` to find the installation guide (when you may not have the internet working).
Its usability by non-specialists can be improved (and is, release by release) but the concept is very promising for reproducible systems.
[1]: https://github.com/OverkillGuy/jibyconf/blob/master/GUIXSD_V...