[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

[squiggleblaz]

Yes I just replied to your other comment with the same observation. It reminds me of an article by Paul Graham, I forget which, who expressed the difficulty of explaining to programmers who lack an abstraction just how good the abstraction is. Anything you can do with NixOS, you can do with any distribution, because it isn't magic. But somehow, more stuff becomes possible because it gives you a better way to think.

(As for why the docs are so bad, I think it's because of the lack of good canonical documentation. There's too many copies of it. Search engines ignore the canonical version because it's presented as one giant document. Parts of the system aren't documented at all and you have to work out what you've got by reading the code. The result is that you have no idea what to do if you want to improve the situation - it seems like your best option is to create new documentation. And now you have the same basic level of documentation that didn't help the first hundred times it was rewritten. And I don't really think submitting a PR to nixpkgs is exactly userfriendly, so it probably discourages people from doing the "I'm just trying to understand this, so I'll fix up the documentation as I learn something" thing.)

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