User-friendly NixOS distro?

One thing I’ve been thinking could really help win new converts to NixOS is a Manjaro-style distro. Something that does to NixOS what Manjaro did to Arch Linux. Ideally it would require very little knowledge of behind-the-scenes Nix infrastructure and provide a user-friendly experience.

Part of this would involve getting something like Guided installer · Issue #15573 · NixOS/nixpkgs · GitHub fixed. A lot more of this just involves taking time out to really polish a NixOS configuration so it includes things that an end-user really wants. We could also include more stuff by default than the basic graphical distro has (the ISO itself would be small but the installed configuration could get much bigger).

Is anyone interested in something like this? Not sure if it would be an official part of NixOS, or a separate thing that uses NixOS modules.

20 Likes

This thing would need a nice graphical installer, so it seems like it might be nice to focus that effort on a NixOS graphical installer that has a option to select from a few prepared configurations, this being one.

5 Likes

I think a graphical configurator requires a solution to specifying complicating things. If you want a GUI-manageable system, how do you install TeXLive (to name one example where a small not-plain-data expression is strictly required now)? Not sure what semantics should lie under the GUI for this case…

2 Likes

Having a graphical installer and then throwing nix expressions at people just a second later when it comes to actually using the system doesn’t seem very coherent. The only interaction any end-user is likely to have with NixOS is in a managed environment, with everything set up (and locked down) by IT.

That’s one opinion from https://www.reddit.com/r/NixOS/comments/88z7mp/first_impression_of_the_nixos_installation/dwq4exb/

2 Likes

Here is an example how an installer can look with many customisation options: RFC: Graphical installer for NixOS · Issue #21662 · NixOS/nixpkgs · GitHub

I would love to use the solid foundation of NixOS with the user-friendly desktop from elementary OS. Many components are still missing sadly.

We would have to research a way to organize the options NixOS has without overwhelming the user. Maybe that could be a topic for a master thesis? Also sane defaults for desktop users.

A major part would be to install and update Nix packages with a graphical tool. With PackageKit support, we are not far away from that. Packagekit not compiling with Nix-backend enabled · Issue #21230 · NixOS/nixpkgs · GitHub We also need a graphical way to do a system upgrade.

Localization would also help reach more users.

I think the goal should be to make NixOS as user-friendy as possible without loosing flexibillity for advanced users. But an own “distro” with install image and manual could be a good start to experiment and get feedback.

3 Likes

I think a module system for Nixpkgs is probably the longterm solution for this. But honestly I’m not sure if we would really need a GUI to actually configure NixOS (even though that would be useful). Just pick some good defaults that most users wants and point everyone to NixOS manual for tweaking. This seems to be how Manjaro handles it (package management is still console based etc.).

I think a module system for Nixpkgs is probably the longterm solution for this. But honestly I’m not sure if we would really need a GUI to actually configure NixOS (even though that would be useful). Just pick some good defaults that most users wants and point everyone to NixOS manual for tweaking.

Well, if installing is simpler than maintenance, it feels a bit mousetrap-ish…

Sane defaults for TeXLive are also hard. And it is not the only case where we want an option value to be something more than plain data.

Hi,

I think the best way to win new NixOS-users would be a graphical package
manager, and a way to (semi-)automatically resolve conflicts. [1]
The current nix-tools are unfortunately not very user-friendly and
not intuitive. It got better with the nix-command but things like
“nix install” is still missing.

With a graphical package manager, many users of other distributions could
benefit from the Nix-repository as addon for their non-NixOS-distribution.
And after this, some of them may use NixOS for their next installation.

best regards
Roland

[1] Unfortunately, resolving conflicts in Nix is currently very hard, and
nearly impossible for no-expert-users. The error-messages are only
partly helpful, an you often have to guess what to enter to set
the priorities. In addition, it currently seems to be impossible
to set the priority of a currently-being-installed package, which
makes installing even harder.

1 Like

Asking naively:

Is a graphical installer as simple as a FLTK (or similar) wrapper around the usual install process, and a plasma session?
Or does the liveboot have additional complications that I’m unaware of?

Would it be possible to expose meta packages and meta nixos modules? For example I can image a meta package who’s goal is to be look as close to Ubuntu as possible, one the looks as close to Elemenary os etc. Would that be possible?

Would it be possible to expose meta packages and meta nixos modules? For example I can image a meta package who’s goal is to be look as close to Ubuntu as possible, one the looks as close to Elemenary os etc. Would that be possible?

That sounds like what profiles do:

They’re pretty simple now but could definitely be made more complicated.

1 Like

A graphical package manager would definitely be nice, although IIRC Manjaro doesn’t come with one either and its one of the most popular Linux distros out there. I think a lot of Linux users can at least use command lien for installing packages (of course there’s still a lot of usability issues in Nix to be worked on). I worked on getting PackageKit to support Nix a while ago but eventually gave up as its abstractions don’t match very well with Nix’s. A GUI package manager for Nix would probably have to be written from scratch to support multiple users, profiles, etc.

1 Like

Hy,
a small personal opinion: GUIs are not user-friendly. They seems to be,
but they result in inflexible complex software that trying to make more
flexible result in turn in unmanageable, unusable pachyderms.

Installing a local system is normally composed by few step:

  • booting
  • disc partitioning
  • copying on partitioned storage some fs trees
  • customize copied files accordingly (users, groups, net configs etc)
  • reboot to the new system

