Live data from Hacker News

Nix – Death by a Thousand Cuts

dgt.is

261–270 of 336 posts

Re: Nix – Death by a Thousand Cuts

#261

Earlier quoted context omitted.

> good recommended workflows for incoming users Users of what exactly? Workflows for configuring a desktop to play Steam games is vastly different from workflows for managing a cattle fleet of enterprisey servers.

On how to assemble your config. Every config I open does things a little bit different, from the get-go, when using flakes. Add package sets as overlays to nixpkgs or pass inputs downstream? How to parametrize "system"? What's stuff like flake-parts and flake-utils for? Should I use them? All these came to my mind on the first day.

It's not really a "config", it's actually a program that plugins into your infrastructure-as-code process to build system images. As expected, people here love to bikeshed and have vastly different opinions on "best practices".

Re: Nix – Death by a Thousand Cuts

#262
post #252

Earlier quoted context omitted.

eduroam is not your everyday WPA{2,3}-PSK, it's WPA2-EAP. There are official shell scripts to provision certificates, but they only seem to work on major distros, and for some reason the eduroam website made different scripts for every university. Also, for most people this is their first (and last) experience with 802.1X, especially setting it up themselves. In my experience few years ago, it was a pain to set it up…

But then it would suck equally as much on any other Linux distro, NixOS has no relevance here. (I have also suffered from tying to connect to eduroam on Linux laptops).

