Sven Slootweg (soft-deprecated) @joepie91@pixie.town

*desperately searches for loose components bin for like 10 minutes*

Ah yes, I've found it, it was the bin labelled "components" at eye level directly in front of where I was standing to begin with

@risottobias@tech.lgbt Right, I get what you mean. I can only speak for the parts of the community that I interact with (eg. the Matrix rooms), but:

While I can't say that elitism is *entirely* nonexistent in the community, it's certainly something that's seen as undesirable and that's actively pushed back against. And generally people are aware of how elitism is a risk.

The documentation quality is still a problem, but also one that is recognized by many, and that people work on improving. Lot of work left to do, though.

For "beginner-friendly systems", I'd refer to my previous reply; that's included in what I call "accessibility" there.

Bottom line: there's a lot of work left to do, but *culturally* speaking the NixOS community is in a pretty good place, at least by typical Linux standards.

@oscarmlage What the two have in common is that they are built around the ideal of "declaratively specify what things should look like, and it Makes It So".

There are significant differences in how they accomplish those things though:

Ansible is designed as a system manager. It expects to be imperatively changing stuff about a (Linux) system, specifically in networked scenarios. It does not make the system itself.

Nix, on the other hand, is designed as a *build system*. It produces reproducible build artifacts from a given deterministic specification. But, unlike most build systems, the scope of *what* it can build is very broad.

A configuration file is a build artifact. A software package is a build artifact. An ad-hoc shell environment is a build artifact. An entire NixOS system is a build artifact. All of it is just build artifacts referencing other build artifacts, with each artifact being (sort of) content-addressable.

This means that Nix is a far more generic tool than Ansible is (and anything it needs, it can just conjure into existence, because it's a build tool!); but it also means that for specific *kinds* of builds, you want additional tooling to use *with* Nix.

For building software as well as a whole NixOS system, that additional tooling lives in nixpkgs. For building "an entire cluster of systems", that tooling is morph, NixOps, and so on. They all just do different kinds of builds, and Nix itself doesn't care about the distinction between them.

This is how you end up in a situation where Nix looks like Ansible, but it also looks like `apt`, and it also looks like `make`, and it also looks like `npm`, and a whole bunch of other tools. All of those are really different kinds of specialized build systems, and Nix implements those mechanisms generically!

The downside of that is that because Nix can do basically everything, there's not one obvious "hot path" for how you use it, and so you'll have to figure out how to use it for *your specific usecase* rather than just following a "getting started" doc like for Ansible (which only has one usecase really).

That's fixable with better and more comprehensive documentation, of course, but as it stands, there's a lot of work left to do there.

@risottobias@tech.lgbt Actually, as some concrete examples of how Nix functionality could serve to make things *more* usable than other distros, if done right:
- The generation/revision system makes it possible to build an intuitive *and reliable* system rollback UI
- The isolated environments makes it possible for a (graphical) package manager to have a "try out this app without installing it" button
- The isolation also makes it very unlikely for different software sources to conflict; this means that the whole problem of "I added an external repo and now my system is broken" can be entirely sidestepped, and in fact this can be actively *encouraged* in the UI design

@risottobias@tech.lgbt I would say that there is a significant part of the community who feels that it should be more accessible, and there are ongoing efforts to actually make it so (in documentation, ergonomics, etc.).

At the same time, there are definitely also people who feel that "it's fine, you just have to learn how to use it". This can make it exhausting to have discussions about how to improve accessibility, when those people get involved.

With how most of the ecosystem is de facto managed by the community (because the Nix runtime itself only has a very limited scope), I would say that there is a high chance that things will become more accessible over time - but exactly how long that takes will very much depends on how many people have the energy and motivation to actually make it happen.

One thing that *does* seem to be fairly universal, is people's desire to have Nix be a sort of 'universal fabric' for system and package management scenarios, ie. the idea is that it or a model like it *should* be adopted (behind the scenes) everywhere. Most of the disagreement is about whether that is already viable today or not.

And from my own perspective as someone trying to work on accessibility: I'd say that, on balance, the community is receptive to this sort of work. There's just a lot left to do, but it's not a hopeless endeavour IMO.

All that having been said: much like with Mastodon, there are *some* things that just work fundamentally differently, and to which people will have to adjust. But I'm convinced that it's *possible* to make these accessible enough that it exceeds the usability of most other Linux distros today.