Now I bet nearly anyone say “hey partition with GParted is far easier
than parted/fdisk/sgdisk/…” and that’s true IF you only want plane
disk partition. However if you want LUKS or LVM or zfs etc there is no
support. Of course it can be added, a not so light work but can be done.
However it does not suffice: what about RAID support? And which RAID?
Of course you can also add such support, including perhaps multipath,
other kind of storage etc in a GUI. You end up in a monster super-hard
to maintain and hard to use. Long story short you can’t made a complex
task friendly with a wrapper, because GUI IS a wrapper, you can limit
significantly users options or you create a monster.

Second part: creating the new system if you already are a NixOS user
you probably only want to copy your config, few .nix files, and run
nixos-install, perhaps you have a config resulting in a /nix/store
too big for your ram and so you first install a minimal config and in
the new booted system you put your big config and run nixos-rebuild.
If not, well how complex need to be a GUI to wrap Nix flexibility?
Of course, you can copy Ubiquity/Anaconda/… forms (user, password,
perhaps a limited pkg selection) but that’s super-limiting so you will
leave the user in an undefined post-install setup… Like all other
classic distros do.

Local NixOS deploy can certainly be more friendly and comfortable,
for instance offer a simple static binary to build a custom NixOS iso
with your favourite config it will be nice so new user can download
few Mb extract somewhere and find a ‘build_iso’ binary and few basic
default configs to start from. Perhaps a script can try to guess a
basic hardware-configuration.nix and suggest a default pkg selection
based on actual installed distro, perhaps (it’s a bit scaring) it
may present an option to use guessed and user-approved hw-config
itself to auto partition the new system. Perhaps it can include an
option to test the modified config before create the iso. After the
iso can be easily flashed on a usb stick and at boot it can auto-apply
pre-built config. The same system can be included in NixOS itself as
a derivation so a NixOS user can create “fully or partially unattended
install” to deploy new machines. Perhaps this binary “pre-installer”
can be a small local http server (go can do that pretty out-of-the-box)
that serve a mini-site with full documentation builtin to guide new
user in the process of creating a new config. But trying to copy other
distros IMVHO means copying bad things instead of good one.

As a new NixOS user I found many astonishing wonderful things and other
that I do not like too much, for instance

  • ability to describe in text a system, a built-in Infrastructure as
    code implementation;

  • ability to apply such config to local system or remote hosts
    (NixOps);

  • ability to handle home (homeManager).

For the “do not like” things:

  • a somewhat obscure DSL, IMVHO Guix do a far nicer choice with Guile
    scheme, I can’t say pro and cons of nix vs scheme but I definitively
    find scheme far more easy to use and understand;

  • a non-so-big documentation, often not much updated, missing howtos
    for non super-basic tasks, absence of “complete showcases” to copy
    from.

Perhaps this last point is due to the Nix evolution speed and relatively
small development community, perhaps due to the development model not
tied to “literate programming” I do not know but I think this is the
only real “unfriendly” NixOS part. Newcomers not accustomed to read docs
and use CLI IMVHO can’t find “their environment” in NixOS, it’s a FOSS
project, so something to serve their devs/community itself, not to serve
“consumers”. Newcomers willing to learn may find hard to start certainly
not because of the lack of a GUI installer but because of the lack of
howtos and docs big enough to being able to step-by-step drive a new
user from zero to a working system and indicate possible “exploration
paths to evolve more”.

– Ingmar

8 Likes

wrt nice gui installer

one potential option for consideration is
gobolinux/AbsTK - ‘The Abstract Toolkit - a widget toolkit for GUI and text-mode applications’

apparently it works for gobolinux*
*myself i have not installed gobo!
;}
… live-iso + nix
spares me that task

Since version 010, GoboLinux features an installer that works on both text and graphical mode. The feature set of both modes is identical, thanks to the innovative AbsTK (Abstract Toolkit), created by the GoboLinux team especially for this installer:
GoboLinux - the alternative Linux distribution

2 Likes

a small personal opinion: GUIs are not user-friendly. They seems to be,
but they result in inflexible complex software that trying to make more
flexible result in turn in unmanageable, unusable pachyderms.

On the days when I am optimistic, I believe that software without
a strong model of the subject domain which is compatible with the user’s
mental model. It’s just that with CLI it is easier to change an
interface to adjust it towards a model that arises, and it is more
obvious when the software lacks one.

Of course, that means that for me Git is still unusable complex piece of
software flexible in wrong directions, even if it has a CLI — its
vocabluary just doesn’t fit the mental model I picked when I was first
trying out a few DVCSes.

Note that a GUI for NixOS confguration if expected to inherit and follow
Nix and NixOS models of the world. This should help.

Now I bet nearly anyone say “hey partition with GParted is far easier
than parted/fdisk/sgdisk/…” and that’s true IF you only want plane
disk partition. However if you want LUKS or LVM or zfs etc there is no
support. Of course it can be added, a not so light work but can be done.
However it does not suffice: what about RAID support? And which RAID?
Of course you can also add such support, including perhaps multipath,
other kind of storage etc in a GUI. You end up in a monster super-hard
to maintain and hard to use. Long story short you can’t made a complex
task friendly with a wrapper, because GUI IS a wrapper, you can limit
significantly users options or you create a monster.

I think for partitioning there is no obligation to create a monster to
support most of options. Partitioning has an overarching theme: you have
(maybe layers) of storage pieces, and you can cut a piece and delegate
its further management to a different piece. LUKS? Take this piece,
encrypt it, now there is a piece of storage that corresponds to what’s
inside the cryptocontainer. Etc.

