"ma questo pacchetto, è FISICAMENTE un PACCHETTO, o no?"

...io mentre chiedo ad @alephoto85 di spiegarmi "cose" sull'informatica mentre installiamo GuixSD.

#linux #linuxIta #unixIta #guixsystem #guufIta #corradoguzzanti #guzzanti

https://www.youtube.com/watch?v=Mo0qlLkbe5w

So #GuixSystem (i.e., the OS) has a service to provide a build VM to sandbox the #Guix build process, and this made me think, it could be handy to provide a service for creating #Trisquel or #Parabola VMs as a base, effectively extending the Guix functionality set with the Debian & Arch Linux package archives

@jas @josch

Have not tested booting #GuixSystem yet, but... probably?

That is my near-term goal, anyways...

This is the end of this experiment with #Guix and #GuixSystem

I really like the ideas behind Guix, and learned a lot by reading its documentation and playing with it. But I will put it back on a shelf for now, because what I need is a system for daily use which gets out of the way. At my current skill level with it, and in its current state, we're not quite there yet.

I'm keeping my configuration files and a fresh installation iso, so I can get going more quickly next time I feel like trying it again.

After a few days of testing, it turns out #FedoraSilverblue is going to fit the bill nicely. It shares some ideas with Guix (immutability, rollbacks, in general better isolation between OS and apps), and everything I need seems to be available and working out of the box.
It's running smoothly on this 10-year old Intel Nuc, so will also be fine on a 10-year old MacBook Pro (with slightly higher specs) whenever I'm ready to make the switch.

This other thread is what prompted me to try and find a more future-proof OS: https://fediscience.org/@Guillawme/113152436757689301

First time I have time to play with #Guix and #GuixSystem since the previous post... The spring semester is getting very busy very fast, leaving little time for this experiment.

Today `guix pull` really made the computer break a sweat, big time. This is telling me that, as cool as Guix is, and as much as I like the ideas it embodies, maybe I am not quite yet ready to make it my main OS. On the other hand, with today's update several CLI apps I was missing are now available. Really cool to see more things entering the package collection!

I still want to contribute some package definitions, but at the current rates at which I learn and guix improves, these might well be contributed by others by the time I figure out how to make them build* or how to send my contributions**.

*: with some I got stuck, see for example https://codeberg.org/guix-science/guix-science/issues/64

**: I wish the main guix channel was on a forge like Codeberg, it would be so much easier to contribute.

A bit frustrated with #Guix and #GuixSystem lately... Can't get 'emacs --daemon' to work reliably. I have a shepherd user service that starts and stops cleanly. But 'emacsclient' can never bring up a graphical window despite being run from a graphical session.

But somewhat surprisingly, setting up a wifi printer was easier than I expected. Seeing the CUPS printer test page made my evening yesterday! (small things, eh?). I still need to move this to the system configuration file, since this initial test was done through the CUPS web interface.
The scanner on this same device worked with zero configuration, over the wifi too. Getting this to work was one of the main potential roadblocks to ditching macOS. I don't scan or print often, but when I need to it's for important things. And it's too inconvenient to scramble to find a scanner/printer at work or at a library, so it's got to work at home.

Lately I've had less free time to play with #Guix and #GuixSystem (no longer on vacation), so I haven't written to this thread. Recent progress is like two steps forward, one back. Still progress.

I made my configuration files public here: https://codeberg.org/Guillawme/guix-config
It's a work in progress. If something is obviously wrong I'd like to know, so don't hesitate to tell me, whoever is reading this.

Thanks to Guix I resurrected my old #Emacs config, and it's been very fun!
I started it in June 2015 while procrastinating on my PhD thesis... which I wrote more efficiently, of course, once I had an Emacs config I liked. 🙃 I abandoned it in 2019 to switch to doom-emacs. Doom never felt like home, it's somebody else's config after all. It also looks too much like an operating system. I quit doom when it started doing native compilation of elisp files by default: each update would make the computer break a sweat. At this point I also had "config burn-out" (not bankruptcy, it was still manageable, but I was tired of it). Some parts of Emacs never worked well on a Mac, which made it frustrating. I settled on helix, which is excellent! I love its approach of "good defaults" and "everything built-in".

