Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/foo-dogsquared/guixsd-config

My NixOS-config-inspired GuixSD config.
https://github.com/foo-dogsquared/guixsd-config

Last synced: 3 months ago
JSON representation

My NixOS-config-inspired GuixSD config.

Awesome Lists containing this project

README 

          
= foo-dogsquared's GuixSD config

:toc:



This is my config on my https://guix.gnu.org/[GuixSD] installation.

Similar to my https://github.com/foo-dogsquared/nixos-config[NixOS configuration], it provides a quick way for me to install GuixSD very quickly with all of the settings intact (for 99% of the time) which is the advantages of using NixOS and GuixSD.



== Getting started



Before you can get this setup, there are some prerequisites to do:



* You've decided for a https://guix.gnu.org/manual/en/html_node/Manual-Installation.html[manual installation] and already in a shell.



* The partitions are already setup and mounted in `/mnt/` as the root.



* Installed git or any other package (e.g., udisks2 if you have it in an external hard drive, ssh if it's on a remote computer) that can get the files.

footnote:[You can install it with `guix package -i $PKG`.]



* Have http://www.gnu.org/software/make/[GNU Make] (or whatever build system compatible with it) already installed.



Setting up consists of cloning this repo (i.e., `git clone $GIT_URL`) somewhere in your filesystem preferably in `/etc/guixsd-config` and `make install`.



Take note that the setup has separate configurations for the system (i.e., link:./hosts/[`./hosts/`]) and the user (i.e., link:./manifests/[`./manifests/`]).



== Project structure



The current setup should have the following folder structure:



[source, tree]

----

guixsd-config

├── config/

├── hosts/

├── manifests/

├── modules/

├── packages/

└── README.adoc

----



* link:./config/[`./config/`] is the cluster-wide footnote:[When I say 'cluster-wide', I mean throughout all of my machines from a desktop (which I have only one) and laptops (which I have none).] ad-hoc configuration of the programs I often use.

In this case, it will be my https://github.com/foo-dogsquared/dotfiles[dotfiles].



* link:./hosts/[`./hosts/`] is the system configuration for each of my machines with each of their name listed as a directory.

For more information, see the <> section.



* link:./modules/[`./modules/`] is where particular modules (e.g., metapackages) are stored.

They are primarily used by the `./manifests/` folder for user configuration.



* link:./manifests/[`./manifests/`] contains https://guix.gnu.org/cookbook/en/html_node/Guix-Profiles-in-Practice.html[individual profiles] and https://guix.gnu.org/cookbook/en/html_node/Basic-setup-with-manifests.html[manifests] for user-level declarative configuration of their local system (e.g., Guix packages, third-party channels).



* In the future, custom https://guix.gnu.org/manual/en/html_node/Services.html[services] may be stored under link:./services/[`./services/`] where it can contain certain services that are convenient to have (e.g., Recoll indexing, Unison backup).



== Hosts



In link:./hosts/[`./hosts/`], it contains the configuration of each machine stored in their individual folder (with their name as the directory name).

It is intended to be copied on the appropriate place (at `/etc/config.scm`) but you could choose to just configure it anywhere else.



The configuration should strictly contain system-wide configuration and system-exclusive user configurations (e.g., guest users, helper accounts).

User-specific configurations that can be found on other systems should go to the link:./manifests/[`./manifests/`] folder.



For best practice, each host on `./hosts/$HOST` should follow the following folder structure:



[source, tree]

----

./hosts/$HOST

├── config/

├── manifests/

├── modules/

├── config.scm

└── README.adoc

----



This folder structure is inspired from this very setup.

The difference is it is solely for system-specific stuff: `config/` for system-specific ad-hoc configurations, `manifests/` for system-specific users profiles, and so forth.

It should also have a `config.scm` file that contains the full system configuration similar to `/etc/config.scm` from your first installation (the guided graphical one, anyway).



For accessibility and self-reminder, it is recommended to create a README file.

It could be written in any format with any file extension.

In my case, I have README written in https://asciidoctor.org/[Asciidoctor] with the `.adoc` file extension.



== Modules



link:./modules/[`./modules/`] contains the modules which are primarily metapackages (a package of a list of package) intended for easy toggling when configured with the https://guix.gnu.org/cookbook/en/html_node/Basic-setup-with-manifests.html[manifests].



=== Workflow



Since my modules setup is a bit customized for my needs, I'll try to explain it quickly.

Here's the current project structure of the configuration (as of 2020-09-02):



[source, tree]

----

guixsd-config/modules

├── desktop.scm

├── dev.scm

├── editors.scm

├── shell.scm

└── _utils.scm

----



If you've already taken a peek on the main modules (e.g., `desktop.scm`, `dev.scm`), they are all defined with `create-pkg-interface` procedure.

It is a procedure defined from `modules/_utils.scm`.



.Example of using `create-pkg-interface` for creating a package module

[source, guile]

----

; modules/games.scm

(define-module (modules games)

  #:use-modules (gnu packages)

  #:use-modules ((modules _utils) #:prefix utils:

                                  #:select (create-pkg-interface)))



(create-pkg-interface

  pkgs-games

  '(

     (default . ("0ad"

                 "battle-for-wesnoth"

                 "endless-sky"

                 "openmw"

                 "openrc"))

     (proprietary . ("lutris"

                     "playonlinux"

                     "steam"))))

----



The above code listing will produce a exported procedure like the following:



[source, guile]

----

(define*-public

  (pkgs-games #:key (allow '()))

  (

    ; The unimportant implementation...

    ; It will just create a list of names of the packages based from the allowlist of branches.

  ))

----



Which on a manifest, you can use it like this:



[source, guile]

----

; manifests/sample.scm

(define-module (manifests sample)

  #:use-modules (gnu packages)

  #:use-modules (guix profiles)

  #:use-modules ((modules games) #:prefix games:))



(specifications->manifest

  (append

    ; Muh games.

    (games:pkgs-games

      #:allow (list 'default 'proprietary))



    ; Your additional packages that are not added to the modules.

    '("neovim"

      "lf"

      "minetest"

    )))

----



== Why GuixSD?



Guix has a lot of good stuff a power user may look for.

Here are the following features I find very attractive:



* Declarative configurations which enables easier reproducibility.

The community behind Guix also happens to focus for https://reproducible-builds.org/[reproducible] and http://bootstrappable.org/[bootstrappable] builds which is interesting for me, at least.



* Offers a transparent binary/source installation process.

If a package is not available as a binary, it will just build the package for you instead.

The best thing about it, it's optional with just a simple toggle option (`guix package -i $PACKAGE --fallback`).



* Straightforward packaging process in case you didn't find the package you're looking for.

This one is a must (in my opinion) if you want to make an independent Linux distro from scratch.

You can either contribute to the https://guix.gnu.org/en/packages/[official package archive] or https://www.gnu.org/software/guix/manual/en/html_node/Channels.html[create one yourself].



* Available options include rollback, letting you switch to previous configurations.

This is useful for emergency situations where your current configuration doesn't work and rework your config.

Theoretically, you would have a difficult time screwing your system up.

footnote:[Practically, I don't know much but I imagine it would be "easy" especially for an idiot like me.

We'll just have to see.]

You could also go all the way back to your first installation provided you didn't garbage-collected your system yet.



* It's a strictly https://www.gnu.org/distros/free-non-gnu-distros.html[free distro] with the ability to add your own proprietary stuff.

As far as I know, there's no mechanism in Guix that prevents you from adding them.

That alone makes it a true free distro for me: the freedom to add your own garbage. footnote:[;p]



=== Want to learn about Guix?



You might've heard about Guix (which is probably you're here).

Here are the stuff I've look for resources:



* https://guix.gnu.org/manual/[The official manual] serves as a pretty good introduction to Guix (which it should be good).

It contains a bunch of information from installation process to the conceptual overview to anything Guix-related.



* https://guix.gnu.org/cookbook/[The Guix cookbook] is a great practical introduction on what to do next after the installation process.



* The community behind Guix is pretty great and welcoming to newcomers.

You can go to the IRC chat at `#guix` channel on irc.freenode.net to give them a visit.



* https://gitlab.com/pjotrp/guix-notes[Pjotr Prins' notes on GNU Guix] is a set of great document on the subject.

It is pretty detailed so take as much as you want, revisit stuff, and glance at the possibilities of the distro.



* I also applied (READ: currently applying) the same practical approach from the https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs[Nixology video series].

Explore with the Guix



For other concepts such as channels, you can look at the official manual.

Or just search through websites such as GitHub, GitLab, and the like.

I found https://notabug.org/wigust/guix-wigust/[fairly active Guix channel] as a good example.



About my experiences learning Guix, I cannot accurately say anything since it is pretty close to Nix.

I would say since there's a lot of overlaps with Nix, it is almost seamless.



I've encountered fewer (but more major at times) problems compared to Nix and here's an exhaustive list of them:



* Hardware compatibility is one of the major problems.

I'm able to install GuixSD on bare metal without any scratches but for extra peripherals like WiFi adapters, it is not possible unless you've used a https://gitlab.com/nonguix/nonguix[non-free Guix channel that has it available].



* Package count is far fewer compared to https://github.com/NixOS/nixpkgs[nixpkgs].

It's no surprise since Guix is a younger project appeared a decade after Nix.

Compared to other packaging process footnote:[My experience on packaging is very limited, I've only created a handful of packages for Arch Build System but then again, it's only takes copy-pasting it.], Guix offers a straightforward packaging process that can help Guix pick up the steam in increasing the package count.



* Only strictly free and open source stuff (FOSS) are applied.

Again, not a surprise since it is a GNU project.

Speaking of which, not all FOSS are there for various reasons (e.g., Firefox is not included since it contains copyrighted material).

To get around it, you can create your channel composed of packages that will never get accepted upstream.

footnote:[There's already one at https://gitlab.com/nonguix/nonguix if you want to get ahead.]



* Learning https://www.gnu.org/software/guile/[GNU Guile] which is strictly not a requirement but it is a must if you want to go beyond configuring your system in a simple fashion.

I would put this at the far end when put it in a tier list of problems.



* Speaking of GNU Guile, there is a certain lack of missing details in the documentation especially if you're familiar with the basic ropes of Guix.

For example, there's not much of an introduction to packaging aside from using importers which is the easy way out (in my opinion).

What about if the package requires a bit of an intervention with the shell?

What is the equivalent of moving files, copying files, substituting words for a quick patch?

Those sort of stuff.

It has the opposite problem of https://nixos.org[Nix] documentation where the introductory documentation sucks.

What I'm saying is: it has strong beginner's documentation but lacking technical details for the familiar which may end up having a more frustrations.

At least with the Nix documentation problem, it is already there outright, leading you to devise solutions from the get-go and a lot of the community tries to improve the situation.

Meanwhile with Guix documentation problem, you'll be initially invested with the good starting documentation and having to scour for the rest if ever you find yourself needing for a solution.

footnote:[Nonetheless, I recommend getting in touch with a community these days which can alleviate most problems like these.]



* The underlying development infrastructure sucks.



** The https://guix.gnu.org[website is nice] and all but then you get into the workflow inside of the project.

I get the technical merits of using a mailing list (e.g., doesn't require much internet connection, only requires an email address which every developer has, requires less moderation, requires only one interface [email client] to manage) but there's not much saying if the mailing list looks like a 90s website and can be unfamiliar to most newcomers.

footnote:[They say don't judge a book by its cover but most people however base a website by its appearance.]

Simply prettifying it can go leaps and bounds into improving the user experience.



** The https://debbugs.gnu.org[issue tracker] is a pain to use and has the same 90s aesthetic which isn't the best interface.

Even with the https://issues.guix.info[prettified version], it is not much of an improvement since the searching mechanics seems to not work correctly but it is still great for reading the issues.

Speaking of the issue tracker, it is also slow at times although this may be due to my location.

Even at the best times, it can take at least an hour to get an issue ticket resulting in a slow pace of contribution.

(Personally, I don't see it as a problem since my pace is already slow anyways but I can see this as a problem for others.)



** The way to contribute is with patches (really?) which is unfamiliar to most newcomers, thus, will have lower participation rate.

Most FOSS contributors are familiar with pull requests due to popular platforms like GitHub, Gitlab, and so on.

I have my gripes with patch-based workflows but the core problem I have with patches is how it make contributions not easy to replicate by others (except the maintainers who know what they're doing 99% of the time).

footnote:[Or maybe I'm just an idiot who cannot see the merits of a patch-based workflow.

I think this is a generational thing and as part of the newer generation, can anyone tell me why patch-based workflows is a good thing?

There must be a reason Sourcehut uses it, right?]

It's already hard to use the issue tracker but with this, it attracts even less new contributors.

I really hope the team behind Guix will move in to pull requests once they have gained enough steam or something something divine intervention.



Compared to Nix, the community behind Guix has written great documentation with their https://guix.gnu.org/blog/[blog], https://guix.gnu.org/manual/en[manual], and the https://guix.gnu.org/cookbook/[cookbook].

The graphical installation helps a ton with providing you to get familiar with GuixSD.

Simple things like those do add up to the experience and I'm loving it.