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

201–210 of 361 posts

Re: The Curse of NixOS

#201

Post by ratorx »

JulianWasTaken wrote: post #106

I too have tried nixOS and nix many times in the past few years (and just recently went back to having a computer with it permanently installed, albeit not my main one). I think another underappreciated reason it's been difficult to use is the CLIs involved are often really arcane (in ways that often remind me of using GNU find, a program I don't think is one that scores high UX marks). For example, uninstalling some…

> you get to run `nix-collect-garbage` manually

If you mean running NixOS (the distro), rather than just Nix (the package manager), then there’s an option for this `nix.gc.automatic`. You may also want to look at `nix.optimise`. When using just Nix however, I don’t know if they bundle the timers.

Re: The Curse of NixOS

#202

Post by amarshall »

AshamedCaptain wrote: post #52
amarshall wrote: post #38

Earlier quoted context omitted.

This can be avoided my not overriding the package attribute, but instead creating a new one and then only using that as-needed. What you describe as a deal-killer is just purity and safety. Updating a build input gives no guarantee that the build output will be the same or even work. Sure, as smart humans we can say “I know this change does not impact X, so it’s fine”, but NixOS is based partly on the claim that we d…

> What you describe as a deal-killer is just purity and safety. It's not really "pure" since you are packaging software with side-effects to begin with. Even if you use the same text bit by bit it's also no guarantee that the output will be the same or that even it will work. You are still relying on some human claiming that it will do. So the advantage is not really that big in practice, and the disadvantage means r…

Sure, if you have a program that outputs a random number, NixOS doesn’t make it suddenly always output the same number (would one even want that?). Nix aims to remove side-effects from the build system (and some aspects of the execution environment), not from within the program itself. Whether the program itself is pure is up to it, not NixOS. But the point is that NixOS eliminates whole classes of why the output may be different.

Re: The Curse of NixOS

#203

Post by taeric »

AceJohnny2 wrote: post #183
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 int…

This can really only work if we accept that some things will not change. Only software I know that did this is TeX.

And it was deliberate there. He acknowledged that done things could be improved. Or just done differently. But, he made the choice that it is a foundation for a lot of other code, so bug fixes only.

Edit: I should say explicitly that I agree with you. And I am interested in how this can be solved otherwise.

Re: The Curse of NixOS

#204

Post by assbuttbuttass »

tomberek wrote: post #154
assbuttbuttass wrote: post #8

As a NixOS user, I like this article a lot. But one thing stood out to me: > It also means that it's impossible to statically know what other packages a given package might depend on. Currently, the way this is implemented is essentially grepping a package for /nix/store/ to try to figure out what the dependencies are, which is obviously... not great. I'm not sure what the author is talking about here. He says it's i…

Just like any other package manager, this information can be queried without grep. nix-store --query --references /run/current-system # or with new CLI: nix path-info --recursive /run/current-system This information is managed and tracked for you. And while I understand the desire to have "normal" FHS paths, the hashing and the injection of the hashes (think "tags") is exactly the mechanism that makes dependency trac…

Right, after the package is built the dependencies are stored with the package metadata like any other distro.

Re: The Curse of NixOS

#205

Post by outworlder »

The Nix package manager is amazing. I'm currently using it on my work OSX machine (instead of homebrew). It works well (with home-manager).

The author is spot on about the language though. I don't understand why people have to keep reinventing the wheel and designing bad languages when good options exist. At least they didn't use YAML...

Re: The Curse of NixOS

#206

Post by deckard1 »

112 wrote: post #93

Ranting about Nix being hard is like going to Russia and complaining that the local language doesn't sound English. Like many other things worth your time, it's something you learn through deliberate practice and focus.

There are many things that require tremendous practice and study that aren't worth your time as well.

You have to justify it somehow. And I just don't see the value prop in Nix yet. I would compare it as such: Nix is to Docker what Google+ was to Facebook. Maybe it's superior. But the benefits are so marginal that the costs of switching will prohibit most from giving it a shot. Most people want reproducible builds and easy configuration. If they are getting that from Docker, why switch?

