Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Curse of NixOS

blog.wesleyac.com

Post reply on HN
Print view View original

181–190 of 361 posts

Re: The Curse of NixOS

#181

Post by madars »

0xbadcafebee wrote: post #110

There are some fundamental problems that no distribution can solve (not even Nix). Every level of abstraction has its own set of dependency issues, yet there exists no abstraction or concept that handles conflicts in every one of those levels. There are a lot of hacks and kludges used by Nix in order to try to get there, but it's only most of the way. We've hit the limit of what we can kludge. I think the future of s…

You might enjoy Stripe's "APIs as infrastructure: future-proofing Stripe with versioning" -- https://stripe.com/blog/api-versioning Original HN discussion: https://news.ycombinator.com/item?id=15020726

Re: The Curse of NixOS

#182

Post by [deleted] »

rgoulter wrote: post #6

"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…

[deleted]

Re: The Curse of NixOS

#183

Post by AceJohnny2 »

taeric wrote: post #173

I feel the conflict between the good and bad here is interesting. First, it has to be acknowledged that the reason everything can be installed to separate directories is a modern luxury. Hard drive space used to be much more constrained. Second, everything being installed to a unique location is why everything has to be rebuilt. And gets into the fun that you can't update just part. The problem, then, is we never con…

> The problem, then, is we never converged to foundational level software. That is, if we agreed that bash was a foundation of the system, there would just be the one. And you wouldn't get an odd web of versions of it linked everywhere. All code would just use bash.

I can't imagine how this would be possible, in practice. Software has fractal complexity, there are always things that need to be tweaked, unexpected interactions that need to be decided one way or the other (and changed back).

I remember when Android decided to ship sqlite as part of the base OS, and everyone celebrated this robust, stable inclusion. And yet, sqlite continued to evolve, such that many Android apps nowadays just bundle their own version rather than use the OS's outdated version.

Perhaps we're still in the early days of computing, and only just now starting to see a flattening of the S-curve of change (more likely, I've gotten older and "everything old is new again"), and now some kinds of "foundational" software can stabilize.

But I note that there hasn't been a modern replacement of POSIX, and what POSIX defines is considered hopelessly outdated and limited.

Re: The Curse of NixOS

#184

Post by colordrops »

colinramsay wrote: post #11

> I'm going to keep using it, since I can't stand anything else after having a taste of NixOS This is how I feel about NixOS. I like what it gives me but I don't really like much else about it. Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure. Off the top of my head there are a couple of things I've hit a dead end on recently: - Packaging a Flutter desktop app…

This was a dumb choice by the flutter team. Yes, Nix doesn't provide an easy workaround, but let's not put all the blame on Nix.

Re: The Curse of NixOS

#185

Post by jonringer117 »

octoberfranklin wrote: post #75
rgoulter wrote: post #6

"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…

> the Nix language is about as straightforward as "JSON plus functions". Except that they concoct weird custom terminology for everything . It's not a hashmap, or a map, or an object. No. It's an attrset . Riiiiight. It's not a build script, it's a derivation . Etc, etc.

> It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight.

This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys. Nix was inspired by a research project called Aterm, which did have this property. Also, you can do things like reference other keys in an attr set, which many other dictionary data structures don't support.

> It's not a build script, it's a derivation.

Derivation encapsulates everything which goes into a building something. Dependencies, env vars, flags, sources, patches, the build script, package version, and package name all get packed into a derivation. These paramaters get hashed which is how the hash for the store path gets determined.

Derivations can be thought of an unambiguous build "recipe", which has already resolved based upon all configurable inputs (dependencies, build platform, host platform, target platform) .

https://book.divnix.com/ch04-01-create-a-derivation.html#ins...

Nix is optimized for creating reproducible builds.

Re: The Curse of NixOS

#186

Post by tadfisher »

all2 wrote: post #117
kstenerud wrote: post #87

Earlier quoted context omitted.

The other problem is the condescending replies from the higher tier nix folks while everyone else struggles. I almost think they garner a sadistic pleasure in watching everyone fail. After months of "It's obviously this" and "you're not even trying" and "have you even looked?" and "there are plenty of examples out there already" and "you should start out by reading the introduction docs" and "you obviously don't know…