I do think you make an important point that we shouldn’t take away the
options.

Note that the GUI might be a convenient way to organise autocompletion,
and (unfortunately) there are users that are more comfortable with this
than with other ways. Even if they do understand the nuderlying choices.

Second part: creating the new system if you already are a NixOS user

Sure, if you edit Nix code fluently, you would just do that.

Yes, it is important to just create and edit a Nix-language config that
can always be switched to manual editing.

As a new NixOS user I found many astonishing wonderful things and other
that I do not like too much, for instance

Note that there are other things to enjoy.

  • Much smaller notion of package conflicts, with simpler rules and less
    chances to get caught in a gotcha.

  • Much better chances to find out if two installations use the same
    thing.

  • Much better chance to roll back a change that went wrong; usually
    I can roll back only the part that went wrong and go on with the rest.

These benefits are not based on the details of the configuration
editing. Some people might value them enough to try NixOS, and a GUI
configuration editor might reduce the cost of an experiment.

For the “do not like” things:

  • a somewhat obscure DSL, IMVHO Guix do a far nicer choice with Guile
    scheme, I can’t say pro and cons of nix vs scheme but I definitively
    find scheme far more easy to use and understand;

In some sense, Nix is purely-functional in a way that doesn’t fit
general-purpose languages; so there is still this switch between
evaluation-time purer code and build-time code (and run-time code).

  • a non-so-big documentation, often not much updated, missing howtos
    for non super-basic tasks, absence of “complete showcases” to copy
    from.

Note that for a given amount of documentation, there is still a question
of how accessible the relevant documentation is while configuring the
system. If you have a special-cased configuration editor, it is easier
to show inline descriptions from module definitions.

only real “unfriendly” NixOS part. Newcomers not accustomed to read docs
and use CLI IMVHO can’t find “their environment” in NixOS, it’s a FOSS

Well, it turns out that some parts of value Nix and Nix* provide can be
made more accessible by relatively cheap wrappers that also happen to do
a lot of things in a wrong way.

I do think it is important that the configuration editor should allow
slow and gradual transition to manual editing, but I hope it might end
up actually possible.

project, so something to serve their devs/community itself, not to serve
“consumers”. Newcomers willing to learn may find hard to start certainly

I think this discussion might be a good place for developers with
a common goal of minimising their own expenditure of effort to help
people who want to decide whether to invest effort into learning Nix.

(I am not one of them, but I think some of the claims in your post were
too pessimistic)

Hy,

Of course, that means that for me Git is still unusable complex piece
of software flexible in wrong directions, even if it has a CLI — its
vocabluary just doesn’t fit the mental model I picked when I was first
trying out a few DVCSes.
Oh, UAU, finally another Git disgruntled user :slight_smile: IMVHO the sole reason
of it success reside in what an ancient teacher describe as “sheep
effect”: “a big name create and use it so it must be the best”.
Unfortunately I think that requesting a GUI installer fell in the same
effect “well-known distro with ‘user-friendliness’ reputation have it so
it’s better adopt this approach”…

Personally, after OpenSolaris/SUN death I had chosen Ubuntu mostly
because “it works well”, “it’s a better Debian” etc and FreeBSD does
not play well anymore on my iron. I already know Debconf so I go for
it. After when they choose to suppress alternate iso I have find how
limited Ubiquity is. After when they decide to ditch Debconf for a
homegrown curses installer I end up saying that Ubuntu can’t really
be used anymore. Now my desktop is NixOS and I’m lobbing to switch
also as much as any other system I can…

Note that a GUI for NixOS confguration if expected to inherit and
follow Nix and NixOS models of the world. This should help.
Well, perhaps is a personal mind limitation… But I can’t figure out
anything that can “inherit” a programming/expression language in a GUI.
Even “mythological programmers” like ancient Parc devs of Xerox Alto
have tried something similar with Smalltalk and fail, Plan9 8½ and it’s
successor rio also fail and all of them are mostly text arranged in some
GUI environment, not “full-GUIs” like modern’s one… Perhaps Emacs is
the sole flexible text-based GUI out there with success, and nearly any
Emacs user suppress menubars, scrollbar etc…

I think for partitioning there is no obligation to create a monster to
support most of options. Partitioning has an overarching theme: you
have (maybe layers) of storage pieces, and you can cut a piece and
delegate its further management to a different piece. LUKS? Take this
piece, encrypt it, now there is a piece of storage that corresponds to
what’s inside the cryptocontainer. Etc.
But is it simpler than their native interface? And more important can be
automatized more or less than them? Personally I think that actual
storage solution are all too old to be used well today, I think zfs was
a pioneer of a new kind idea of how to handle storage, perhaps
superseded by Dragonfly’s Hammer and waiting to see where BCacheFS will
go but I do not see nothing really exiting and I’m stick with
LUKS+LVM+nifls2 triplet… Can a GUI do something like Stratis, keeping
flexibility that even Stratis itself miss in some corners? Personally
I’ll be really surprised if so…

Note that the GUI might be a convenient way to organise
autocompletion, and (unfortunately) there are users that are more
comfortable with this than with other ways. Even if they do understand
the nuderlying choices.
Well, having something comfortable as
NixOS Search
NixOS Search
locally is certainly a very welcomed thing for me. Having a small docs
side-by-side while installing can be also a very good thing, far better
than look for something in the wiki and in a search engine. And yes, a
GUI can do a good job in that sense, perhaps even better than GNU info
for most users, but that’s not an installer, it’s a complementary app
in the live image…

