45
submitted 2 years ago* (last edited 2 years ago) by wwwgem@lemmy.ml to c/linux@lemmy.ml

I've been curious about NixOS for quite some time. Reading about it I couldn't see how the config sharing capabilities, setup, or rollabck would be better than Arch and sharing the list of installed packages, using downgrade or chroot.

So I decided to run NixOS in a VM and I'm still confused. An advantage I can see for NixOS is its better use of cores and parallel processing for packages install.

It's clear that I'm missing something so please help me understand what it is.

Edit: Thank you to everyone in this great community! It's always so nice to have a constructive and sane discussion.
After reading so many comments, they all confirm what I've read before and I may realize that my real problem is already having a stable system and no need for the great NixOS options that are very neat but would not benefit my specific and simplistic needs. That being said I can't refrain myself from being curious and will continue testing NixOS.

The need for only 2 config files is the top of the iceberg but hiding more complex configuration to rely on. Not that I really have too much spare time but I do enjoy learning and tweaking NixOS. With its current development state, things are changing a lot so it can keep me busy for months. That's probably what I was mostly looking for: another toy to play with.

Along my journey I will learn a lot about NixOS and may find a feature that will motivate my switch to it. Thanks again for all your precious feedback!

I'll also take this opportunity to share the best help I've found so far to start with NixOS: https://github.com/MatthiasBenaets/nixos-config And his 3 hours (!) video: https://m.youtube.com/watch?v=AGVXJ-TIv3Y

top 50 comments
sorted by: hot top controversial new old
[-] kionite231@lemmy.ca 15 points 2 years ago

for me personally I like to be able to install software temporarily using nix-shell command it's awesome. the installed program will be gone once you leave the nix-shell. It's just awesome for me.

[-] neosheo@discuss.tchncs.de 3 points 2 years ago

Don't forget to run nix-collect-garbage tho. The program is actually still installed, the symlimk to $PATH is just deleted after exiting the nix-shell

I agree, but you don't need nixos if that's all you want since you can get nix-shell on most linux distros

[-] wwwgem@lemmy.ml 2 points 2 years ago

That's indeed pretty neat.

[-] onlinepersona@programming.dev 13 points 2 years ago

Better in some ways, but it has the worst documentation of any distro I've seen so far. https://nixlang.wiki is trying to improve that

CC BY-NC-SA 4.0

[-] Laser@feddit.de 12 points 2 years ago

How to read NixOS documentation:

  1. Go to wiki, see if topic exists
  2. If it does, notice how it doesn't cover your case
  3. Use the hints from the wiki to get your search engine redirect you to https://ryantm.github.io/nixpkgs/
  4. Notice it still doesn't cover your use case
  5. Use search engine again, this time with the hints from aforementioned page, to arrive in the proper code in the nixpkgs repository
  6. Read annotated source code to see what actually happens

Yeah, this is how I found https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-wrapper.sh yesterday because I wanted to install some shell scripts that needed to be adapted.

Don't get me wrong, maintaining a distribution the way NixOS is a huge effort and I can't praise the maintainers and developers enough. The ecosystem they've built is unlike I've seen anywhere, and the technical foundation is sound – in fact I'd wager more sound than what commercial distributions offer. The latter just have more grease. But I do understand the criticism about lacking documentation. But human labor is scarce, and I mean look at me posting this here instead of improving it.

There's also no good guidance or best practices for packages in nixpkgs and stuff is permanently changing (which in my opinion is good). E.g. did you know that new derivations should be sorted by letters, not categories, and not go into all-packages.nix? At least if your derivation doesn't require fancy attributes (pardon me if that is not the correct term). Or that stdenv.mkDerivation rec {…} is not best practice, but rather stdenv.mkDerivation (finalAttrs: {…})? And why the latter even works?

Writing good documentation for a system, especially one that's permanently evolving, is not easy, and I prefer all efforts going to actually maintaining and evolving the system itself than trying to get the perfect documentation that's outdated in a matter of time. And without trying to gatekeep it, NixOS is a distribution for advanced users. I recommend it to everyone who has a solid understanding of how a Linux system is composed because I think it's important what NixOS abstracts away from you. And as an advanced user, reading commented code once in a while is fine in my opinion.

[-] onlinepersona@programming.dev 6 points 2 years ago

