_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Guix for Development
civodul wrote 42 min ago:
On the same topic, check out this how-to on software development with
Guix from the Cookbook (author here): [1] The idea was to show that
there are several "levels" to take advantage of Guix for development,
where the `guix.scm` file in David Thompson's blog post is the first
level.
(HTM) [1]: https://guix.gnu.org/cookbook/en/html_node/Software-Developmen...
pshirshov wrote 44 min ago:
But flakes are more sound and more convenient!
anthk wrote 52 min ago:
Guix asking for donations from propietary websites it's a disgrace to
GNU.
But i woudn't expect less from some hijackers. [1] Proof: [2] [3]
(HTM) [1]: https://guix.gnu.org/donate/
(HTM) [2]: https://donate.stripe.com/8x2bJ133ia2H3Zw4j38N201
(HTM) [3]: https://donate.stripe.com/aFaeVd7jy7Uz1Ro02N8N204
(HTM) [4]: https://donate.stripe.com/dRm5kD47m0s79jQ9Dn8N202
nickez wrote 1 hour 19 min ago:
What if a piece of software isn't packaged, like for example the ARM
GCC toolchain. In a Dockerfile I just need to curl and unpack it. How
do I solve that with guix?
bflesch wrote 1 hour 36 min ago:
How is the scheme syntax in any way an improvement over JSON? Can't
they build the same thing but use JSON - which everyone already uses -
instead of pushing a new verbose syntax?
cess11 wrote 10 min ago:
I think it would be tricky to develop a package manager in JSON.
tetris11 wrote 4 hours 30 min ago:
I love Guile over Nix syntax, but the one killer feature Nix has that
Guix doesnât is making a single static binary of common programs and
then deploying them elsewhere.
In Nix, this is a single flag. In Guix, you either deploy with all
libraries on a custom /guix path, or nothing.
dhon_ wrote 3 hours 26 min ago:
How do you do it in nix?
rudhdb773b wrote 4 hours 57 min ago:
I love Guix documentation, but unfortunately I've had to stick with Nix
because its more polished with a large library of packages.
LLMs have also made writing syntacticly correct Nix scripts much
easier, so I don't miss Guix's Guile that much.
sohrob wrote 8 hours 4 min ago:
I wanted to go all-in on Guix but the installation process was made too
difficult due to the lack of non-free software available during install
time. I wish they would take the Debian approach and leave it up to the
user to decide which packages they would like installed on their system
or not.
icen wrote 6 hours 31 min ago:
Thereâs nonguix for access to non free drivers and such. I think
that system crafters have some installable images if you donât have
a current guix install to build one
Itâs regrettable that this is necessary, but with so few Ethernet
ports on laptops itâs harder to install these things without access
to WiFi.
goranmoomin wrote 9 hours 58 min ago:
I feel like declarative container-like dev environments (e.g. nix shell
or guix shell, and so on) will become much more popular in the
following years with the rise of LLM agentic tools. It seems that the
aformentioned tools provide much more value when they can get full
access to the dev environment.
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]: [1]:
(HTM) [1]: https://sprites.dev
(HTM) [2]: https://exe.dev
sdsd wrote 17 min ago:
As a Guix lover and LLM tooling enthusiast, I complete agree.
Administrating my system via Claude Code is so much easier. LLMs work
better on a system that's hackable via text.
attila-lendvai wrote 2 hours 9 min ago:
random note: there's `guix shell --container --emulate-fhs`.
esperent wrote 10 hours 7 min ago:
> 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 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?
otabdeveloper4 wrote 2 hours 42 min ago:
You'd be nuts to run the Docker daemon anywhere near production.
skavi wrote 9 hours 23 min ago:
In Nix (and, Iâd assume, for Guix) you can go the other way around:
[1] .
As a side benefit, the generated docker image can be very tiny.
(HTM) [1]: https://mitchellh.com/writing/nix-with-dockerfiles
valorzard wrote 5 hours 47 min ago:
Yeah Guix has a Dockerfile export
dominicm wrote 9 hours 27 min ago:
While not directly mentioned in this article, guix pack[1] allows you
to distribute your software in multiple formats, including Docker
images.
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]
(HTM) [1]: https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix...
arikrahman wrote 11 hours 45 min ago:
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 bad with
everyone vibecoding away it's complexity anyways.
wswin wrote 10 hours 25 min ago:
I think they're two different tools. Containers are great for
production environments. Beside reproducibility, they also give
control over resources
and manage virtual devices. Things that are rather not needed during
development.
akshitgaur2005 wrote 5 hours 47 min ago:
That is also an option with guix --container
herewulf wrote 11 hours 8 min ago:
You can even generate Docker images deterministically with Guix. :)
smnplk wrote 12 hours 22 min ago:
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.
sidkshatriya wrote 6 hours 47 min ago:
The nix language is maximally lazy. It does not evaluate things it
does not need to. This is good because you don't want it to burn CPU
building things (very expensive expressions!!) that it will
ultimately not need for final derivation. I'm wondering if guix
scheme is suited well for this task:
(a) evaluation is eager
(b) lots of variable mutation.
But perhaps lazy evaluation and lack of variable mutation in guix
scheme is not such a problem after all for a nix _like_ system -- I
don't know.
attila-lendvai wrote 2 hours 6 min ago:
"lots of variable mutation" is more like "variable mutation is no
impossible, but not common".
helibom wrote 5 hours 35 min ago:
I'm still new to both Guile and Guix, but I've been reading the
Guile and Guix reference manuals recently and I think some of your
concerns about eager vs. lazy evaluation of packages are addressed
by Guile's quoting mechanism, more specifically "quasiquote" [1].
This quoting mechanism allows passing around references to package
definitions and whatnot, without actually evaluating those
expressions until build time.
Guix extends quasiquote to create something called "G-expressions"
[2], which are even more so fitted to something like the Guix/Nix
build system.
1. [1] 2.
(HTM) [1]: https://www.gnu.org/software/guile/manual/html_node/Expres...
(HTM) [2]: https://guix.gnu.org/manual/1.5.0/en/guix.html#G_002dExpre...
atiedebee wrote 5 hours 58 min ago:
Im very familiar with Nix or the language, but why would
interpreting guile scheme for package management be expensive? What
are guix and nix doing that would require evaluating everything
lazily for good enough performance?
Hasnep wrote 3 hours 12 min ago:
It's not the Nix/Guile that's expensive, it's situations like:
let chromium = pkgs.chromium; in 1 + 1
In a maximally eager language you'd need to wait for the entirety
of Chromium to build before you can find out what 1 + 1 is.
atiedebee wrote 3 hours 5 min ago:
I checked the spec and Scheme R5RS does have lazy evaluation in
the form of promises using "delay" and "force", but I can see
why explicitly having to put those everywhere isn't a good
solution.
benreesman wrote 8 hours 39 min ago:
I compile nix derivations to well-posed effect/coeffect/graded monad
algebra so I can do real bill of materials and build on an action
cache engine maintained by professionals, but that's mostly for
long-tail stuff.
These days with a la carte access to all of the container ecosystem
primitives as nice, ergonomic, orthogonal operations I don't really
see the value in nixpkgs. Don't really see the value in a container
registry either: a correctly attested content addressable store with
some DNS abbreviations is 100 lines of code because mostly it's git
and an S3 shim.
The category error at the heart of nixpkgs is that the environment in
which software is compiled need resemble the environment in which it
executes. Silly stuff. So whether you're a patchelf --rpath ...
Person or an unshare --bind-mount Enjoyer (isomorphic), just
remember, in 2026 the guy with the daemon that runs as root does not
want you to have nice things.
arminiusreturns wrote 9 hours 50 min ago:
Now if we could just get people to combine Guix and other guile
scheme packages that are awesome like mcron into their stacks, and
then backfeed more fixes into the ecosystem, we have a real chance at
helping GNUland!
herewulf wrote 11 hours 13 min ago:
You can run Nix packages on Guix if there isn't a "native" package
for it. Look at nix-service. [1] I've never felt the need myself. If
something is missing, I add it and I think that is the real fun in
running Guix because creating your own well defined package or
service is deeply rewarding.
Anyway, you can find people using it in the wild either by search
engine[1] or with Toys[2] which is also handy for finding examples of
missing packages too.
[1]: [2]:
(HTM) [1]: https://guix.gnu.org/manual/1.5.0/en/html_node/Miscellaneous...
(HTM) [2]: https://duckduckgo.com/?t=fpas&q=%22config.scm%22+nix-servic...
(HTM) [3]: https://toys.whereis.social
heavyset_go wrote 11 hours 25 min ago:
This is where I'm at after using Nix for a few years for different
use cases. I never want to write it again, and would welcome a Scheme
over Nix.
whompyjaw wrote 12 hours 16 min ago:
Im with you. As an emacsen, i feel itâs natural for me to use Guix,
but nix is so so much more popular⦠:/
digiown wrote 12 hours 4 min ago:
Guix being a GNU project the purism also doesn't help. Just look at
this: [1] 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.
(HTM) [1]: https://github.com/nonguix/nonguix
allan-a wrote 4 hours 40 min ago:
nonguix is similar to debian's non-free sources. It's also
maintained by many of the same contributors to guix. Enabling it
is also similar to how you enable it for Debian. I have never
seen anyone blamed or shamed for using nonfree drivers by the
guix community, which I can say has been a very warm and
welcoming community.
attila-lendvai wrote 2 hours 3 min ago:
it does happen, and it happened to me, too.
but the attitude has been changing recently from active shaming
for even mentioning non-free stuff, to passive acceptance of
pragmatically pointing a newcomer to nonguix.
herewulf wrote 11 hours 5 min ago:
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.
gf000 wrote 7 hours 48 min ago:
Open hardware is mostly a lie.
They all run proprietary blobs inside and out. It's ridiculous
gatekeeping to say that on the kernel level it's bad, but below
it I just put my head in the sand and disregard the millions of
lines of closed-source code.
digiown wrote 9 hours 16 min ago:
I really don't think you can gain much realistic freedom going
without the blob. The powers that be will never let you have a
freely modifiable radio transceiver.
The blob is better viewed as a part of the hardware in this
case. What's most likely to happen to get rid of the blob is to
just put it on the non-modifiable parts of the device. Viewed
in this way, the blob is at least something you can practically
inspect, unlike the firmware on the chip itself.
See also the discussion on CPU microcode:
(HTM) [1]: https://lists.gnu.org/archive/html/info-gnu/2018-04/ms...
freeopinion wrote 10 hours 53 min ago:
Are there really a lot of alternative Wifi chips that don't
require closed blobs? Do you have a list?
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.
davexunit wrote 12 hours 24 min ago:
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.
herewulf wrote 11 hours 9 min ago:
(Small) discussion of the release.
(HTM) [1]: https://news.ycombinator.com/item?id=46732047
pmarreck wrote 13 hours 25 min ago:
both guix and nix are 1000% better for setting up and managing
per-project deps deterministically
(DIR) <- back to front page