Second part: creating the new system if you already are a NixOS user
Sure, if you edit Nix code fluently, you would just do that.
I don’t. I’m a new users, with few months on NixOS and substantially
zero contribution, only a super-duper-simple fix, my knowledge of Nix
and NixOS is REALLY limited. But nevertheless I’m pretty comfortable
with my /etc/nixos config (and soon homeManager). One of the reason
that bring me to NixOS is exactly the ability to replicate my system
simply drop few text files on a directory and let the installer do it’s
business. For my newcomer’s eyes it’s a sort of preseed/kickstart on
steroid, merged with Saltastack/Ansible/… and as the base of the OS
instead of being an external wrapper.

  • a somewhat obscure DSL, IMVHO Guix do a far nicer choice with Guile
    In some sense, Nix is purely-functional in a way that doesn’t fit
    general-purpose languages; so there is still this switch between
    evaluation-time purer code and build-time code (and run-time code).
    My knowledge is too limited to judge, it’s simply a “skin preference”
    but having took a glance a Guix I think I understand what you say,
    only even if some Guix/scm construct seems to be… well… Not easy
    to digest, I still can try to figure out some mechanics while on Nix
    I have to ask. Perhaps this is not general, being an Emacs user I see
    lisp-y stuff frequently so I feel more natural such way of express
    concept than a completely new one.
  • a non-so-big documentation, often not much updated, missing howtos
    Note that for a given amount of documentation, there is still a
    question of how accessible the relevant documentation is while
    configuring the system. If you have a special-cased configuration
    editor, it is easier to show inline descriptions from module
    definitions.
    Well, I’d really like to contribe docs, only to do so I need knowledge
    and actually I found it’s hard/time consuming to aquire it… My ideal
    preference is a book, something like “read this n-th page and you have
    enough knowledge to get started with your own feet, big-picture well
    distilled and small in-depth aspect as needed to start a common case
    senario + an evolution path outlited”. Of course producing something
    like that it’s long and complex and kept it up-to-date it’s also hard
    but IMVHO that’s the best “companion” to easily access ANY other docs,
    including a wiki, an ML/forum, APIdocs, developer guides etc. Having
    docs aside in the install process is useful, but only after having
    aquired a basic knowledge, as a reminder or a way to do small personal
    explorations.

I do think it is important that the configuration editor should allow
slow and gradual transition to manual editing, but I hope it might end
up actually possible.
I can’t imaging how… Trying to look elsewhere (i.e. RAD softwares) I
do not really see anything effective. And there where tons and tons of
effort from ancient “user-programmer” effort to modern IDEs…

project, so something to serve their devs/community itself, not to
serve “consumers”. Newcomers willing to learn may find hard to start
certainly
I think this discussion might be a good place for developers with
a common goal of minimising their own expenditure of effort to help
people who want to decide whether to invest effort into learning Nix.
Hum, I think only good, clear, complete, step-by-step documentation
may lead users to knowledge without flooding forums/IRC etc with
questions, lack of it result in the opposite… Users not willing
to learn… Well… They’ll keep asking and perhaps having a separate
place for newcomer’s discussion may help but it’s not a good path, we
are in an era where people think anything can came in a snap but those
kind of people can’t really be part of a FOSS community, the ancient
Internet Manifesto shoud be advertised as answer for them IMO.

(I am not one of them, but I think some of the claims in your post were
too pessimistic)
Yep, I’m really pessimistic not about NixOS but about IT and society
future in general. Nix{,OS} as now, as idea IMO is a VERY good future
and present, and certainly start to mimic other “old” distros it’s
not a good thing for me. I think Paul Graham’s article’s
Beating the Averages
tell a really simple truth also summarized by an ancient Italian
proverb “the pitiful doctor make the gangrenous wound” or follow
certain desire result in disaster instead of good.

– Ingmar

Oh, UAU, finally another Git disgruntled user :slight_smile: IMVHO the sole reason
of it success reside in what an ancient teacher describe as “sheep
effect”: “a big name create and use it so it must be the best”.

Please do not discount the significant amount of personal effort and
time the said well known person has sinked into communicating the basic
model of the world behind DVCSes. Of course, he communicated the Git
version (which I find suboptimal compared to other options), but the
effort was real and informative to some people.

Then network effects — not network effects of software, actually, there
is probably more network effects from GitHub.

Maybe a bit of focus of speed helped with advertising. Of course, Git
gained speed by using details of ext3 behaviour that are no longer there
(so Git has some data corruption risks on ext4).

Unfortunately I think that requesting a GUI installer fell in the same
effect “well-known distro with ‘user-friendliness’ reputation have it so
it’s better adopt this approach”…

I think there is a chance to do things that are useful to some people.

Personally, after OpenSolaris/SUN death I had chosen Ubuntu mostly
because “it works well”, “it’s a better Debian” etc and FreeBSD does
not play well anymore on my iron. I already know Debconf so I go for
it. After when they choose to suppress alternate iso I have find how
limited Ubiquity is. After when they decide to ditch Debconf for a
homegrown curses installer I end up saying that Ubuntu can’t really
be used anymore. Now my desktop is NixOS and I’m lobbing to switch
also as much as any other system I can…

Note that Ubuntu doesn’t seem capable to deviate from Debian enough to
drop apt, as for Debconf — it was not in the critical stack, so it was
dropped.

With Nix*, Nix and Nixpkgs seem to be bound to evolve continuously, and
the most likely direction for GUI wouldn’t even put many requirements on
NixOS code compared to the current needs of the manual.

