[Iron_Ninja5]

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.

[wasting_time]

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 configuration.

Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs.

Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).

[squiggleblaz]

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.

[kokada]

> 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.

One reason to set `mutableUsers = false`: https://mynixos.com/nixpkgs/option/users.mutableUsers.

> 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.

Impermanence: https://github.com/nix-community/impermanence.

To be clear, I don't use neither. But you can get NixOS to be almost completely stateless (if this is something you care) with a few changes. The power is there, but it is disabled by default because it is not the pragmatic choice in most cases.

[squiggleblaz]

`One reason to set `mutableUsers = false`: https://mynixos.com/nixpkgs/option/users.mutableUsers.`

That doesn't help. Mutable users is about the lifecycle of the /etc/passwd file. What's I'm referring to is /var/lib/nixos/uid-map.

[diffeomorphism]

How would "bit-identical" or "free of side effects" make an actual difference in practice?

Rollback is already very easy with filesystem snapshots. Configs are already tracked by etckeeper. New laptop: either copy the whole drive or the package list and dotfiles. Also, how often do you have to get new laptops for this to be relevant ?

[Phlebsy]

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 a fresh install then there's a big risk.

NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.

[sidkshatriya]

Here is a simple workflow with mutable systems like Fedora that I think a lot of people are missing. AI could be brought into this workflow also for those who want that:

(1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS)

(2) Make destructive changes like install a new windows manager, some drivers etc.

(3) If everything worked out well, continue

(4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before

This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed.

Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision.

[exitb]

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.

[arianvanp]

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 the same power.

In the meantime i dont expect Debian users to ever write a package themselves or to modify one.

In nixOS you do it all the time

[sidkshatriya]

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 <name of package>

$ cd <name of package>

# 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

[arianvanp]

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

[dezgeg]

Bye bye getting automatic upgrades to that package.

[squiggleblaz]

yes i think you've hit the nail on the head. I tend to view NixOS not as a distribution, but as a distribution framework. The system configuration is the sources for an immutable distribution as much as it as system configuration.

You're in no way bound by decisions of the nixpkgs contributors: as you say, we can add a patch. Or we can also decide we totally disapprove of the way they've configured such-and-such a service and write our own systemd service to run it.

Anyone can write a local debian package which adds a patch, and build and install it. And anyone can write a systemd service and use it instead of the distribution's systemd service. But on NixOS, these are equal to the rest of the system rather than outside it. Nixpkgs is just a library which your configuration uses to build a system.

[sidkshatriya]

I like your analogy and it does make sense.

But note that I did caveat my suggestion: "Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision."

[pkulak]

That’s a great way to get one of the benefits of nix. But you still can check that snapshot into version control, share it with all your machines, etc.

[sidkshatriya]

You're right ... you cant check that snapshot into version control and share with your machines etc. When you need that level of control and need to scale your configuration to other machines NixOS sounds like the right choice. If it's for your own machine and you just want to try out a new windows manager non-destructively use snapshots.

[computably]

Fedora also offers immutable distros which are (I've heard) much more user-friendly than Nix. Sure you can make a hacky pseudo-immutable workflow on a mutable distro but that's literally more effort for a worse result.

[michaelmrose]

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

[codethief]

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.

[kllrnohj]

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.

[riquito]

I was looking at hyperland in Fedora this week. I wanted to try out the latest release (released two weeks ago give or take). It wasn't available yet (maybe it isn't still). That's ok, but I checked what would I have needed to do to build it myself, and I didn't want to mess with a bunch of dev dependencies I didn't really care about and that I would have forgotten, so I ended up not trying it

[wasting_time]

You can just install Nix on Fedora and grab it from there.

[pkulak]

Well,

programs.hyperland.enable = true

is your dnf equivalent on nix. But nix also lets you declare all your key bindings, load Noctalia with systemd, etc.

[jama211]

I think they just mean that the fat that they can do it this way says a lot about the os. No need to get into the weeds on exactly how to install hyprland. It was an example.

People who get bogged down by the details of examples/analogies are usually missing the point of why people use examples/analogies.

[nullbyte808]

Some things are not that simple and nix options come in handy automating other packages and services needed.