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
Why I love NixOS
201–210 of 323 posts
Re: Why I love NixOS
#202I 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.
Re: Why I love NixOS
#203Earlier 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…
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
#204Earlier 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.…
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
#205Earlier 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…
# 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.
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
#207Earlier 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.
Re: Why I love NixOS
#208Earlier 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…
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
#209Earlier 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…
Re: Why I love NixOS
#210The 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.