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

NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

github.com

Post reply on HN
Print view View original

141–150 of 186 posts

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#141

Post by kaba0 »

qbasic_forever wrote: post #139
kaba0 wrote: post #94

Earlier quoted context omitted.

Also in RAM. You don’t want to runa whole-ass container for `ls`.

No a process running in docker or on your host is going to use the same amount of RAM. There is no RAM dedicated to a running container on Linux--it's just a process that's flagged with some metadata to tell the kernel that it should be isolated in certain ways, like with a unique root filesystem.

Loading in the whole container though does increase the necessary RAM — with nix, two versions of the same executable can link to the same hash, but it is unlikely to be the case with Docker.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#142

Post by soraminazuki »

tkz1312 wrote: post #58
qbasic_forever wrote: post #14

Earlier quoted context omitted.

It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit. Fully reproducible environments with home manager and nixos are neat but IMHO you can just use ansible to do the same thing on debian, arch, etc. if those systems have…

fwiw nixpkgs has significantly more packages than arch (including the aur), and those packages are also significantly more up to date. No other repo comes close to nixpkgs in this regard. This has been the case for quite some years now. https://repology.org/

I also like that packages in Nixpkgs goes through code review.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#143

Post by bpye »

ertian wrote: post #122
bpye wrote: post #80

Earlier quoted context omitted.

> It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit. That'll depend if you're on stable or not. If you're on stable and you need something from unstable that's also possible without any real risk of breakage on NixOS.

Also, once you've learned the ins and outs of Nix (which TBH I didn't find as hard as others, there's tons of examples) it's usually pretty simple to update software yourself--relatively risk-free. For example, I've been keeping Minecraft on the cutting edge for my kid by occasionally updating a URL and hash. A lot of the modules provide a 'package' option to make that easier.

Yep, a lot of the time it’s as simple as overriding the src and version of a given package -though if the package has patches to build on Nix it can be more work.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#144

Post by lillecarl »

_hl_ wrote: post #37
bergkvist wrote: post #23

The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time tha…

> Building third party flakes takes forever since every flake uses its own version of nixpkgs. The “official” (as in, community consensus) solution seems to be to bring your own nixpkgs, and manually override the nixpkgs of every dependency (and their transitive dendencies) and verify your build still works. Which just doesn’t seem right to me. Flakes are great for building an ecosystem of composable, reproducable so…

This depends, Hyprland has their own flake, and rather than overriding nixpkgs they recommend adding their cachix binary cache. You get binaries for Hyprland from Cachix and for it's dependencies from cache.nixos.org.

Works well for me. Though when doing configuration changes I usually pass --no-substitutes (or smth) to not query all my subs for derivations that'll never be in a remote cache.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#145

Post by lillecarl »

hlandau wrote: post #105

To date I've paid no attention to Flakes because whenever I look at them, they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous. I'm not going to make the code I publish needlessly dependent on specific architectures. This problem seems to be solved commonly in two ways: - People thoughtlessly and senselessly listing only x86; - People using the popular flake util…

It's like C++, you have boostlib which is separate from stdlib but you pretty much need it either way.

Or in JavaScript, you need left-pad to align text to the right, which everyone and their uncle depends on.

Nix is a programming language, where there are holes people will plug them with libraries, what's weird?

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#146

Post by bergkvist »

ParetoOptimal wrote: post #129
bergkvist wrote: post #23

The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time tha…

> Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. You only need to `git add` the file once. You do not need to stage every change after that before flakes can "see" the change.

Yes, you are right - I misremembered this detail. My problem at the the time was I didn't want to commit my flake.nix to the repository in one of my previous work places (for political reasons). So I had to unstage and restage it every time I created a new commit.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#147

Post by lillecarl »

bongobingo1 wrote: post #8

Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux syst…

> If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux system? I dont really want to dump a working system and duel booting always has whatever you need on the other system.

100%, I recommend people to start with home-manager before NixOS as it's easier to escape the Nix when you're out of depth than if you're on NixOS. It'll manage your user systemd units and everything else within your user, it's great.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#148

Post by bergkvist »

chriswarbo wrote: post #135
nextos wrote: post #6

Earlier quoted context omitted.

Because Flakes are simultaneously discouraged and labeled as unfinished, yet used by many. Some aspects of Flakes are a bit contentious. For example, official adoption of Flakes will mean Nix will no longer be a mono-repository. Plus, Flakes are tightly coupled to Git. However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when u…

> However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when using channels. I'm still not convinced by flakes; however, I agree that channels are problematic (and I still don't fully understand them, after a decade!). The first things I do after installing Nix are to delete all the channels and unset `NIX_PATH`. I used to use `…

`fetchTarball` with a github archive link is much faster than `fetchGit` for bootstrapping nixpkgs.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#149

Post by midchildan »

pharmakom wrote: post #121
nextos wrote: post #22

Earlier quoted context omitted.

It can get you two major things. Docker-like reproducibility for any development project in a much more convenient way. And the ability to try lots of software without installing it. For me, the last one is a gamechanger, as I am no longer worried about littering my system with tons of dependencies. Say I want to convert an eBook I downloaded. I can quickly use Calibre for a one-off thing, with nix run nixpkgs#calibr…

This is already solved by Docker. I know Docker has a bunch of issues and Nix is clearly a more elegant design, but in practice Docker works fine (at least for my use case).

It's really not. Docker is a tool for binary distribution. Docker images are those binaries. Dockerfiles used to create Docker images don't have any mechanism to ensure reproducibility whatsoever. Unlike Nix, you can't take a Dockerfile and expect builds to succeed.

Furthermore, Docker images are monoliths that's isolated from the system. Instead of system administrators choosing the isolation boundaries that best fits their requirements, the image packagers put walls around each and every image. As a result, Docker containers are inflexible compared to traditional Unix applications. Piecing together multiple Docker containers is a clunky experience.

In contrast, Nix is an integrated build/configuration/deployment system. Entire systems down to the package level can be reproduced from Nix expressions.

It also gives system administrators power over the whole process. Administrators have control over things like how each components are pieced together, and where isolation boundaries are placed. They can even make tweaks to the package build steps.

Docker can't substitute Nix. It's not a matter of elegance. Their features and capabilities are wildly different.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#150

Post by seabass-labrax »

pmarreck wrote: post #138
hlandau wrote: post #105

To date I've paid no attention to Flakes because whenever I look at them, they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous. I'm not going to make the code I publish needlessly dependent on specific architectures. This problem seems to be solved commonly in two ways: - People thoughtlessly and senselessly listing only x86; - People using the popular flake util…

> they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous Well, we're talking about evaluating a pure function (literally the entire philosophy of Nix is treating a build like a pure function). Those things are variable state as an input which affects the output, and therefore must be specified as inputs. I don't see the problem here (if you have already accepted th…

It would be nice to have a shorthand value that means "evaluate this pure function exactly the same way regardless of the 'system' parameter", which would be helpful for completely architecture-less packages (such as interpreted scripts).
Post reply on HN