Nix fork Aux.computer fixes the political but not the technological objections | Hacker News Reader

Nix fork Aux.computer fixes the political but not the technological objections

theregister.com

5 pointslproven11 comments

The writer of the article doesn’t seem to understand how nix works, which in some way is even more convoluted that “trusting the PATH” as he portrays it, but it works so good that once you get it, it totally makes you think you were “doing it wrong” as he quotes flox’s CTO.

Thus no, aux doesn’t try to fix the nix store path, as it’s not understood to be broken.

I’m just a participant on the project as much as the rest of my life allows it, but as I understand the goal of aux is to change the governance structure, and how it maps to projects like nixpkgs with its huge state and nixos modules.

> The writer of the article doesn’t seem to understand how nix works

I am the writer and the submitter too.

I have written about Nix before, and received thanks and praise for my articles from the Nix community.

Examples:

https://www.theregister.com/2022/12/13/nixos_2211_raccoon/

https://www.theregister.com/2024/03/23/flox_1_nix/

https://www.theregister.com/2021/12/03/nixos_linux_os_design...

I think that I do more or less understand it, at the trivial level of what it's for and what it does and how it achieves it.

For those reading, as in that thread on Discourse and indeed here, to fail to appreciate that means that you've not understood the point of my article.

Nix achieves its goals. I am not disputing that. I am saying that the cost of that is just too high. That cost is losing a filesystem layout that to ordinary humans is readable, makes sense, is navigable, and most of all, is maintainable and can be modified, used, changed, and updated, by hand if Nix fails in some unforeseen way.

This, though, is fixable.

That would give the fork a goal and a chance. Without that, I don't think it has one.

I think this is a good point -- The ideal state is probably something that is immutable where you need it, and mutable where you may need to make frequent changes. Making small tweaks to your configuration should be easier than needing to write and re-evaluate Nix expressions.

We took a similar approach with our product (Devbox): Immutable package store (powered by Nix) to guarantee correctness, coupled with mutable project state. Here's a post where we explain our thinking: https://www.jetify.com/blog/do-repeat-yourself-global-packag...

I get the point of in-mutability, I keep this kind of hybrid environment where I abuse the different include systems of software to keep mutable files that can be easily changed. I guess the different module systems could make it easier, but I still fail to see what this has to do with the nix store, or more so, with the names of the paths in the nix store, everything there is the inmutable part.

Some times, and I guess a lot of times since I use home-manager, I do want my configs to be inmutable, at least the permanent part that is shared between my devices.

I read that blog post, and came off not quite understanding how it is a similar approach. Specifically where it says,

> Devbox installs packages globally in the immutable Nix store and creates a local virtual environment based on your project devbox.json config

Is this "local virtue environment" different to a nix develop shell (which uses, for instance, $PATH environment pointing to nix store paths)? If so, in what ways?

Good to be proven wrong.

And yeah, as you say I fail to understand your article. I mean, most of the stuff is exactly where you expect it to be even if it’s actually a link to the store, nix store doesn’t supersedes the whole filesystem. I can accept that there’s loss of information, I guess it might matter sometimes if a binary is in “/bin” or in “/sbin” but so far I don’t see how the regular filesystem structure or even gobo’s would help, to fix your software, at least if you want to keep immutability, which is a another can of worms. And even then, if you hack something depending on these paths, IMO you are back to the “doing it wrong” part.

Am I missing something here?

> And yeah, as you say I fail to understand your article.

Please do explain, then. I always try to be as clear as I can, time and deadlines permitting.

> I mean, most of the stuff is exactly where you expect it to be even if it’s actually a link to the store

What does that mean?

> nix store doesn’t supersedes the whole filesystem.

It absolutely does on NixOS, which is all I have looked at. I have absolutely no need of Nix on top of any other distro; indeed, I can't even imagine what I'd use it for.

