I agree, but the best way to facilitate growth is to run meetups, community groups and events like the office hours. in alchemical terms, it’s an endothermic reaction. it requires time, energy and very specific catalysts to develop new users. synchronous communication is more time-consuming, but facilitates growth faster.
if there was a kind of interaction medium that facilitated pair-programming or collaborative programming, that would be optimal. you need to see noobs make mistakes and show them how to find answers faster. AI isn’t really a replacement for mentorship, since people value the interpersonal connection (or at least they do for now)
omarchy on the other hand distributes its main sources with the installation… oh i forgot that nixpkgs does that too. it’s really the best way to find answers (not the browser and not LLM). you find information about things you weren’t looking for.
this is somewhat of a barrier, but not really. the FHS issue on NixOS just needs a bit more tooling to delve into profiles. they’re pretty easy to understand from a high level and actually it helps a ton to learn the underlying linux concepts
larger barriers that noobs can’t anticipate/predict issues or level of effort when encountering:
lib64 linking and patchelf (they don’t necessarily know to look for nix-ld)
integration of inputs to flakes and searching for the right ones (i could imagine this leads to cargo culting). learning to use disko or nixos-anywhere has left me with a lot of questions, but i usually take my time and plan out how to deploy things.
performance issues with overrides/overlays (easy to resolve, but could sometimes result in large flake.nix and project refactors if you’re new).
discovering names for services, learning to search the sources, using tools like git-repo-manager, writing packages/derivations
one curveball that probably comes up often is relying on flake inputs that point to nixpkgs-unstable – even if that’s transparently resolved by a symbolic reference to nixpkgs@25.05, it can still be an issue if some upstream is referring to service attr names that only exist in nixpkgs-unstable. if it ends up creating layers of overlays/overrides this could result in confusing the noob.
I’ve used Guix for a while and doing things like guix graph --type=reverse-package are all supported in a single CLI. the same functionality requires identifying a lot of external tooling, which is fine… but again, if someone can spend time with a noob and help them identify those tools early on, then the learning experience is more likely to perceived sustain value.
as for omarchy, they have a custom build of omacom-io/omarchy-chromium. otherwise, you can package some of their scripts individually. some of this is required for the PWA functionality … I think, but I’m still working on that.
I don’t really anticipate that anyone else would want to use this approach: You may not need Home Manager, but if I get their chromium build running, maybe i could push that up to the omarchy-nix flake. idk yet what functionality it lacks.
Only a few of the omarchy scripts call Arch/AUR tooling, but I doubt they’re receptive to making their code distro-agnostic. there are still a ton of great ideas in the distro though
I was just reading this thread and feel the focus on noobs is a bit misguided. Most successful open source projects show a great respect for their users. I don’t think the word noob fits that.
I would be interested in having a good nix module that packages omarchy.
I use NixOS because I want tight control over my system but I still appreciate high quality UX.
I like opinionated systems because I just want sane defaults for mail, window manager and not get distracted before I start my actual work.
It is out of consideration for the users that this discussion is taking place. We are concerned that making a one click install for new users (noobs) will hide too much of the normal installation behaivior needed to understand the key concepts of NixOS.
If you feel differently, feel free to work on/with any of the packages linked above to package this.
Yeah, what not-jack said. We mean no offence to noobs (new users), we were all noobs at some point. What we fear is that while we may be able to build a nice simple one-click installer, we wont be able to maintain that beyond the installer.
And so a noob will install NixOS thinking how easy and quick it is, only to get dumped in the middle of a desert and told “good luck”. Thats not productive for them or us. The diffculty curve needs to get more uniform, not less.
I think the biggest thing plaguing the adoption is the poorly written guide/tutorials
If this was a topic that was taught in a school,
Terms would be defined and explained clearly with real aplicable examples from the start. Like a normal school text book.
But somehow the guide decided to forget how textbooks teach concepts from beginner to advanced in a reproducible manner. Alot can be learned from that so I’m having to wade through fluff to try and write my own as I learn
that is precisely a perfect example of how not to teach a topic, though I appreciate the body of work that was put into nix.dev
Existing Nix tutorials suffer from common problems:
Obscure examples: They use 1 + 1 and x: x + 1 when you need to learn how to describe software builds.
Jargon without context: Terms like “derivation”, “closure”, and “attribute set” are thrown around without explaining what they mean in practice.
No clear progression: Concepts appear in an order that makes sense to experts, not learners.
Missing the “why”:
They tell you how to write arbitrary Nix, but not why the language is designed this way.
Practical examples and applications which are found in real world stable production environments - should be the way from zero
There should be an official single source of truth which covers how to learn the language and its up to date implementations as the language and its implementations develop
In learning any language learning the theory happens while it is being applied to real world conversation - same with math
Having written the language tutorial a while back, I appreciate the feedback a lot! Everyone, excuse the slight tangent, but… it would help greatly if you have suggestions how to improve:
What would you propose to do instead in order to get people to the point where they manage to debug problems with their expressions in code as complicated as with software builds? If you want to build software once you know the language, the Nix Pills are still pretty much alright, apart from a few outdated bits.
Please report instances of this on the issue tracker, this should never happen. I don’t think we do that in the language tutorial, but old material that nobody got around to brushing up surely has some of that.
A number of people went great lengths to make a sensible progression for the tutorials. You will notice that implementation is lagging behind. What is the thing you are most sorely missing, where do you think is the biggest gap?
Yeah indeed, I would love to have a lot more of the why. We still don’t have any of the explainers I wanted to have when I started. That work was never really popular though, and it seems like most users really just want to look things up more conveniently, either reference documentation or how to do certain things. Which “why” would you do first?
Agreed, this could be a document on its own. I tried to capture the most important pieces in the introduction to the language reference though. What would you change there? I guess something about why pure and declarative are desirable properties for a language made for setting up complex software builds?
Anyway, apart from building OCI containers, which is a well-known use case that’s unlikely to go away very soon and for which we still don’t have a good upstream guide, what are you missing most?
Agreed, which is why I think the current language tutorial (and a bunch of other Nix-only things) should move into the Nix source and have tests. Could you help with some of that?
Actually would love to. At the moment I’m putting together examples for each topic from nix.dev as I learn which is helping me bridge the gap and get a better understanding - so far has involved referencing public repos, vimjoyer and a bit of trial and error. But its a bit all over the place notewise as I’m working through each section for my learning at the moment but that is something once I get through I am happy to share and if there is any benefit you find from it - I’d be more than happy to contribute any alternative/better ways to express the learnings or at least add some of the examples that help me.
Apologies if any offense was taken. On the amazing nix-path journey.
Since this is now about discussing tutorials, I’d like to add that The Nix Package Manager - Nix-Book seems to present the information in a cleaner manner.
(It might be the case that a moderator would move the tutorial/documentation discussion to a separate topic, to not derail this too much)
