make betterer
This commit is contained in:
parent
ae8de1ad55
commit
d362c2b81b
GPG key ID:
9FBC6FFD6D2DBF17
1 changed files with 168 additions and 60 deletions
|
|
@ -7,26 +7,81 @@ desc: I love GNU, but im tired of managing everything myself.
|
|||
I love GNU and all of the work they do, but If i have to work a full time job to
|
||||
use your software the way I want, its not feasible for me to use...
|
||||
|
||||
### GNU/Guix
|
||||
### Why GNU/Guix?
|
||||
|
||||
[Guix](https://guix.gnu.org) is a declarative linux distrobution developed by
|
||||
the GNU project. If you ever herd of glibc, coreutils, or GNU/Hurd, its that
|
||||
crowd. Guix's goal is to build declarative system that is fully libre: the
|
||||
primary goal of the GNU project and the free software foundation. This means
|
||||
running zero free software, no drm, no binary blobs, no strictly licensed
|
||||
code, and not even providing the option to the user to run proprietary software
|
||||
if they want. This is the GNU way.
|
||||
Throughout my time using Linux, I have hopped around many distributions. I
|
||||
started with Ubuntu, a commenly used Linux system. It is a preprepared Linux
|
||||
system, installing a windowing environment for you, a miltutude of system
|
||||
packages, and uses the `apt` package manager. I eventually switched to Manjaro
|
||||
as I found the `apt` package manager cumersome, and I wanted a leaner prebuilt
|
||||
system. Based on Arch, Manjaro uses the `pacman` package manager which I found
|
||||
to be alot faster and nicer to use. Manjaro still had a lot of packages
|
||||
preinstalled but I continued to use it for a few years, mainly throughout
|
||||
high school. When I got to college I wanted a system that I could build myself
|
||||
so I eventually switched to Arch Linux. As the base of Manjaro it shared many
|
||||
similarities but it allowed me to have more fine grain controll of what was on
|
||||
my computers.
|
||||
|
||||
#### Declarative systems
|
||||
#### Unsustainable state
|
||||
|
||||
A declarative system is built and can be fully reproduced from a single
|
||||
configuration. On my old guix system, I had a set of multiple guile scheme files,
|
||||
guix's configuration language of choice, that specified the entire system. What
|
||||
packages were installed, the users of the system with what groups they have, the
|
||||
bootloader, init system and the services it runs, and everything else is all
|
||||
contaiend in those scheme files.
|
||||
What Ubuntu, Manjaro, and Arch Linux all have in common is that they are statefull
|
||||
systems. Each of them have a predefined base system which can build ontop of
|
||||
manually. The problem that I faced was forgetting what changes have been made,
|
||||
what programs were installed (and why I installed them), and what
|
||||
configurations were applied. At times I like to cut down or trim my system,
|
||||
but I would find that I dont know what is installed, where its installed,
|
||||
and why I installed it.
|
||||
|
||||
For example, the following scheme defined the users that were on my systems.
|
||||
When trying to mirror my custom system on another device, things would never be
|
||||
exactly the same, and It was a hassle to try to mirror changes from one device
|
||||
to the other. I tried to use a [git repository](https://g.freya.cat/freya/dotfiles-arch)
|
||||
that stored some configurations and a list installed packages, but it never
|
||||
solved every edge case, and didn't allow me to have any differences between systems.
|
||||
|
||||
An example was that my laptop had a intel cpu and my desktop AMD, and my list
|
||||
of packages didnt allow me to have only amd microcode on my desktop and only intel
|
||||
microcode on my laptop. It was annoying to manage, and I wanted something else.
|
||||
|
||||
Another example for paru, an [AUR](https://aur.archlinux.org) package
|
||||
manager, I could not partially modify its config file. When I still was using
|
||||
Arch I wanted paru to use `doas` instead of `sudo`, which is a single line
|
||||
change in the config. Since paru stores all its configs in `/etc`, I would have
|
||||
to save the entire config file (and all its default settings) to save my one
|
||||
change. Unlike other programs I cannot just have custom per user overrides in
|
||||
my `~/.config`.
|
||||
|
||||
#### Being declarative
|
||||
|
||||
I found my solution in [GNU/Guix](https://guix.gnu.org), a declarative system
|
||||
developed by the GNU project. For those who don't know what a declarative system
|
||||
is, it's an environment where a declarative package manager, provided with a
|
||||
configuration, installs programs with their settings, installs and runs
|
||||
background services, provisions user accounts, and anything else needed by the
|
||||
system. If two machines are provided the same configuration, they will be
|
||||
exactly the same down to the programs installed, services, users, bootloader,
|
||||
etc. Another upside is that the configuration languages are commonly functional
|
||||
programming langauges, allowing the user to specify differences between systems
|
||||
but still share a common base.
|
||||
|
||||
Guix is developed by the GNU project and the Free Software Foundation. It uses
|
||||
[Guile](https://www.gnu.org/software/guile/) as its configuration language,
|
||||
[Shepherd](https://www.gnu.org/software/shepherd/) as its init system, and is
|
||||
fully libre. There is alot to love about Guix. Besides being declarative, Guile
|
||||
is a lisp dialect which I enjoy (functional programming for the win). Its init
|
||||
system is also configured in guile allowing the entire system (packages, users,
|
||||
configuration) along with the code to run services to all be in one place. Being
|
||||
libre has its downside that no binary blobs will be packaged (meaning no drivers),
|
||||
but there is a third-party repo called [nonguix](https://nonguix.org/) that
|
||||
solves this problem.
|
||||
|
||||
With Guix I was able to declare everything in two guile scheme modules, one for
|
||||
my system, and one for my home environment. In both I could specify system and
|
||||
user services, packages, and configuration. When applying my custom configuration,
|
||||
Guix will automatically install my desktop environment, wallpapers, my teminal,
|
||||
my neovim configuration, auto run script files, custom CA certificates,
|
||||
and everything else. With a single command I can easially clone my entire system!
|
||||
|
||||
As an example, the following scheme defined the users that were on my systems.
|
||||
```scheme
|
||||
(define freya-user-accounts
|
||||
(lambda (groups)
|
||||
|
|
@ -57,31 +112,72 @@ Packages can be defined...
|
|||
))))
|
||||
```
|
||||
|
||||
Guix also uses an inhouse init system called shepherd that defines services using
|
||||
guix configuration scheme files. Declarative systems are really cool. If I break
|
||||
something, I can easially fix it by rolling-back my system. I dont have to figure
|
||||
out what stuff in the system changed, and manually repair it. Since everything is
|
||||
defined by configuration, it be overwritten when I rebuild the system state.
|
||||
Another thing specific to guix I liked is that it uses guile as its
|
||||
configuration language. For these reasons and many more, I switched to guix over
|
||||
two years ago and stayed on it until recently. Recently I left guix, and this is
|
||||
why.
|
||||
Services can be defined...
|
||||
```scheme
|
||||
(define-public %freya-services
|
||||
(append
|
||||
;; append needed base services
|
||||
(list ; mtp
|
||||
(simple-service 'mtp udev-service-type (list libmtp))
|
||||
; polkit
|
||||
polkit-wheel-service
|
||||
; font config
|
||||
fontconfig-file-system-service
|
||||
; networking
|
||||
(service ntp-service-type)
|
||||
(service network-manager-service-type)
|
||||
(service wpa-supplicant-service-type)
|
||||
(service modem-manager-service-type)
|
||||
(service usb-modeswitch-service-type)
|
||||
; dbus
|
||||
(service upower-service-type)
|
||||
(service polkit-service-type)
|
||||
(service pam-limits-service-type)
|
||||
(service elogind-service-type)
|
||||
(service dbus-root-service-type)
|
||||
; openssh
|
||||
(service openssh-service-type
|
||||
(openssh-configuration
|
||||
(authorized-keys
|
||||
`(("freya" ,(local-file "../../files/keys/freya-ssh.pub"))
|
||||
("root" ,(local-file "../../files/keys/freya-ssh.pub"))))
|
||||
(permit-root-login #t)
|
||||
(allow-empty-passwords? #t)
|
||||
(password-authentication? #f)
|
||||
(public-key-authentication? #t)
|
||||
(x11-forwarding? #t)
|
||||
(allow-tcp-forwarding? #t))))
|
||||
;; append guix base services
|
||||
(modify-services %base-services
|
||||
(guix-service-type config =>
|
||||
(guix-configuration
|
||||
(inherit config)
|
||||
(substitute-urls
|
||||
(append (list "https://substitutes.nonguix.org"
|
||||
"https://substitutes.freya.cat")
|
||||
%default-substitute-urls))
|
||||
(authorized-keys
|
||||
(append (list (local-file "../../files/keys/nonguix.pub")
|
||||
(local-file "../../files/keys/sakura.pub"))
|
||||
%default-authorized-guix-keys)))))))
|
||||
```
|
||||
|
||||
### The problems
|
||||
### Not all grass was greener
|
||||
|
||||
So there was a lot great about Guix. I could have my entire system configured and
|
||||
deployed in one place. Guix is also libre supporting real free and open source
|
||||
projects. But I ran into a few issues, some that were quite major.
|
||||
|
||||
1. The Guix package manager is really slow
|
||||
|
||||
I have no gosh darn idea what the heck GNU was doing when they built guix, but
|
||||
their package manage is slooooow. Really slow. Snail slow. If I wanted to
|
||||
instantiate my configuration on a new system It could easially take one to two
|
||||
hours. HOURS.
|
||||
|
||||
Also, the guix package manager doesnt do TLS correctly. I don't
|
||||
know what why, but it every so often, especially when installing an entire system,
|
||||
it will crash and loose any builds or downloads it was in the middle of processing.
|
||||
Since the guix package manager is slow, it then takes a moment to start back up.
|
||||
In conclusion, when instantiating a new system, I have to start the installer
|
||||
multiple times, which adds to the hassle and install time.
|
||||
The guix package manager is used to redeploy the system, pull updates for
|
||||
the channels (guix's name for repositories), load the environment. It does
|
||||
everything and is core to the system. So what sucks about guix is how slow
|
||||
its package manager is. Just to pull down new changes from my guix channels,
|
||||
it could take at least a few minutes. Updating my system could sometimes take
|
||||
30min to an hour. Anything guix tried to do was slow, and it constantly
|
||||
redoes redundant work when completing multiple tasks in succession. This
|
||||
sucked because anytime I wanted to update my system I was filled with dread.
|
||||
|
||||
2. Very few packages
|
||||
|
||||
|
|
@ -108,13 +204,10 @@ GNU would tell you to get better friends and get a better computer.
|
|||
I'm sorry but im just not going to do that. Unlike other distrobutions that
|
||||
hide non-free software behind a flag, GNU just doesnt support it. At all. Nada.
|
||||
|
||||
There are people in the community that add support themselves in their own
|
||||
third-party repositories, but they can break. And even with those third-party
|
||||
repositories the software may still not be packaged. Even more If you want to
|
||||
package it yourself, guix's build system doesnt make it easy to package non free
|
||||
software. Guix does not provide the utilities to do it. There are third-party
|
||||
extensions to the build system that make it easier to package proprietary
|
||||
software, but its not official and provided by guix.
|
||||
I did mention earlier abou nonguix, a third-party repository, which packageseverything
|
||||
everything I just mentioned. Its really good, but I wasnt super comfortable
|
||||
relying on a super small team for a set of packages that I relied on daily.
|
||||
|
||||
|
||||
4. Documentation and Support
|
||||
|
||||
|
|
@ -128,30 +221,45 @@ luckier if the documentation was any good. With guix, the best place to figure
|
|||
how to use the system is IRC chat logs, mailing list archives, reading other
|
||||
peoples dotfiles, and reading the guix source code.
|
||||
|
||||
### NixOS (the solution)
|
||||
### NixOS
|
||||
|
||||
NixOS is another declarative system that is much older, more widly used, and
|
||||
better supported then GNU/Guix. Guix was even a hard-fork of Nix. The major
|
||||
two differences is that NixOS is configured using their inhouse nix language,
|
||||
which isnt great, and that NixOS uses systemd for their init system.
|
||||
better supported then GNU/Guix. In fact, guix is a hard-fork of Nix. The major
|
||||
two differences between nix and guix is how they are configured (the language
|
||||
used), and the init system. Unlike how guix uses guile and shepherd, nix uses
|
||||
nix (the language), and systemd.
|
||||
|
||||
Besides not being able to use lisp, and being forced to use systemd, there are
|
||||
many benifits to NixOS over Guix. Nix supports non-free software if you choose
|
||||
to use it. Nix has good documentation. Nix has packages for almost everything.
|
||||
And compared to guix, nix is really fast.
|
||||
For a while when using guix, I also used nix on the side for a few packages.
|
||||
Guix didn't have some packages I wanted such as firefox (non GNUd version),
|
||||
starship prompt, discord and element (they were broken using the guix packages),
|
||||
and rust (rust-analyzer was broken using the guix package). Guix and nix
|
||||
both support installing a home environment ontop of any distrobution, not just
|
||||
their own system environments. So for a while when using guix, I was already
|
||||
relying in nix for part of my setup. When using nix there were a few things
|
||||
I noticed. The package manager was way faster, an order of magnitude faster
|
||||
then guix's. Also there were alot more software that was packaged, and packaged
|
||||
properly. On guix I ran into software that sometimes was just broken, and thats
|
||||
probably just to the much smaller community and team working on and maintaining
|
||||
guix.
|
||||
|
||||
So I switched.
|
||||
So a thought appeared that I could not get out of my head for a while. If not is
|
||||
faster (solves problem #1), software is packaged and works (#2 & #3) why not switch?
|
||||
I pondered this for a while, but what really hit the nail in the coffin was nix's
|
||||
superior documentation. Nix has a much bigger community meaning that if I ran
|
||||
into an issue it would be alot easier to solve. I wasnt and am still not a
|
||||
super huge fan of systemd and the nix programming language (not the nix package
|
||||
manager), I pulled the lever and switched to NixOS.
|
||||
|
||||
#### My experience
|
||||
|
||||
Ive been on NixOS for a little over a month now, and I'm loving it much better.
|
||||
The nix language is kind weird, but I can live with it. I dont have to use
|
||||
third-party repositories just to get packages to get my system to boot. It
|
||||
takes minutes not hours to setup a system. Everything just works™.
|
||||
For about two months now I have been in nix. Its alot faster and quicker to use.
|
||||
Updates and pulling down changes are alot faster and efficient. It is quite rare
|
||||
for software to not be packaged. And nix also supports proprietary if you choose
|
||||
to use that. There is alot about guix that I love, but I ran into too many
|
||||
problems. I am able to have my declarative system with nix without the hassle
|
||||
of guix.
|
||||
|
||||
You can see my guix configuration [here](https://g.freya.cat/freya/dotfiles-guix)
|
||||
and my nix configuration [here](https://g.freya.cat/freya/dotfiles-nix). If you
|
||||
are trying to learn or switch to either system, you can use them as a good
|
||||
resource. You can also view the guix repository I created called [sakura](https://g.freya.cat/freya/sakura)
|
||||
when I had to package things. But if you need a recommendation to use either GUIX
|
||||
when I had to package things. If you need a recommendation to use either GUIX
|
||||
or NixOS, from someone who used Guix for two years, use Nix.
|
||||
|
|
|
|||
Loading…
Reference in a new issue