Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I love NixOS

birkey.co

Post reply on HN
Print view View original

251–260 of 323 posts

Re: Why I love NixOS

#251

Post by rounce »

erichocean wrote: post #12

What I'd like to see is Omarchy implemented via the Nix package manager. (Seems like a good project for AI, actually.)

Why? Most people’s system configurations are publicly accessible on GitHub. Stuff like Omarchy only makes sense* when the system must be configured imperatively and there is a cost to trying things (accumulation of application residue). When you build your system declaratively you can just copy the bits you like from other people’s configs, or even just run their config as-is.

* IMO Omarchy doesn’t make sense anyway, far too much opinion and too little utility. It’s not a distro it’s some guy’s overly promoted pile of crufty scripts and dotfiles.

Re: Why I love NixOS

#252

Post by kiliankoe »

loremm wrote: post #3

This is niche and HN is full of these back and forth comments. One thing which a particular type of crowd will appreciate is being able to apply simple patches to constantly-up-to-date packages. For an example, I love atuin but it, by default, skips commands starting with space. Currently it's not configurable and while I wait for time to submit a PR or for the issue to be resolved, make a single line `patch` which j…

I'm just curious what your motivation for the patch is, because I too use atuin and see the space-prefix as a feature. It's been around for a while (longer than atuin) to keep certain commands out of my history on purpose, like when running some one-off command with credentials as an arg.

Other than that I very much agree, patching stuff is wonderful in nix-land! Especially when things in nixpkgs-unstable break.

Re: Why I love NixOS

#253

Post by codethief »

michaelmrose wrote: post #168
Phlebsy wrote: post #164

Earlier quoted context omitted.

The problem that exists is that you cannot just willy nilly try out entirely different desktop envs/window managers/audio frameworks on an existing install of any other distro and be certain everything will work exactly as it was when you remove it. Especially as an only moderately knowledgeable user that won't know every single piece of config that needs to be changed back. Unless you're trying everything new out on…

Actually desktop environments are entirely modular and even audio stacks are just a few packages and enabling a few services

Man, I still remember what a pain the migration from PulseAudio to Pipewire was. Sure, it's only a couple packages, disabling a few services, enabling a couple others. But I had to do this almost on the daily, while bugs in Pipewire/Wireplumber were still getting ironed out and were rendering my audio stack temporarily unusable.

Re: Why I love NixOS

#254

Post by codethief »

stephen_cagle wrote: post #60
DHolzer wrote: post #55

I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much. Sometimes I even prefer nix-shells over uv for quick one-off Python scripts. I cannot sufficie…

Have you heard of any good projects for running isolated containers in NixOS that are cheaply derived from your own NixOS config? Because that is what I want. I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system". Basically, I want to be able to run completely unverified code off of th…

https://spectrum-os.org/ is trying to marry QubesOS (everything runs inside a VM) with Nix. It's still very much in development, though.

Re: Why I love NixOS

#255

Post by bjoli »

rowanG077 wrote: post #92
Pay08 wrote: post #83

Earlier quoted context omitted.

It reads almost the exact same as any functional C-style language. Not to mention that specifically for Guix, you're going to be writing the (name value) form for 99% of it.

I don't agree at all. Just look at these derivations: https://codeberg.org/guix/guix/src/branch/master/gnu/package... I counted and you regularly see this: "))))))))))" at the end. This is not a language that is optimizing for being written by humans.

Which is the most tired critique of lisp ever. Even the text editor on my phone can keep parens balanced for me.

S-expressions were supposed to be replaced by a more user friendly syntax. The trade offs were not worth it and every try to replace sexprs failed.

If it is such a problem you can use wisp to write your packages.

https://www.gnu.org/software/guile/manual/html_node/SRFI_002...

Re: Why I love NixOS

#256

Post by codethief »

laserbeam wrote: post #192
DHolzer wrote: post #55

I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much. Sometimes I even prefer nix-shells over uv for quick one-off Python scripts. I cannot sufficie…

