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

Nixery – Docker images on the fly with Nix

nixery.dev

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Nixery – Docker images on the fly with Nix

#81

Post by JamesSwift »

lijogdfljk wrote: post #65
colordrops wrote: post #48

Earlier quoted context omitted.

I was afraid of Nix before I adopted it based on what I've read. Now that I've taken the leap, there is no going back. Other operating systems are crude dinosaurs in comparison. Once you get past the learning curve and the initial setup (which can be steep), your system will be far more stable and easy to maintain than anything out there. Declarative OS builds are the future, whether it's Nix or something else.

I actually hate Nix.. and i agree, i'm never going back. I use it on my desktop (Linux), my Macbooks, and i want it on my Windows machine (not that it's going to happen hah). The thing that Nix, for me, currently fails at is introspection. Every function is a black box and i have no clue what's in it. I have to go dig up files on github to see what it even accepts. It's as if everything is obtuse. A "simple" LSP/Type…

Agreed on Flakes. It both makes the entire thing much more pure in terms of its guarantees about reproducibility/portability as well as being a lot easier to understand for me as a non-expert consumer.

Re: Nixery – Docker images on the fly with Nix

#82

Post by mikepurvis »

JamesSwift wrote: post #81
lijogdfljk wrote: post #65

Earlier quoted context omitted.

I actually hate Nix.. and i agree, i'm never going back. I use it on my desktop (Linux), my Macbooks, and i want it on my Windows machine (not that it's going to happen hah). The thing that Nix, for me, currently fails at is introspection. Every function is a black box and i have no clue what's in it. I have to go dig up files on github to see what it even accepts. It's as if everything is obtuse. A "simple" LSP/Type…

Agreed on Flakes. It both makes the entire thing much more pure in terms of its guarantees about reproducibility/portability as well as being a lot easier to understand for me as a non-expert consumer.

As a learner myself over the past year, I also strongly prefer the flake workflow— the tooling design makes more sense, there's no implicit magic about where your inputs are coming from, and everything is pure by default. Not to mention the absolute delight that is the `--override-input` flag— being able to layer your project into multiple flakes and then trivially rebuild it with just one part overridden from a modified local source, so great.

But yeah, it's super frustrating that it's all still hidden behind experimental flags and the official documentation continues to suggest non-flake workflows, though. It's ready for primetime— commit to it please!

Re: Nixery – Docker images on the fly with Nix

#83

Post by e3bc54b2 »

imhoguy wrote: post #20
nickysielicki wrote: post #12

I don’t know if it’s just because I hopped on the bandwagon in the past few months, but it really is starting to feel like Nix is gaining momentum. You can use it on Mac, WSL, Ubuntu multiuser, Docker, in an nspawn container, or through NixOS on a drive. You can build a livecd iso or a Raspberry Pi image from the same flake that you use for everything else. I work in embedded with Yocto every day, and I can’t help bu…

qq: Any good tutorials to get up to speed with NixOS with 64-bit Raspberry Pi Zero 2 please? I have a plan to thinker with some off-grid IoT this year, good moment to try something new, like Nix, than continue with Ansible which unfortunately gets out of hand with very long lasting installations - no implicit cleanup of removed resources and lack of build reproducibility (apt-get update issue really).

Different model, but I just (about 2 days ago) setup my Pi 4B using this, and was done in about an hour:

https://nix.dev/tutorials/installing-nixos-on-a-raspberry-pi

I made it difficult for myself by using flakes, but if you don't care about that, just follow the instructions and you'll be set in 10 min flat.

Re: Nixery – Docker images on the fly with Nix

#84

Post by soraminazuki »

exdsq wrote: post #77
soraminazuki wrote: post #66

Earlier quoted context omitted.

> when the total Nix lines of code > 10k for a project then have fun! I have the suspicion that you’re talking about auto-generated Nix code. For comparison, lock files for language-specific package managers can easily exceed 10k lines. But I have yet to see any hand-written Nix build description for a single software project reach nearly as much LOC.

I just checked and without giving too much info I’ll round, but there’s 20 repos with 10K commits of pure Nix repos, 3k issues across them, and 30k references to the word nix lol. Random check and none of the files are generated in these repos - it’s all reasoned code judging from commits. These are then used across all projects which includes additional nix stuff. Going for the entire org and these numbers increase…

Assuming your team consolidates Nix code in a few repos, that sounds fairly normal. In contrast, my team maintains a bunch of RPM builds and it's messier business than Nix. More boilerplate, breakage, and manual work.