The problems with nix/nixos documentation are:

  • documentation isn't sexy so not many want to do it
  • documentation is difficult to be written by beginners because... they're beginners
  • nix/nixos maintainers undervalue documentation efforts - I've tried to get in pull requests, but they just stall (not reviewed, nitpicked to death, simply not merged, etc.)
  • it isn't generated from source code

Also, the very top heavy decision making process harms the community. Some person with hundreds of commits can push through nearly any change (good or bad) relatively quickly, unless other frequent contributors are really really against it. However, fresher contributor with a great change is forced to go through a never-ending process and few stay to actually finalize it.
Pushing to master was not seldom for a long time and IINM it isn't possible anymore. But maintainers can simply (and do) create a PR, make a change and merge it.

These difficulties just make me want to fork nixos. For documentation, at least there's https://nixlang.wiki

CC BY-NC-SA 4.0

[-] Laser@feddit.de 4 points 2 years ago

Good points. If you go through the open pull requests on nixpkgs, there's a lot of stuff that never got through and it's not obvious as to why. I was happy to see a lot of stuff merged less than a week ago. But at this point, there's a huge backlog.

As to forking NixOS, which in my opinion means forking Nixpkgs, Guix system seems like a good start. I decided for NixOS because of proprietary packages as I use Steam, and support for secure boot which while still young and only through lanzaboote works very well for what I use it.

[-] onlinepersona@programming.dev 3 points 2 years ago

Guix system seems like a good start

I'm glad they exist. It shows that the concepts can be successful using another language. To me, the major downside is exactly what you said: no proprietary stuff. Additionally, it's LISP.
In a fork, I'd try to change the way decisions are made, which software is used, add linting and autoformatting to repositories, move away from github (maybe by the time I find the time to we'll have federated sourceforges) and github actions, maybe use nickel or haskell instead of nix, generate documentation from sourcecode, try and use a distributed cache (tahoelafs, ipfs, storj or some other distributed/decentralised file storage), etc. Getting any of that done in the current repos seems like an uphill battle.

CC BY-NC-SA 4.0

[-] Laser@feddit.de 3 points 2 years ago

Let us know when you do! It's a huge undertaking and NixOS has a pretty big network effect. Doesn't mean no one should tackle creating an alternative. I fully believe declarative distros are the future for any production environment and that the space is far from taken by current distributions.

[-] Atemu@lemmy.ml 1 points 2 years ago

documentation isn’t sexy so not many want to do it

Don't think that's the primary issue. Most of us can appreciate good documentation.

It's more of a resource problem. We could either be writing docs or working on literally everything else. Docs are important but so are updates, fixes and new packages/modules/etc. Most of us contribute in our free time and would rather spend that little time on ensuring that the distribution works.

nix/nixos maintainers undervalue documentation efforts - I’ve tried to get in pull requests, but they just stall (not reviewed, nitpicked to death, simply not merged, etc.)

Not at all. It's, again, a resource distribution problem. That happens to many, many PRs, regardless of what they actually do. We have a rather severe shortage of reviewer time.

Nitpicks can be annoying but the people do it because they actually do care; quite a lot.

it isn’t generated from source code

It... is?

https://nixos.org/manual/nixos/stable/options (warning: humongous page, may crash your browser)

very top heavy decision making process harms the community.

What kind of decisions are we talking about? The RFC process is the exact opposite of "top heavy".

Some person with hundreds of commits can push through nearly any change (good or bad) relatively quickly, unless other frequent contributors are really really against it.

No. Someone recently got their commit access revoked for self-merging something that was really not good. We care about quality.

However, fresher contributor with a great change is forced to go through a never-ending process and few stay to actually finalize it.

Yup, that happens. We don't have enough time to give newcomers a really good experience.

Though if I'm honest, a fresh contributor should rather get more of a feel for the processes and conventions for a bit before trying to implement a "great change" (as in: size and complexity) anyways. That massively reduces the need to go back and forth over obvious mistakes a more experienced contributor would simply not have made.

maintainers can simply (and do) create a PR, make a change and merge it.

And it's frowned upon. Especially if that touches something someone else maintains and no reasonable response time was given.

Again, someone recently had their commit access removed for doing exactly that. We don't like this either and this issue is slowly but surely getting better now.

These difficulties just make me want to fork nixos.

That won't help anyone.

