Oh, UAU, finally another Git disgruntled user 
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.