Note that a GUI for NixOS confguration if expected to inherit and
follow Nix and NixOS models of the world. This should help.
Well, perhaps is a personal mind limitation… But I can’t figure out
anything that can “inherit” a programming/expression language in a GUI.

It’s all question of vocabulary; when you edit configuration, what are
the knobs you end up turning.

For example, Synaptic GUI operations are relatively transparent wrappers
over the most popular APT operations. There are packages, there are
dependencies, packages can be filtered, installed and removed, they have
descriptions…

Even “mythological programmers” like ancient Parc devs of Xerox Alto
have tried something similar with Smalltalk and fail, Plan9 8½ and it’s
successor rio also fail and all of them are mostly text arranged in some
GUI environment, not “full-GUIs” like modern’s one… Perhaps Emacs is
the sole flexible text-based GUI out there with success, and nearly any
Emacs user suppress menubars, scrollbar etc…

There are pretty advanced Vim plugins. Of course, GNU project aura
behind GNU Emacs might have helped it at some point.

Well, for editing configuration.nix you want completion, you want option
search, you want option documentation pop-ups… At some point it might be
simpler to maintain a GUI for a very limited special-case editor than to
make sure the Emacs mode for editing the configuration is accessible to
Kate/IDEA users.

I can just say that even though I have an expression to create
a prepared Firefox profile and its input is prefs.js, I still use
about:config for option lookups before trying to look at the MDN. Then
I copy the option name into a text file from there, yes. Fortunately,
about:config is friendly towards mixing its use with editing prefs.js,
and I hope NixOS configuration editing GUI would also have this useful
property.

But is it simpler than their native interface? And more important can be

Easier for whom? Below some level of high-speed manpage search skills,
it is likely to be easier for some users.

Then again, of course for weird enough fs layout requests NixOS
configuration becomes more annoying to edit than just a script to set up
everything. So I do not use NixOS as-is and write my own bootscripts
instead. But many people want things that are well-supported, and prefer
the integration value of using mainline NixOS.

I think once you say configuration.nix is good, having a GUI editor for
it doesn’t depend on whether it is better for a specific task than just
writing a script directly.

automatized more or less than them? Personally I think that actual

No, it is not more important. If something is built using the existing
automation interfaces and doesn’t mangle the underlying logic, it
doesn’t need to be automatable — it just needs to allow for easy
inspection of low-level automatable actions corresponding to GUI
choices.

Not every consumer of automation APIs needs to reexport them in full.

LUKS+LVM+nifls2 triplet… Can a GUI do something like Stratis, keeping
flexibility that even Stratis itself miss in some corners? Personally
I’ll be really surprised if so…

GUI doesn’t need to do everything, it should just provide escape routes
to do some things you care about manually without losing access to doing
later step with integrateed completion. Most people don’t care about
changing the small details of everything, and can get some value from
easier onboarding at first. Those who find it valuable to learn the
details might stop using the GUI, that’s OK, as long as there is some
working feedback channel between those who understand the details and
those who use the GUI.

Note that the GUI might be a convenient way to organise
autocompletion, and (unfortunately) there are users that are more
comfortable with this than with other ways. Even if they do understand
the nuderlying choices.
Well, having something comfortable as
NixOS Search
NixOS Search
locally is certainly a very welcomed thing for me. Having a small docs
side-by-side while installing can be also a very good thing, far better
than look for something in the wiki and in a search engine. And yes, a
GUI can do a good job in that sense, perhaps even better than GNU info
for most users, but that’s not an installer, it’s a complementary app
in the live image…

Then again, it is nice to integrate the documentation lookup with what
you are editing right now. Then again, there is little harm in having
a small popup window that says «You need to partition the HDD (button
to start Parted), edit the configuration (button to start the
configuration editor) then start the actual installation (button to
open nixos-install in a terminal window)».

Would that be a GUI installer?

I do believe configuration editor with integrated support for looking up
context-relevant documentation is on the critical part anyway, and I am
arguing in favour of making sure the configuration editor from the
installer can be used afterwards, too.

Second part: creating the new system if you already are a NixOS user
Sure, if you edit Nix code fluently, you would just do that.
I don’t. I’m a new users, with few months on NixOS and substantially
zero contribution, only a super-duper-simple fix, my knowledge of Nix
and NixOS is REALLY limited. But nevertheless I’m pretty comfortable
with my /etc/nixos config (and soon homeManager). One of the reason
that bring me to NixOS is exactly the ability to replicate my system
simply drop few text files on a directory and let the installer do it’s
business. For my newcomer’s eyes it’s a sort of preseed/kickstart on
steroid, merged with Saltastack/Ansible/… and as the base of the OS
instead of being an external wrapper.

I just read the three manuals and declared myself comfortable editing
Nix code for my configuration (ten years ago, plus or minus)

  • a somewhat obscure DSL, IMVHO Guix do a far nicer choice with Guile
    In some sense, Nix is purely-functional in a way that doesn’t fit
    general-purpose languages; so there is still this switch between
    evaluation-time purer code and build-time code (and run-time code).
    My knowledge is too limited to judge, it’s simply a “skin preference”
    but having took a glance a Guix I think I understand what you say,
    only even if some Guix/scm construct seems to be… well… Not easy
    to digest, I still can try to figure out some mechanics while on Nix
    I have to ask. Perhaps this is not general, being an Emacs user I see
    lisp-y stuff frequently so I feel more natural such way of express
    concept than a completely new one.

