What other approaches do folks use to deterministically customize Linux?
You must log in or register to comment.
NixOS could be the future if it had a better community, documentation, and a user interface to manage the system. Right now, it’s still completely unusable for even tech literate folk. In fact it’s unusable for people without time.
If NixOS is to become the future, it has to become more user friendly. Not only as a system but as a community. A community that ridicules people asking questions or responds with “just read the source code” might as well just continue believing in “self-documenting” code.
And let’s not even dive into the close-source source forge dependency they have.
As a huge NixOS enthusiast I wholeheartedly agree with you. It works amazing for me but only because my autistic ass hyperfixated on it to the point of tinkering with it every afternoon for months.
I would love to be able to recommend NixOS to people but unfortunately, the lack of good documentation is a huge problem.
my autistic ass hyperfixated on it to the point of tinkering with it every afternoon for months
Relatable 💯 I had a basic functional system after the third time trying NixOS. But then I started trying to get my old workflow and programs back and anything missing from nixpkgs was such a pain.
But I persevered and now keep trying to get others
interestedto share the pain, but they (rightfully) aren’t very excited about the prospects. These are people working in tech and who have written code for at least 5 years BTW.Unfortunately my efforts of communicating problems and solutions to the NixOS community mostly fall upon deaf ears or resistance. Maybe it’s the way I communicate it. Dunno.
As a prior proponent of graphical programming interfaces, I’ve been thinking there’d be a good use case for a GUI based control panel for NixOS, something that could transcompile standard user selected options down to a nix config that could be abstract of the way from most users, like any sort of game save file.
Given all options and packages in nixpkgs are already machine readable and indexed, supplying a GUI based tool to procedurally generate nix codes doesn’t at first seem initially daunting, but given the past discussions around this idea perhaps proves it to be on the contrary:
- https://discourse.nixos.org/t/is-anyone-working-on-a-gui-tool-to-manage-packages/5540
- https://discourse.nixos.org/t/wondering-about-nix/32919/5
- https://github.com/nix-gui/nix-gui
- https://discourse.nixos.org/t/negativity-around-the-graphical-installer/67646/12
Although SnowflakeOS in particular looks promising:
SnowflakeOS Simple, Immutable, Reproducible SnowflakeOS is a NixOS based Linux distribution focused on beginner friendliness and ease of use.
I think Snowflake OS is dead. The NixOS community didn’t really get behind it for whatever reason. My guess is that many people don’t understand enough about NixOS to contribute, but those that do are too proud of their ability to understand it that making it easier for others would seemingly devalue it. I have noticed that many nerds attach a sense of self-worth to understanding difficult things and will fight tooth and nail when those things are made more simple as it will diminish their self-worth.
Given all options and packages in nixpkgs are already machine readable and indexed, supplying a GUI based tool to procedurally generate nix codes
Nix can create attribute sets from JSON, so there isn’t a need to generate nix code. Projects like npins do this albeit for another purpose (locking dependencies without flakes).
Anyway, NixOS is lightyears away from a noon friendly OS because it’s also terribly far away from a dev friendly OS.
Ah, that’s a shame. Thanks for the context though.
I did feel a little bit of that slight dismissal or elitism from the thread I linked above about the graphical installer ISO. Although I think the relative surge of new users after graphical ISO’s implementation did end up changing some minds on the merit of its continual development.
It seems like some tools just never fully realize their potential market demand until they’re finally implemented and consequently adopted. Quite the catch 22.
I also wonder if it’s a bit of a motivational aspect for individual contributors, as in demand with mostly originate from novice users who’ve yet to master the Nix language, yet by the time one’s gained enough experience to contribute to Snowflake OS, you’ve kind of grown out of outgrow the need for it. That kind of reflects my personal interests around graphical programming, as I became more familiar with various languages, my inkling for a graphical representation of control flow gradually waned.
Still, I think lowering the barrier to adoption is in the long run best serves the community and in sustaining new contributors. Sort of like the conventional Greek proverb:
A society grows great when old men plant trees whose shade they know they shall never sit in.
Nix can create attribute sets from JSON, so there isn’t a need to generate nix code.
Is there a good way of mixing and mashing JSON attribute sets with conventional nix config files? Perhaps relegating some config to machine-generated JSON, and some hand crafted configs?
I agree with the points you are making. As for loss of interest for making things graphical, in my case it’s just a lack of time. If I had time, SnowflakeOS would have my contributions.
Is there a good way of mixing and mashing JSON attribute sets with conventional nix config files? Perhaps relegating some config to machine-generated JSON, and some hand crafted configs?
For sure. I’m on mobile right now but something like
{...}: builtins.fromJson( builtins.readFile ./path/to/configuration.json )and importing that in your
configuration.nixshould do the trick. You have handcrafted stuff in another nix file, but it will be your responsibility to make it work with the imported/managed JSON. Maybe SnowflakeOS even does that. I’m not sure.
