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

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

Finally got around to publishing my HDD rack design!

Video: https://www.youtube.com/watch?v=18qHf6oyXV8

STL can be found here: https://git.cryto.net/joepie91/modular-hdd-rack