Re: Nixery – Docker images on the fly with Nix

#85

Post by rekado »

tazjin wrote: post #31
civodul wrote: post #29

In the same spirit but in the form of a readily-usable command (rather than a service), 'guix pack' can produce application bundles in a reproducible fashion, in the Docker format as well as in other formats: https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix... Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'!

> Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'! I've been meaning to extract it into a more standalone tool that can output a layer distribution, that way it could also be used in things like Nix's `dockerTools.buildLayeredImage`. The main annoyance is that creating the popularity data inside of a build is not easily possible for the entirety of the package set. Stil…

Guix is not a fork of Nix. Guix reuses an earlier version of the Nix daemon.

Re: Nixery – Docker images on the fly with Nix

#86

Post by frafra »

stabbles wrote: post #61
frafra wrote: post #49

Earlier quoted context omitted.

> You can just download a bunch of packages in parallel, extract them in parallel, and finally "merge" the prefixes to get those combined bin/ and lib/ dirs. docker pull achieves the same result: layers are fetched in parallel, and they are extracted using pgiz (parallel gzip). It just uses a pre-defined order, which does not harm performances, but it is not useful either in case nixery is used.

The point is not about parallelization, it's that nixery has to optimize for cache reuse, which is an artificial problem created by docker. If you have two layers installing an individual packages like /nix/store/x and /nix/store/y, stacking them as [x, y] and [y, x] would result in the same docker image contents, but docker will generate different hashes.

Thanks for clarify your point.

> If you have two layers installing an individual packages like /nix/store/x and /nix/store/y, stacking them as [x, y] and [y, x] would result in the same docker image contents

This is an assumption which is valid for nix, but not for most of the package managers. Whenever such assumption can be considered correct, Dockerfiles can achieve similar results using multiple stages, but you would probably need a pre-processor to have a stage for each package. Something like an `INCLUDE` directive could help too: https://github.com/moby/moby/issues/3378.

Re: Nixery – Docker images on the fly with Nix

#87

Post by tazjin »

rekado wrote: post #85
tazjin wrote: post #31

Earlier quoted context omitted.

> Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'! I've been meaning to extract it into a more standalone tool that can output a layer distribution, that way it could also be used in things like Nix's `dockerTools.buildLayeredImage`. The main annoyance is that creating the popularity data inside of a build is not easily possible for the entirety of the package set. Stil…

Guix is not a fork of Nix. Guix reuses an earlier version of the Nix daemon .

You're saying "it's not a fork, it just uses an earlier, modified version of the codebase". What is a fork if not that?

I don't know how divergent it is, probably quite a lot at this point. The concepts should still be very close though and that should mean that a lot of tooling is theoretically portable between the two.

Re: Nixery – Docker images on the fly with Nix

#88

Post by mekster »

nickysielicki wrote: post #12

I don’t know if it’s just because I hopped on the bandwagon in the past few months, but it really is starting to feel like Nix is gaining momentum. You can use it on Mac, WSL, Ubuntu multiuser, Docker, in an nspawn container, or through NixOS on a drive. You can build a livecd iso or a Raspberry Pi image from the same flake that you use for everything else. I work in embedded with Yocto every day, and I can’t help bu…

I've stopped taking it seriously after seeing blogs like this.

https://blog.wesleyac.com/posts/the-curse-of-nixos

Re: Nixery – Docker images on the fly with Nix

#89

Post by samueldr »

zimbatm wrote: post #15
mateuszf wrote: post #13

Earlier quoted context omitted.

Not tried that but I've heard it's even possible to build custom Android distros.

samueldr has been doing a lot of good work in that direction. See https://mobile.nixos.org/ and https://github.com/samueldr/

Just noting, using Nix it is also possible to build an actual real deal Android image using Robotnix:

- https://github.com/danielfullmer/robotnix/

This is different from a non-Android Linux on Mobile devices, which is what Mobile NixOS aims to achieve :).

Re: Nixery – Docker images on the fly with Nix

#90

Post by rekado »

tazjin wrote: post #87
rekado wrote: post #85

Earlier quoted context omitted.

Guix is not a fork of Nix. Guix reuses an earlier version of the Nix daemon .

You're saying "it's not a fork, it just uses an earlier, modified version of the codebase". What is a fork if not that? I don't know how divergent it is, probably quite a lot at this point. The concepts should still be very close though and that should mean that a lot of tooling is theoretically portable between the two.

Guix uses a fork of the daemon. Guix, however, is not a fork of Nix.
Post reply on HN