Live data from Hacker News

Why I love NixOS

birkey.co

201–210 of 323 posts

Re: Why I love NixOS

#201
post #112

Earlier quoted context omitted.

As a NixOS user for 3 years, and a Claude user for 1+ year, I agree with you that it's an ideal fit. I've been very happy with, for example, how Claude can configure GNOME via dconf settings: tweaking those settings declaratively requires cross-domain knowledge and knowing where to dig. But Claude just knows. But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its o…

also the AI hallucinating nix options. I have to constantly check https://search.nixos.org/packages?channel=unstable

oh yeah AI realy does not seem to actually know which packages exist. I once asked AI to create a devenv for some Julia development and it pulled some packages out of its ass that just plain did not exist.

Re: Why I love NixOS

#202
post #116

I feel the same way about Guix with nonguix channel enabled. NixOS is awesome but I prefer Guile to Nix's language and I enjoy the docs more. But definitely sister OSes.

There's nowhere near enough love for Guix. I don't understand it. It has far better foundations. I would never invest time into some "config language". Using a real programming language has huge benefits, and it's a good one (Scheme).

Re: Why I love NixOS

#203

Earlier quoted context omitted.

This feels like a very high-tech solution to a problem that doesn't really exist. Why involve an LLM to install Hyprland when "sudo dnf install hyprland" works fine? I feel like you're mistaking Nix being 'AI-ready' as a feature, when in reality, you're just forced to use an LLM because Nix is too annoying to manage manually.

The key point is that all such tweaks to the system is managed in a one configuration file. While installing Hyprland may be a one-liner, configuring it and all other services from a single entry point is incredibly liberating. Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system…

While nix might be free of side effects, activating a nixos configuration isn't as free as you imply. As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id. And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.

Not an argument against using NixOS - I think the bridge device issue could reasonably be regarded as a bug rather than a fundamental design issue, and the user id/username mapping is a totally reasonable design decision which can be taken into account by forcing the user id numbers anyway.

Re: Why I love NixOS

#204
post #151

Earlier quoted context omitted.

> This is not a language that is optimizing for being written by humans I've taken a look at the code - having never written a line of Guix in my life - and it seems very readable to me. It's cleanly structured and makes good use of indentation. The string "))))))))))", which you claim you're seeing 'regularly', appears exactly twice in 4,580 lines of code. It's the longest parens string that appears in the file. See…

I indeed searched for the longest chain. Something that happens in 4.5k lines twice is hardly rare. And even if you take away a brace it occurs even more frequently. And yes your example is better, but still terrible. The point is not the formatting. The point is that there is that 10 deep nested code is just not easy to understand. I would also say a line of c/python that does 10 nested function calls as unreadable.…

> Something that happens in 4.5k lines twice is hardly rare.

Provided you don't consider the context, sure. One of them is software with buggy tests, the other is one that provides a custom test suite that basically has to be reimplemented in the package definition. How often do you think either of those things happen?

Re: Why I love NixOS

#205
post #174

Earlier quoted context omitted.

It’s like saying you don’t need a version control system for coding, as you can just make a copy of your sources before making important changes.

A snapshot of your build folder. Not even the sources. This is my other problem with mainstream Distros. Extending them is completely opaque. NixOS is source based and anything and everything can be updated by the user. Need some patch from kernel ML? 1 line of code. Need a Bugfix in your IDE that hasn't landed in a release? 1 line of code. There is no distinction between package maintainers and end users. They have…

FWIW... I have modified packages on Fedora and installed them. The workflow is very simple... of course, not as simple as NixOS but here goes:

# clone the package definition

$ fedpkg clone -a

$ cd

# install build dependencies

$ sudo dnf builddep ./nameofpackage.spec

# Now add your patches or modifications

# now build the package locally

$ fedpkg local

# install locally modified package

$ sudo dnf install ./the-locally-built-package.rpm

Re: Why I love NixOS

#206

"Loving" any OS is strange to me. It's just a tool. I don't love my kitchen knife, or car. Nor do I love my computer, or any application on it. Web3, Rust, NixOS. The holy trinity of cult-like appreciation. I do wonder what brings forth such fanaticism.

I love my kitchen knife and I love Emacs. More love is a good thing. Unless you're the kind of person who thinks not loving is better because you've got nothing to lose.

To me, loving inanimate "trivial" things diminishes the value of love. I love my girlfriend and my pets. I like my kitchen knife and my car. To bunch up both into the same category confuses things into "which one do I love the most", some sort of spectrum of love.

In the case of a fire, I'm sure you wouldn't prioritize your laptop with NixOS over your cat (let's imagine that the only backup is in the house that's on fire).

Re: Why I love NixOS

#207
post #199

Earlier quoted context omitted.

Pasting? Give Claude/codex the ability to go fix it itself and have it deal with it directly.

no thank you, there are things I do not want Claude to have rwx on. like my entire f*cking system. I run llms in a docker container with just the folder I'm working in.

If you grant access to the Nix daemon socket but not writing outside the current directory, that's an effective sandbox. It allows evaluating derivations but not actually installing them.

Re: Why I love NixOS

#208

Earlier quoted context omitted.

A snapshot of your build folder. Not even the sources. This is my other problem with mainstream Distros. Extending them is completely opaque. NixOS is source based and anything and everything can be updated by the user. Need some patch from kernel ML? 1 line of code. Need a Bugfix in your IDE that hasn't landed in a release? 1 line of code. There is no distinction between package maintainers and end users. They have…

FWIW... I have modified packages on Fedora and installed them. The workflow is very simple... of course, not as simple as NixOS but here goes: # clone the package definition $ fedpkg clone -a $ cd # install build dependencies $ sudo dnf builddep ./nameofpackage.spec # Now add your patches or modifications # now build the package locally $ fedpkg local # install locally modified package $ sudo dnf install ./the-locall…

Arch Linux also has a long history of people writing their own package specs (AUR) and is relatively simple too of course.

Let me put it differently. The documentation of NixOS treats package maintainers and users as kind of equal.

This has benefits and downsides. Benefit is that everyone is treated as a power user. Downside is that power users are horrible at writing docs and this philosophy is my main theory why NixOS docs are so .... Bad

Fedora (and RHEL) end user and developer docs are written for quite different audiences

Re: Why I love NixOS

#209

Earlier quoted context omitted.

A snapshot of your build folder. Not even the sources. This is my other problem with mainstream Distros. Extending them is completely opaque. NixOS is source based and anything and everything can be updated by the user. Need some patch from kernel ML? 1 line of code. Need a Bugfix in your IDE that hasn't landed in a release? 1 line of code. There is no distinction between package maintainers and end users. They have…

FWIW... I have modified packages on Fedora and installed them. The workflow is very simple... of course, not as simple as NixOS but here goes: # clone the package definition $ fedpkg clone -a $ cd # install build dependencies $ sudo dnf builddep ./nameofpackage.spec # Now add your patches or modifications # now build the package locally $ fedpkg local # install locally modified package $ sudo dnf install ./the-locall…

Bye bye getting automatic upgrades to that package.

Re: Why I love NixOS

#210

The author almost touches on the one more topic that I adore about Nix, but ends up just so missing it: NixOS is absolutely incredible for its ability to be configured through AI tooling. And I don't mean that it's better than other operating systems, I mean that it's the only game in town. I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's point…

This feels like a very high-tech solution to a problem that doesn't really exist. Why involve an LLM to install Hyprland when "sudo dnf install hyprland" works fine? I feel like you're mistaking Nix being 'AI-ready' as a feature, when in reality, you're just forced to use an LLM because Nix is too annoying to manage manually.

[flagged]
Post reply on HN