This matches my experience. I played it for 50 hours on PC (and I am a very lazy gamer, typically I get tired of everything in one hour), and didn't encounter any breaking bugs. Overall, it's a very enjoyable story-driven game, although "AI is more A than I".
My explanation for the outrage is that in the past few years quite a few people made youtube careers bashing AAA games. Making outrage videos a lucrative business, apparently, and the new generation of wannabe game journalists jumped on the train.
Sluggish UI, dark patterns, OS rebooting when it feels like it, OS waking up during the night for some shenanigans, surveillance, nagging, ads... I don't know how people can have so little self-respect to use windows. Feels like living in a rental apartment with a creep landlord, while with linux you own the house.
> 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.
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.
> This is precisely why it's important that Twitter calls out when things are stated as fact without evidence.
Twitter is a platform for stating things as fact without evidence. 120 (or whatever it is now) character limit is not suitable for having cogent conversations.
> 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.
> Except that your anecdote is completely misleading given that the patched version was intended for creating Nix packages. You could've just used the unmodified version instead.
The package was called rebar3, not rebar3-nix or something. If the fork was called differently then no one would complain. Also this fork was based on hacks, like patching rebar3's internal files and messing with caches. If you don't see anything wrong about this, then this way of thinking just proves what I said in the parent.
But forking rebar3 wasn't needed at all, because rebar3 _already_ had all the features needed for Nix. Namely, it has get-deps command producing fixed output derivation, and it supports _checkouts directory, needed for hermetic build.
> Then use the unmodified rebar3 for your project instead. But anyways, if your threat model involves not trusting SHA256, you likely have a problem with your said cryptographic chain of custody too.
There's no reason to use SHA256, if you just replace it with a different SHA256 whenever it doesn't match with the upstream.
> Nix even alleviates some of the problems because you can use different versions of the same software, meaning that different packages don't have to share dependencies as aggressively as other distros do.
Docker exists. Although it's not perfect by any means, it doesn't require reinventing the entire world. I extrapolated my experience with Erlang to the rest of NixOS reinventions, which in theory could be wrong, but it was convincing enough for me.
> That's an outright lie. NixOS doesn't prevent you from storing secrets in a file and applying your usual UNIX permissions. FHS has absolutely nothing to do with it.
I was not talking about "storing secrets in a file", but rather about the whole live cycle of the secrets, including transferring them between parties, storing, provisioning, rotation, etc (imagine you have to solve a problem of changing some secret on 100 machines securely and reproducibly via blue/green deployment). As far as I know, Nix doesn't provide facilities for solving this problem at scale. I would be happy to be proven wrong.
> FHS has absolutely nothing to do with it.
It absolutely does. Some pieces of software look for secrets in /etc/ (Kafka, for example). When etc (or its analogue in /nix) is world-readable hilarity ensues.
I've yet to encounter another distro that deliberately breaks 3rd party software the way Nix did it to rebar3 (before it was reverted).
> Plus, the statement that you have to patch all packages is false.
IIRC `patchShebangs' script runs for any package using stdenv.
> I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen.
Which distros? Can you share a comparison in number of tests/coverage?
> Dramatic, but again, simply not the case.
As other commenters mentioned, software written for GNU\Linux often assumes FHS. NixOS breaks FHS, and has to patch soft to work around that.
> This is a good thing.
How so?
> This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros.
Other major distros don't break FHS, therefore they don't need to patch trivial things like shebangs.
> All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it.
It depends on your threat model. Mine is stricter.
> If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed.
Once again, it breaks the cryptographic chain of custody set by the upstream. In my threat model that's not acceptable. I tend to trust the upstream more than the distro.
> Why not store secrets in a private location, just like you would on any other distros???
Secret provisioning is by far the most difficult DevOps problem, and it can go catastrophically wrong for all too many reasons. Nix not only doesn't help, but also introduces additional footguns with world-readable configuration files.
> What is it that other distros have that Nix is missing?
Other distros have FHS. FHS accounts for secret management, among other things.
> Yes, it saves me from having to do a clean install of my system every few months.
Ok, though I never had to do a clean install of GNU\Linux either on my dev machine.
Yes, really. This PR partially reverted this behavior (or rather made it less intrusive): https://github.com/NixOS/nixpkgs/pull/54115/files , but from there you can easily track "rebar3 hermecity patch", which had introduced it.
Nix is a nice research project, but after playing with it for ~6 months and contributing to nix-packages, I came to conclusion that (in my case) it's not suitable for production nor development, and now I manage my personal machines with a simple Ansible playbook.
Main reason for leaving was that Nix package maintainers have to heavily patch all software. Packaging for nix is more like porting software to another operating system. Just check the amount of ad-hoc patches in nix-packages repo, and note that they have automated tools for patching the most common problems, so the problem is even worse. Now how about quality of these patches... I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much, because the original author of the derivations abandoned them.
Moreover, Nix breaks the chain of trust for the language packages. For example, Erlang and Elixir packages are signed cryptographically. Most erlang libraries come with a rebar.lock file containing hashes of the dependencies, so reproducible builds are already ensured. Unfortunately, package hashes are incompatible with Nix derivation SHA's, because they include some additional envelope data. What did Nix people do to work around this problem? They patched out the checks for rebar.lock files from the 3rd party Erlang build system. I would not dare to run a distro that contains patches like this in any kind of production environment.
Additionally, /nix directory is readable by all users, so you cannot use Nix to manage secrets, and there was no universally approved way of doing so (or at least it was the case at the time I was using it).
As for personal use... You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities, and to be honest, do you really need such degree of reproducibility for your very own dev machine?
My explanation for the outrage is that in the past few years quite a few people made youtube careers bashing AAA games. Making outrage videos a lucrative business, apparently, and the new generation of wannabe game journalists jumped on the train.