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

231–240 of 361 posts

Re: The Curse of NixOS

#231

Post by jeofken »

Ericson2314 wrote: post #225
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

Why avoid LVM?

If you could point me to a practical instruction on how to get it running I’d be very thankful! I’m sure I’m missing something basic - as is usual when struggling with UNIXes…

Re: The Curse of NixOS

#232

Post by mst »

ris wrote: post #191
2pEXgD0fZ5cF wrote: post #48

Earlier quoted context omitted.

Same here, tried NixOS for ~3 months, I tried to go all-in too, I spend time to really read the docs and work out an intricate configuration that leverages features like flakes and covers my system setup and dotfiles (got inspired by Lissners NixOS configuration) and was ready to handle multiple systems in preparation to roll it out to my 2nd and 3rd machine. Ultimately there were warts that I was able to solve, but…

I honestly think that Nix is one of those things where "going all in" is one of the worst things you can do. Running a desktop system on NixOS is quite a tricky prospect for someone with no experience of Nix and you'll likely get frustrated with having to learn some potentially alien concepts to achieve simple things. I tend to recommend people start in the shallow end, using Nix on a regular Linux distribution (or e…

Being able to spin up an entire network of qemu+kvm VMs easily to do proper integration testing of my system configs was a revelation.

Re: The Curse of NixOS

#233

Post by kitsunesoba »

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…

Did they ever fix the need to disable SIP for nix to work on macOS? That made trying it out a nonstarter when I looked into it 2 or 3 years ago.

Re: The Curse of NixOS

#234

Post by jonringer117 »

floatingatoll wrote: post #222
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.

Currently, there's 8.7k stars, 7.2k forks. And 2000+ maintainers have added themselves: https://repology.org/repository/nix_unstable

So, I would say a pretty large portion.

Also, the contribution model for nixpkgs is just opening a PR, so it's a fairly low (non-technical) barrier-to-entry for most contributors.

Re: The Curse of NixOS

#235

Post by mst »

mikepurvis wrote: post #199
FRidh wrote: post #178

Earlier quoted context omitted.

This is indeed not very good. Note there is a reason that overridePythonAttrs exists: it overrides the call to buildPythonPackage instead of mkDerivation. There is/was an RFC on standardizing overriding in Nixpkgs but it got stuck. I think for these things to improve what is really necessary is funding to improve Nixpkgs. These kind of issues are fairly hard to solve as they span multiple ecosystems and require coord…

Oh, of course, and in my case it was an important discovery, because my custom packages were all also defined in terms of my own mkDerivation-wrapping function, so I happily copy-pasted the definition of overridePythonAttrs to make my own overrideMyAttrs version of it. But it was brutal that I had to just stumble across this. I think the article correctly identifies that there is decent enough documentation in Nix fo…

The language reference worked out fine for me but the chasm between "basically running" and "knowing what I'm actually doing" has been substantially painful and I'm still not on the other side.

Though I say this while continuing to slog through said pain as I find time because once I've learned a particular thing it's always felt like it was worth the effort to get there.

Re: The Curse of NixOS

#236

Post by mikepurvis »

selestify wrote: post #229
mikepurvis wrote: post #223

Earlier quoted context omitted.

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

I'm not seeing an easy reference right now, but I feel like a number of articles bemoaning the state of open source maintainership have come up over the years, particularly in conjunction with high profile security issues like the ones in the OpenSSL and log4j projects.

But in short, the maintainers are mostly uncompensated, and therefore have no sense of urgency or obligation to a faceless stranger making a drive-by contribution. Every accepted contribution is something that has to be understood, supported, and even justified by the project's maintainers going forward, so each one is an opportunity to take on more work and risk, and obviously by definition almost all them are things the maintainers didn't themselves "need" or they would have done it themselves. So each new branch or bugfix is relevant to a codepath that no one involved in the planning, testing, or release-preparation for that project has a first-class stake in. Each new capability added is an opportunity for there to be shrieks following a release because it was inadvertently broken in the course of some other bit of development.

Re: The Curse of NixOS

#237

Post by jeppesen-io »

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.

I'd recommend LUKS. NixOS has a guide in the wiki but if you're looking for an example, see my nix readme. Might have a typo or two but it's 99 percent there

https://github.com/NelsonJeppesen/nix-lifestyle#luks-encrypt...

Unencrypted boot with LUKS root, nothing fancy

https://nixos.wiki/wiki/Full_Disk_Encryption

Re: The Curse of NixOS

#238

Post by jonringer117 »

StreamBright wrote: post #213

> The first is relatively simple: they developed their own programming language to do configuration Exactly this. I do not understand why did they do that.

Because it's a domain-specific-language, optimized for packaging software.

The relevant passage:

> Its only purpose is to describe components and compositions. A component is created through the derivation primitive operation, which accepts all information necessary to build the component. This includes its dependencies, which are other derivations or sources.

Full phd thesis: https://edolstra.github.io/pubs/phd-thesis.pdf

Re: The Curse of NixOS

#239

Post by silasdavis »

pimeys wrote: post #230
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…

Thanks for the config it looks interesting and quite mature, the possibility of sharing such kind of has me on board.

Incidentally I was coming from i3 (xmonad before but wanted something I could switch over to wayland where I could watch video like its 1995). Never in love with configuring all my own task bar, power management, disk mounting, screenshot program, rubbish task launcher with no icons, etc. but did it anyway for the sake of beautiful ceramic tiles... I've been playing with pop shell gnome extension for creature comforts, which via dconf plugin of home manager actually seems text configurable. Not that I've done it yet.

See you are using sway, ever considered going IKEA with gnome?

Re: The Curse of NixOS

#240

Post by jonringer117 »

dangus wrote: post #169

Something that perhaps detracts from the positives of NixOS is that a lot of the tools that have the biggest issues with the need/difficulty of dealing with multiple versions and environments have long ago come up with their own solutions to the problem. Python has pyenv, NodeJS has nvm, Terraform has tfenv, and the list goes on. Then if you're running on a server/VM/cloud, it seems to me that you should be treating…

> Python has pyenv, NodeJS has nvm, Terraform has tfenv, and the list goes on.

Nix makes these all largely irrelevant, in a consistent way. If anything I would say this supports nix's usage.

> Then if you're running on a server/VM/cloud, it seems to me that you should be treating your systems as cattle instead of pets. I never update packages on servers, I build a new image/instance, test it, and replace the server.

You can do this is nix as well. You can take a configuration.nix and ship it as a version controlled file, an iso image, pxe boot image, ami, vhd, or other formats.

> I wonder if some of the benefits of NixOS were either solutions looking for problems or solutions where better solutions rose to prominence.

I don't think so: https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-...

> I haven't even started talking about containerization, either!

Containers generally take an impure process and create a "snapshot-in-time". Nix allows you to "hydrate" your configuration in a reproducible and repeatable fashion. OCI images can only really be layered, can't be composed, and commands like `sudo apt-get install` or `pip install` also makes the runtime behavior dependent on when the image was created.

Post reply on HN