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

221–230 of 361 posts

Re: The Curse of NixOS

#221

Post by civodul »

zeec123 wrote: post #138
snicker7 wrote: post #103

Guix configuration is in Lisp, a well-established language (60 years and still strong). Moreover, Guix package code is written in a clear, declarative style. Nix package definitions, on the other hand, typically embed shell scripts in them.

Yes, but systemd is missing and most drivers because they are not gnu.

Guix System uses Linux as its kernel, so no driver "is GNU", whatever that means.

The choice to use the Shepherd rather than systemd is motivated by a vision that we can get better integration using a single language and set of tools all the way down. As an example, this gave us services in containers several years ago:

https://guix.gnu.org/en/blog/2017/running-system-services-in...

Overall Guix System alone gives a coherent and unified view of the system; systemd also does that to some extent, but it's not in as good a position as Guix's declarative OS configuration to do that. For example, this is the kind of system exploration that Guix enables:

https://notabug.org/civodul/guix-explorer

Re: The Curse of NixOS

#222

Post by floatingatoll »

seddona wrote: post #95

Interesting to see exponential growth in NixOS github stars https://star-history.com/#NixOS/nixpkgs&Date . Perhaps the user base is reaching a tipping point where there will be the resources to address some of these problems.

What fraction of those who starred a project on GitHub become committers to and/or donate more than once to it?

I've always assumed that this is a vanishingly small amount, on the order of one in ten thousand or so, but I could be underestimating.

Re: The Curse of NixOS

#223

Post by mikepurvis »

tomberek wrote: post #187
mikepurvis wrote: post #157

Earlier quoted context omitted.

"... 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…

Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself.

Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocoproject/poco/pull/3105

Re: The Curse of NixOS

#224

Post by Ericson2314 »

I understand the first complaint but not the second

> The second flaw is that NixOS does not actually provide real isolation.

I thought this would going to be about security, but then it was about having to repackage the world. But Nixpkgs is current the biggest and most up to date package repository in the world (we finally beat AUR). Packaging enough stuff is emphatically not the problem.

What I want to see is development be easier with Nix, because winning over the hearts and minds of upstream developers is the final frontier. To that end I wrote https://github.com/NixOS/rfcs/pull/92 and https://github.com/NixOS/rfcs/pull/109.

As a side benefit, autogenerating more Nix means less handwritten Nix! I do think people give the language itself to much grief when the problem is more the library side with the copious override shenanagins and other stuff.

Re: The Curse of NixOS

#225

Post by Ericson2314 »

jeofken wrote: post #115

Does anyone have some tips on how I can partition an EFI laptop for NixOS with full disk encryption? I’m struggling to install NixOS on my Librem 14 - and have resolved to Ubuntu as it does all that for me.

Use LUKS, don't use LVM.

I do that with ZFS for all the non-ancient stuff in github.com/Ericson2314/nixos-configuration

Re: The Curse of NixOS

#226

Post by pimeys »

AceJohnny2 wrote: post #215
dqv wrote: post #212

Earlier quoted context omitted.

>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. Just don’t use emacs ;) In all seriousness, were you pulling from unstable? Disallowing installation because the hydra build is failing has gotten me, albeit for an obscure package I never use. >And flakes are explained…

> I finally figured out the weird incantation to get flakes to work. It was not trivial. Care to share with the class? ;)

For the system, I like the devos template:

https://github.com/divnix/devos

The idea of flakes is how you define inputs, and you define the system (and packages, and shell etc.) in the outputs using the inputs. The inputs are git repos which point to other flakes. You can mix and match these as much as you want (see the devos repo for examples) and when you build the derivation, it generates a lockfile for exact commits in that point in time what were used in the given inputs.

You commit the lockfile and in the other systems where you pull your config from the repo, it uses exactly those commits and installs the same versions as you did in your other systems.

This was quite annoying and hard to do before flakes. Now it's easy.

The problem what people face with building their system as a flake is combining the packages so you can point to `jq` from the unstable nixos and firefox from the stable train. I think this aspect needs better documentation so it wouldn't be so damn hard to learn (believe me, I know). Luckily there are projects like devos that give a nice template for people to play with (with documentation!)

Another use for flakes is to create a development shell for your repo, an example what I did a while ago:

https://github.com/pimeys/nix-prisma-example

Either have `nix-direnv` installed, enter the directory and say `direnv allow`, or just `nix develop` and it will gather, compile and install the correct versions of packages to your shell. Updating the packages? Call `nix flake update` in the directory, commit the lockfile and everybody else gets the new versions to their shell.

Re: The Curse of NixOS

#227

Post by tikhonj »

throwaway894345 wrote: post #198
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've tried to use Nix on and off for years. I always run into issues where I need to write some package and (1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible (2) Basic things like figuring out the argument types for a particular nixpkgs function take an insanely long time. It always involves grepping around the whole repo (nixp…

Yeah, I've had that similar experience too, and I'd love to see an approach that can fundamentally improve on this axis.

The way I see it, it's the foundational ideas that are important—but there are a few key principles beyond the one covered in the blog post.

Separately, today, I think the foundational advantages Nix has more than justify the learning curve—but that's a less obvious idea and I understand why it's hard to convince other people about it :).

Re: The Curse of NixOS

#228

Post by silasdavis »

I've been running NixOS for 2 months having had my eye on it for a while.

So far I feel like I'm making progress. Having started from the masochism of Gentoo followed by the relatively lesser masochism of Arch my feeling is at least these hours of configurating are not being poured into the void but will have a substantially longer payback period. Reinstalling Arch or Gentoo always inevitably involved a large amount of remembering long forgotten config incantations which despite a certain number of git configuration repos for system and home and some scripted installation tended not to avoid a significant amount of tedious unfulfilling grunt work at the bootstrapping console.

Mind you I'm interested in views from those who are further along and feeling the pain. I can well believe that that getting to the first '80% how I want things' configuration might be much easier than the next 10% on the same path.

I'm using unstable, flakes, and home manager as a module in the main configuration.nix.

The language doesn't feel particularly arcane or difficult though so I don't relate to that complaint yet. As others have mentioned. A few fairly standard functional features (recursion, destructuring, first class functions) plus JSON sounds about right.

Re: The Curse of NixOS

#229

Post by selestify »

mikepurvis wrote: post #223
tomberek wrote: post #187

Earlier quoted context omitted.

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…

Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself. Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocopro…

What are the well-understood reasons? It seems weird to me, as someone who hasn’t worked on open source, that the PR would just sit there untouched and not even commented on

Re: The Curse of NixOS

#230

Post by pimeys »

silasdavis wrote: post #228

I've been running NixOS for 2 months having had my eye on it for a while. So far I feel like I'm making progress. Having started from the masochism of Gentoo followed by the relatively lesser masochism of Arch my feeling is at least these hours of configurating are not being poured into the void but will have a substantially longer payback period. Reinstalling Arch or Gentoo always inevitably involved a large amount…

It's a pretty good ride still (depending what you need). I tend to run a tiling wm with lots of customization and it's great to just have all these tools and behavior synced everywhere. I build emacs from scratch with lots of packages and special config. I have neovim with all the goodies, firefox installing with the plugins and config I want.

All automatically synced between my machines. I also really pushed myself to learn to maintain nixpkgs. It's been tough, but definitely worth it.

Config, if you want to take a look: https://github.com/pimeys/nixos

Post reply on HN