At the distro level, average people are going to benefit by having reproducible builds done upstream. Debian does this, IIRC. As does F-Droid and a few others. If you trust Debian, then you implicitly trust the packages Debian installs.

NixOS doesn't even solve the real aspect of Linux that I find terrifying: security. Linux is a blob of overlapping and bewildering security mechanisms and tools. You have groups, permissions, SELinux, capabilities. The whole thing leaks like a sieve.

Re: The Curse of NixOS

#207

Post by hypersoar »

I've been using Nix for about a year. I don't use NixOS but home-manager and nix-darwin. Just about every single time I've tried to do something new, it has ended up being way more complicated than I thought at first.

- Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop.

- Setting up a local environment for a Go project? No problem. Er, except some tools need to be installed globally, quite against the Nix philosophy.

- For a system or home configuration, you'll encounter packages, modules, and flakes. Packages are explained in the Nix documentation. The functions people actually use to make packages are explained in the Nixpkgs documentation. Modules are explained in the NixOS documentation. And flakes are explained in...uh...well, you'll figure it out. (You don't need flakes at this point, but they're on their way. And they won't replace packages entirely.)

- Debugging? gl,hf

- And this is all before we get into my admittedly complex system configuration using flakes, nix-darwin, and home-manager. Some things need to be set up at the system level, others at the home level. And cross-referencing the two is a pain. I just got an M1 mac. Some packages need to have their x86 versions installed, against Nix's protestations. I appreciate the guy who made a configuration framework that figured out how to do this, because I certainly couldn't.

Anyway, I love it.

I think it's the mathematician in me. The whole idea is too aesthetically pleasing for me to resist. The hope of having everything placed just so by a mere wave of my hand, too tempting. Damn the consequences.

Re: The Curse of NixOS

#208

Post by xxpor »

alpaca128 wrote: post #43
globular-toast wrote: post #7

Earlier quoted context omitted.

Is the author aware of Guix?

Apparently not, or forgot about it when writing the article: > it's so clearly the only operating system that actually gets how package management should be done

Isn't Guix just nix with guile?

Re: The Curse of NixOS

#209

Post by mindslight »

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…

I think your reasons are focused on Nix for package management. For NixOS specifically, I would add:

5. It's essentially a source distribution with caching. If you want to add say a kernel patch, or any other type of patch, it's straightforward. Whereas running Debian and finding the solution to some problem is building a modified package, my usual conclusion was just to bear the problem until it was fixed upstream, rather than suffer the maintenance burden.

6. The top-level config is front and center, and stateless. No messing about with update-initramfs, wondering what the heck the initrd is actually doing etc.

7. Taming the complexity of system software's configuration state. For example, there is no mucking with the systemd mess of /etc/systemd vs /lib/systemd and its assorted symlinks, as this configuration is handled at a higher level.

And for Nix I'd add

8. Dead simple cross (or emulated) compilation toolchains. Building A Cross Compiler used to be a Big Deal, with Nix it's basically like any other declaration to build an entire cross/emulated environment.

Re: The Curse of NixOS

#210

Post by xxpor »

rekado wrote: post #144
light_hue_1 wrote: post #85

Earlier quoted context omitted.

Oh yeah, nonguix. What a mess. An unsupported pile of packages that break regularly. And if you dare ask a question about it in any official forum you're kicked out. Nix has its issues, but guix is ideologically radical in a extremist "We don't care if your machine is unusable, enjoy your freedom", kind of way.

Wow. Not true. You're not kicked out if you "dare" (how brave!) ask a question about it. You're welcome to chat about it on #nonguix. Is it really that hard to accept that #guix is not #nonguix and that we don't discuss proprietary software on the main channels?

There's two kinds of projects:

Those who care about ideology

And those that want things to actually work and get stuff done.

The second group is the one that wins all of the users. Of course, there's room for both types of projects in the world. But don't be surprised when people who don't want to waste time on a political discussion that doesn't effect their lives in any way don't want to put up with it.

Post reply on HN