I suggest reading the comments on the article, which it seems to me are strongly in agreement with my points. (Believe me, this is not a general rule: they very often aren't!)

Nix solves a problem I personally do not have, which is why I don't use the tool or the distro. Since the docs and the fora and indeed entire products such as Flox assume everyone has the problem, they don't spell out what it is and why fixing it matters.

> so far I don’t see how the regular filesystem structure or even gobo’s would help

That is a mind-boggling comment to read.

Unix is a ~50 year old OS, with millions of users. Its filesystem is at the core of the OS design and its layout is known to millions of people.

If a project comes along and throws it out, it has to have an exceptionally good reason. Nix does not.

Gobo does. Gobo says "Mac OS X does this better. We aim to equal and exceed what NeXT did." And it does, in its own terms: it...

1. Replaces the Unix filesystem hierarchy with a new one that is cleaner and more readable.

2. But crucially, it is not only more human-readable, it also gives better isolation.

3. It also allows radically simpler packaging tools.

4. And it bestows the ability to have multiple concurrent versions of entire software subsystems.

Nix delivers only points 2 & 4. It reduces #1 and it does the reverse of #3.

In other words: it gives isolation and the concurrent versions, but it does so via more complex packaging tools that need users to learn a whole new programming language, and it eliminates the familiar FHS and replaces it with a new flat programmatically-defined one that is almost unreadable to humans.

> What does that mean? > It absolutely does on NixOS, which is all I have looked at. files in /etc are still where you would expect them to be, files in /var are still where you would expect them to be, files in /boot are where you expect them to be.

You won't find stuff on /lib, /usr, or /bin but even if you did, well it defeats the inmutability if you could just manipulate them, which is pretty much the purpose of nix.

This is my problem with your article, so you can map these files with nice names; now what? want to hack something with them?, then why use a declarative system? want to manually modify them? then why use an inmutable system? It totally defeats the purpose of nix. Thus my opinion, and not trying to be dismissive, that you don't understand what nix is trying to do.

> I suggest reading the comments on the article, which it seems to me are strongly in agreement with my points.

I just did on your suggestion, and I'm not impressed. The top comment is saying that if the OS get's borked they restore from backups, so not interested in software generated paths... which hey, it's a valid workflow if it works for that person, yet the whole point of a declarative system is that you can rebuild your system in mins without any backup.

That's my whole point, I don't care about where the packages are, they could even come from a magician hat, what I want is to be able to write a configuration of the exact packages that I want and that it actually works instead of some mess like ansible/salt/whatever. I don't particularly care about isolation, even if that's kinda the reason why the system works, if I were interested only in isolation or running multiple versions of software I would just use containers.

> In other words: it gives isolation and the concurrent versions, but it does so via more complex packaging tools that need users to learn a whole new programming language, and it eliminates the familiar FHS and replaces it with a new flat programmatically-defined one that is almost unreadable to humans.

I agree that the packaging tools (nix lang and underlying scripts) are complex, that might be something to fix, but I fail to see how knowing the path of packages works to do anything but to encourage the mess that people who love nix try to avoid.

Several points to this.

1. It's "immutable" not "inmutable".

2. There are lots of immutable distros without Nix. Fedora CoreOS and Atomic. Ubuntu Core. EndlessOS. SUSE MicroOS. Immutability is irrelevant here.

3. You miss the point that the commenters were making: it's necessary to be able to fix computers when software goes wrong. This is the entire basis of a global trillions-of-dollars industry and most of my career for a third of a century. This is not a "nice to have", it is a 100% cast-iron REQUIREMENT.

4. If being declarative is so important, then explain WHY because most of OS design isn't, and yet somehow they have been working for 60 or 70 years now. It's like functional languages: none of the fans can be bothered to take the time to explain why they are so good, and as a result, nobody cares.

http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...

5. You may not care about isolation, but I am telling you: the rest of the IT world cares a LOT. I predicted the rise of containers in 2013, before Docker was founded:

https://www.theregister.com/Print/2011/07/18/brief_history_o... (I think it was this one.)

Isolation is huge and vitally important and in the field of Linux it's worth billions. If Nix offers radically new and better methods then it needs radically new and better explanations because there are lots of existing methods and they work fine.

You seem to be addressing side issues and niggles to me, and avoiding confronting the core thing.

Being able to read, understand, navigate and maintain the filesystem hierarchy is a keystone of Unix. If you want to remove that keystone then you must have extraordinarily good reasons, and after reading tens of thousands of words of discussions of Nix, I am not convinced the reasons are good enough.

I think a human-readable filesystem could be retained, and improved over existing designs, while also delivering declarative generation and management. I am trying to point this out, proposing examples and mechanisms, and you (and the wider Nix community) are not addressing it. Instead, the world is saying "we really want this and we will not give it up" and the Nix folk are not listening.

[Article author/submitter here]

Thanks for that.

I don't really want to join yet another forum -- and I hate web fora, and that includes Discourse -- to reply. Is there any point in replying here? Would anyone relay my comments, or ask people to come and read them?

Reply on news.ycombinator.com