Perhaps my favourite feature of Guix is
guix shell
. It is one of those tools that I don’t know how to do without. Even if you are not ready to use Guix as a package manager (or distro),guix shell
alone might be a reason to have Guix installed.Why?
This article describes a really nifty feature of Guix.
Wow, yes as a linux developer this sounds all too familiar! I haven’t heard of guix before, but if it can solve these things…then I want it yesterday!
I read the only other article on the author’s blog… sounds like he needs to be cheered on.
https://gexp.no/blog/it-wasnt-for-nothing.html
I’ll have to play around with it before I get a good feeling for how well it works. So where is the download? If nothing else I’ll probably take inspiration from guix to improve my own dependency management processes as I find it to be one of the more annoying aspects of software development.
Keep in mind Guix is GNU, and as such it uses the Linux-libre kernel.
Yeah. The article didn’t make that clear at all, but here’s the obligatory missing link.
https://guix.gnu.org/
It seems to me a similar feature would be very useful on all linux distros used for development. While there’s a lot of overlap with centralized package managers, But developers frequently deal with a myriad of external dependencies from a myriad of sources. I for one have always found this frustrating. We kind of need a meta package manager that does NOT aim to be yet another package manager but instead works by sitting on top of others.
I’ve found containers to be really handy for this. The tooling is still ridiculously bad and nothing really works with them, but they show promise.
Toolbx, distrobox, or something custom with buildah+podman are the tools I’ve been using.
https://distrobox.privatedns.org/
https://containertoolbx.org/
https://buildah.io/
https://podman.io/
systemd-nspawn containers are also really cool, but less widely known. nspawn containers are probably the best user tool out of all the container technologies.
That’s kind of what PackageKit aims to be, but it’s flaky and incomplete.
Aside from that, I’d like something which could install packages into the user’s home dir.
Flatland_Spider,
Containers and the cgroups they’re built on are awesome! I had been using my own container implementation on linux for a while and it was great until systemd took over depending exclusive privileges for itself. Other process managers are expected to give up control and become subordinate to systemd even when they’re running as root. It’s like the borg. While I give Poettering credit for his contributions, he deserves a ton of blame personally for systematic power grabs that render alternatives less viable.
https://lwn.net/Articles/676831/
I suspect it may be intentional on his part; making things harder for alternatives may be good for him personally, but it’s bad for FOSS in general IMHO.
Anyway I know you didn’t sign up for this debate, sorry! I agree with you that containers are awesome. The isolation really helps with the kitchen sink syndrome. Dependency management still needs work though and that is why this Guix piqued my interest
Alfman,
It was intentional. systemd was built to be tied closely to the Linux kernel, and part of that was systemd was given control of cgroups.
That decision was made because of oddities in how the Linux kernel handles PIDs. I think it has something to do with reuse or wraparound of PIDs. I don’t remember exactly. It was a random post on the Fediverse.
systemd being responsible for cgroups and containers is not one of my gripes. I’d rather systemd be responsible for them then Docker.
Most of my gripes revolve around networking. They’re slowly getting solved, but they should have been obvious on day 1.
Yeah, actually I wouldnt mind systemd if it could be treated as equal. Systemd should function under other process managers and other process managers should function under systemd such thst there is no preferencial treatment either way. The ideal process manager should not assume or care whether it is pid 1. Lennart was in a great position to use his influence to make things right and it would have gone a long way in addressing/avoiding conflict. Systemd could have complimented other tools instead of fighting with them and Linux and BSDs could be better off for that.
While I stll think we’re better of for having replaced sysvinit, there were missed opportunities to better follow the unix principals. We ended up with a monolithic system, which runs counter to the unix philosophy of simple tools working together.
Alfman,
Side track.
For a second I thought you were referring to Borg, the cluster manager:
https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/
Which is actually a pretty neat piece of software.
sukru,
Ha! Never heard of it but yea sounds kind of neat. I figure every big company needs something like it to manage large clusters.
Alfman,
Think of it as the successor to Kubernetes. Much older and much more complex.
Can’t exactly say how long it has been around, but here is a master thesis describing a tool that works on GCL files, from 2008: https://pure.tue.nl/ws/portalfiles/portal/46927079/638953-1.pdf
Btw, I have never seen a master thesis with blacked out sections.
And, yes, unlike simpler YAML, BCL/GCL has a lambda function, and hence is turing complete.
@Flatland_Spider
That’s the Guix System OS you are referring to.
The article is discussing the Guix package manager. Which can be installed on any GNU/Linux OS.
https://guix.gnu.org/en/download/
Zayn,
Cool. Yeah I found the link later but it should be in the blog too!
I may try to test this on linux when I get some time
I didn’t realize they could be separated. That’s cool.
That’s cool. That’s kind of my workflow with Distrobox, Toolbx, or Buildah+Podman, depending on what I need.
Guix is interesting, and so is Nix, which it’s based on. It will be super interesting to see the GNU Herd kernel Guix option.
How is it better, different, worse than nix package manager that can be used independent from nixos?
Different: It uses Guile instead of the Nix DSL.
Better, Worse: I’m not sure.
My understanding is that guix started as a fork of nix, therefore they share quite a lot of similarities in design and features. Or at least did so initially.
Better or worse depends on the user, but let me list a few things:
– guix is a GNU project and a free software distribution, so they don’t support any non-free software. They don’t use systemd either. – NixOS is more “pragmatic”, it has things like spotify or steam in the repositories.
– Nix uses the Nix DSL instead of Guile Scheme. Guile is probably the better language.
– nixpkgs has more manpower, but probably also a larger scope
– nix(pkgs) probably has more corporate backing
disclosure: I’m a nixpkgs committer and have never really used Guix much