User-friendly NixOS distro?

Development
21

That are very good next steps! Like said earlier, a very accessible tutorial/how-to for the installation (including this graphical setup) is needed.

Maybe the documentation could be interactive to some degree, so you can choose if you want BIOS/UEFI, LVM+EXT4 or LUKS and get just the commands you need with explanation and links for more context. Help people make informed decisions about partitioning layout and filesystem.

Then other people can also create videos from that. Some people like to watch arch linux install videos :smiley: I thought multiple time about creating a video in german. I have also documented how i install NixOS in german which is a bit more detailed than the official manual. NixOS Installation | davidak.de

We can do all of that with NixOS without changing the install on console, so no need for a new distro.

22

I think SVK did not exist, and it is known that he basically looked
mostly at speed. Also the Montone release at that exact moment was the
slowest release of a couple of years in both direction.
At Linux scale, using history is impractical anyway, right?
I mean I’m sure and certain that Linus Torvalds and Linux devs need
something like Git. Only IMO many other people from other projects,
even only students approaching version control for the first time
do not need it, they need only a small subset of Git & other VCS
features and using Git or start with it instead of being a good thing
for them is a bad one and due to the “network effect” push other VCSs
to the oblivion even if they are better for most common usage.

For instance Fossil offer built-in wiki/bugtracker/minisite and all is
stored in a file, from toy to medium size project this can be a super
nice feature, they can simply fire up a VPS and share their work with
the rest of the world plus having their near complete infrastructure
offline backed-up naturally by any project member. Monothone is… well,
a strange beast, however it’s slow patch algebra maybe very useful for
web-less project based only on mail communication for sharing code.
Bazaar or Mercurial are simpler and easier to learn than Git so maybe
a nice option for many etc. Long story short: diversity. The key of
evolution. With git, not because of git faults, not because of git devs
faults, but because of “sheep effect” we are loosing them in both VCSs
and site hosting.

That’s why I fear any “too standard” thing, any “newcomers desired”
thing, the first because lead to little room and habit to evolve, the
second because chances are really high that it’s not a good thing but
the most advertise one for interest of few “powerful” not for us all.

We probably have already reached a scale where lookin up old PRs is
getting less and less practical anyway…
So this perhaps is a sign that PR does not really scale and find
other (better) way’s maybe needed, perhaps not today but in agenda
anyway…

There are GUIs that fall through to actually entering code for some
things. Dunno, Dr.Geo or KIG.
Mh, yep… But they are essentially toys…

Second, that’s why I ask how TeXLive support should even look like —
if things like that get figured out, we can get an editor that handles
a majority of configurations in use by developers.
TexLive actually have a GUI-installer to create personal profiles,
install-tl {-gui=perltk,-gui=wizard} but TexLive itself is far simpler
than NixOS and essentially a profile is about packages, language
support and locale settings. Also it’s approach itself demonstrate how
bad is it’s overall design: they choose to do anything themselves so
any distro have trouble to integrate TexLive in their package system.
And that’s common for nearly any complex project, from Python, Perl to
Emacs. In the end I think that Xorg approach while not easy to maintain
is the best to ease integration because they know people do not install
by hand individual monster’s normally…

Skepticism is non-actionable, questions about specific corner cases —
hopefully — are.
Too early then, I’ll have to wait and see how someone design such GUI
NixOS installer, try it and find how well or bad it work… My only
“prejudice” is:

  • how to integrate it without compromise unattended / non-local deploy
  • how to support flexible storage configs, including LUKS, LVM, zfs
    support, other classic fs support for people who build their own
    image to support them, including btrfs subvolume/raid buggy status,
    stratis etc
  • how it can present NixOS strength to newcomers so they do not think
    “hey, another distro”, sticking with “classic approach” and so find
    NixOS hard instead of easy and featureful

Actual support probably means LSP, then we end up waiting for
universal LSP support in editors…
Yep, sorry, I forgot the base :frowning:

I think Linux storage is flexible and composable and can be fine-tuned
because each layer has well-defined responsibilities.
Well… It’s a bit off-topic but… Do you remember the “rampant layer
violation” by Andrew Morton? And now anyone pry for zfs flexibility and
ease of use, pry for stratis or other project, pry for Hammer port etc.
In theory, so from programmer side, having well defined layer is a good
thing, but we are user (maybe admin), we need comfortable environment
for us, not for devs. I think this is an ancient debate between devs
point of view vs operation.