Can you share some good examples of how you use nix shells with python for one off scripts? I am still figuring out how python interacts with nixos :(

Do you have to figure this out? Sure, it's nice and "pure" if everything is configured through Nix but there is something to be said about being pragmatic. Personally, I just enabled nix-ld[0] and use uv to install and handle my Python versions and package dependencies. Much, much easier.

[0]: https://mynixos.com/nixpkgs/option/programs.nix-ld.enable

Re: Why I love NixOS

#257

Post by dml2135 »

beepbooptheory wrote: post #126
hombre_fatal wrote: post #101

Earlier quoted context omitted.

The upside of Nix config is that it's the state of my system in a declarative config file. I have these packages installed and these firewall settings and these users with these permissions and this folder served over Samba and these hotkeys that do these things and these Obsidian vaults synced over SyncThing and these devices in my SyncThing network and Neovim installed with these plugins and ... This is difference…

But if you are not reading or comprehending the config file, why does it make any difference? You ask AI to purge ffmpeg from your system, it will probably know more about doing that with apt than with nix, right? And if the input on your end is "remove ffmpeg from my system" or whatever either way , what's the need for nix? You will be much happier just editing /etc files and such in the standard way, rather than ho…

For me, the difference is that there is no way in hell that I want to give an AI assistant full access to configure my system live. With a declarative config, the only access it needs is to an isolated git repo.

Re: Why I love NixOS

#258

Post by perrygeo »

codethief wrote: post #256
laserbeam wrote: post #192

Earlier quoted context omitted.

Can you share some good examples of how you use nix shells with python for one off scripts? I am still figuring out how python interacts with nixos :(

Do you have to figure this out? Sure, it's nice and "pure" if everything is configured through Nix but there is something to be said about being pragmatic. Personally, I just enabled nix-ld[0] and use uv to install and handle my Python versions and package dependencies. Much, much easier. [0]: https://mynixos.com/nixpkgs/option/programs.nix-ld.enable

Easier and largely compatible with the rest of the world. Solving problems with "If we all switched to NixOS..." is a non-starter in most organizations.

My rule of thumb: keep a strict separation between my projects (which change constantly) and my operating system (which I set up once and periodically update). Any hard nix dependency inside the project is a failure of abstraction IMO. Collaborating with people on other operating systems isn't optional!

In practice this means using language-specific package management (uv, cargo, etc) and ignoring the nix way.

Re: Why I love NixOS

#259

Post by kllrnohj »

Iron_Ninja5 wrote: post #159
alembic_fumes wrote: post #104

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.

I use Nix for my homelab servers, and I'm using AI to be my IT support staff essentially. I don't need to ask AI for help installing hyperland, that is trivial as you say, but setting up nginx port forwarding? samba configs? k3s or k8s? Yeah individually any one of those things isn't very hard. But instead of spending 30 minutes reading through config examples and figuring out where it's setup I can instead spend 30 seconds just telling AI what I want, skimming the output to see if it's looks reasonable, and then doing a good ol' `git commit` of the config file & kicking off the "now go do it" nix build command.

And, critically, at no point does an LLM ever have access to sudo, shell, etc.. It just works with plain text files that aren't even on the machine I'm deploying it to.

Re: Why I love NixOS

#260

Post by JamesSwift »

Novosell wrote: post #226
JamesSwift wrote: post #135

Earlier quoted context omitted.

Generally something like languages.javascript.enable = true languages.javascript.package = pkgs.nodejs_24

24 != 24.14.0

If you care about the _exact version you are pinning_ (even though you will guarantee the pin between team members without needing to do this step), you can either pin nixpkgs repo to the state that had that version, source the target version directly, or for some ecosystems (eg ruby) you can just specify a version with a number and it has tooling to resolve that using "traditional" approaches.

In general though when working on a team, you dont really care about the _exact semver version_, you care about the major and handle version bumps by bumping the pin of nix packages.

Post reply on HN