21–30 of 51 posts
For the same reason, I don't think I will ever move off of Nix again. Once something works, it works reproducibly. I can always go back to a known-good state if I break something. This gives me freedom to experiment that I would otherwise not permit myself for fear of breaking an important workflow.
I like Nix but I think the current model of reinventing a new set of declarative configuration settings for each package is fundamentally misguided and will not scale in the long term (look at the number of program-specific options in Home Manager for example). The nice thing about container-based systems is that all the existing documentation for configuring a given program continues to apply as expected. Of course…
I first learned about Nix about 10 years ago. And back then I thought exactly this – it can't scale.
But I'm pleased to be proven wrong.
Earlier quoted context omitted.
I'd say adopting JSON/YAML.
I rarely downvote on HN, but when I do, it must be a comment promoting JSON over any other configuration language (sorry) Nix isn't even that arcane. Its documentation simply sucks. Once you grasp the idea, it feels almost great
It's somewhat quirky though :)
https://nixos.wiki/wiki/Nix_Language_Quirks
https://md.darmstadt.ccc.de/xtNP7JuIQ5iNW1FjuhUccw
(but then again, what language isn't...)
I only got started with NixOS a couple of weeks ago and I must agree. I would never consider running Nix on my daily Desktop machine (I'm using Arch BTW). It's more work and hassle than it's worth it. OTOH I just set it up as the base for my new DIY NAS. There it is limited to just the bare minimum of bringing the system up and providing some core services (including Samba). And for this I found Nix' declarative appr…
How much of this is really just unlearning what you have learned, and needing to internalize the Nix way of doing things which may allow more flexibility in the end?
Better fix your about page ;) I've dabbled in NixOS and come to many of the same conclusions. The learning and troubleshooting overhead just isn't there yet (for me). I appreciate the concept and I do think declarative configurations do have a place in the near future, especially in corporate environments. I'll probably give it another go in a year or so to see if it's gained any more polish.
There once was a post "The curse of Nix", or something like that, with the main idea that Nix isn't perfect, but once you tried it, everything else seems even worse. For the first six months of using NixOS I couldn't run anything but a browser (I'm exaggerating a bit), yet all attempts to get back to Arch failed for me. Now it's been over 4 years of having NixOS on all my computers, from Laptops to ARM SoCs driving m…
I've been using it for a few years now and I still feel a little confused, but asking llms explain nixos has been immensely helpful. If I'm feeling really lazy, I just ask claude to generate the specific nix code for whatever I need that doesn't work or exist in nixpkgs.
Earlier quoted context omitted.
I had the opposite experience. I started using it as a daily driver around 10 years ago and could never to back to anything else. It's just super solid and once you have it configured it just works forever. I agree that the learning curve is pretty steep, especially if you want to use something that's not in nixpkgs but those things are vanishing day by day.
Yeah, for all the blog posts about quitting NixOS there's plenty of us who continue using it. I don't think it's just the steep learning curve though, I think it's just not for everyone. You _have_ to enjoy side quests where you dive deep into hairy problems, and effectively be willing to front load effort into setting up an environment so that it works well for you in the long term.
Earlier quoted context omitted.
Yeah, for all the blog posts about quitting NixOS there's plenty of us who continue using it. I don't think it's just the steep learning curve though, I think it's just not for everyone. You _have_ to enjoy side quests where you dive deep into hairy problems, and effectively be willing to front load effort into setting up an environment so that it works well for you in the long term.
I think OP sums it up pretty well. If there isn't an existing module or one that does exactly what you want, your only way forward is to program your way out of it. That's just not something I want from my daily driver of a distribution. It doesn't help that this programming happens in a weird (to me) functional language.
And that's fine! People are different, there's no way one OS is the best choice for everyone. :)