Ironically, it was your post on the Manjaro forums last month which made me start looking at nixos. Glad to hear you found a distro that fits you and thanks for pointing me in this direction.
This used to be the case in NixOS as well. It doesn’t bother me that much, since I usually just stay logged in and rely on the screen locker. But it’s a clear regression compared to before.
This works for me. Do you perhaps use shell not listed in /etc/shells? You need to list the package/path in environment.shells if you do not use NixOS module that does it for you…
Mh,
personally I consider nearly ALL the cited point as thing to avoid:
-
Slack… I HATE it and do my best to avoid it as all Electron
crapps out there; -
GNOME has evolved to a point of be a *load of unstable crap,
and NOT on NixOS but in general; -
I never find traditional systems like Manjaro maintainable for
long time, rolling releases in particular when at any point in
time they can brake; -
I always found GUI installer limited and limiting and their
automated partitioning a thing to be avoided.
Having a declarative config for me is a relief: I can simply save
few text files and have all I need to deploy my systems. No more
personal scripts, no more fight with Saltstack or Ansible. It’s
simply amazing.
The cons I’ve found on Nixos are:
-
Nix language, not really documented in a good nice form and not
easy to understand, to a point, honestly, that I’ve looked a bit
about Guix System since scheme is far easier to digest,
unfortunately for me a distro that reach 1.0 milestone WITHOUT
LVM or ZFS support is a bit ridiculous; -
Some things normally work on classic distros are a pain on NixOS,
mostly proprietary crapps or proprietary printer and scanners
drivers packages, it’s not good but I understand why they can’t
work properly and they are NOT a priority; -
The docs, the wiki is ok, but I feel the need of a damn good manual
like a book, only discovering things like “how to configure bind”
was a long web search after another. Not knowing up front I can’t
contribute but that’s a big issue for a revolutionary system, being
“different” from the mainstream means that new users have to learn
it to benefit and contribute…
However I’ve NO intention to leaving NixOS and I thanks all it’s devs
for that fantastic piece of software 
@trusktr I hope you’ll install Nix package manager on Manjaro, just as tribute to this whole Nix journey. Maybe some day some package will break on Manjaro and you’ll just grab it from Nix like-a-boss.
Thank you for your article. It is well written, with practical examples. Some points make me miss imperative-style distributions based on Debian or Arch Linux.
I do agree with your first argument
Tools like
nvm(or any tools that install Linux binaries expecting to operate in a traditional Linux FHS environment) don’t work out of the box in NixOS
From my experience, standard package/version managers npm, pip, … do not work flawlessly in NixOS and this breaks a lot of common development workflows. (never used nvm btw).
For instance, when I was on Ubuntu, while working on python projects, after a checkout that changed the requirements.txt file, my Pycharn IDE would automatically suggest to update the current virtualenv. AFAIK pip was used under the hood to grasp needed package versions. It was easy to synchronize the virtualenv with the current commit.
Nix has an authoritative way to manage packages. It’s a package manager “to rule them all”. IMO that’s a good thing – all software packages should be centralized (e.g. in the nix store). Their is no theoretical reason to do the other way round. I only know pragmatic reasons that prevent developers to centralize all packages, due to mainstream habits. If you disagree I am really curious to read your arguments.
The current state of development habits involves several package managers (npm, pip, …). Usually at least one per language, often with its own main repository, that contains a set of versions for each library/application package. Taking care of these scattered repositories seems a lot of work from each community. AFAIK it is not easy to wrap each package management machinery (repository included) through a unique package manager, that would use each of them when needed. IIUC Nix is trying to do so, but I wouldn’t recommend it for general audience yet until their is a standard development workflow for each language.
From a productive developer point of view it may thus be a good reason to stay on an imperative distribution for the moment: they have proven development workflows. For me other benefits of Nix/NixOS counterbalance this drawback. It’s up to each user to identify its needs.
Comparing NixOS with Manjaro is not 100% fair IMO, since NixOS is at the software level of Arch Linux: it gives you a framework to manage your modules and software packages. With both of them you can build the system you want, whereas, with Manjaro, you get an opinionated system state dealing with most common usages. Currently I would say that NixOS has no full fledged distribution for general audience, whereas Debian has Ubuntu and Arch Linux has Manjaro.
Manjaro ships with a nicer Gnome experience out of the box.
This is by choice. We decided to follow GNOME’s upstream package sets as closely as possible to have vanilla GNOME installation. See Cleanup GNOME3 default applications · Issue #67310 · NixOS/nixpkgs · GitHub.
It is listed in /etc/shells, so that isn’t the problem. I should probably dive a bit deeper. But as I said, it’s not a hassle for me, but I can imagine it being annoying to newcomers.
Preface
The critiques to the GNOME experience seem very particular to switch to an entirely Linux distribution.
My following comments aren’t to to make you back out on your decision, but as I’ve actually tailored the default Gnome experience in NixOS, I believe I should commentate on them.
Not wanting to edit configuration files?
I didn’t need to edit any configuration files
If you dislike even using the Nix language I don’t think NixOS is for you.
I feel in the future, if we had a graphical interface for these things, NixOS would be much more practical for the average user.
The GNOME experience
Vanilla?
Manjaro ships with a nicer Gnome experience out of the box.
We decided on having the defaults to be vary “Vanilla” in NixOS because NixOS is a very general purpose distribution.
We actually align almost completely with what upstream recommends:
Which I believe is the SDK used in GNOME OS.
I’m confused about the critique about things being vanilla in general.
Another distro that has lots of points for users ease of use is Fedora, and it’s about just as vanilla as ours.
Doesn’t ship GNOME Tweaks?
Manjaro’s Gnome flavor ships with Gnome Tweaks
Umm, you can install gnome-tweaks? :shrug
environment.systemPackages = [
pkgs.gnome3.gnome-tweaks
];
And let’s investigate how this is completely different than installing any package with pacman is like.
With the above configuration, your system will always have gnome-tweaks. It will have gnome-tweaks wherever this configuration is realized. If you change your nixpkgs revision (update nixos) and this package is broken you wouldn’t be able to realize your configuration. You could install NixOS and twenty different machines with this configuration, and it will have the same result everywhere.
That’s the paradigm shift in NixOS, and that’s in managing your setup declaratively. You don’t just have to rely on things being there because the developers decided that what was going to be included by default. You can then instead, formulate your own exact profile for the experience you want on your machine, and can replicate that on any machine with Nix. I don’t think many, if any, distro’s offer this kind of functionality in the bones of the system.
Doesn’t have enough extensions/themes out of the box?
and a bigger variety of popular Gnome Extensions and Themes available out of the box.
This is rather disappointing to think that my competition in other distros is that they have more themes packaged for you to use right away. You can also do packaging requests on GitHub, and while there’s no guarantee it will be packaged, it could happen.
Another thing that NixOS actually makes pretty easy is extending nixpkgs with more packages.
This is a feature in NixOS Nixpkgs Reference Manual.
Apps that want it (like Slack, Chromium, and others) get their task icon placed in the top right of the task bar thanks to the knotifier extension, and clicking the icons reveals options for controlling the application. It’s a “system tray” so to speak.
Yeah, Gnome killed that functionality a while ago. So IMHO, GNOME distributors shouldn’t even tailor to accommodate for this. All things mentioned above ^ apply, it’s just an extension to install.
Nice Shell and GTK themes out of the box in Manjaro, while NixOS only has the default theme (with modified logo and background).
Is GNOME Adwaita not nice? I guess Manjaro has a custom theme.
GDM Issues?
Normally the GDM login screen should show a button for my user profile that I can click on (or hit enter) then type my password (this is the default Gnome GDM experience), but in NixOS I have to manually enter my username in a text field for some reason. GDM works fine in Manjaro.
Never encountered this bug, but I suspect it has something to do with an issue with AccountsService and Logind maybe in 19.09. Would love to see a bug report from anyone here who’s experienced it.
Hard to setup a desktop environment?
it takes more work to properly set up a desktop environment in NixOS.
Plus it is easy to install the desktop environment the wrong way, as there are multiple good and bad ways to install things in NixOS.
This is easily the most confusing comment for me.
To install a desktop environment in NixOS, is probably as simple as it could get anywhere.
services.xserver.desktopManager.gnome3.enable = true;
services.xserver.desktopManager.xfce.enable = true;
And nixos-rebuild and you’re done.
In other distro’s, all you’re dealing with is packages. Using Xfce, for example, in Manjaro is just a matter of installing a metapackage. It’s true there’s multiple ways to install things in NixOS, but Xfce isn’t a package in NixOS to install.
Closing
I see so many Linux users find issue in their distro of choice’s user experience and make no effort to send feedback. I’ve fixed bugs like
almost exactly after I saw the post, and ported the fix to the stable release.
Full disclosure, I actually used Manjaro before I was using NixOS.
And while I noticed similar paper cuts upon switching, I understood I switched for something greater than reducing paper cuts.
warmth - 
worldofpeace
@trusktr Thank you for taking the time to write up and send us your feedback. I appreciate it.
Just a note on the NodeJS development: I don’t use nvm, instead I simply pick the version of node I need with nix-shell -p nodejs-12_x, and I actually use v12 as a default install for my user.
I don’t manage NPM dependencies via Nix during development, it’s just too much of a hassle at the moment. I don’t even package the end result as a Nix package even though I should. Recently there seems to have been good progress on packaging NPM for Nix, but I didn’t have time to look at it yet.
Furthermore, I’m actually using Nix via Nixpkgs on macOS, which is great. You can keep using nixpkgs on Manjaro Linux if you like.
(macOS itself is not so great any more, it’s more and more locked up in annoying ways. I’m really considering switching to Windows, I’ll see what Apple brings out this spring for the 13" line)
For battery life, I wonder if either powertop from Intel, or tlp, would help, i.e.
# One or the other, probably not both but not sure
powerManagement.powertop.enable = true;
services.tlp.enable = true;
I believe manjaro actually uses one of these default, and perhaps maybe thermald for intel chips?
Ah, I haven’t heard of thermald, thanks! Perhaps that will allow me to not boil water with my laptop
Ironically, one(?) of my NixOS desktops does have this, though I haven’t had the time to determine why or how 
I wouldn’t use any rolling release for productions servers. For personal computing, I think it is fine. I am honestly saving time compared to having to tweak and configure my OS. I have other more important things (for me) that I want to work on. I want more configuration that macOS or Windows, but not as much as needed for bare Arch Linux or NixOS.
It fit my needs well, because I just wanted to wipe a computer clean, and boot into a linux distro as a daily driver without fuss. Maybe that isn’t your case. I personally am not going to dual boot anything, I’m not going to make partitions, I just need one, etc. I just want to get to work on my other projects. Your situation may be different, maybe you want to have multple OSes on one machine, or you want to manage server configurations and happen to be able to do that without much fuss within NixOS constraints, or whatever it may be. In that case I understand you need the configurability, but for me it isn’t much of a benefit right now.
As for your other bullet points, that’s just opinion. I like or need those pieces of software.
Declarative config is not a bad idea. However with NixOS there’s in fact multiple ways to achieve the same thing for NixOS configuration, and that can be confusing and some ways lead to worse results than other ways.
I think that still requires potential ELF patching or FHS mocking. It’s not ideal. I think borrowing ideas from Conan, NPM, and ied (which is inspired by NixOS in its hashing technique) may lead to better results. Those three package managers don’t care about your OS environment, and any filesystem dependence is only local to each project. I wrote more here why it may be a better path to come up with something along those lines for a new OS in this comment. I think an approach that leaves user’s OS untouched from the beginning is going to be much easier to adopt by many, as well as make a good foundation for a new OS.
A vanilla experience isn’t bad per se, but there’s issues like GDM not behaving like it should be default (sometimes switching back and forth for no apparent reason) or application opening as other applications which is confusing. I tried to configure Gnome from scratch with Arch Linux, and I know these issues can be tricky to achieve. Some default configuration is totally needed, and Arch doesn’t give you that, and NixOS is missing something. Manjaro has the Gnome configuration mastered, and it has no issues at all. As an example, I know that Gnome needs particular PAM settings (at least the last time I tried a few years ago) to play well with multiple user accounts. Those aren’t things that you just get out of the box installing upstream libs, so there’s room for mistakes when making a full configuration for an out-of-the box experience.
Based on this experience, I know that Manjaro went through pains with perfectly configuring things such as the auth system (PAM, or whatever it may be now), authentication popups, .desktop applications not crossing into each other, GDM Xorg integration, etc, and the system just works in every way that I expect.
Maybe I misconfigured something. There’s multiple ways to configure NixOS to get (almost) the same results, but inevitably it leads to slightly different results. With pacman, there’s only one way to install something. With nix, there’s multiple ways to install something with differing results, and it isn’t always obvious which way is the best.
I believe in the idea that Nix has on a general level, but I have a feeling there’s a better way to do it that doesn’t rely on hacking FHS/ELF/etc.
Maybe, but with Manjaro at least I get something without thinking about it. It may be nice if NixOS gets “flavors” like Gnome flavor, KDE flavor, in the form of configurations (minus the hardware parts which still need to be generated), and these flavors would come with everything that people expect from a full desktop so they don’t have to configure a single thing. People who like to configure everything don’t have to use the config flavors.
I forgot to mention, in Manjaro, there are zero messages during boot (which is what I want). All I see is the built-in Dell logo, and for a moment I can even move my mouse on top of the Dell logo (somehow Manjaro retains the OEM boot logo in memory), then finally GDM appears right after that (with my mouse still moving). Manjaro boot is quite polished out of the box!
I couldn’t disable all boot messages in NixOS, even with plymouth enabled.
Hi,
I wouldn’t use any rolling release for productions servers. For
personal computing, I think it is fine. I am honestly saving time
compared to having to tweak and configure my OS. I have other more
important things (for me) that I want to work on. I want more
configuration that macOS or Windows, but not as much as needed for
bare Arch Linux or NixOS.
Being an admin I can’t agree: you save time as long as nothing brake
a thing that happen, and happen not so rarely, more important it can
happen at any update, while on classic release model you know that
something might and probably brake but at a specific time, and you do
the upgrade when you have spare time for that.
In an idea world thing might be different but in the real world a
system that can be kept up to date indefinitely without breakage
is not there. No OS is the world, proprietary or FOSS, altogether.
The main advantage of NixOS for me is simple: when something breaks
I can recover quickly with an almost fully automated deploy. I can’t
forget a package, a parameter in some config in /etc, it’s all in few
text files in a single place, easy versioned. Essentially the very
same thing we do for years from personal scripts to modern
orchestration tools like SaltStack or Ansible.
When you deploy a system by hand you can’t remember always and it’s
really unlikely that default distro perfectly match your needs and
desire. If you update once an year, I mean a fresh-install per year,
at least you “install skill” remain current, you know your desktop
enough, doing it less frequently means have you desktop in a semi
unknown (forgotten) state. And when a disk breaks you have to start
over again, loosing far more time than the little NixOS keep up and
loosing it on-the-spot, not when you are ready and free.
Windows is a big pain in that sense because it normally breaks at any
point in time and it’s automation, while PowerShell now can be viewed
like a kind of NixOS-config, it’s extremely hard, with absurd design
choices and long works needed for any stupid thing. I do not know
the state of OSX automation but since I do not see it in an enterprise
context I suspect is even worse.
Counting on a system that “can last longer” and push it until it crash
is a recipe for disaster, not time saved.
It fit my needs well, because I just wanted to wipe a computer clean,
and boot into a linux distro as a daily driver without fuss. Maybe
that isn’t your case. I personally am not going to dual boot anything,
I’m not going to make partitions, I just need one, etc. I just want to
get to work on my other projects.
I do not have dual boot of any kind, but I need partition for backup and
sharing purpose: for that I use zfs, because it offer a damn good
“rampant layer violation” that makes anyone life easy, with a common
storage pool, with effective snapshots, compression, checksumming,
live-resilvering etc. With it I can keep my data, not only my system in
a good shape. I can backup and share portion of my home easily, I can
view in different ways etc. Classic POSIX filesystems are a thing of the
past, too limited for today’s need. And in the past we also have going a
bit further, for instance with Plan 9’s file system in userspace
concept, that’s now the ubiquitous FUSE.
Partitioning is not much a system thing, it’s a “data” thing. Relaying
on “the cloud” (someone else computer) to backup and data availability
is like putting money in someone else pocket to avoid being robbed. It
might work for a certain period of time, when the service works well,
after one’s pay it so much that there is no recovery. Also relaying on
very few disks counting they do not breaks it’s another recipe to a
disaster.
Most GUI installer default partitioning relaying on a single home
volume, generally in ext4 these days or even worse in btrfs. Both have
a long trail of failure, especially btrfs. Big volumes with frequent
write like a browser profile dir easily breaks and having all your data
means a full restore is needed. Also proper backup is hard. For ext* fs
one’s need lvm to have snapshots and they are painfully slow, for btrfs
we have snapshots but they are really uncomfortable to use, if you use
stratis you relay on an experimental spaghetti-code crap built to
satisfy programmer’s desire while trying to have something that scale.
It does not work properly as many things simply because devs, especially
these days, tend to ignore the rest of the world scale, only focusing on
their personal desktop and not the unknown developer who read “how to be
a genius in 24h, a God in a week” but top-profiles devs like Linus
Torvalds who in the past say to be a terrible admin barely capable of
maintain his desktop and recently criticize zfs “because it does not
perform so well in some benchmarks”, or Andrew Morton years ago when he
say that’s a rampant layer violation. Sorry to all devs here, but
systems need to scale and sometimes interaction with admins is needed
and operation is needed, DevOps, CI/CD pipelines etc are not an answer
but only Babel’s tower trying to push a failed idea/dream.
Declarative config is not a bad idea. However with NixOS there’s in
fact multiple ways to achieve the same thing for NixOS configuration,
and that can be confusing and some ways lead to worse results than
other ways.
That’s a good point, IMVHO the ability to install package via CLI should
not be there, it might be useful sometime when one’s do not want to do a
full rebuild just to add a package but perhaps a temporary nix-shell for
that is a better way.
I think that still requires potential ELF patching or FHS mocking.
It’s not ideal.
That’s due to the limit of present time storage, a relic from the past
no one seems to be able to update properly, the last one who try was
SUN with zfs, SGI (far) before with XFS. BCacheFS is still more an idea
than something usable, Hammer is only a DragonflyBSD thing, nifls2 is
essentially a dead project and they are only a small step ahead in
storage tech. Storage-package management-installers are intimately
coupled and trying to separate them have a price. Nix{,OS} use the
/nix/store concept to circumvent storage limitations and ELF patching
and symlinking exercises are the price to pay. At OpenSolaris time IPS
start timidly to describe a package manager integrated with zfs but it
was in a very early stage, only BE (boot environment) concept mostly,
so instead of create a network os symlink you simply have a zfs clone of
the root volume with the relevant changes, storage is deduplicated, no
need of a store and symlinks but also no declarative config at that
point, it can be added and some devs plan to add them with the new
OpenSolaris installer that never really happen (they give birth to
Caiman instead, SUN was already finished and so OSol project, IllumOS
devs do not have the manpower to go further). But that is the sole
clean and proper way: having “classic POSIX file access” decoupled from
real storage, only as a view, different views, of the actual datas.
Unfortunately I think Nix devs can’t really go in that direction it’s to
much work for the size of Nix{,OS} project, a far bigger community and
far bigger resources are needed to make it is a time short enough to
avoid being pushed into oblivion like GNU Hurd and other projects.
Also certain “hw” and “Gnome” issues I also see myself and do not see
by defaults on Ubuntu and others are IMO due to the same reason: the
size of the community. Not “big enough” to have enough “users
bugreports” to tweaks all those small annoyances… It’s legit to be
annoyed but it’s not a Nix* fault, merely community size, manpower can
be compensated a bit with technology, but only a bit…
BTW sorry for the long post and poor English.
– Ingmar
This is something I want to have in NixOS that we could incubate. It’s actually much easier to achieve this in NixOS because of our module system. From just looking at my configuration on my machine, I have a lot of tweaks that I guess distros like manjaro have as defaults.
There is some miscommunication here, I didn’t talk about NixOS, but about Nix package manager. I think Nix packages are often as hermetic in dependencies as Docker containers are. Definitely no need for ELF patching for Nix packages on any Linux distro.