Well, I started using Nix after some experience with Scheme, so Scheme
would be a more familiar base for me (there was no Guix back then).
But Nix language syntax is an hour of reading, while semantics of all
the corner cases is a bit more of learning. Then again, I think Guix
supports fewer weird corner cases than Nixpkgs tries to support, so
there might be genuinely fewer gotchas.

  • a non-so-big documentation, often not much updated, missing howtos
    Note that for a given amount of documentation, there is still a
    question of how accessible the relevant documentation is while
    configuring the system. If you have a special-cased configuration
    editor, it is easier to show inline descriptions from module
    definitions.
    Well, I’d really like to contribe docs, only to do so I need knowledge
    and actually I found it’s hard/time consuming to aquire it… My ideal
    preference is a book, something like “read this n-th page and you have
    enough knowledge to get started with your own feet, big-picture well
    distilled and small in-depth aspect as needed to start a common case
    senario + an evolution path outlited”. Of course producing something
    like that it’s long and complex and kept it up-to-date it’s also hard
    but IMVHO that’s the best “companion” to easily access ANY other docs,
    including a wiki, an ML/forum, APIdocs, developer guides etc. Having
    docs aside in the install process is useful, but only after having
    aquired a basic knowledge, as a reminder or a way to do small personal
    explorations.

Note: any remark «I wish I knew it before» from you as a newcomer (with
some explanation of context) might be a contribution to documentation
that cannot be replaced by enthusiastic people who already know their
way around.

(I do think that just reading the Nix manual and skimming the NixOS
manual is still enough of the core model for the first installation;
some finer details might be harder to learn)

I do think it is important that the configuration editor should allow
slow and gradual transition to manual editing, but I hope it might end
up actually possible.
I can’t imaging how… Trying to look elsewhere (i.e. RAD softwares) I
do not really see anything effective. And there where tons and tons of
effort from ancient “user-programmer” effort to modern IDEs…

Well, I have edited Lazarus form definitions manually, and it worked.
And on the code side it just added some stubs that were perfectly usable
for further editing.

And here you already can edit the same configuration via Vim or Emacs
with different plugins; I don’t see why a special-case editor couldn’t
edit the same configuration.nix

project, so something to serve their devs/community itself, not to
serve “consumers”. Newcomers willing to learn may find hard to start
certainly
I think this discussion might be a good place for developers with
a common goal of minimising their own expenditure of effort to help
people who want to decide whether to invest effort into learning Nix.
Hum, I think only good, clear, complete, step-by-step documentation
may lead users to knowledge without flooding forums/IRC etc with
questions, lack of it result in the opposite… Users not willing

Checking if something specific works well on NixOS before investing
effort is a legitimate demand.

Good context-aware completion is faster to use than standard-form
reference documentation.

to learn… Well… They’ll keep asking and perhaps having a separate
place for newcomer’s discussion may help but it’s not a good path, we
are in an era where people think anything can came in a snap but those
kind of people can’t really be part of a FOSS community, the ancient
Internet Manifesto shoud be advertised as answer for them IMO.

Unfortunately, meatshield is also useful. We need to tell some upstreams
that they are doing things wrong; user count helps even if these users
cannot contribute neither code nor documentation by their own.

(I am not one of them, but I think some of the claims in your post were
too pessimistic)
Yep, I’m really pessimistic not about NixOS but about IT and society
future in general. Nix{,OS} as now, as idea IMO is a VERY good future
and present, and certainly start to mimic other “old” distros it’s
not a good thing for me. I think Paul Graham’s article’s
Beating the Averages
tell a really simple truth also summarized by an ancient Italian
proverb “the pitiful doctor make the gangrenous wound” or follow
certain desire result in disaster instead of good.

We need solid foundations and an option to work in terms of these
foundations. Having multiple shiny wrappers on top is OK as long as they
don’t break the underlying foundation.

Maybe I am more pessimistic than you because I do not consider NixOS
mainline usable for my laptop (I still use Nixpkgs kernel, though). But
anyway, the GUI installer would be on top of NixOS tooling, so your
desires would be still feasible, just not the most popular approach.

Nix* has a lot of inertia, so forgetting configuration.nix at all is
just not feasible from coordination POV.

Please do not discount the significant amount of personal effort and
time the said well known person has sinked into communicating the
basic model of the world behind DVCSes. Of course, he communicated the
Git version (which I find suboptimal compared to other options), but
the effort was real and informative to some people.
I didn’t, but as any FOSS project Linus Torvalds create Git because he
need it and he need it in that way, I bet he look at other dVCS, perhaps
Monotone, Darcs, SVK, … perhaps he look at other contemporary new dVCS
projects (Mercurial, Fossil, Bazaar) and he find they do not suit his
need. So he create it’s new tools and release it to the world as any
FOSS project. I do not discount it enormous personal effort, I only
criticize many that choose Git simply because “it’s created by Linus so
it must be good” often even without looking at other dVCS and VCS in
general. FOSS evolve thanks to diversity and cooperation, being all on
a single project cut down evolution, create dangerous SPOFs and make a
prject grow to a point that casual contributing it’s super-hard.

Then network effects — not network effects of software, actually,
there is probably more network effects from GitHub.
And that’s another thing I criticize: having such “hub” is needed, we
do not have fully-distributed solution that work and scale out of the
box. But being all in one single service, especially if it’s a
proprietary one, owned by a company, non by a no-profit organism it’s
a big Damocle sword, especially if it’s not only use as a mere “official
URL” that can be changed easily but also for some proprietary features
like PR that can’t be “ported” easily elsewhere…

