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

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

@pinpox@chaos.social From a governance perspective, I'd say that it's highly likely that Flakes will indeed end up replacing various of the current mechanisms.

The model also generally makes sense - it addresses a bunch of real problems with how Nix works today, IMO, in a pretty effective manner design-wise. The RFC actually does a decent job of explaining the motivations: https://github.com/tweag/rfcs/blob/flakes/rfcs/0049-flakes.md

That having been said, the standardization process has been... suboptimal, to put it mildly. The whole RFC process (which is *supposed* to be used for this) was pretty much bypassed, the design having been pretty much settled upon before the RFC process even really started, and this has frustrated quite a few people.

The implementation process has also been a mess, and this could probably have been avoided by actually involving the community, instead of just dumping it into everybody's lap.

(Think "half the community is depending on an experimental-flagged feature and CLI tooling is getting updated in such a way that it sometimes just doesn't work with Flakes disabled anymore, etc. - on paper it's still unstable, but in practice it's largely become a requirement.)

Given the problematic standardization process, I'm not optimistic about community feedback really being considered prior to stabilization, and so I don't expect much to change.

We'll probably end up with a pretty decent system in the end, but it could have been done *so much* better if more work went into the governance side of things, and the community was actually involved in the design process.

TL;DR: It's *technically* not stable yet but for all practical purposes it pretty much already is.

@ebi Heh, that's a tricky one!

So I would say that there's not really any *fundamental* difference between ARM/mobile and other systems, in that all the same benefits are still useful on those devices for all the same reasons.

What *is* different, however, is the typical hardware configuration of such devices - and I can see some issues there with the current state of Nix and NixOS.

Some things that come to mind:

- Nix is currently not exactly resource-efficient. It requires quite a bit of CPU and RAM to evaluate a system configuration, which is not great on many mobile devices, which are often specced lower.

- The atomic upgrade model is great, but also very space-hungry. Again, mobile devices are frequently not very generous on storage space, and this could cause issues, at least without a deduplicating filesystem.

- Nix is still heavily keyboard-oriented, and well, most such devices don't have a keyboard :) So it's probably *even more* important for there to be good management UIs on such devices. Less of a problem for embedded ARM stuff like routers.

I don't think that any of these issues are impossible to overcome, but there's definitely quite a bit of 'core work' left to make this viable outside of an experimental context.

That having been said, there *is* https://mobile.nixos.org/ as an ongoing project. I've also seen various efforts for running NixOS on eg. ARM routers, but I'm not sure what the status of any of them is.

Perhaps more interesting in the immediate term is using Nix as a build system for eg. Android images; and there's actually active work ongoing here! Robotnix can build customized AOSP systems, for example: https://github.com/danielfullmer/robotnix

Maybe other "off-device" approaches might be viable as well - if it doesn't need to run on the device itself, that'll at least eliminate the CPU/RAM constraints.

In summary: I think it would be really cool to run NixOS on mobile/ARM devices, but I think that in practical terms we're still quite a way away from it - further than for desktop/server usage.