This right here is enough for me to not even bother tying this OS. I'm always interested in operating systems (and the adjacent config systems that live on top of the Linux kernel, Arch Linux is one of those, Gentoo is another). But I'm not so interested in adding vitriol to my life, no matter the technical excellence. I'd rather live with a mundane kludge than deal with knowledge elitism.

In my experience the Nix community is extremely welcoming and refreshingly vitriol-free. This person isn't representative of the community.

Re: The Curse of NixOS

#187

Post by tomberek »

mikepurvis wrote: post #157
tikhonj wrote: post #146

I've been using Nix and NixOS for a while and I've seen four core advantages: 1. Nix store: what the article covers: multiple versions of the same package, "virtualenv for everything"... etc 2. Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. 3. Flexibility: Nix works for system packages on NixOS as well as user pac…

"... with no system state to worry about" I don't disagree with you, but one of my skepticisms about this is that Docker and Dockerfiles made the same promise like eight years ago, and at least as a small time operator (eg, homelab), it never really felt like the system was as stateless as it was telling me it was. There were always logs, indexes, caches, database content, and all the rest of it, and all of this had…

You can't get rid of all state. The pros/cons of a Nix approach is that it is far more explicit about what is pure/impure. This experience is similar to going from a dynamically typed language to a stronger type system; it can be frustrating to be told that something is not allowed. Nix's usability difficulties often come from trying to build or use software that violates purity in some way (reading HOME directories during compilation, using the network in some way, assuming a dependency will "just be there"); it prevents these mistakes at the cost of forcing the person doing the packaging to fix these issues. This is a huge benefit in the long-term, but can annoy short-term uses.

Re: The Curse of NixOS

#188

Post by chriswarbo »

avakand wrote: post #21

I tried using NixOS on a laptop for a month and switched back to Arch a couple of months ago. It was an interesting experience - I never used functional programming language before, but nix was pretty ok as a configuration language. It looks like funny version of JSON with functions. Debugging it was a real pain though - I was trying to write (or copy from someone else config) a function to recursively import all mod…

> Jetbrains IDEA was updating very slowly and when I wanted to pin a version of it simply overriding version variable in the overlay was not enough - there were also some other linked variables. Emacs package from custom overlay constantly tried to compile itself, requiring me to check build status on hydra build system.

The way I solve this is to import multiple versions of Nixpkgs, since they're all self-contained.

For example, if I'm upgrading from Nixpkgs/NixOS 21.05 to 21.11, and I find that package 'foo' has broken, or been removed, I'll do this in an overlay:

    self: super: {
      foo = self.nixpkgs2105.foo;
    }
Where nixpkgs2105 is a pinned revision of the Nixpkgs repo, defined in another overlay. My current Nix config has pinned Nixpkgs versions going back to 2016. For example, here's a bunch of such overrides:

https://github.com/Warbo/nix-config/blob/master/overrides/fi...

At the moment I'm using niv to manage the pinned Nixpkgs versions (the 'repoXXXX' entries):

https://github.com/Warbo/nix-helpers/blob/master/nix/sources...

Re: The Curse of NixOS

#189

Post by JamesSwift »

qudat wrote: post #155
JamesSwift wrote: post #132

Earlier quoted context omitted.

Coming from docker before nix, I think nix is a better version of docker for some use-cases. If the ecosystem is supported then I much prefer nix for speed (both runtime and development speed)

I agree that when nix works, it's great. However, I find debugging docker infinitely easier than debugging nix. I played around with the idea of adding nix for work projects and getting buy-in from other colleagues. But after working with it for weeks and still running into issues, there's no way I could in good conscience recommend the tool.

Yep, definitely have to be careful about exposing nix to others. I did it on a 2 man team to great effect, but would really have to vet teammates before doing it on a broader scale. I do, however, generally write all of my scripts with nix-shell shebangs to give a layer of consistency/guarantee, and that has had a couple people ask me about it.
Post reply on HN