User-friendly NixOS distro?


#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. https://davidak.de/nixos-installation/

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.


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