@codesections I've tried guix on top of Fedora, failed to install it by hand and installed package instead. I tried packaging stuff a little but did not succeed.
Derivations computation is fairly heavy but otherwise it's really nice
> but otherwise it's really nice
What did you like about it? A lot of people I respect like it a lot, but I'm having trouble wrapping my head around the advantages. Is it just being able to roll back to a previous state, or is there more that I'm missing?
@codesections you can have any combination of any packages in any version. If you do development it's invaluable to have dependencies not spread thin across the system but confined in environment.
Plus everything is built in "sterile" conditions and you can build too and challenge your substitution server (assuming you use one).
> If you do development it's invaluable to have dependencies not spread thin across the system but confined in environment.
Right, but isn't that what `cargo.toml`, `package.json`, or whatever are for? Put differently, many (most?) programming languages have a way to have local dependencies managed on a per-project basis, right? Or is there more to this that I'm missing?
> challenge your substitution server
I'm not sure I follow what that means, sorry.
@codesections yes, that's like that but more powerful.
Even with language-level package managers you often need native deps, like here:
It's so much nicer when there's definition which can get it from your system *or* get exactly the version needed.
Okay, sorry. By default Guix is set up to build everything on its own. You can use substitution server you trust to download packages instead. There's an option to build on your own to check the server.
Thanks, that's starting to make sense :D
By the way, I saw your pinned toot about @ing before following you—mind if I follow you? You seem interesting and nice
@codesections not at all, you're also nice and interesting, feel free to follow and thanks for asking.
> I was sold on guix the moment I read that you could have a per-process environment and try out a package without installing it… now I use Nix every day, and probably run nix-shell (or my wrapper "nix-environment" which has a "guix environment --ad-hoc"-like syntax) to temporarily set up an environment every day.
I'm slightly confused. Do you use GuixSD or NixOS? Or neither but use Guix as a package manager on a different distro?
@codesections I'm trying GuixSD out, it's pretty cool, definitely worth a shot. They indeed seem to be serious about having a relatively stable system by 1.0 and actually reaching that in a reasonable time. IMHO it's the best packaging model Linux has.
However. There are quite a few buggy packages.
What do you like about it? The `functional packagae managment` sounds really cool in theory, but I haven't run into a situation where I'd need that (knock on wood). Are there other advantages to the package management that come up if you *don't* break your system?
And how about hacking the system in Guile? I keep seeing that touted as a pro, but haven't wrapped my head around what that makes possible.
@codesections I haven't yet had a chance to use Guile, but being able to boot into previous system configs saved my ass once already. You can sort of do similar things with ZFS/BTRFS snapshots on traditional distros but in GuixSD it's integrated from the start. I also plan to export my system and user profiles into Git so that I can more easily reproduce the system, in case of things like hardware failures, or just wanting to have a VM with the same packages.
@codesections (actually, i'm not sure they're called profiles. basically i wanna put /etc/config.scm and the files that describe what packages are installed into a git repo. i think they might be called manifests. idk.)
@codesections The biggest problem for me is speed and RAM. Haskell packages need a lot of RAM to build. Also, AFAIK sometimes things are needlessly rebuilt.
This leads to system upgrades that are much slower than what I am used to on Arch, but once Guix will have more package mirrors and build servers (they have like, one?) that will probably change for the better.
> boot into previous system configs saved my ass once already.
Yeah, I get that as a big advantage. I guess it's just hard to get *excited* about it, since I've never run into breakage. Maybe when my beard is a bit grayer I'll be more appropriately paranoid ¯\_(ツ)_/¯
But if I'm going through the effort to distro hop, it's a lot more enticing to have $COOL_NEW_FEATURE than the ability to recover if things break. The later is insurance, and it's hard to get excited for insurance
@codesections You don't actually need to distro-hop though, if you just want to try out Guix. I have it installed on Arch, although I haven't really used it much, since I already have all the necessary packages from the Arch repos and the AUR.
guix environment is something I want to try soon, which is usually described as "python's virtualenv but for every language/build system/framework/whatever"
Hi! I'm a #guix contributor and some of the cool things about it are the ability to have a central declarative configuration for your whole system, the fact that you can install incompatible software (for instance if they require a different version of some dependency), the per-user profiles (and more, but with no nice UI), the reproducibility and the temporary environment (à la pypi, but much better). Feel free to ask more about these 😁
Thanks for chiming in!
> install incompatible software
That does sound handy (though I haven't run into a problem personally)
> per-user profiles
Am I right that this isn't that useful for a single-user desktop? Or does it have advantages for non-natural-person users (e.g., running git or a db as their own user)?
> temporary environment
What does that let you do on a system level? I haven't used pypi, but I have used nvm/rvm, which sound similar
Per-user profiles let you be organised. If you use the guix system, you get a system profile for everyone, but you'll have to reconfigure the whole system to change it. Then you can install stuf in root's profile that only root needs, and your usual software in your user's profile. User (and root) profile can be updated "statefully" with verbs like install or remove, or "statelessly" with a manifest, in both cases in a transactional manner.
Temporary environments are really interesting for developpers. They allow you to create an environment where all your dev tools are installed. This is like virtualenv, npm or opan but with a general package manager, so you can have environments for a web project, a C project or a java project. You can also have an environment for a project that uses multiple languages. That is usually hard to manage, because other PMs tend to have side-effects.
> You can also have an environment for a project that uses multiple languages
Oh, that *is* a really interesting use case. I can see how that would be really handy for e.g., Mastodon development since Mastodon is built with Ruby, Node, and more—it'd be great to have a single "Mastodon" environment that sets up the right environments for all the respective languages.
@roptat @codesections I noticed that Guix uses symlinks and environment variables a lot and I've been wondering, has the Plan 9 approach of using per-process namespaces and union file systems been considered? since the 90's Plan 9 has been doing things like guix environment by just overlaying different things into /bin (eg. the ape/psh command that drops you into a POSIX environment) but it lacks a concept of packages and operates purely on files and directories.
I'de actually had the same kind of idea and explored that on an #lfs system. I used AUFS to overlay different packages on top of /bin for instance, and namespaces after overlaying dependencies to build packages in a temp dir. But that approach is less "pure": packages could reference things in /bin that they never were built with, so they can suddenly break or behave differently because of the context. It's much easier to control env vars.
That's a bit sad 😕
Even if you don't install the full system, you can still install guix on parabola (what we call a foreign distro). There's even a script to do the install for you, it couldn't be simpler 😉
Some people are working on a better installer to get rid of tge painful manual steps, so I hope you'll try it when we release 1.0!
@codesections I’m using it everyday; before that I was using NixOS (technologically pretty much the same thing as Guix System).
Today I cannot imagine working on a system which is not declarative, immutable and reproducible.
(Alas sometimes I need to do that to manage OpenWRT router and Mediatek-based Debian NAS—every update on those makes me nervous xD).
@codesections not less, but not afraid *at all*. I can freely experiment, develop, fiddle with kernel modules and so on cuz I know I can always boot into a working profile.
Plus immutabil-, reproducibil- and declarativ-ity results in pros like
• I can use multiple version of a program, for example install every Firefox since 42 and see how a web page looks on them. After that I can garbage collect them and my system is like new cuz every dependency is tracked. No leftovers. System stays clean.
• I can define a reproducible environment for each project. So e.g. I can compile (w/o any issues, whenever I want) my TexLive documents. Even those I created many years ago.
• Installing my OS on a new hardware takes literally 5 mins cuz everything is declared in a file. No more searching for imperative commands like… how the hell did I configure NFS on Arch in the past? What commands did I use?
• I can install software with conflicting deps. On Arch/Debian sometimes installing one package breaks another one. On Nix/Guix that doesn’t occur.
• I can define profiles with ‘different OSes’ and switch between them e.g. a headless mode and a Wayland session and a penetration testing profile.
Everything can exist a once and do not pollute/break each other.
Those were pros from top of my head.
The most important thing: if what you currently use works for you then don’t switch.
It's worth noting that pacman warns you about dependencies breaking your packages and that PKGBUILDs support things like 'provides' which help even further.
On Nix, some standard #Linux software requires modifications i.e. I remember rustup being broken for quite a while there.
Now, the isolation is nice, it's just worth pointing out that, like everything, it's not purely benefits vs everything else.
Declarativity, immutability and reproducibility have a price—more compilation, more upfront work during packaging, breaking implicit assumptions (standards ;) like FHS, ‘binaries-from-the-Interentz’ don’t work out-of-the-box (though that could be a good thing too), we need to learn new things,and more.
I’m happy to pay that price but I must repeat:if your current system works for you then stick to it!
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.