Didn’t you just criticise Linux storage for things that actually
enable handling of weird corner cases?
Coming from other unices I do criticize Linux for many thing but in
this case I simply doubt that Linux native limitation and excess of
unuseful complexity due to bad design can be “improved” adding another
layer on top.

Well, if you share it and link from somewhere, there is a chance that
the next Newbie Documentation Drive will look at it to understand which
things are the hardest to understand.
I’ll probably do sooner or later (I’m plan to have a small personal
website to share stuff, only I do not have enough time to create it
well so…), for know they are only sparse unpolished and mixed
language (English, Italian and French depending on when I note them
and for who) org-mode notes but I’d like to evolve in something more
structured and perhaps integrable in NixOS wiki instead of being
another blog post.

– Ingmar

23

At Linux scale, using history is impractical anyway, right?
I mean I’m sure and certain that Linus Torvalds and Linux devs need
something like Git. Only IMO many other people from other projects,
even only students approaching version control for the first time
do not need it, they need only a small subset of Git & other VCS

I agree

We probably have already reached a scale where lookin up old PRs is
getting less and less practical anyway…
So this perhaps is a sign that PR does not really scale and find
other (better) way’s maybe needed, perhaps not today but in agenda
anyway…

Keeping track of history doesn’t scale.

There are GUIs that fall through to actually entering code for some
things. Dunno, Dr.Geo or KIG.
Mh, yep… But they are essentially toys…

They are efficient research tools. There is still some place for
research in planar geometry.

Second, that’s why I ask how TeXLive support should even look like —
if things like that get figured out, we can get an editor that handles
a majority of configurations in use by developers.
TexLive actually have a GUI-installer to create personal profiles,
install-tl {-gui=perltk,-gui=wizard} but TexLive itself is far simpler
than NixOS and essentially a profile is about packages, language
support and locale settings. Also it’s approach itself demonstrate how

I mean: we have TeXLive support. How GUI configuration editor should
interact with that? It does seem a relevant and nontrivial question.

  • how to integrate it without compromise unattended / non-local deploy

Simpler config values are also desired because they are easier to
document. The rest is orthogonal.

  • how to support flexible storage configs, including LUKS, LVM, zfs
    support, other classic fs support for people who build their own
    image to support them, including btrfs subvolume/raid buggy status,
    stratis etc

NixOS config for this is plain data. Yes, not very easy to make
complicated setups, but no worse than now.

  • how it can present NixOS strength to newcomers so they do not think
    “hey, another distro”, sticking with “classic approach” and so find
    NixOS hard instead of easy and featureful

I don’t think that paragraph about «purely functional system management»
is going anywhere. Maybe configuration editor should also version
configuration.nix, it is annoying how often people forget to do that.

I think Linux storage is flexible and composable and can be fine-tuned
because each layer has well-defined responsibilities.
Well… It’s a bit off-topic but… Do you remember the “rampant layer
violation” by Andrew Morton? And now anyone pry for zfs flexibility and

I prefer to think in term of these layers when deploying systems, and
I have never ever developed in-kernel FSes…

