Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guix for Development

dthompson.us

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Guix for Development

#21

Post by digiown »

herewulf wrote: post #13
digiown wrote: post #6

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.

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:

https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002...

Re: Guix for Development

#22

Post by benreesman »

smnplk wrote: post #4

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.

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.

Re: Guix for Development

#23

Post by sohrob »

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.

Re: Guix for Development

#24

Post by gf000 »

herewulf wrote: post #13
digiown wrote: post #6

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.

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.

Re: Guix for Development

#25

Post by sidkshatriya »

smnplk wrote: post #4

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.

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.

Re: Guix for Development

#26

Post by icen »

sohrob wrote: post #23

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.

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.

Re: Guix for Development

#28

Post by atiedebee »

sidkshatriya wrote: post #25
smnplk wrote: post #4

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.

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 sc…

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?

Re: Guix for Development

#29

Post by valorzard »

skavi wrote: post #20
esperent wrote: post #16

> 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…

In Nix (and, I’d assume, for Guix) you can go the other way around: https://mitchellh.com/writing/nix-with-dockerfiles . As a side benefit, the generated docker image can be very tiny.

Yeah Guix has a Dockerfile export

Re: Guix for Development

#30

Post by akshitgaur2005 »

wswin wrote: post #15
arikrahman wrote: post #7

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 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.

That is also an option with guix --container
Post reply on HN