I think there is a chance to do things that are useful to some people.
There is always room for anything in FOSS, it’s only a matter of how to
grow and evolve such room, sometime it’s easy, sometime might be
dangerous because “transform” by it’s weight the course of a project
slow down or badly evolve it in the timeline…

With Nix*, Nix and Nixpkgs seem to be bound to evolve continuously,
and the most likely direction for GUI wouldn’t even put many
requirements on NixOS code compared to the current needs of the
manual.
I hope so, my main fear is in the mid terms to find big boilerplate
code for support “the GUI part” (extra code ⇒ extra bugs) and in the
long term a situation like Ubuntu’s one in witch distro decide to
drop better installer for worse because the new userbase is more and
more composed by newcomers that are not comfortable with powerful and
flexible solutions.

It’s all question of vocabulary; when you edit configuration, what are
the knobs you end up turning.
Understood, but how many knobs you can trigger with code respect of how
many you can fit in a GUI?

For example, Synaptic GUI operations are relatively transparent
wrappers over the most popular APT operations. There are packages,
there are dependencies, packages can be filtered, installed and
removed, they have descriptions…
Because package operation are “atomic manual actions” on both UI, but a
written config it’s another story. A simple one can be easily wrapped
with a GUI (think about sysctls), a flexible one, even simple, it’s hard
(think about classic fstab) a really complex one I can’t figure out how
it can be mapped without deeply change the config itself transforming it
in some sort of ini-style key-value pairs…

Well, for editing configuration.nix you want completion, you want
option search, you want option documentation pop-ups… At some point it
might be simpler to maintain a GUI for a very limited special-case
editor than to make sure the Emacs mode for editing the configuration
is accessible to Kate/IDEA users.
Hum, I think Jedi (python) approach is protable, essentially a REPL with
an API to communicate with other software instead of human. Maintain a
GUI it’s far complex and just to start require to choose some toolkits
and having it installed…

I can just say that even though I have an expression to create
a prepared Firefox profile and its input is prefs.js, I still use
[ 2 more citation lines. Click/Enter to show. ]
about:config for option lookups before trying to look at the MDN. Then
I copy the option name into a text file from there, yes. Fortunately,
about:config is friendly towards mixing its use with editing prefs.js,
and I hope NixOS configuration editing GUI would also have this useful
property.
I second, for Nix options, but about:config is essentially a key-value
config, Nix is a kind of programming language… An order of magnitude
complex.

Then again, of course for weird enough fs layout requests NixOS
configuration becomes more annoying to edit than just a script to set
up everything. So I do not use NixOS as-is and write my own
bootscripts instead. But many people want things that are
well-supported, and prefer the integration value of using mainline
NixOS.
I mean that actual Linux “storage” is really terrible and obsolete and
that make hard doing complex (and even less complex) thing, that must
be solved IMO at “linux” level, not with a GUI on top of actual tech.
Also support well “common cases” IMO lead to less and less support for
corner cases, IMO “good defaults” are a good thing but a different kind
of beast than “common case” in the sense that make people happy but do
not tend to “emarginate” corner cases.