I’ll probably do sooner or later (I’m plan to have a small personal
website to share stuff, only I do not have enough time to create it
well so…), for know they are only sparse unpolished and mixed
language (English, Italian and French depending on when I note them

OK, major European languages…

English-language index might help a bit to know whether to ask Italian
speakers for help.

24

Keeping track of history doesn’t scale.
But being able to “know” history to a certain extent it’s still a need
so find a mechanism that “scale enough” it’s needed. If I have to pick a
suboptimal solution at least I’ll go for an open one, something I can
control and something that does not tie in any way to a service,
especially a proprietary one…

I mean: we have TeXLive support. How GUI configuration editor should
interact with that? It does seem a relevant and nontrivial question.
That’s a good example, and I think there are others (Emacs for instance
but also Perl, Python, Ruby, Haskell, Go, …) when some nontrivial
software have it’s own “package management” it’s a nightmare by itself,
wrap it it’s only another layer of complexity. Of course as it’s done
in text it can be done in a GUI, only that GUI became somewhat big, for
instance featuring “submodules” for any complicated stuff… That’s what
I call a path to a monster: simple start, limited only to simple things,
after became complex and complex to a point that came back to text it’s
simpler to use even for newcomers…

I prefer to think in term of these layers when deploying systems, and
I have never ever developed in-kernel FSes…
Hum, if you have ever tried zfs in production (so perhaps not LLNL port)
I bet you’ve find it super fantastic compared to any other classic
storage solution…

OK, major European languages…
English-language index might help a bit to know whether to ask Italian
speakers for help.
I mean that I have few separated notes, slides, little articles in a mix
of language born as personal note in some case, demo for few colleagues
in a language, for a LUG talk in another etc. Ideally I think about a
guide to “deploy my setup” in English so remaster NixOS iso to support
zfs or nilfs2 etc, step-by-step install with various scenarios (mdraid,
LUKS+LVM+… etc) and few precooked configs for various task like:

  • end-user desktop (Gnome shell with some extension, Kde etc)
  • geek/seasoned users desktop (EXWM, i3&few other tiling, sawfish)
  • homeserver (DNS, samba/nfs file sharing, print server, …)
  • few single-purpose server for simple scenarios

With good explanations and suggestion on where to go to know more on any
topic. Only I still need enough spare time and knowledge of NixOS for
myself to do that in a reasonably good shape.

If someone it’s interested and there is a way to propose that as a small
project instead of a personal blog why not, contribute with articles and
translations it’s certainly easy for me than decide to create a decent
blog, another one on the web :slight_smile:

– Ingmar

25

Keeping track of history doesn’t scale.
But being able to “know” history to a certain extent it’s still a need
so find a mechanism that “scale enough” it’s needed. If I have to pick a
suboptimal solution at least I’ll go for an open one, something I can
control and something that does not tie in any way to a service,
especially a proprietary one…

We have some part of it in PRs…

I mean: we have TeXLive support. How GUI configuration editor should
interact with that? It does seem a relevant and nontrivial question.
That’s a good example, and I think there are others (Emacs for instance
but also Perl, Python, Ruby, Haskell, Go, …) when some nontrivial
software have it’s own “package management” it’s a nightmare by itself,
wrap it it’s only another layer of complexity. Of course as it’s done
in text it can be done in a GUI, only that GUI became somewhat big, for
instance featuring “submodules” for any complicated stuff… That’s what
I call a path to a monster: simple start, limited only to simple things,
after became complex and complex to a point that came back to text it’s
simpler to use even for newcomers…

Doesn’t work like that, as the complex things need to be activated, and
the simple things would still work the same. Developing the monster
would be painful by that point, though.

I prefer to think in term of these layers when deploying systems, and
I have never ever developed in-kernel FSes…
Hum, if you have ever tried zfs in production (so perhaps not LLNL port)
I bet you’ve find it super fantastic compared to any other classic
storage solution…

I want a separate resizable FS for /tmp that is wiped on boot. mkfs is
the fastest way. I don’t want to have to relearn everything to gain
things I didn’t ask for.

I don’t want snapshots, because I want to put things into VCS.

26

Keeping track of history doesn’t scale.
But being able to “know” history to a certain extent it’s still a need
so find a mechanism that “scale enough” it’s needed. If I have to pick a
suboptimal solution at least I’ll go for an open one, something I can
control and something that does not tie in any way to a service,
especially a proprietary one…

We have some part of it in PRs…

Oops, in git repo

27

Hy,

We have some part of it in PRs…
Yep, but they are a proprietary GitHub platform, not a Git feature,
so what if tomorrow “Nix” have to abandon GitHub? I do not talk about
migrating history but choosing a new tool to keep workflow up and
running for all devs and users.

I want a separate resizable FS for /tmp that is wiped on boot. mkfs is
the fastest way. I don’t want to have to relearn everything to gain
things I didn’t ask for.

I don’t want snapshots, because I want to put things into VCS.
VCS are nice for preserving history, but not really nice with binary
contents (from video/image/music to pdfs docs etc) and not much
performing and efficient for backups. Personally I choose nilfs2
because being a logfs it create a “zero overhead snapshots” (named
checkpoints) at any fs write() so I have and effective protection
against accidental deletion/overwrite having the most up-to-date
copy before accidental event and also comfortable for consistent
live backups (simply resync-ing against the most recent mounted
snap). Unfortunately being a traditional fs it’s not as flexible
as zfs, I can enlarge and shrink live volumes issueless but on top
of LVM and LVM itself is not much comfortable and quick as zfs.
The best storage system I know of is DragonflyBSD Hammer, but I
can’t use it on GNU/Linux and I can’t really use Dragonfly except
for personal play/exploration… It’s not a matter of re-learning
it’s a matter of storage needs, for many classic swap, root, home
plain partition even without separate boot are ok, as long as they
do not experience an hd failure or accidental overwrite just before
something important and their backups are not up to date or they do
not have anything really important on their desktop because use
someone else storage but for a generic distro, so including server
usage, having good storage is really important and GNU/Linux does
not shine too much in that sense.

That’s a bit off topic but it fall in the classic category of “until
it happen nobody care”, desktop users normally do not care too much
about data protection since our actual systems both hw and sw works
really well, devs do not care too much about using someone else
service since there are plenty and they work really well but they are
still SPOFs and “incident waiting to happen”… The same is IMO for
GUIs/modern installers, they are generally designed to fulfill typical
desktop user expectancy, they play nice, they look nice, after when
released in the wild disaster happen and work to fix new installer
start, resulting in few years in a monster. That’s for instance the
path took by SuSe in the past (Yast) and Ubuntu recently with both
Ubiquity bugs and limitation and new DI replacement…

Anyway, we well see what will happen :slight_smile:

– Ingmar

28

We have some part of it in PRs…
Yep, but they are a proprietary GitHub platform, not a Git feature,
so what if tomorrow “Nix” have to abandon GitHub? I do not talk about
migrating history but choosing a new tool to keep workflow up and
running for all devs and users.

I meant git repo, I sent a correction afterwards.

I want a separate resizable FS for /tmp that is wiped on boot. mkfs is
the fastest way. I don’t want to have to relearn everything to gain
things I didn’t ask for.

I don’t want snapshots, because I want to put things into VCS.
VCS are nice for preserving history, but not really nice with binary
contents (from video/image/music to pdfs docs etc) and not much
performing and efficient for backups. Personally I choose nilfs2
because being a logfs it create a “zero overhead snapshots” (named
checkpoints) at any fs write() so I have and effective protection
against accidental deletion/overwrite having the most up-to-date

Some people just use chattr +i (personally I have workflow that
minimizes risks of accidental overwrites, but +i is indeed sometimes
nice).

Of course, this implies division into large and immutable and small and
mutable (which go into VCS). Large and mutable needs special care
anyway, and special tools like the ones Postgres needs…

nilfs2 seems to have some other nice properties, though, but I never
got around to trying it.

as zfs, I can enlarge and shrink live volumes issueless but on top
of LVM and LVM itself is not much comfortable and quick as zfs.

Dunno, LVM works and I do want to separate failure domains for
different FSes with different usage patterns.

for personal play/exploration… It’s not a matter of re-learning
it’s a matter of storage needs, for many classic swap, root, home
plain partition even without separate boot are ok, as long as they

(I have 9 partitions mounted on system boot, actually, and only /home
can be called a data partition untouched by system)

do not experience an hd failure or accidental overwrite just before

I actually consider HDDs consumables, like printer ink/toner.

still SPOFs and “incident waiting to happen”… The same is IMO for

(I do use my laptop offline from time to time, and configure everything
in a way that fits best offline use — except things that are defined
in terms of network interaction, of course)

GUIs/modern installers, they are generally designed to fulfill typical
desktop user expectancy, they play nice, they look nice, after when
released in the wild disaster happen and work to fix new installer
start, resulting in few years in a monster. That’s for instance the
path took by SuSe in the past (Yast) and Ubuntu recently with both
Ubiquity bugs and limitation and new DI replacement…

Again, you are comparing GUIs without any globally consistent concept
system behind them with a plan for something on top of NixOS
configuration system — a configuration that seems to satisfy you
semantically.

There are real complicated questions about GUI configuration editor. If
you want to prevent GUI installer from happenning, you should look
around the ecosystem and look for a question that is complicated and
interesting and relevant, so that it gets attention and obviously should
be resolved before going on. If there are hard trade-offs, consensus
will just never happen.

If all questions do get resolved reasonably, then the editor will work
fine with underlying ecosystem as it is and won’t create a problem.

29

At the moment, I suspect most users are developers of some sort. So my thought is, what would make their lives easier. Something I’ve sometimes wanted is a quick way to see the diff when changing options or faster feedback while developing nix expressions. I can hook up a file watching script, but the main limitation for easy quick tools seems to be the the speed of evaluations. If we can take advantage of some sort of incremental build or a faster evaluator we will probably discover unexpected tools and features for increased understanding for a wide range of users. I’m thinking the equivalent of what hdevtools is for Haskell.

1 Like
30

Besides the installer, Manjaro has a lot of GUI fixes we have abandoned in NixOS.
Disable font antialiasing in one click (without mass-rebuild) and XFCE 4.13 to name a few.
That polishing of GUI is not fun and probably requires pay workers to do the work done.

31

I meant git repo, I sent a correction afterwards.
Sorry, I kept in my “live” tag your previous message and forgot the
second one, even with notmuch I’ve too many mail…

Some people just use chattr +i (personally I have workflow that
minimizes risks of accidental overwrites, but +i is indeed sometimes
nice).
That’s ok for static content, but not feasible for frequently changed
content… Think about a large document (a thesis, a big report etc)
that it mistakenly overwritten because you hit save&close after an
erroneous change, perhaps a binary docs like a video you edit or an
audio or a picture and undo capabilities of your software can’t help.
With a logfs you can recover issueless and it have substantially zero
overhead in the sense that it’s a protection maybe used very rarely
but does not require anything after initial setup.

Of course, this implies division into large and immutable and […]
Sure, this is always needed even to make backup easy but a net division
between mutable and immutable is hard. Personally I divide per topic and
per importance of data (like volume for music/photos/video less
important, volume for docs, volume for config, generic “varhome” for
all configs and chance I do not care). Also it require user action in
too many case, think about pdfs invoices, you can easily categorize
them but or you have a (big) script to chattr any of them or you have
to act manually for any new invoice. And this kind of “always append”
contents does not fit well in a VCS…

Anyway it’s a bit offtopic…

There are real complicated questions about GUI configuration editor.
If you want to prevent GUI installer from happenning, you should look
around the ecosystem and look for a question that is complicated and
interesting and relevant, so that it gets attention and obviously
should be resolved before going on. If there are hard trade-offs,
consensus will just never happen.
Oh no, I’m only a NixOS user, can’t pretend to steer any evolution! I
only give a (strong and repeated) world of warning about possible
evolution I already see in the past.

– Ingmar

32

That’s ok for static content, but not feasible for frequently changed
content… Think about a large document (a thesis, a big report etc)
that it mistakenly overwritten because you hit save&close after an

«think thesis» → VCS

There are real complicated questions about GUI configuration editor.
If you want to prevent GUI installer from happenning, you should look
around the ecosystem and look for a question that is complicated and
interesting and relevant, so that it gets attention and obviously
should be resolved before going on. If there are hard trade-offs,
consensus will just never happen.
Oh no, I’m only a NixOS user, can’t pretend to steer any evolution! I
only give a (strong and repeated) world of warning about possible
evolution I already see in the past.

NixOS community tries to make different mistakes than other ones!
Sometimes we even succeed.

Actionable issues raised will mean that you, yes you, can make sure that
the things you are worried about will be at least deliberately (and
likely thoroughly) considered. I mean, «just a user» might be a reason
to abstain from trying to change the decision on a implementation
detail, but users-who-are-no-NixOS-developers are exactly the group of
people with valuable and underrepresented opinions about use cases.

33

Truly @davidak’s remark about the elementary OS UI on top of NixOS is critically important. I don’t know if folks are aware of the Darling effort (think WINE but running macOS apps atop Linux instead), but one can begin to capture the vision if you just consider this for a few moments.

Apple is moving down a terrible path and people are wanting out, BUT they want and need their macOS apps. Linux would be incredibly stupid and naive to think for a moment that the community couldn’t use the remarkable boon that this could bring. Having a cohesive and very macOS-like user interface with the same keybindings would change the world for Linux as a whole.

Having a foundation of the Nix package manager would be enormously helpful and exciting in terms of gluing system admin and general installation + updates together.

2 Likes
34

FYI: The Pantheon Desktop is packaged for NixOS for some time now. It is included in 19.03 stable channel!

I use it for some months on personal and work computers. Only one critical problem exists with multi-monitor setups: Pantheon session crash after lock or suspend with multi-monitors · Issue #60082 · NixOS/nixpkgs · GitHub. See general progress here: Pantheon · GitHub

Darling is also packaged. Well, kind of. But it seems far from usable. But indeed an interesting effort.

https://github.com/NixOS/nixpkgs/issues/38628

I’m not sure if we should use the new elementary Installer and create a elementary ISO. I like it because it has state of the art design, but it is quiet new. A more general solution would be better for the success of NixOS.

But first we need Design and UX for an Installer that fits NixOS and teaches the user the basics without overwhelming them! Elementary is doing a fantastic job in that space: Get Settled into elementary OS with Onboarding | by Cassidy James Blaede | elementary | Medium

Without Design that has the user experience in mind, it is just a tech demo that experts can use. I wish NixOS becomes more user friendly and make it’s advantages available to more people. For that, we must hide most of the magic happening on the technical level. Users just want to install the system, configure it, install software and be productive. elementary OS delivers that.

I think right now only technical people are involved in NixOS. We need designers, UX experts and technical writers to make it accessible to more people.

3 Likes
35

This is exactly correct. Even myself, with over 25 years on Linux/FreeBSD I am done with “fiddling” and this is why I moved to macOS around 15 years ago. Now with Apple making the decisions it’s making regarding eliminating 32-bit and a plethora of other decisions that are moving away from “developer-first” centricity, I’m looking for another home within the next 1-3 years. I’m still going to need macOS apps and I’m still going to need Windows apps, but how those are presented is a big deal to me and this is where Darling and perhaps even Wine come in (or perhaps the WSL 2 model from Windows 10 that’s going to be released this fall is the better model to follow regarding virtualizing some aspects).

At any rate, the only thing that Linux is missing (and has never been able to get together) is a cohesive UI/UX. KDE would have been the winner had the idiots with Gnome had not somehow screwed up the hearts of Linux users back circa 2000. The Linux community has never recovered from that royal screwup and we’re still dealing with crap today and people like Ubuntu and Pop_OS are continuing to push it hard with negative side effects.

Elementary probably is the only realistic good UI/UX path that already exists, but there perhaps could be better options if a strong and cash positive organization could get behind such an effort. It wouldn’t take much to get a NeXTSTEP/GnuSTEP/Cocoa-like library in full swing and a strong wm. I suppose that Vala can be the base of that, but perhaps even V lang would be more efficient and effective over the next few months. V’s multi-platform capacity could be a real key aside from all of its other attractions (it looks like V may be the most popular upstart language ever at this point with getting over 10k stars on GitHub within just about a month).

Anyway, a lot to consider and a lot of potential if the proper core people could be brought together under the same opinion and umbrella vs continuing to hold this Linux diversity crap up as some kind of banner or badge of honor… :confounded:

2 Likes
36

I don’t think building something new is going to be a solution. There are already excellent GUI libraries, such as Qt. To become a competitor on the desktop (assuming the desktop still matters), you need a very focused effort to polish some existing desktop to remove the thousands of paper cuts. This is how GNOME 2.x became a very good environment in the mid 2000s. Sun Microsystems invested a lot of power in usability studies, HIG guidelines, and polishing the GNOME UI. Of course, they were motivated to improve GNOME to replace CDE.

Though I am not sure who’d be willing to invest the manpower in such an effort. It will be interesting to see how far the Elementary people get. At least they have the right mindset.

2 Likes
38

It feels like the missing stepping stone for wider adaptation. According to Repository statistics - Repology there is enough well maintained packages.
One proof of concept DE with decent GUI installer would open NixOS for the world to try.

1 Like
39

I haven’t been here that long but it really seems like a GUI installer with a pretty desktop isn’t enough. While a GUI installer would definitely ease the barriers to getting nix installed it seems like it would just slam them into the next wall that much faster.

The nix install process just involves partitioning and mounting disks, editing a config file and running nixos-install. The walls that come up after install are much harder to scale. To use nixos in any meaningful way, you have to have at least a basic understanding of the nix language and some nixos concepts that are very different from pretty much any other OS out there.

I think to make nixos user-friendly would take a full blown derivative distro that included some tools and automation to ease the learning curve. It seems like that would inevitably come with trade-offs to flexibility and/or purity but that would probably be OK in a derivative distro.

3 Likes
40

It’s 2020. GUI = Webpage these days. Fish shell is an example of how one can have a web gui (I’m not saying it’s the prettiest).

Users know webpages - they are friendly things with known UI conventions and come with bookmarks and back buttons. An app store where you click on apps and they get added to the config sounds great, and then you can review your changes to the configs and hit the make it so button. Done well it could lead people into the world of the config and demystify it a little.

Microsoft did brilliantly with their vba script macro recording as people could find out how to do things and then tweak it to their own needs.

Nix seems awesome in delivery of its vision, it’s just the discoverability of its powers that are lacking (from my newbie viewpoint).

I’d also like to point out that it’s not the lack of a UI installer, it’s the lack of the app store / config brought to life that is the missing link. People only have to install it once. But after that they have to live there. If you make living there beautiful then they’ll put up with jumping through hoops to get there.

2 Likes
41

I think you’re spot on. I had the idea the other day of a web based Nix configuration system + native mobile app being a potentially killer combination enabling a lot of unique features people would love including easier installation.

Imagine a system like this:

  1. Nix(OS) runs a webserver that can be connected to locally via a browser
  2. This interface acts as a graphical configuration editor. The “app store” portion is essentially just adding/removing packages to an array.
  3. When the user is done making changes there’s a “make it so” button to apply the config
  4. The interface offers easy rollback and management of generations

Now that would be useful on its own, but if we take the concept a little further it becomes unique and IMO a highly awesome way anybody manage their system(s) that doesn’t exist elsewhere

  1. The webapp is also a mobile app (use react-native for a single codebase)
  2. Offer services via nixos.org (of course also with option to self host). These services would include:
  3. Allow for easy connection via proxy (for example: https://connect.nixos.org/{identifier} to reach your machines from anywhere as long as it has internet)
  4. Auto-backup and versioning of configurations
  5. Sharing of configuration pieces, to make common use cases easier. For example an option for “android development” or “lamp server” or “steam gaming” or “nodejs development” or “kde desktop” IIRC nix modules already enable this, but discoverability and sharing isn’t easy.
  6. Use the app for installation. Pop installation media into a machine then open the app, auto-detect the installer or scan the displayed QR code (or navigate to the url) to configure and install the machine remotely. Apply your saved configs to do it quickly. Quickly and easily set up multiple or headless machines!
  7. Notifications. Machine rebooted? Service crashed? The Nix app could be your hub for managing all your nix deployments.
  8. Expert mode: raw config editing but nice to use via an embedded monaco editor (the editor vscode uses) with nix extension.
  9. Crazy idea: auto-packaging (or guided packaging) of apps that aren’t in nixpkgs yet. For many apps adding them to nixpkgs seems to be just boilerplate of getting the url and hash then putting them into the standard builder, checking they work, then submitting a PR. Could that be largely automated?

All of this combined would be amazing for day-to-day use of NixOS and for building/managing deployments of multiple NixOS machines.

I love Nix and NixOS but I always find myself back on MacOS after several months of nix-ing because the day to day usage and management of NixOS gets in the way of other things I need to do. Right now there’s a lot of hoops to jump through in order to do “simple” things in NixOS. Most of those things aren’t hard to do, but there are a lot of steps and minutia to remember to get them done. Most of the time I don’t remember that stuff and have to go searching. Most of the time I don’t have time to do that at the moment.

I’m guessing others feel this way as well and that an easier way to manage nix systems would go a long way to easing the most common use cases. I’m a web/react-native dev by trade so I’d love to hack on something like this but unfortunately for the foreseeable future I’m not realistically going to have the time to put together anything of substance.

5 Likes