Now I realize how much the Emacs experience is better in GuixSystem. Certain things are still a pain to set up (emacs --daemon, anyone?), but I am hopeful that once done it will function forever thanks to Guix.

My adventures on #GuixSystem: I have learned two lessons in the last few days:
(1) Don't use ext4 for your root drive in #Guix - you will run out of inodes. That is a bad thing, and has required me learn how to properly use btrfs with subvols etc. This necessitated several attempts to make a working install! Then:
(2) Don't put /tmp on tmpfs, even with 32Gb of memory. If you have any complexity in your setup, you will run out of space before the build completes. This is also bad. Remounting /tmp elsewhere doesn't seem to be possible, or at least easy. I made a very simple configuration which did build, but wouldn't boot. Earlier generations also didn't boot. So now I am going through the install process yet again.
To be clear - this is OK - it's a test machine, a learning opportunity, and I have time. There are some odd things in the installation process I don't understand, so I want to clarify these as well.
I think I might make it an #hpr episode when I finally know enough!

Every time I use #guix I am blown away by how much better the CLI and #guile is than Nix. Hoping I can daily #GuixSystem over NixOS soon…

Configuring #GuixSystem reminds me of configuring #Emacs, and not only because of the lisp parenthesis soup*.

The similarity goes deeper than the configuration syntax. They both make me constantly question whether I should pin down and declare every last bit of configuration explicitly, or only customize what I need and implicitly use the defaults for everything else. Sometimes I find it very difficult to resolve this tension. But I will try to remain pragmatic and only customize what I need. I need a working system more than a perfect system. And I want to spend more time using said system than configuring it (even though it is pretty fun to run reconfigure commands and see new things right away! it's good to use small hardware that makes these reconfigure operations long and noisy, otherwise I could play with this all night...).

*: Said with all due respect! I actually find this notation convenient when indented/formatted nicely, which Emacs does very well of course.

So, as I learn more about #Guix and #GuixSystem, I started to read other people's configurations. This is helpful because it puts the snippets from the documentation in context, and it is easier to see the big picture this way.

But some of the configurations I read are much more than customization from the code provided by the documentation. They look more like full programs, organized in modules, with their own custom syntax, etc. So I started reading the documentation of #Guile, to understand the code I'm reading a bit better.

The most helpful read so far is the style guide linked from the Guix documentation. It explains some naming conventions like the names ending with a question mark, a star, etc. I had somewhat guessed from context what these symbols mean, but it's helpful to find these naming conventions explained somewhere.

One convention that remains unexplained is the % sign in front of some variable names like %base-services, %desktop-services, %default-channels, etc. The trend seems to be that the % sign denotes system-wide defaults. Is this correct? Or does % indicate something else?

I don't remember what state my #GuixSystem was in exactly when I first tried to connect to it by ssh the first time and it didn't work. But after a full update, a reconfigure, and a reboot, it works fine. Still can't seem to get X11 forwarding to function, but I suspect this is a problem on the Mac laptop's side (it used to work though... will have to look into this).

Now I am mostly done with the system configuration (maybe some minor tweaks will be necessary as I make progress reading the documentation) and started porting my home configuration to 'guix home'. Figuring out how it works with 'guix home container', I can already tell I will like it a lot!

Enabling Bluetooth in #GuixSystem is so far one of the lowest hanging fruits, with simple power management: each of these features is only one line in the config.scm file and a ‘guix system reconfigure’ away.
Nice to now have wireless options for sound on this computer (speaker, headphones).
File transfer over Bluetooth will be a bit more complex it seems, but hopefully it’s only a matter of finding an app that does it.

After going somewhat in circles yesterday, some faster progress today: #GuixSystem can now use the Intel wifi card on this computer. It only took one ‘guix system reconfigure’ this time, possibly because I made sure I didn’t run ‘guix pull’ beforehand (if I understand correctly how #Guix functions, not running pull means it keeps currently installed versions of packages already present in the current system that the next system needs). And it definitely used substitutes automatically: no way it would have completed this fast if it had needed to compile a kernel.

It will be nice to no longer have this cable running across the room between the router and computer, catching things in between. 🍝

Next steps: configure Bluetooth so I can use a wireless speaker, configure sshd so I can do system tweaks and maintenance remotely from the laptop.

Some more progress configuring my #GuixSystem: yesterday night I managed to add nonguix as a system-wide channel with substitutes. But it took three attempts at ‘guix system reconfigure’ before it completed. The first time I forgot that it wouldn’t use the substitutes unless explicitly told so, so I cancelled and restarted it. The second time for some reason it still needed to build webkitgtk and this is no fun on a small computer… so I cancelled it after a long time of 100% CPU usage with very slow progress, and was about to give up after this one. Tried it once more with ‘--dry-run’ out of curiosity, which showed that finally it was going to download everything pre-built, so I ran it again and it only built 3 derivations and eventually completed.
I don’t understand why ‘system reconfigure’ updated channels every time (which triggered many derivation builds), I thought only ‘pull’ should do that (I did run pull first, but not before the other two attempts). So I probably need to read some sections of the #Guix documentation again.

Little progress last weekend... A successful installation, only after messing around with the installer until I realized I should use the generated config.scm as-is (attempts at customization at this stage trip up the installer), run `guix pull` and `guix system reconfigure` immediately after the first boot, then reboot, so I start with a current system. Only then can I customize with any chance of success.
Did that, but forgot to setup FDE. 🙃 So here we go again tonight!

#Guix #GuixSystem

Progress today: I managed to setup the NUC’s UEFI to boot from removable media by default. This makes it much easier: if the bootable media is in, it boots; no need to press a function key to enter the boot menu.

I also tested that the #GuixSystem installer I made boots correctly on the NUC.

Still baby steps for now, mostly because I can’t carve out enough uninterrupted free time for the bigger steps. In the meantime, I’m reading about #Guix. The more I read, the more I find it amazing. 🤩

Trying to find how to enter the NUC’s boot menu, I first found this help page: https://www.intel.com/content/www/us/en/support/articles/000005847/intel-nuc.html
Which led me to this one: https://www.intel.com/content/www/us/en/support/articles/000089801/intel-nuc.html
The trick to bypass the NUC’s “fast boot”: start it with a long press (3 s) on the power button instead of a simple press. Doing so, I got to a menu and realized that the keyboard I use sends function keys only if I also press the Fn key. So maybe this also works during the regular boot, will check this next.

Soon ready to install #GuixSystem!

The iso produced by `guix system image`, on a USB stick, gives a functioning installer. My laptop could boot from it. But not the Intel NUC mini-computer: for some reason, hitting the suggested key during startup doesn’t enter the boot menu, so Ubuntu boots. Will need to figure this out before I can install #GuixSystem on the NUC.

In the meantime I’ll familiarize myself with #Guix installed on Ubuntu. The documentation sometimes seems to assume Guix System, so some things remain unclear to me.

Found a second-hand Intel-NUC from 2015 with decent specs, barely used. So I jumped on this opportunity to test #Guix and #GuixSystem!

(Tried before in a VM, it works but isn't as exciting. And not ready to change OS on the laptop I use daily.)

Poor little computer broke a sweat upon `guix pull` (from 1.4.0 to current), and now again with `guix system image` (generating an installation iso). I will try to `guix pull` frequently so each is a lighter operation.

Very excited to try `guix home`!