GUI doesn’t need to do everything, it should just provide escape
routes to do some things you care about manually without losing access
[ 3 more citation lines. Click/Enter to show. ]
to doing later step with integrateed completion. Most people don’t
care about changing the small details of everything, and can get some
value from easier onboarding at first. Those who find it valuable to
learn the details might stop using the GUI, that’s OK, as long as
there is some working feedback channel between those who understand
the details and those who use the GUI.
As long as GUI and classic text can coexists without issue (like classic
"do not edit manually it might be overwritten bye … warning) I have
nothing against, only I think it will be really hard to realise such UI.

Then again, it is nice to integrate the documentation lookup with what
you are editing right now. Then again, there is little harm in having
[ 2 more citation lines. Click/Enter to show. ]
a small popup window that says «You need to partition the HDD (button
to start Parted), edit the configuration (button to start the
configuration editor) then start the actual installation (button to
open nixos-install in a terminal window)».
Would that be a GUI installer?
Kind of, yes, a sort of wizard-literate style active documents. It can
be nice, only as long as it does not start to ditch or less support
automatable way :slight_smile:

Note: any remark «I wish I knew it before» from you as a newcomer
(with some explanation of context) might be a contribution to
documentation that cannot be replaced by enthusiastic people who
already know their way around.
I do it, right now I keep and org files that log my discovering
including indirect one I discover simply receiving discourse mails,
planning, when I well be comfortable enough to write down a complete
howto with “many evolution paths” the reader can choose. For now it’s
only a small log about creating a custom iso to support zfs before,
nilfs2 now, installing on few UEFI and Bios systems few notes about
nvidia-optimus crap etc. If someone is interest I may invest a bit
more time in that or at least sharing it in some way :slight_smile:

Checking if something specific works well on NixOS before investing
effort is a legitimate demand.

Good context-aware completion is faster to use than standard-form
reference documentation.
Of course, but if you already know something for instance because you
already read some docs, otherwise it might be an uncomfortable and not
so safe way to explore something you do not really know…

We need solid foundations and an option to work in terms of these
foundations. Having multiple shiny wrappers on top is OK as long as
they don’t break the underlying foundation.
That’s what I fear…

– Kim

I didn’t, but as any FOSS project Linus Torvalds create Git because he
need it and he need it in that way, I bet he look at other dVCS, perhaps
Monotone, Darcs, SVK, … perhaps he look at other contemporary new dVCS

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?

FOSS project. I do not discount it enormous personal effort, I only
criticize many that choose Git simply because “it’s created by Linus so
it must be good” often even without looking at other dVCS and VCS in

Many also chose it because they didn’t know what DVCS is before they
heard Linus Torvalds talk about Git. He more or less was working on
creating demand, which bootstrapped network effects.

URL" that can be changed easily but also for some proprietary features
like PR that can’t be “ported” easily elsewhere…

We probably have already reached a scale where lookin up old PRs is
getting less and less practical anyway…

With Nix*, Nix and Nixpkgs seem to be bound to evolve continuously,
and the most likely direction for GUI wouldn’t even put many
requirements on NixOS code compared to the current needs of the
manual.
I hope so, my main fear is in the mid terms to find big boilerplate
code for support “the GUI part” (extra code ⇒ extra bugs) and in the

Current module system is complicated enough that it is hard to add much
complexity for GUI support… The volume of code that is only used by
GUI shouldn’t bother you, these are not bugs you care about.

long term a situation like Ubuntu’s one in witch distro decide to
drop better installer for worse because the new userbase is more and
more composed by newcomers that are not comfortable with powerful and
flexible solutions.

Follow the money. We have a rare situation where this phrase can be used
in an optimistic key. People who offer paid services using NixOS need
repeatable deployment process; the project founder is among them.
Whatever forks off, demand for automatable deployment is backed by code
and money contributions…

It’s all question of vocabulary; when you edit configuration, what are
the knobs you end up turning.
Understood, but how many knobs you can trigger with code respect of how
many you can fit in a GUI?

There are GUIs that fall through to actually entering code for some
things. Dunno, Dr.Geo or KIG.

(think about classic fstab) a really complex one I can’t figure out how
it can be mapped without deeply change the config itself transforming it
in some sort of ini-style key-value pairs…

First, the configs advised to newcomers already avoid anything not
expressible in JSON. GUI JSON editors for known schemas exist.

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.

Skepticism is non-actionable, questions about specific corner cases —
hopefully — are.

Hum, I think Jedi (python) approach is protable, essentially a REPL with
an API to communicate with other software instead of human. Maintain a
GUI it’s far complex and just to start require to choose some toolkits
and having it installed…

Actual support probably means LSP, then we end up waiting for universal
LSP support in editors…

I second, for Nix options, but about:config is essentially a key-value
config, Nix is a kind of programming language… An order of magnitude
complex.

Well, for a long time there has been a lot of resistance to let Nix
become full-fledged programming language. I think this is a bit of
evidence in favour of simple things being possible in a simple way.

I mean that actual Linux “storage” is really terrible and obsolete and
that make hard doing complex (and even less complex) thing, that must

I think Linux storage is flexible and composable and can be fine-tuned
because each layer has well-defined responsibilities.

be solved IMO at “linux” level, not with a GUI on top of actual tech.
Also support well “common cases” IMO lead to less and less support for
corner cases, IMO “good defaults” are a good thing but a different kind
of beast than “common case” in the sense that make people happy but do
not tend to “emarginate” corner cases.

Didn’t you just criticise Linux storage for things that actually enable
handling of weird corner cases?

As long as GUI and classic text can coexists without issue (like classic
"do not edit manually it might be overwritten bye … warning) I have
nothing against, only I think it will be really hard to realise such UI.

Well, if that warning does say where to put manual overrides, I consider
it succesful coexistence. And we have profiles for that. Manually-edited
profile, strictly structured GUI-edited profile, and possibility to copy
and edit something into the manual profile.

nvidia-optimus crap etc. If someone is interest I may invest a bit
more time in that or at least sharing it in some way :slight_smile:

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 myself is a bad documentation writer just because I prefer reading
documentation styles most other people find bad. So I cannot recommend
how to contribute best beyond preserving what is very hard to recover
later.

so safe way to explore something you do not really know…

I think rollbacks make exploration safer, and if someone doesn’t want to
read distro manual, chances are the installation will be in a VM anyway.

We need solid foundations and an option to work in terms of these
foundations. Having multiple shiny wrappers on top is OK as long as
they don’t break the underlying foundation.
That’s what I fear…

Incentives are good, though: do not break old style of use and you can
commit basically whatever GUI support on top, break something — get the
changes reverted at random.

Personally I think that it’s brilliant to focus on usability, regardless of how it’s implemented. I haven’t read the whole thread as it seems that it has devolved into a CLI vs GUI discussion.

Here are a few ideas that might or might not have already been discussed

  • Repair Nix PackageKit - it would provide a nice GUI for users to list and install packages. It goes a bit against declarative packages but maybe there is a way around that.
  • Add an service that generates Live ISOs on the fly with the desired package sets and hardware configuration. It could be a constrained to a subset of features to avoid combinatorial explosion.
  • Add VSCode and a Nix LSP server in the Graphical ISO to allow for code-completion in the initial NixOS configuration.
  • Integrate nixpart or some similar solution in the installer to replace fdisk/parted with a declarative disk layout configuration.
  • Integrate nixos-hardware with the installer. Ideally there is a detection tool that finds what machine the user is running on to select the right configuration.
  • Pick one DE like KDE and fix all the issues. So at least one DE is working very smoothly.

With all these changes the user should be able to pick, test and install KDE and have a nice and working environment. There are many more issues to fix obvious but this is a journey. What other ideas do you have?

11 Likes