Having worked on Nix-related documentation for almost a year as my day job all I can add to the discussion is this:
all documentation can be made easy to understand if you make knowledge dependencies explicit and only use those you declare
doing that takes a lot of time and effort, and it already begins with finding the leaf items (core concepts) to explain
we desperately need a maintainer (i.e. lead editor) for NixOS documentation
Please feel free to step up and join the documentation team. Iâll do everything in my capacity to support you.
Personal opinion from first-hand experience: Ideally bring funding to work on the subject at least part-time for at least half a year. Anything else is probably going to stall or evaporate.
The great vantage is that, in a certain sense, Nix allows to configure the whole system using an uniform language. This is way better than to learn a hundred different configuration styles for a thousand different packages with intricate interactions.
Just do an internet search for LAMP or LTSP.
In this sense, NixOS is a perfect backend for a SnowflakeOS.
The only problem is that someone needs to write the plumbing - and it resumes to more NixOS modules!
Some ramblings tonight while trying to work out a number of issues that remind me of âuser friendlyâ. They might sound a rant - but I am positive we can fix it, and keep promoting Nixos.
Summary - I think we need to be more cautious about the benefits, but reinforce the path is worth it!
Better delineation of nix and nixos - it is far too easy to find a âhelpâ that refers to the other side and doesnât work for you
Up to date documentation - the number of times I have found something that should work (and did just 6 months ago) but doesnât anymoreâŚat least we need a mapping to âif you found x, try yâ
Flakes and home manager. It took me literally weeks to get a flake working that allows HM. And I still canât find how to install ânon-freeâ correctly! At least a guide that would steer those like me who will âget seriousâ to avoid the initial approach and jump straight to flakes would save angst trying to convert!
âPassing the buckâ. There is a lot of âit is really hardâ stuff out there - my example is home-assistant where the wiki gives me an error and the only suggestion is to âask the matrix groupâ (I have yet to find out how to do that in Nixos!). This approach makes Nixos appear unfriendly (and I am not blaming any users on the forum at all - just highlighting external perception).
Reproducible. A lot is made of consistency and rollback. However, boot configs can easily break a system (I have done it several times), and nix is not a total panacea - I use folding at home and for my first 90 or so iterations of my system it wouldnât work. Then it did for about 30-40 iterations. Now it doesnât again. I documented my âfixâ in the forum, and I havenât deviated from that, but something has happened. I have the same app on 4 architectures - 3 donât work with the GPU, and 1 does (in theory the hardest?!). Debug is really hard! I think that dragon warnings are required.
The nix language seems very complicated to me at times. I often canât look at two options and see how they differ, and hence why I should choose one or the other. As a result, the error are often impenetrable.
Finally - happy to try and helpâŚso if anyone has suggestions where I can contribute let me know!
Hello! Creator of SnowflakeOS here. From experience, Iâve found that the main difficulty in making a user-friendly interface for NixOS is many different ways someone can structure their configuration. This is part of the reason I decided to make SnowflakeOS instead of just a series of add-ons to NixOS, it allows me to make opinionated and predictable choices in how everything is configured.
I feel like this is even more relevant to NixOS than any other distro given how many different ways you can manage and configure it.
I think it can be in time, at least out of the box, but given what I mentioned above about endless ways to configure everything, I feel like itâd be pretty hard to support all possible configuration formats, and would add additional burden to the NixOS team. However I do plan on making Nix Software Center and NixOS Configuration Editor available in nixpkgs once stabilized. So theoretically once that happens a new used could just add nix-software-center to their environment.systemPackages and be able to use it pretty easily.
But overall the goals I have for SnowflakeOS are to:
Show that a user-friendly NixOS based distro is not only possible, but also works well
Create tooling for creating other NixOS based distros
Create user friendly tools for all NixOS users (Like the software center and configuration editor)
The Calamares Installer feels, to me, like a shuttle service to a space lab where a bunch of scientists have been floating around in suspended animation conducting esoteric experiments for a long time.
The only way Nixos might work for me is if every 6 months HQ provided a few templates for action and I go on a Linode and go though them, monkey see monkey do. By following one at a time one of the multiple Byzantine options for configuration I could at least see at least a plumbing in action, which would expand my mind, for sure.
You can not define it any better anymore⌠There is a clear boundary.
nix is the tool and language.
ânixOSâ is the linux distribution that uses the nix expression language and the nix build tool to manage itself.
There are even 3 seperate manuals for Nix, nixpkgs, and NixOS.
I have to agree though that some inofficial ressources are mixing Nix, NixOS, and Nixpkgsâ responsibilities and are very sloppy with the naming.
I have never had that problem in the official documentation. If this happened to you with the official documentation please point out the location, that is something the doc-team needs to be aware of!
Then please open a thread here. Though, HM is not NixOS, nor is it an official extension. It is a community project.
Thanks @AndersonTorres and @NobbZ for positive replies to my grumpy post (wasnât meant to be but I seem to be collecting issues faster than I can whack down!).
Iâve probably been to quick to find the answer rather than re-read the official docs, so I will try betterâŚand Iâm not really a programmer and find nix hard which doesnât help.
Iâll create a thread regarding HM - Iâve only very recently got flakes working, and I want to document what I have tried with HM. I prefer to create a post that helps document better what I have tried rather than just âthis is the magic line to put in configuration.nixâ.
Hello! Iâm glad you paid attention to this post.
Yes, it really is.
However, have you considered making these utilities so that they follow the âstandardâconfiguration.nix hierarchy and if something unusual is detected (e.g. files are connected differently somehow or a parameter has completely different values) give warnings that the utility may/will not work correctly?
I mean, newbies are unlikely to do anything unusual at first.
And if, after a while, they want to complicate their configuration, they will have already mastered the terminal and they are unlikely to need graphical configurators.
Cool thing is, they already do! I try to support as many configurations as possible, so there are options to define your config locations, with the default checking /etc/nixos/configuration.nix.
I think by âstandardâ he means the default configuration structure set up when you first install NixOS. So no flakes, two nix files /etc/nixos/configuration.nix and /etc/nixos/hardware-configuration.nix. But even though this is the default, I wouldnât say itâs necessarily best practice, just a good starting point.
Understood! So I am already beyond that using flakesâŚ
Thx
In terms of best practice, some guidelines would be useful for those getting deeper into configuration.
My OCD makes me ponder if all my desktop config elements such be in âdesktop.nixâ, but I also want all services in âservices.nixâ (I know - my choice).
I would have appreciated some guide rails or a discussion of some of the implication of those choices.
Yes, that is something of an issue. Discourse is much more discoverable, so we should prefer to point learners with specific issues here, rather than the matrix. In the end, it saves a lot of time when you can find a prior instance of your exact issue and an accompanying solution quickly and easily.
I think one of the major strengths of nixos/home-manager is the freedom to organize your config in the most intelligible way, rather than in a way dictated by the underlying structure of the programs you use.
To use that to the fullest, I recommend splitting your config into files not by whatâs being configured, but why itâs being configured. Think of your config in terms of (fairly) modular pieces of functionality, or goals you want to achieve, then set whatever settings you need to for that functionality in one file. Itâs fine if a single program has its settings spread all over the place, so long as things that are related, from your perspective as the user, go together.
This has the advantage that your code is a lot more readable in a year or two, when youâve forgotten how it all fits together, and that itâs more readable for others when they look at only a part of it. But most of all, itâs editable without accumulating settings that you no longer know why theyâre there or if itâs safe to remove them.
Sometimes that guideline will lead you to dedicate one file largely to a particular program, if the program fulfills the goal wholesale. Other times, it will lead you to combine a bunch of settings configuring different interacting parts of your system, to make a functioning workflow.
Recently I am using a monolithic configuration file. It is easier to find my configurations without the need of opening multiple files.
I believe that it would be interesting to do the same when using a graphical configurator: something like /etc/nixos/config-save.nix and the config tool would work on that.
Also it would allow to add arbitrary code, by always loading a /etc/nixos/config-custom.nix file when present.