[-] onlinepersona@programming.dev 1 points 2 years ago* (last edited 2 years ago)

We have a rather severe shortage of reviewer time.

That's probably true, but the number of reviewers is very limited as well. Most people in the nixos org have no merge rights. Someone who creates package ABC and has it merged, is not able to merge changes onto package ABC without the stamp of approval from one of the few people with merge rights --> a small, select group of people are saddled with the final decision.

The community could do with more people with merge rights or something like The Collective Code Construction Contract (C4).

Nitpicks can be annoying but the people do it because they actually do care; quite a lot.

Most of the nitpicks could be resolved by a linter and auto-formatter. It's also quite annoying when a review is just a bunch of character modifications, renames, replacement of entire sections with no comment whatsoever. Or when knowledge is implied. "use mkDerivation (final: ...)" or "use path instead of ./." like... OK, what does that even mean? Why isn't mkDerivation {} or ./. OK and if there is a new standard/convention, why isn't it mentioned somewhere that's hard to miss like the the PR template, or linter or build output? Having it on nix.dev as a suggestion, is not the way to do it.

What's even worse is when you get one review like the above, change it, then get another review that again changes something according to undocumented convention, you change it, and another reviewer comes along with yet another such review. I don't contribute to nixpkgs anymore, in part, for that reason.

It… is?

https://nixos.org/manual/nixos/stable/options

The options and lib do it, but why not the rest? What about stdenv? What about fetchers? build-support?

very top heavy decision making process harms the community.

What kind of decisions are we talking about?

How easy or hard is it to get a repo in the nix-community org? Who is allowed to make large changes to nixpkgs e.g review process, CI/CD, package naming, etc? There have been discussions in the community forum about adding linters and nix-fmt but no big-wig ever gave it the go-ahead, so it never happened.

How was the official wiki nixxed anyway? Was that an RFC?

The RFC process is the exact opposite of “top heavy”.

When RFCs can simply be closed as "won't resolve" or whatever the euphemism is for "no, not on my watch" without community consensus, then I'm not sure what else to call it.

Though if I’m honest, a fresh contributor should rather get more of a feel for the processes and conventions for a bit before trying to implement a “great change” (as in: size and complexity) anyways

I agree. Large and complex changes from newbies are difficult to integrate. But there are QOL changes from newcomers I've seen that (again) were just stalled or nitpicked to death. There have also been packages requested by a few people, a PR from a newcomer attached and it just never crossing the finish line. A reviewer left a comment, the PR creator made a change and asked if it was fine now, only to hear crickets.

These difficulties just make me want to fork nixos.

That won’t help anyone.

I disagree. If the OG nix community won't change (or won't do it quickly enough), then that's the beauty of opensource: the project can be forked.

