Trying out the Guix distro
- Anmelden oder Registrieren um Kommentare zu schreiben
I've been enjoying the guix package manager on Trisquel and on Hyperbola recently, and decided to fill my 3rd partition with the Guix distro instead of Parabola.
Here's the first screenshot. I'll write up some thoughts on the installation process, which was not the easiest or most intuitive installation. However, it's running very well after installation. I'll use it for awhile and see if I would recommend it to others.
| Anhang | Größe |
|---|---|
| guix1.jpg | 70.14 KB |
I am a translator!
The recent question on the Guix help mailing list to install Guix System in a logical volume is from me. Based on the received advice, I'll try when I have time (probably not before Christmas).
I've found guix in general to be download-hell. I never imagined needing to download packages to remove a package, but it happens on guix.
One of my requirements is that I can have a fully offline repository. Debian-based systems work really nicely for this, but on Guix this seems impossible. Maybe if you do enough `guix packs` you can string together something. As an aside, this is where snap is better than flatpak, with snap you can perform `snap download` on all the packages you need. With flatpak you can try `flatpak --create-usb`, but I never had any luck with that.
>"One of my requirements is that I can have a fully offline repository."
I've never desired to have offline repos. Sounds intriguing though.
As a command line package manager, guix is very nice with some incredible rollback features. It doesn't seem any more bloated than flatpak from what I've seen so far. Guix downloads lots of smaller packages as dependencies, whereas flatpak downloads monstrously large runtimes. Two different approaches, but neither one should be pointing a finger at the other and screaming "bloat!"
Snap is proprietary from my understanding, which means I have no interest in it.
You are right, I prefer guix to flatpak/snap (you can use guix to package things into debs, dockers, whatever, it seems to me guix is thinking big whereas flatpak/snap was just trying to bypass packaging things for distros).
I found guix's command line system also way more sensible than Nix's (guix install package vs nix-env --install package for one example).
I'm under the understanding snap is free software, but the snapcraft repository code is not. If my understanding is correct, there being no other snap repo, a FSDG distro could include snap, modify it to remove access to the snapcraft repo, and create a mirror of snap/assert files for users to download (this is similar to the Mozilla addon repo problem).
Sounds good. Having never used Ubuntu or Mint other than a momentary trial, I know next to nothing about snap. If someone wants to make a libre repo, I think that would be a good thing for Trisquel users to have access to.
I believe the snap server side is nonfree (and not released to the public).
I'm going to write down a few steps that I take as I try a manual install of the Guix distro. I've succeeded at installing via the graphical installer, but it hijacks the grub for the entire hard drive, and I have it on a drive with partitions for Trisquel and Hyperbola as well. I prefer to have Trisquel's grub handling the boot chores. Therefore, time to try a manual install.
1. First off, getting networking to work on this manual installer via the command line is a bit of a hassle, so I've found a workaround. Guix is one of the very few live installers I've tried (really the only one) where you can switch back and forth between the manual and the graphical installer at will, and use the good features of each one. I start in manual install mode, which simply gives me a command line. The rfkill package on this installer has killed my wifi device for some reason, but if I enter the following command it springs back to life:
rfkill unblock all
At this point, I want to go back to the graphic installer, because signing into my home wifi is much easier from there. I hit the Alt-F2 key combo, which brings me to a tty where the Guix installation manual is automatically laid out. Then, when I hit the Alt-F1 key combo to go back to the installer, it will ask me if I want to go into the manual or graphical installer. I choose graphical. After entering a few things like my language, keyboard layout, and entering a host name, I come to the networking part of the graphical installer. It asks if it should scan for wifi connections, I say yes. It finds my home wifi and allows me to sign in. Sometimes I have to tell it to keep signing into the same wifi 2 or 3 times before it grabs a good connection. Once that's done the installer asks me for a root password and a username and password, and then starts offering an "Exit" button at the bottom of the screen. I hit "Exit", and then "Abort" on the next screen, and then I'm back to the beginning where it's asking me if I want to use the manual installer or the graphical one. I choose the manual installer this time.
2. Partitioning. I pre-partitioned my Guix partition as btrfs. I found from an earlier error that corrupted one installation of Guix I did that the ext4 file system, which is the Guix installer default, fills up all available inode space very quickly, and makes the hard drive unusable. This is apparently because the way Guix works is it copies a huge number of small files to the hard drive, and apparently ext4 uses up inodes to accomodate all those small files. I don't understand the technology of inodes enough to explain further, but the advice I found in a Guix bug report on the same issue was to use the btrfs file system instead, and that it doesn't use up the inodes at all. That's what I'm doing.
3. Mount the hard drive partition. For me, this is as follows - any other installer will need to study the output from the 'lsblk' and the 'blkid' commands to determine which hard drive partition they are mounting:
mount /dev/sda3 /mnt
4. Start something called "cow-store". This is a Guix installer command, apparently it makes the area where the packages are stored copy-on-write so the data is written to disk instead of written to the Live USB's memory:
herd start cow-store /mnt
5. Make adjustments to the config file. Copy over the example config file from the Live USB, and go through it and make changes, such as to where Grub should be installed:
mkdir /mnt/etc
cp /etc/configuration/desktop.scm /mnt/etc/config.scm
nano /mnt/etc/config.scm
I had to make a bunch of guesses based on the installer guide document on what my config file entries should look like. I don't know if this will work correctly the first time.
6. Then install the system:
guix system init /mnt/etc/config.scm /mnt
Going to try it now, I'll report if success or (probably) failure this time.
EDIT: Aaaaand - it failed. No surprise. My config file caused a few errors I was able to fix, but ultimately my config file references to my partition were too far away from what the install program was looking for. I'm going to need to re-partition a bit, re-do my setup and config file, and try again.
I am a translator!
Thanks for the guide.
Someone raised a "running out of inode" issue on the Guix help mailing list 2 weeks ago. Out of the 5 answers, 3 say "I am using btrfs and there is no problem" and 2 say "you can increase the number of inodes manually". So the conclusion I would draw is indeed "use btrfs rather than ext4" but that is not in the manual.
I initially thought Guix System should be easier to install and use than Parabola, perhaps I was wrong.
The main problem with inodes was I had only given the distro about 50GB of space on the last partition on an otherwise full hard drive. The inode solutions that I found in my brief search involved expanding the partition size, which I could not do. However, once I switched to btrfs, 'df -i' was showing 0% inode space in use. So definitely btrfs would appear to be the superior solution.
I am a translator!
Here is a copy of the message:
About 17 packages in, I started getting a "No space left on device" error; looking closer at it, – while I still had ~20% of free disk space available – I was fresh out of free inodes. I remembered that someone I'd read, somewhere, had said you'd probably want, at least, 50G for Guix so I figured I probably shot myself in the foot with so small a root and just opted to reinstall. This time, I deleted the home partition and the root one to create one 156G partition for the entire install and figured that'd be sufficient (I've been using ext4 for these, in case that information is relevant, any). This time, though, I managed 21 packages before running into the same issue. There's still 70% of the disk space free but I'm entirely out of free inodes; leastwise, I was but I tried a guix gc, just to see what all got freed up, and, now, I have 5% of all inodes free.
So it is not only a problem of partition size.
I really like the idea of Guix. Being able to have multiple versions of a package installed is nice, and functional programming languages are cool. It seems a lot more flexible than traditional package managers.
When I tried Guix on an existing system, "guix pull" (the equivalent of apt update if I understand correctly) was really slow. Is that still the case, or has it gotten better?
Yes, this is a verrrry slow method of package management. I feel like it's 2001 and I'm on dialup again. Like watching paint dry.
That slowness is one of several reasons why this is not a distro I would be able to use daily. I'll post more about the negatives later.
On the positive side, once you get everything installed and updated, it is a nice responsive distro on the desktop.
I am a translator!
I also use Guix as a package manager over Trisquel (and now also over Debian on my desktop, due to serious problems with Trisquel) and I can confirm it is very slow. About "multiple versions of a package installed", does that refer to different users having their own profile or something else?
I installed it via the graphical installer this time, and gave Guix its own entire hard drive, which it seems to want pretty badly. It's working out pretty nicely now. I'm using btrfs for the / partition, and I gave it a small fat32 partition at the front of the disk, as it seems to want that for grub. I don't think it's able to put grub on a btrfs partition.
I did the partitioning with Trisquel prior to starting the Guix installer. The Guix installer's partitioning tool doesn't work most of the time.
So this is an unexpected surprise - Guix has flatpak in the repo. Here's the flatpak version of LibreOffice running on Guix.
Guix also has Nix itself. It does not however have Snap since Snap requires systemd and Guix uses shepherd. I don't think there's any work being done to enable snap.
Between Guix, flatpak, and Nix a user should be able to nearly all the software they need (I can't recall if it also has docker, it might). Unfortunately due to throwing out the FHS if it's not in one of those three it can be a real pain.
I found that AppImages don't work by default. At least the couple that I tried.
- Anmelden oder Registrieren um Kommentare zu schreiben