11–20 of 69 posts
Always interesting to see an older article come back around. I could probably update this a bit for 2026 but my workflow is just about the same now as it was then. Guix is good and just released 1.5.0, check it out.
Honestly I'm just glad that this declarative approach is steadily being realized. It hasn't hit mainstream adoption yet, but it gives me hope that this headline is making the rounds. Docker is, as the article describes, just a bandaid and the symptom of unthoughful development foundations. In the long term, Guix may win out. Probably not in my life time though. But it's a win for developers, and nix really isn't so b…
Earlier quoted context omitted.
Im with you. As an emacsen, i feel it’s natural for me to use Guix, but nix is so so much more popular… :/
Guix being a GNU project the purism also doesn't help. Just look at this: https://github.com/nonguix/nonguix I don't even disagree that nonfree software is bad, but blaming the users who often have no choice in the matter (e.g. drivers) is the wrong way to go.
Earlier quoted context omitted.
Guix being a GNU project the purism also doesn't help. Just look at this: https://github.com/nonguix/nonguix I don't even disagree that nonfree software is bad, but blaming the users who often have no choice in the matter (e.g. drivers) is the wrong way to go.
It's a little inconvenient but for example my Framework laptop Intel WiFi chip requires a binary blob and I want aware of this. Now that I am, I can make better hardware purchasing decisions. There are plenty of alternatives that don't require that blob and it's the only thing I need from the no free channel.
Are they found in any laptop that is reasonably available on the market?
I don't think that Guix is punishing users by not supporting non-libre hardware. They are making a choice in what they develop and anybody of similar mind can join their effort.
The nonguix folks are practical. It just stinks that nothing ships with a Wifi chip that doesn't require nonguix pragmatism.
Honestly I'm just glad that this declarative approach is steadily being realized. It hasn't hit mainstream adoption yet, but it gives me hope that this headline is making the rounds. Docker is, as the article describes, just a bandaid and the symptom of unthoughful development foundations. In the long term, Guix may win out. Probably not in my life time though. But it's a win for developers, and nix really isn't so b…
I agree, for local development docker is often overkill.
However, for production it's absolutely not overkill. And since pretty much all projects are intended for production at some point, they'll need a Dockerfile and docker compose or some other equivalent.
And at that point, you're maintaining the Dockerfile anyway, so why not use it for local dev as well? That way your dev and production environments can be close to identical.
Guix looks nice - probably nicer than docker for dev work. But is it nice enough to justify maintaining two separate systems and have your dev and production diverge?
Sprites[0], exe.dev[1], and more services seem to be focusing on providing instant VMs for these use cases, but for me it seems like it's a waste for users to have to ssh into a separate cloud server (and feel the latency) just to get a clean dev environment. I feel that a similar tool where you can get a clean slate dev environment from a declarative description locally, without all of the overhead and the weight of Docker or VMs would be very welcomed.
(Note: I am not trying to inject AI-hype on a Guix-related post, I do realize that the audience of LLM tools and Guix would be quite different, this is just an observation)
[0]: https://sprites.dev
[1]: https://exe.dev
Guix looks really tempting to me because i find guile scheme so much more pleasant than nix. But i heard there are not that many packages in Guix. I wonder if some sort of transpiler from nix derivations to guix package definitions would be possible.
> Dockerfiles are clunky and the rather extreme level of isolation is usually unnecessary and makes things overly complicated I agree, for local development docker is often overkill. However, for production it's absolutely not overkill. And since pretty much all projects are intended for production at some point, they'll need a Dockerfile and docker compose or some other equivalent. And at that point, you're maintain…
The general philosophy of Guix is to have a single definition for how to build your software and use it for the entire dev to production pipeline.
[1]: https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix...
> Dockerfiles are clunky and the rather extreme level of isolation is usually unnecessary and makes things overly complicated I agree, for local development docker is often overkill. However, for production it's absolutely not overkill. And since pretty much all projects are intended for production at some point, they'll need a Dockerfile and docker compose or some other equivalent. And at that point, you're maintain…
As a side benefit, the generated docker image can be very tiny.