A great example of the tar-like movement of the OG nix community (or the maintainers? dunno) is the wiki. A member finally had enough and just started another one (https://nixlang.wiki/), which IMO already looks and feels much better than unofficial yet officially linked to nixos.wiki. That wiki seems to have come from the official wiki being killed, but then a need for a wiki arising and a nix community member taking it upon themselves to create it as the (for lack of better term) nix top dogs for whatever reason didn't recreate it.

I have sympathy for the long-time contributors (maintainers? although that seems to have another connotation in the nix community) to nix, nixpkgs, nixos, etc. There are a lot of moving parts, input, feedback, opinions, PRs, issues, and whatnot, but as a newcomer, there seems to be a resistance to change or at least an inability to take advantage of the good will and energy of the community.

CC BY-NC-SA 4.0

load more comments (2 replies)
[-] Ramin_HAL9001@lemmy.ml 12 points 2 years ago* (last edited 2 years ago)

What is good about NixOS (and GuixOS) is that they apply to package management the same principles that Git applies to managing source code. The Nix store is basically an append-only database (you might even call it a "blockchain") of inter-dependent packages.

So from an individual computer user's point of view, it is much safer to install and roll-back software with Nix than with an ordinary package manager that might allow you to accidentally delete package dependencies and break your system. With Nix, you can install packages that actually do break your system, but because of the append-only nature, you can actually roll-back the install automatically right from the Grub boot menu, no need to re-install anything.

Another advantage of NixOS, though this is more from a system operator's point of view, is that you can guarantee reproducible builds. If the package you have installed has the same hash on all of your computers, that is a simple, human-verifiable proof that all of those systems are running the exact same build of the software. You can probably see that this is very useful for people running servers, like compute clusters, or doing things like A-B testing.

[-] nomen_dubium@feddit.de 7 points 2 years ago

(don't know if arch supports this natively now but) declarative package managment is why j started using it... having ansible/terraform basically be a part of the os is great for me because a reinstall of the current running system just means i copy my configuration.nix and i'm back to where i was but fresh...

another thing is build isolation (you can have clashing dependencies without issues because each package specifically links to the dependencies it needs)... it does kind of bloat the disk a bit, but it also shares dependencies of the same version across packages so it's not like flatpack (if i understand that correctly)

[-] java@beehaw.org 11 points 2 years ago

I think if you have no answer, it could be that NixOS doesn't solve any problem for you. In effect, it's not better. Don't buy into social media hype. It's just a tool like any other.

[-] wwwgem@lemmy.ml 2 points 2 years ago

You're spot on and that's what this discussion helped me figure out: I have no problem. I knew that but I also thought that NixOS would bring something new to improve my Linux usage. So far I still see such improvements for servers or deployment on several machines but not for a single user with standard needs (and this statement may be wrong and due to my limited experience with NixOS).

But NixOS approach is quite different from others and I feel like I may discover something of interest to me once I learn more about it. Also, just for the sake of learning and discovering, I will continue experimenting with it for a while.

[-] chayleaf@lemmy.ml 4 points 2 years ago

In short, Nix reduces the setup time, both for your system and for your projects. If you find yourself spending a while setting stuff up (for example, after a reinstall; or maybe you want to run your project on another PC and need to install the right dependencies), Nix will help. Otherwise, if your desktop is vanilla Fedora or whatever and you don't do much programming (or you don't have any dependency management problems), Nix probably isn't for you.

[-] flashgnash@lemm.ee 8 points 2 years ago

For me it's the fact that I have one source of truth for my whole system config that I can stick in git

If I want to clean up software I don't need anymore I just remove them from the package list and they're gone next rebuild

Also means when I reinstall or setup a new system I just run the installer, do a git pull, rebuild and I've instantly got all my tools, configured just how I like them

Also, if I want to make a big change I can build my system in a VM first to make sure it works first (not that I do that because it also lets me revert to an earlier build from grub if I need to)

I've also got both my laptop and my PC on basically identical configurations from the same git repo with each of them having a smaller config file for hardware specific stuff

[-] chaorace@lemmy.sdf.org 5 points 2 years ago

You'll understand when you're older, son

[-] wwwgem@lemmy.ml 8 points 2 years ago* (last edited 2 years ago)

Or maybe I'm already too old for so much tech. But thanks for letting me think that I'm still a young boy ^^ Not helping with my question but pretty self satisfactory.

[-] savvywolf@pawb.social 4 points 2 years ago

I'm currently working on rebuilding a Debian web server that's been around for 10 years and accrued configuration over that time in NixOS. It's nice to have one single easy to understand file that fully defines the server and can be used to rebuild it if needed.

[-] wwwgem@lemmy.ml 4 points 2 years ago

I can see that from a server maintenance point of view. After having read so many great things about NixOS, I may have exaggerated my expectation and I may be the problem for being a user with too limited needs to get the full benefits of NixOS.

For me this single config file doesn't save that much additional files and most of them would be files you configure only once during installation. Nonetheless I can see how "easier" it would be to save one file instead of 3 to reproduce your system and I can only imagine how much better it is from a server point of view.

[-] cybersandwich@lemmy.world 4 points 2 years ago* (last edited 8 months ago)
[-] wwwgem@lemmy.ml 3 points 2 years ago* (last edited 2 years ago)

Great feedback, thanks! I've appreciated being able to replicate my system in NixOS within only few hours. I found NixOS actually pretty easy to take a grasp on, though I still didn't look at flakes in detail. You spot on the reason why I'm using Arch and a bunch of applications you can tweak to perfectly meet your own specific needs (neovim, neomutt, bspwm, rofi...).

I love spending time to config them and to learn new things. This is basically why I'm interested in NixOS as well. Being entirely satisfied with Arch and not being a distro hopper, the fact that I installed NixOS means a lot to me but now I need tangible reasons to fully move to it. Maybe time will help me in my decision.

All the great feedback in response to this post so far confirm how great NixOS is and I had no doubt about that. I may realize what it can bring me after some weeks of serious use. Thanks again for the time spent to write your feedback, very much appreciated

[-] taanegl@beehaw.org 3 points 2 years ago* (last edited 2 years ago)

So, it's like this. Your operating system is an environment. It has it's paths, it's got it's file system. In many ways said system can have plenty of conflicts and issues regarding dependencies, runtime and permissions, even cruft that it will accrue over the years even.

This is where nix comes in. Nix creates sterile, reproducible environments. With flakes, the reproducibility is 1:1. It can also manage several environments, all isolated from each other.

Not only that, but technically speaking, nix can build anything, as it's a build system of build systems. You don't have to rely on nixpkgs or NixOS. You still get the environmental magic, along with whatever nix evaluations you put into it, so you could make your own nixpkgs (or recipes, really).

Personaly I want to go deeper, so I was thinking of how I could beat make my own package set by getting all the SRPM's of say RockyLinux to create rockypkgs, which is just the Rocky Linux selection of packages and patches built into nix environments.

Maybe you could then also have ubupkgs, fedpkgs, rhelpkgs... mix and match packages lol Yeah, it really is that insane.

Imho Nix has not reached it's potential yet because of some stuff that needs to be fixed, but restructuring and refactoring is underway. Nix as a command will become more streamlined and central for ease of use, and nixpkgs needs a bit of recajiggering to get the package layering just right - or so I've heard (find us, in the Matrix chats).

LETS GO, RFC136!!!

[-] yianiris@kafeneio.social 1 points 2 years ago

NixOS is better because...

...broken link ... or non-existent reasoning?

@wwwgem

[-] vole@lemmy.world 1 points 2 years ago

This is a text post, so the OP wrote text corresponding to the title. You should be able to see it at the top of the post. (Spoiler, OP is basically asking the community why NixOS is better, because they don't quite understand the advantages of using NixOS.)

[-] hallettj@beehaw.org 1 points 2 years ago* (last edited 2 years ago)

NixOS puts your full system configuration in a portable set of files. You can easily reproduce the same configuration on another machine. I also like that instead of accumulating a growing list of packages that I don't remember why I installed I have package lists specified in files with comments, and split into modules that I can enable or disable.

IMO NixOS works best when you also use Home Manager to apply the same benefits to your user app configurations and such. (OTOH you can use Home Manager to get those benefits without NixOS. But I like that I get consistency between the OS-level and user-level configurations, and that both use the same set of packages.) I use Home Manager to manage my list of installed packages, my dot files, Gnome settings, Firefox about:config settings, and so on.

You might be installing packages imperatively with nix profile install or with nix env -i. If that's the case you're not going to see the full benefits of a declarative system in my opinion. I prefer to install packages by editing my Home Manager configuration and running home-manager switch.

I like that NixOS + Home Manager automates stuff that I used to do by hand. A couple of the things that I do or have done are to,

  • test an experimental window manager, Niri
  • use Neovide (a GUI frontend for Neovim) with a custom patch to tweak font rendering

Now I have that kind of stuff automated:

  • Since there was no packaging for Niri when I started trying it I wrote my own in my NixOS config with a NixOS module to set up a systemd unit to run it. Because Nix packages are effectively build scripts, whenever I update Nix automatically pulls the latest version of Niri and compiles it without me having to think about it anymore.
  • I use the Neovide package from nixpkgs with an override to compile with my custom patch. Like with Niri my configuration automatically gets the latest Neovide version and builds it with my patch when I update, and I don't have to think about it anymore. I use this overlay to do that:
modifications = final: prev: {
  neovide = final.neovide.overrideAttrs (oldAttrs: {
    patches = (oldAttrs.patches or [ ]) ++ [ ./neovide-font-customization.patch ];
  });
};

You can see that I compile some things from source. That's fine on my desktop, but takes a while on my travel laptop. But I don't need to compile on my laptop because I can use Nix's binary cache feature. I push my NixOS and Home Manager configurations to Github, and I have Garnix build everything that I push. Garnix stores everything it builds in a binary cache. So when I pull my latest configuration version on my laptop it downloads binaries from that cache.

load more comments
view more: next ›
this post was submitted on 13 Jan 2024
45 points (100.0% liked)

Linux

58744 readers
358 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS