[k32]

> First of all, the fork obviously isn't there for general consumption.

I didn't know that when I installed a package called "rebar3" and spend some time trying to understand what's wrong with my build. Oh, my bad, should've known better that "rebar3" was for internal consumption, and I need to install "rebar3-open" instead.

> Second, it would've been nice if you've raised an issue on GitHub and helped improve Nix instead of complaining and spreading borderline falsehoods on HN.

Thanks for suggestion. I did exactly that, and I fixed this entire mess. In fact, the current NixOS Erlang infra is partially based on that work.

> Ranting about how "it's a hack!" based on cherry-picked implementation details isn't convincing at all.

I professionally work with Erlang, and I know what is hack and what is not.

> Tell me a single major distro where it's okay to essentially redistribute packages from language-specific package managers without making huge adjustments in the way packaging is handled. I know of none. For countless software, distros just give up on packaging altogether because the effort required to make that adjustment can easily get out of hand.

Language-specific packaging should be left to language-specific package managers, they have more domain knowledge. Nix doesn't solve this dilemma in any better way.

> Also let me remind you that almost all Docker container images rely heavily on distro-provided packages. What are you going to do now?

Keep on using it? Take systems software from the distro-provided packages, add my own stuff on top. Building RPM is a nobrainer. I was considering Nix as an alternative to our deploy process, but realized that it would introduce more problems than solve.

> /etc in Nix is not world-readable, plain and simple.

Please take a closer look at what you're quoting. You missed a very important part:

> (or its analogue in /nix)

You see, if I want to utilize Nix to full extend and use its main "reproducibility" feature, I need to put all my configuration in a derivation. Configuration includes secrets. Derivations are world-readable.

> Neither do other distros

Distros maybe don't, but "bug-ridden kludge that is Ansible" (according to Nix user) does.

[soraminazuki]

> Oh, my bad, should've known better that "rebar3" was for internal consumption, and I need to install "rebar3-open" instead.

If that was your problem, you should've said so instead of spinning it up into an entirely different security problem that plainly did not exist.

> Thanks for suggestion. I did exactly that

Except you didn't stop spreading falsehoods. You've spent more lines using your brand new HN account spreading lies about an open source project people have dedicated their free time into.

> professionally work with Erlang, and I know what is hack and what is not.

Fixating on hyper specific implementation details taken out of context without considering the design, intent, and usage is not what I call professionalism in the software industry.

> Language-specific packaging should be left to language-specific package managers, they have more domain knowledge.

Domain knowledge that fails to build or run portably even on widely used FHS-compliant Linux distros.

> Nix doesn't solve this dilemma in any better way.

I've already explained about the problems distro package maintainer faces and how Nix alleviates some of the problems which you then responded with a totally unrelated "Docker exists" nonsense.

> Take systems software from the distro-provided packages, add my own stuff on top.

So packaging problems won't exist if we just stick with Docker, but you would use distro packages to create a Docker image? How would that even work?

> Building RPM is a nobrainer.

Go tell that to RedHat maintainers.

> Please take a closer look at what you're quoting. You missed a very important part: > > (or its analogue in /nix)

/etc in NixOS is not /nix. It's /etc. Very important indeed.

> You see, if I want to utilize Nix to full extend and use its main "reproducibility" feature, I need to put all my configuration in a derivation. Configuration includes secrets. Derivations are world-readable.

You see, Please. Stop. Repeating. Lies.

You don't put secrets in a world-readable location, period. The typical Nix way of handling secrets is that you store in them in a secure path and point the configuration to that path.

> Distros maybe don't, but "bug-ridden kludge that is Ansible" (according to Nix user) does.

You can use numerous solutions that can work together with Nix. How about NixOps, which, among other things, handles secrets management? Or what about, say, Ansible? After all, any solution that would be able to send the Nix configuration, place secrets in a secure filesystem path, and run commands to build the Nix configuration would suffice.

[k32]

> If that was your problem, you should've said so instead of spinning it up into an entirely different security problem that plainly did not exist.

It was merely an answer to your remark about "this fork wasn't meant for external consumption". Please don't try to substitute the argument.

> Except you didn't stop spreading falsehoods. You've spent more lines lying with your brand new account on HN.

I spent much more time researching this project and trying to figure out the least ugly way to fix its problems. This time was effectively wasted. I just wrote my post so someone who faces issues similar to mine will investigate the matter more carefully.

> Fixating on hyper specific implementation details taken out of context without considering the design, intent, and usage is not what I call professionalism in the software industry.

Ad hominem, moving on.

> So packaging problems won't exist if we just stick with Docker, but you would use distro packages to create a Docker image? How would that even work?

I am not going on to explain how to work with docker, it's a mainstream technology that has plenty of documentation and examples.

> You see, Please. Stop. Repeating. Lies.

https://github.com/NixOS/nix/issues/8

Please don't go ad hominem and don't accuse me of lying. This issue is submitted by Nix devs themselves.

> The typical Nix way of handling secrets is that you store in them in a secure path and point the configuration to that path.

And this is precisely the hack I was talking about. Because of this approach you cannot manage secrets with nix at scale (just to clarify: when I say "nix" I always mean the package manager). This is an issue submitted by core designers.

I think we ran out of productive arguments in this conversation.