Hacker News new | ask | show | jobs
by rcxdude 11 days ago
>Rather than fixing their own project they force work upon so many others.

Nix has put in a ton of work to make their project work, and the assumptions in the rest of the ecosystem have been fighting every step of the way. And I would argue they've been changing it for the better, considering that if you were to just 'try to make nix work' you'd probably mainly come to the conclusion that it was impossible to make work sensibly due to the huge number of places where hardcoded relationships have been baked in.

2 comments

Many of those assumptions are standards such as the filesystem hierarchy (granted, that's an xkcd 927 situation), nix is a bit of a special snowflake that breaks things in subtle ways (e.g. [0][1]) and needs workarounds in various places. Those workarounds are not necessarily onerous, but they would be unnecessary if it didn't deviate.

[0] https://github.com/NixOS/nixpkgs/issues/420513 [1] https://github.com/NixOS/nixpkgs/issues/94228

>and the assumptions in the rest of the ecosystem have been fighting every step of the way

There is an arrogance in the way of thinking that when you see everyone breaking your arbitrary rules you think to yourself "there is no way my rules are at fault, it's everyone else's fault for breaking them."

>due to the huge number of places where hardcoded relationships have been baked in.

And why are hardcoded relationships bad for developers or users of the operating system? "Because they break Nix" is not a good excuse. Plenty of other operating systems work just fine with such things hardcoded, I don't see developers complaining about these hardcoded things, and moving things around can only make things more confusing for the user.

To me it looks like Nix picked a poor design and instead of going back to the drawing board and trying to come up with a better design they have gone all in on trying to force their bad design to work.

How much work do you think iOS or Android spend on app packaging / installation per year. Despite having millions of more developers and billions of more users they spend orders of magnitude less than NixOS does.

Edit: I can't reply since I'm rate limited.

Debian already supports installing multiple php versions.

You can use the update-alternatives command to set which one is default for the php command.

Via your web server's config you can config which php version a site will use.

> There is an arrogance in the way of thinking that when you see everyone breaking your arbitrary rules you think to yourself "there is no way my rules are at fault, it's everyone else's fault for breaking them."

It's not really arrogance - it's just a different way to design a system. NixOS wants a few things:

1. An input-addressed dependency system

2. Easy and robust rollback/upgrades

3. Different versions of software/libraries/services coexisting on a single machine.

A lot of this is just impossible to have together with the way software were written, so NixOS made the changes necessary for them. When it became obvious it might be useful to other people, they upstreamed it.

I do agree with you that the whole `#!/usr/bin/env bash` shebang shenanigan is kinda ass (my personal nixos machine has a `/bin/bash` alias because there's not enough time in my life to care about this issue). But I also think that NixOS is right here, shebangs requiring a full path is just a terrible design in a multi-user world. If different users want to have a different bash implementation, they should be able to!

---

Fundamentally, I think the NixOS OS design is actually beautiful. It's taking most of what makes modern phone OS so reliable (read-only system, A/B partitions, etc...), and bringing their ideas in a shape that is coherent with desktop/server OS design.

I suggest you take a look at Fedora Silverblue. It accomplishes all 3 of those goals.
silverblue doesn't accomplish goal 3 either... if you need conflicting dependencies to interact in the same environment (i.e. outside a container)
I don't see how it achieves goal #1, what am I missing?
Can you precisely describe what the goal of #1 is. For flatpaks an app's dependency can be specified with a sha256 of the artifact or a specific commit of the dependency.
You kind of argue it’s okay one cannot eg. Install two different versions of PHP on a Debian system. Nay!
Of course you can.