💾 Archived View for michal_atlas.srht.site › posts › 4c-dt-guix.gmi captured on 2024-08-31 at 12:19:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-02-05)
-=-=-=-=-=-=-
I should start by stating that my approach is very practical/pragmatic, I believe in much of what the FSF and GNU does, however, I don’t let this inconvenience me. Yes whenever there is a libre alternative then I’d personally go for it every time but I bought a laptop a long time ago, before knowing enough about compatiblity and not being able to use the inbuilt Wi-Fi card or a graphics card for example, teaches me nothing and I wouldn’t gain anything from wasting a good piece of existing hardware.
In that sense, for most people, enabling the NonGUIX channel and changing “linux-libre” to “linux” (yes it’s that simple to switch out the kernel) is not a dealbreaker by any means.
One of the other interesting things about Guix is how do you install other desktop environments?… and get them to appear in the login manager.
Yes, per-user package management is wonderful but it would be very dangerous, to let different users manipulate each other’s installed software or in extension through guix, aliases, the PATH variable, etc. So all the profiles have to be isolated, including the system-wide one that generates files that GDM reads since it is a system daemon this makes some sense, and while GDM could probably check each user’s home directory for session files, as far as I’ve been able to find, it doesn’t. So that explains the question why this has to be in the system config file and doesn’t work by normally installing it.
This is just not true, I try to not ever compile anything, unless I have to which is usually just cause it’s my own package on my channel and it doesn’t have substitutes. Substitutes are a huge part of what makes GUIX so great, you don’t have to compile packages yourself, because GNU does that centrally and then just publishes binaries, the binaries are secure in that you know it is what was you asked for and at any point you want you can just guix challenge the build server and build it yourself, to check if you and the server got to the same package. Since the way the package was built is also available though, you can at any point, just edit it however you like. This solves problems such as: “darn TES3MP requires Bullet to be built with double support, but my distro only publishes the float build”, for example. And very importantly, just allows you to add the software you need, no distro can package all the software, but it’s nice to be able to just write a quick package declaration and have it install just as if it was packaged, and you can even just publish it upstream afterwards.
The issue is, that the build on the build server takes some time, and guix pull always pulls down the newest commits, so if you manage to pull an update to something and try to install it before it can be built, then guix has no choice other than going to the source and building it itself.
There isn’t a magical solution as far as I know, other than using channel locks, which have more than one upside. I mostly only use:
guix pull && guix describe -f channels > channels.lock
nowadays, which pulls down the new channel versions to a file, then I let that file sit for a bit and after that, once everything is built the next day or so, you can go ahead and use guix time-travel -C channels.lock -- <any guix command> to just stay at that version until you feel the need to update again. It means any reconfigure will only make the changes you made to the configuration file and not version changes could’ve cause a problem if you encounter one. And it’s nice to run the same versions of software on all my machines.
That is just a copy of the one the installer generated, otherwise you can use any config file you want or even one you just clone from a completely different machine.
This is, very often unnecessary, there are many ways, functions and places in the config that can just take the package name as a string, so that is my preffered way of doing it. Since the package doesn’t need to be imported at all after that. Most services need configuration so those are probably always required.
If there is really a lot of additions then yes, otherwise just changing things in the config really does take maybe 10 seconds after you execute it.
DT’s really trying to approach this the wrong way, and it isn’t his fault, GUIX works very differently. It has many reasons to ditch the traditional FHS: There’s a man page for it hier[a]
Since all software is build and lives in /gnu/store it means that it can’t interfere thus it’s absolutely safe to use it as an additional package manager alongside any other, it’s so common that there is a word for it foreign distro.
This is a strange and big one, but GUIX really leans on the reproducibility and declaring all dependencies. Building the environment on a case-by-case basis really helps with the approach of.
run make, check what failed, install it, repeat
which happens a lot, even after you install all the listed dependencies. Having the system run this way, forces all the dependencies to be declared, which includes you though as well. When you want to compile something, you should write a quick manifest, which doesn’t have any boilerplate, basically you just write out the packages and libraries you use. After which you can run guix shell -m manifest.scm which drops you into an environment where those dependencies are visible to the compiler you’re using through the magic of environment variables. It’s also great that if you check this into VC then that same environment will be available wherever you need to hack on that project.
The build system of GUIX requires this and disconnects you from the internet, among other things which, might sound weird at first, but it seems at least to me to be a good idea to bring some law into the chaotic nature of building stuff nowadays and I provide you with an interesting read on the subject:
Then you can just copy the dwm package from the guix repo into your own channel, just change the name to dwm-dt or similar and the origin to your own repo and you’re done. Having a personal channel for these things is really comfy, and it even allows you to basically release updates for your own software, so that you code it up, push the change, and updating guix on the other computers will automatically pull the changes, no need for sudo make install. Which I find nowadays to be much neater, again, as all software this is subjective, but make install just seems so messy compared to getting the build handled by the package manager and just having it all clean in a separate directory, removeable at any point, without the risk of forgetting to delete something.
Strange, I didn’t have problems with that (back when I tried it), pip just default to a user install under your own bin if site isn’t writable.
Yep, steam is no problem, the package even sandboxes it nicely. As for Discord, flatpak works very nicely, no problems with those.
I personally used pip, cargo and chicken scheme’s package managers before I learnt how to use Guix for that. There aren’t any problems, 3 days is not enough to even try anything out on a distro DT, why are you making a video on it????? Alright, ofc, it’s content and he’s asking for advice, but the title of the video
GUIX Presents some GNU/Challenges
should not have that undertone then. But alright, cool video, I’m happy there’s talk of this system, it’s just a shame that there’s so much misunderstanding, maybe a motivation to change the new-user experience, which Guix doesn’t think about that much since it’s basically still deep alpha software as far as I’m aware. It really just feels like he didn’t read through the manual, although he did as he said, nevermind, I’ve ranted long enough.