NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally • Hacker News Board

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

#181

Post by resonious » Mon, Aug 14, 2023, 2:18 AM UTC

rgoulter wrote: post #124

resonious wrote: post #116

Just today I was setting up a server for a side project and mulling over do I use ol' reliable Ubuntu+Ansible vs finally trying NixOS. I was very sad to see that all of the popular VPS services (Digital Ocean and the like) "no longer" officially support NixOS. Linode was nice enough to have an official "how to set up NixOS on Linode" guide, but it requires fiddling with partitions by hand. At that point, I feel like…

Those Linode instructions are about installing an OS from an installation ISO from Linode's rescue mode. -- I'd consider that more a 'plus' to Linode that you get to be able to install whatever unsupported Linux on Linode's VMs. But, of course it's not as smooth as the officially supported images. Sibling comment mentions that nix has ways to build NixOS VM images (e.g. https://github.com/nix-community/nixos-generato…

nixos-infect looks great. Don't know how I didn't find that. Might give it a shot.

> Using a tool you're familiar with to get the job done is going to be faster than learning to use a tool you're unfamiliar with.

I'm well aware of this and had the time to do some upfront investment. During that investment, it seemed hard to boil a fresh deploy down to a couple of clicks. Given the great responses I'm getting, that was probably wrong, but wasn't easy for me to figure out through simple web searches!

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

#182

Post by pmarreck » Mon, Aug 14, 2023, 6:19 PM UTC

hlandau wrote: post #176

pmarreck wrote: post #138

Earlier quoted context omitted.

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

Except using NixOS without flakes doesn't require this manual enumeration so it's clearly not a requirement, but a design choice. Nothing is ultimately pure since you're running on top of a kernel which can affect computation. It's unclear to me what practical gain you get from trying to obsessively get "maximum purity", which is in any case illusory because you're still running on a kernel from outside the closure.…

How does this make it "impossible to write portable code"? CPU and OS differences produce different binaries, which are fundamentally different output values. Are you not understanding exactly how this works, or something? If you have an old flake that only defines outputs to, say, ARM, and it's 100 years in the future and no active CPU derives from ARM anymore, that's not the flake's problem. You'd arguably find it far easier to work with the flake in that context (perhaps finding an old emulator to execute it on, and THEN trying to work on migrating that to whatever architectures are used then) than finding the old C code (or whatever) and expecting that to build on whatever tooling is available then. The idea that "C is portable" is laughable, already- it's only portable to the extent that the compiler for it is portable- and then you are right back at the original problem, the dependence on OS and CPU architectures as inputs!

> obsessively get "maximum purity", which is in any case illusory

I don't understand this argument. Should I stop using functional languages because a cosmic ray could potentially mutate a variable that I expect to be immutable? Could it be that expecting perfect purity is in fact the enemy of "good" in this case? The fact that I've almost universally had better experiences in languages that emphasize "purity" (despite running on "uncertain" underpinnings) seems to undermine this reasoning.

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

#183

Post by pmarreck » Mon, Aug 14, 2023, 6:28 PM UTC

seabass-labrax wrote: post #150

pmarreck wrote: post #138

Earlier quoted context omitted.

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

But as the other person said, you're still building in assumptions in that case, which is bad (from the perspective of the whole philosophy of the Nix design choices). Because the script assumes that the script runner (which is also compiled to a certain CPU and OS!) will work when given the script as input, for example- and it is not guaranteed to. If you include the OS and CPU arch, it is FAR MORE guaranteed to (although perhaps, not 100% provably).

Perhaps you haven't dealt with enough Python packages that make assumptions about the availability and state/version of underlying OS-level libraries (and Python itself: See the transition from versions 2 to 3 as an example of this chaos) to understand how important it is to control for assumptions.

What you gain in convenience today, you pay tenfold for as "interest" later (this is thus definitely one aspect of the "tech debt" problem).

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

#184

Post by wtetzner » Mon, Aug 14, 2023, 7:02 PM UTC

qbasic_forever wrote: post #39

Filligree wrote: post #36

Earlier quoted context omitted.

Nix doesn't do network, PID or filesystem isolation. That's a feature. I don't normally want any of those.

You don't have to use them, docker has flags to disable things like network isolation. If you want to go deeper systemd-nspawn doesn't isolate anything (network, pid, user, etc.). And if you are some anti-systemd zealot the plain old chroot command does what you want too (and has done so for decades).

Except none of those solutions are package managers, are they? The thing that's nice about nix is that you can just specify which packages you want by name, and easily get them in your path.

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

#185

Post by seabass-labrax » Mon, Aug 14, 2023, 10:45 PM UTC

pmarreck wrote: post #183

seabass-labrax wrote: post #150

Earlier quoted context omitted.

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

But as the other person said, you're still building in assumptions in that case, which is bad (from the perspective of the whole philosophy of the Nix design choices). Because the script assumes that the script runner (which is also compiled to a certain CPU and OS!) will work when given the script as input, for example- and it is not guaranteed to. If you include the OS and CPU arch, it is FAR MORE guaranteed to (al…

I certainly have experienced my fair share of architecture-dependant Python horror stories, and I agree with your philosophy of convenience as a kind of loan against tech debt! However, if I package a Python script that appears not to use any system libraries or features (maybe I even wrote it myself), I would define the build for any architecture.

One reason for doing this would be for when $DISTRO declares that they will now support a new architecture. What packages would then be expected to require patches? If existing packages were marked as 'all', those can reasonably be expected to succeed and should cause noisy errors if they don't. Conversely, packages which were explicitly marked for specific architectures (even if that is all the architectures that the distribution supported when they were created) can be expected not to work on the new architecture without modification. This does of course require the packager to actually know the difference between using the keywords and just marking every known architecture. And to be fair, what I was originally advocating for in my comment was more like Debian's 'any' wildcard, which is not quite as strong as the assertion that the package is completely architecture-independent.

I would say that a specific tag for architecture-independent builds actually improves the situation: explicitly acknowledging the assumption that exotic architectures will never be an issue. Of course, as your sibling comment mentions, the interpreter is still part of the closure in Nix, so maybe this is incompatible with the existing choices made in the Nix ecosystem.

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

#186

Post by solomonb » Sat, Aug 19, 2023, 3:23 AM UTC

mongol wrote: post #89

solomonb wrote: post #16

Earlier quoted context omitted.

You absolutely do not need flake-parts.

What is it even? I see it referenced now and then and don't understand in what situations it would be useful.

It adds a module system to nix flakes. I've been using nix every day for 4 years and make heavy use of flakes but TBH i'm not really sure the benefit flake-parts. It looks like a ton of new boilerplate.