I assume OP tried to set it up in NixOS config file, instead of using some GUI (such as GNOME's nm-connection-editor).

Re: Nix – Death by a Thousand Cuts

#263
post #68

I love NixOS, it's my daily driver on my personal laptop, but it definitely has given me more than its fair share of headaches. If everything you're going to do is in Nixpkgs, great! Nix will mostly "Just Work" and you'll get all the nice declarative goodness that you want. Since Nixpkgs is constantly getting updated, this isn't that weird of a thing. The thing that's been most annoying to me is when I try and run ge…

Just use Nix/Home Manager on Ubuntu or something instead of NixOS. You get, by far, most of the reproducibility and none of the NixOS issues. NixOS feels more like a great server environment, but not that good of a DE.

I don't think I agree with that. You don't get the system snapshotting, and you can't make your root filesystem tmpfs if you just use Ubuntu + Home Manager.

Re: Nix – Death by a Thousand Cuts

#264

Earlier quoted context omitted.

On how to assemble your config. Every config I open does things a little bit different, from the get-go, when using flakes. Add package sets as overlays to nixpkgs or pass inputs downstream? How to parametrize "system"? What's stuff like flake-parts and flake-utils for? Should I use them? All these came to my mind on the first day.

It's not really a "config", it's actually a program that plugins into your infrastructure-as-code process to build system images. As expected, people here love to bikeshed and have vastly different opinions on "best practices".

I understand that, but even nixos refers to configuration.nix as a "configuration file" in its documentation.

IMO, it's totally OK that people have different opinions on what are best practices. However, I would still like to see official documentation showing beginners how to do things, comparing a few options.

Re: Nix – Death by a Thousand Cuts

#265

I recently tried NixOS 24.11 but quickly decided it’s not for me or something I’d recommend. While the system initially seemed promising, it was frustrating in practice. My first hurdle was configuring the network in configuration.nix. The installed template implies network settings go there, but that’s misleading. Worse, "nixos-rebuild switch" requires a working network, so a broken config leaves the system unable t…

> "nixos-rebuild switch" requires a working network, so a broken config leaves the system unable to fix itself – a catch-22

I just ran into this on an airplane! I'm relatively new to nixos (~4 weeks in) and I had configured my laptop to use DNS over TLS and DNSSEC, which is normally not a problem. But to get through those login gateways for the wifi, you need to disable all of that so they can MitM your DNS requests. "Thats no problem, everything is already in my nix store so I should be able to comment out those lines and run a nixos-rebuild" I thought to myself, but alas I was wrong. I'm sure I could have worked through it with enough persistence but it was a short enough flight that I decided to just wait until I landed to continue my otherwise wonderful journey into the nix.

Re: Nix – Death by a Thousand Cuts

#266

Earlier quoted context omitted.

After spending some time on NixOS I basically decided to hold off until flakes become official and the docs are written with them in mind. In the mean time I just run Arch with Nix home-manager and I'm happy. I've developed enough good habits over the years that I don't get breakages, and home-manager allows me to easily sync my dotfiles across machines..

What makes you reluctant from using flakes? I initially thought I'd never have a need for flakes but after spending an hour on YouTube and Googling, I converted to flakes.

Sorry I was unclear. I’m using flakes, but I don’t want to commit to using NixOS proper until flakes actually get blessed as ready for prod. And yes I know everyone says they are, but I won’t be convinced until the experimental flag comes off.

Re: Nix – Death by a Thousand Cuts

#267
post #175

Earlier quoted context omitted.

Why do you think that? That seems like a pretty extreme viewpoint to me. Stability is a great thing for busy professionals that want stuff to just work. How many apps have you upgraded that have crashed and burned from the update? Me, a lot. both commercial and OSS. With OSS at least you get all the pieces so you can figure out how to put it back together again. With Commercial, you rollback, file a bug report and ho…

To mitigate breakages we should be aiming for better test coverage, at various build levels: class, package, program, system. Our industry's story for system-level testing, for Linux distributions, is poor. NixOS tests are decent, but need more coverage, and something similar needs to be available to upstream so issues are caught during development. Meanwhile, LTS releases have downsides: * Alienating you from upstre…

If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code.

Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long.

> * Alienating you from upstream: why contribute upstream if you'll only benefit from them in 2 years.

I contribute upstream, regardless of if I'm running NixOS, Debian Stable or Windows. It makes no difference to me which OS I'm running when a bug shows up. If I find a bug in X package, I go fix X package. Sure I also fix it locally in my running instance(s), but that's my problem, regardless of which OS I'm running.

> To mitigate breakages we should be aiming for better test coverage, at various build levels: class, package, program, system.

Yes, yes we should. Most software has a terrible testing story. There are very few pieces of software with robust testing. SQLite is one such. One could probably name a handful of others, but after that the list gets really hard to add to.

Re: Nix – Death by a Thousand Cuts

#268

Earlier quoted context omitted.

Most people don't realize that you can read the arch wiki and put the same settings into the nixos options. Where is the point in replicating that all again?

I don't know how to adapt those settings to the corresponding module - there are often differences in naming and hierarchy conventions - and there are other NixOS-specific considerations with regards to its shared-nothing architecture. While it is technically possible to adapt the information in the Arch wiki to NixOS, you need a strong understanding of the software, how it was packaged for NixOS, and NixOS itself to…

Modern modules often have a settings option which directly links to the upstream documentation and you basically write the options from upstream into the settings option.

I look all the time in all kind of sources and skip all the tedious and annoying installation steps and just look at the described configs.

Re: Nix – Death by a Thousand Cuts

#269

Earlier quoted context omitted.

Flakes bring you one interface to share common dependencies which is kot possible without an interface.

That interface could have been built in vanilla nix, though. Instead, a bunch of very useful features are bundled with flakes, like pure eval, eval caching, and git-awareness. But flakes still have some showstopping usability issues preventing users from benefiting from these great features. Issues like that it copies your repo root to the nix store on every evaluation, which scales terribly to bigger repos. Not to m…

Everyone has some opinion. There are the people that say that flakes do to much and others are saying they do to little. No matter in which direction you go, someone is always unhappy.

Eval caching depends on pure eval and pure eval was previously not possible because channels are by design the most impure and cursed thing and are just a bandaid that lasted way to long.

The scaling with big repos gets worse as some use flakes instead of their normal build system which is not the intended use case. You still do development like normal with the normal build system.

Flakes are still unstable because everyone wants something different and there are still breaking changes planned which then everyone would wine about and maintaining backwards compatibility is a pain if you still change fundamental things.

Re: Nix – Death by a Thousand Cuts

#270

Earlier quoted context omitted.

This is why I haven't switched my NixOS to flakes yet. The community discussions always act as though flakes should be the default that everyone should use now, but I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason. So far so good—my system is far more stable than it was under Debian and I've yet to run into anything that didn't have an easy answer. I have a…

I'm glad I'm not the only one who's grinding their gears with flakes. I decided to migrate to flakes because a lot of the documentation for things I wanted to do with NixOS required flakes. It took me at least a few hours to understand what the purpose of them was though. I just wish the documentation would be improved really, as an example https://nixos.wiki/wiki/Build_flags#Building_the_whole_syste... no longer wor…

Be the change you want to see and help documenting the missing parts.

Also that is the old wiki but the same stays in the new one.

Post reply on HN