
NixOS – Purely Functional Linux Distribution - tosh
https://nixos.org/
======
mbrock
Another fascinating thing about NixOS is their system of automated integration
tests for the whole distribution. You can quite easily set up declarative
virtual machines with Nix expressions, and the test suites use this in very
cool ways.

Graham Christensen mentions some of these tests here:
[https://grahamc.com/blog/an-epyc-nixos-build-
farm](https://grahamc.com/blog/an-epyc-nixos-build-farm)

> The NixOS release process is novel in that package updates happen
> automatically as an entire cohesive set. We of course test that specific
> software compiles properly, but we are also able to perform fully automatic
> integration tests. We test that the operating system can boot, desktop
> environments work, and even server tests like validating that our MySQL
> server replication is still working. These tests happen automatically on
> every release and is a unique benefit to the Nix build system being applied
> to an operating system.

> These tests use QEMU and KVM, and spawn one or more virtual machines running
> NixOS.

He goes on to describe

(1) the KDE desktop test that boots a real graphical environment and uses
scripted OCR to detect activity;

(2) the MySQL replication test that verifies correct replication between three
separate MySQL servers on three separate virtual machines; and

(3) a BitTorrent test that starts _four_ virtual machines—namely one tracker
with Apache serving a torrent file, one NAT router with UPnP (!), two peers of
which one is routed through the NAT—and verifies the full process of peer 1
downloading from the seeder and peer 2 downloading from peer 1.

Those tests can all run automatically on a build server for every commit to
the package tree... it's quite something!

The whole BitTorrent test is a 116-line Nix expression that's eminently
pleasant to read:
[https://github.com/NixOS/nixpkgs/blob/49a6964a4250d98644da61...](https://github.com/NixOS/nixpkgs/blob/49a6964a4250d98644da61f24dcc11ee0b28c4f9/nixos/tests/bittorrent.nix)

------
zorked
As you can run Nix on top of any Linux system you can use it wherever you want
it.

Some time ago I was having a dependency-hell problem with a C++ program that
used particular library versions which were available in Fedora (dev machine)
but not Ubuntu (target) - plus there were no static versions of the library to
compile the program as a static binary.

So I used nix to build the package for me. It also did not have the right
version of one library, but I was able to "fork" the library for my build
alone in the same configuration file. Then I was able to nix-copy-closure my
program to a remote host, and it copied all dependencies over (and nothing
more) and I was able to run it under Ubuntu.

Nix is great. I think it is the more proper solution to the problem people
have been trying to fix with Docker.

~~~
corysama
It also runs on Windows Subsystem for Linux.

[https://old.reddit.com/r/NixOS/comments/64xyd7/nix_package_m...](https://old.reddit.com/r/NixOS/comments/64xyd7/nix_package_manager_works_flawlessly_in_windows/)

~~~
ghuntley
NixOS is coming to WSL. Follow twitter.com/geoffreyhuntley for updates.

------
gmfawcett
I've been having great success (and fun!) recently, using Nix to manage the
build for an application that I wrote in D a while back. The app builds
reliably on a particular DMD version (one that's not already bundled in
NixPkgs), and with third-party dependencies pinned at certain revisions. I'd
like to make it easy to re-build the whole app, from any machine, with exactly
that configuration and with a minimum of fuss. Nix seemed like a great way of
coordinating all of that.

After the initial learning curve of the Nix expression language, and how the
parts of Nix interact, I was able to write ~25 lines of Nix script that will
run the whole thing from scratch: find and deploy the right DMD version,
download the right dependencies, and build and install the application.

After a build, I can "copy the closure" of the application to as many other
machines as I want, with no rebuilding needed. This guarantees that all
dependencies (down to libc) are identical on all machines -- even if the
machines already have other versions of those libraries installed. I'm very
pleased with the results.

So: there's a learning curve to Nix; but beyond that, things get better, and
personally I'm finding the return on time-invested to be very good. If you're
interested in building your own software with Nix, I strongly recommend
reading the "Nix Pills" articles a few times and doing experiments as you go
-- many things didn't click for me at first, but the articles helped things
fall into place.

[https://nixos.org/nixos/nix-pills/index.html](https://nixos.org/nixos/nix-
pills/index.html)

~~~
weberc2
I've had a lot of problems using Nix in the past. Not least of which is that
it's terribly hard to search for anything because of the name--not only is the
name generic ("nix package manager" -> "Congress nixes aid package...", "nix"
-> "*nix", etc), but search engines have a terribly hard time figuring out
what nix project I'm inquiring about ("nix package manager", "nix expression
language", "NixOS", specific Nix derivations, etc).

Another problem is that the documentation for individual functions is
nonexistant. If you want to know how a particular function works, you have to
go to the nixpkgs repo in github and try to guess about where the function's
definition would live in the massive directory structure, and once you find
the definition you care about, you have to read the source code (in Nix
expression language--if you're not well acquainted, good luck: the docs are
pretty terse and hard to Google for as previously mentioned) which likely
references other functions, and since imports don't seem to correspond with
the directory structure, you're back to guessing where the symbol you're
looking for actually lives. The problem is exacerbated by the dynamically-
typed nature of the expression language; other dynamically typed languages at
least tell you what type of arguments they expect, but since these definitions
aren't annotated at all, you're left guessing. Documentation would do wonders
for the project, especially if it's autogenerated like other languages and put
in an HTML format so we aren't left hunting around the nixpkgs repo.

What Nix strives to be seems promising, but it's really hard to even evaluate
the core ideas for all of the usability issues.

~~~
manveru
There's a lot of effort going into making documentation better. Recently we
also got function documentation: [https://nixos.org/nixpkgs/manual/#chap-
functions](https://nixos.org/nixpkgs/manual/#chap-functions)

~~~
weberc2
That's great to hear! Hopefully all of my criticism will be invalid very soon
(if not already)!

------
fendrak
I'm a former Arch user who's been using NixOS as my daily-driver at home for
about a year now, and I've really enjoyed it, even above Arch (which I'm also
a big fan of).

The biggest gain over Arch for me is the safety net it gives you in making
configuration changes. Once I've got the machine working, that state can be
booted to for as long as I care to keep its pointer around. This means things
like kernel upgrades are no longer the anxiety-inducing problem they used to
be on Arch for me; if an upgrade fails, I can quickly reboot to the previous
state without having to do anything special.

As a result of this, I no longer need to put off kernel upgrades when I'm
trying to get something time-sensitive done! To be fair, I was running the
ZFS-enabled Arch kernel, which was the cause of most of my problems. However,
using the ZFS kernel on NixOS has been anything _but_ problematic; it just
works, and keeps working!

Nix/NixOS also makes setting up a new machine just the way I like it a joy. If
I move to another machine, need to build a new one, or need to re-image the
current one for any reason, my configuration (stored in source control)
follows me around without me having to remember all the one-off tweaks I did
to make, say, hibernation work correctly.

I haven't yet mastered building packages since I don't find myself needing to
compile things from source all that often, but I can certainly feel the pain
of learning how to do so; it still feels like quite a mountain to climb before
I'd really know what I was doing.

~~~
webster23
Learning to build your own packages is a bit of a chore, but once you get
there, it could not be easier. I suspect building your own packages for Debian
or Redhat would be much more difficult. Let alone getting that package
accepted upstream, which is not that hard with Nixos.

------
blogle
I have been using Nix for about 2 years now at our company and its pretty
amazing. In my experience it doesn't make compiling things much easier than
normal, but the difference is that once something builds, it just works. ALL
THE TIME. In previous companies I spent a ton of time debugging other devs
environments that worked fine on my machine, but cause linker errors, breakage
due to transitive deps, slightly different compilation artifacts, etc.
Furthermore most tools are language specific leaving you to fend for yourself
to get the system dependencies or rely on a separate binary distribution
package manager. Nix handles everything we throw at it, we have even
configured our dev env to roll to the new nightly Rust every week without any
effort from the developer. We also get the performance benefits of compiling
everything with march=native. Additionally our dependencies and dev
environments are cached, so most of our engineers never have to wait for
things to compile. The issue we have ran into is due to the fact we are
running a traditional distro instead of NixOS, which causes headaches when
your code depends on a kernel module (Nvidia drivers for example) or you want
to register systemd units. This has led us to have some hacks in our setup to
make it work. Ultimately we are thinking of just making the transition to
NixOS. Its unbelievable to me that I can deploy an entire mesos cluster with
just two lines of code.

FWIW if you enjoy Nix and are interested in using it in production feel free
to reach out to me. brandon [at] standard [dot] ai

------
xte
Relatively new NixOS user here: I consider Nix{,OS} and Guix{,SD} the future
approach to build a GNU/Linux distro and in general the way to manage a modern
OS. Simple as that.

My main pain point with NixOS is it's obscure DSL, instead of the excellent
Scheme, my pain point with GuixSD testing is absence of LVM support and less
flexibility to create custom installer config than NixOS (for instance I'm a
nilfs2 user for all fs and while it's extremely easy to have a root on nilfs2
with NixOS it's tricky on GuixSD).

For the rest it awesome:

\- fully reproducible deploy (included NixOps and homeManager)

\- safe update, being symlink-based we get poor man's Opensolaris BEs for both
config changes, update and even major release upgrade

\- can manage nearly all inside home via homeManager

\- can deploy a series of hosts via NixOps, like a built-in Saltstack on
steroid.

------
iElectric2
Some self promotion for NixOS infrastructure:

* binary caches as a service: [https://cachix.org](https://cachix.org)

* Nix continuous integration as a service: [https://hercules-ci.com](https://hercules-ci.com)

~~~
colemickens
Do you have a super quick example that you can include in plugs like this? I
am doing my own caching directly with Azure storage (though it works anywhere
you can enumerate and upload blobs) [1], but I think Cachix and Hercules are a
huge potential chance to excite more folks about Nix and NixOS.

I'm thinking something like a blog post where someone patches the Linux
kernel, does a `nix-build | cachix push` and then show how another naive user
might do `cachix use && nix-build` and get a magic no-op build. Maybe just a
slightly more fleshed out example under the "What" section of the Cachix
homepage.

For the non-Nix/NixOS folks, it's an impressive demo, and I suspect even for
Nix-folks, it's impressive for hiding all of the signing/upload complexity.

For others reading this comment, Nix + Cachix means that no two people on your
team should _ever_ need to spend CPU cycles building two copies of the same
binary, or the same docker image, or the same VM image, etc, assuming all of
the inputs are the same. It's so cool, I'm so happy to keep seeing people
finding out about Nix and NixOS. I feel like what Kubernetes did to
application development, Nix does to operating system, toolchain, _and_
application development, _and_ configuration management.

[1]:
[https://github.com/colemickens/nixcfg/blob/master/utils/azur...](https://github.com/colemickens/nixcfg/blob/master/utils/azure/nix-
copy-azure.sh)

EDIT: follow-up: It look like less than 2 minutes to start pushing to my new
Cachix repo. Excellent job with this, it's going to be hard to motivate myself
to keep maintaining my scripts with this being so easy.

~~~
iElectric2
Thanks! That's very good feedback. We are currently working hard to get all
features done and streamlining use. Next phase is marketing to non-Nix devs,
probably 2019 :)

------
kreetx
NixOS is difficult to start out with, and great after that :p.

Started using it recently for work and it has been reliable thus far. The only
issue that I've had was when upgrade to Mojave where a patch was needed. But
to do this you clone the nixpkgs repo (of package descriptions), cherry pick
the fix, point the package manager to the repo, and it continues to work.

One can create docker images from the machine definitions, so the target need
not be nixos, but anything that runs docker.

But if you're not the type of person to pull through difficulties then this
distro is not for you (yet).

~~~
gmfawcett
Another approach is not to patch nixpkgs at all, but just to "override"
packages in Nixpkgs outside of the repository, and build them from your own
project directories.

A simple example: I wanted to build FFMPEG, but with non-free libraries
enabled (which is not the default). Rather than edit "ffmpeg-full" in the
nixpkgs repo, I just overrode it:

    
    
        # default.nix (in some project directory; call "nix build -f ." to run it)
        with nixpkgs;
        {
          my-ffmpeg =
            let overrides = {
            nonfreeLicensing = true;
            fdkaacExtlib = true;
            ffplayProgram = false;
            qtFaststartProgram = false;
          };
          attrs = {
            name="my-ffmpeg-" + ffmpeg.version;
          };
        in
          ffmpeg-full.override overrides // attrs;
        }

~~~
eridius
I haven't ever tried this myself, but I was under the impression that the
`--arg` and `--argstr` arguments to nix-env were supposed to let you change
build options. So could you not say `nix-env -iA nixpkgs.ffmpeg-full --arg
nonfreeLicensing true --arg fdkaacExtlib true --arg ffplayProgram false --arg
qtFaststartProgram false`?

~~~
gmfawcett
You may well be right. In my first attempts, I did try various combinations of
`--arg` and `--argstr`, but I never succeeded in getting a proper build.
That's why I ended up using the override approach instead. I understand a
little bit more (very little!) about Nix now, so perhaps I should give it
another try.

------
phant0mas
Also don't forget about Guix ;)
[https://www.gnu.org/software/guix/](https://www.gnu.org/software/guix/)

~~~
_verandaguy
Is Guix related beyond also being an OS?

~~~
bjoli
Well, it shares the same concepts, although instead of nix it uses guix which
many of us like better than nix.

~~~
gmfawcett
One caution though -- being a GNU project, Guix takes a much stronger stance
on non-free software than Nix does. In Nix, there's a flag you can enable that
will let you build non-free software in the Nixpkgs repository. I don't
believe the same flag exists in Guix.

Note that either system could be used to build your _own_ non-free software,
this is more a question of what is available in the shared repositories.

------
JdeBP
A few past discussions that won't come up in the "past" hyperlink under the
headline here:

* [https://news.ycombinator.com/item?id=5727459](https://news.ycombinator.com/item?id=5727459)

* [https://news.ycombinator.com/item?id=18155777](https://news.ycombinator.com/item?id=18155777)

* [https://news.ycombinator.com/item?id=16773824](https://news.ycombinator.com/item?id=16773824)

* [https://news.ycombinator.com/item?id=15269360](https://news.ycombinator.com/item?id=15269360)

------
mbrock
Here's a funny module I wrote that lets you very easily configure your NixOS
server to serve simple CGI scripts over HTTP, useful for simple web hooks and
such.

[https://github.com/lessrest/restless-
cgi](https://github.com/lessrest/restless-cgi)

It's an example of something Nix is great for: making reusable system modules
that involve systemd units, program dependencies, auto-generated configuration
files, and so on, all in a very reproducible and hygienic way.

------
nickserv
After running some tests I was ready to deploy to a new production server, but
unfortunately my hosting provider (OVH) doesn't offer a ready made image.

After trying to use Debian as a starting point, and several failed boots, I
threw in the towel... Seems like OVH does funky things with their EFI which
doesn't work without some black magic.

For now I'll continue using it on my laptop but it's not living up to its full
potential, most of the configuration is for desktop stuff and NixOS doesn't
really cover that.

When I get the chance I'd really like to try it on my servers, hopefully
sooner rather than later. I can see it working really well with Saltstack for
infrastructure management.

~~~
pfranz
What about just using it as a package manager inside Debian until you can get
a hosting provider to support NixOS?

~~~
ris
This is the way I actually started using Nix in deployment. You can run a full
Nix installation from within a home directory without any special permissions.
Frustrated with the inflexibility of a shared hosting provider running CentOS,
we decided to usurp most all of the provided OS & libraries and ran everything
thru Nix, giving us fully reproducible control over our dependencies.

------
GoMonad
I've thought about making the jump to NixOS a few times. Questions: Do people
use it for their desktops? How do security updates work?

~~~
eeZah7Ux
> How do security updates work

They don't. NixOS does not have a concept of a released, stable distribution
and therefore does not provide security patches backported to it.

You have to keep rolling forward with every new upstream release of the
packages you use.

Perhaps it's OK for some people's desktops but most server environments rely
or stable distributions with LTS support.

~~~
tadfisher
This is patently false. There is a stable release every six months, and a team
dedicated to patching the stable release. I'm surprised you missed this, as
it's right there in the first sentence of the download page:
[https://nixos.org/nixos/download.html](https://nixos.org/nixos/download.html)

You have the _option_ of following the master nixpkgs branch, or one of
several "channels" which are essentially tested checkouts of the main nixpkgs
repo. There are both stable release channels (i.e. nixos-18.09) and unstable
channels (i.e. nixos-unstable).

~~~
e12e
Looking at the security page, which generally points to the announce list -
and a sample (serious configuration) issue:

[https://groups.google.com/forum/m/#!topic/nix-security-
annou...](https://groups.google.com/forum/m/#!topic/nix-security-
announce/qrDU0KH_ZRk)

It's not immediately clear to me that there's an "lts" or "stable" that would
allow easy security only updates, preferably in an automatic fashion? Or is
this one issue a special case where a) the admin must see the announcement,
and b) manually act to secure systems?

~~~
tadfisher
Updates are committed to the stable nixpkgs branch. These then propagate
through the channel. NixOS has a configuration option to enable automatic
upgrades[1], which periodically pulls the latest nixpkgs checkout from the
channel you're following, rebuilds the system, and switches to that
configuration.

[1]: [https://nixos.org/nixos/manual/#sec-upgrading-
automatic](https://nixos.org/nixos/manual/#sec-upgrading-automatic)

------
ilovecaching
My friend at work will never stop talking about Nix and NixOS. The entire
world would be a better place if we all just stopped using Docker and Chef and
switched to Nix. Every package you could want is in Nix, and it's all on
Github. Anything your tool can do, Nix can do it better, except it's congruent
instead of convergent.

My rebuttal has always been that NixOS has been out for awhile and we still
haven't seen mainstream adoption despite how supposedly great it is. I don't
know of any high profile companies using Nix. It appears to be as hobbyist as
Haskell.

~~~
zzzcpan
I think it's well known, that Nix has a lot of implementation related problems
that prevent its mass adoption. They are fixable, but only by different people
and in a different package manager. By those, who care about UX and can
understand that learning some weird functional programming language and its
ecosystem to do basic package management is not ok, but who can still
appreciate Nix's ideas.

~~~
ilovecaching
That sounds right to me. I could see how fundamentally it would be great, but
I think it's as you said.

------
ridiculous_fish
NixOS doesn't have directories like /usr/bin, /etc, etc. This defeats the
traditional `make && make install` path; instead you have to build a nix
package, and be familiar with stdenv.

My concern is that it would be more difficult to install software that doesn't
have a nix package built (in particular, from git repo trunks), and also more
difficult to have confidence that the software I write would work on other
Linux distros. For this reason I chose Arch over NixOS.

In practice NixOS users find these to be significant issues? How do you deal
with them?

~~~
aidenn0
It takes about 5 minutes to make a nix expression for a "./configure && make
&& make install", with most of that time being figuring out the dependencies
and calculating the checksum of the tarball.

Example:

[https://nixos.org/nix/manual/#ex-hello-nix](https://nixos.org/nix/manual/#ex-
hello-nix)

For any standard build tools (cmake, scons, whatever) it's just one extra
line. Applying patches is one extra line. For a non-standard workflow, you can
supply a shell script for each step (unpack, configure, build, install, &c.).
so it's just however many lines that is.

I've had _zero_ issue getting any source-based third party stuff running.
Binaries are a pain, but that's always true if you aren't running the exact
distro that the binary was built for.

~~~
Ralith
> Binaries are a pain, but that's always true if you aren't running the exact
> distro that the binary was built for.

This is actually easier to deal with on NixOS than elsewhere, because the
tools for handling that case (patchelf, buildFHSUserEnv, supporting multiple
versions of a lib, etc) are so well developed.

~~~
danieldk
Indeed, just two days ago I made a derivation for a large binary, which is
built against an older Boost (1.58). On most other package managers, this
would be painful, but with Nix I just made a derivation for that version of
Boost by overriding Boost 1.59, which is in nixpkgs:

[https://github.com/danieldk/nix-
home/blob/f6da4d02686224b300...](https://github.com/danieldk/nix-
home/blob/f6da4d02686224b3008489a743fbd558db689aef/overlays/20-alpino.nix#L4)

------
qwerty456127
I wish this would become more popular in production, it's just so much better
than RHEL and everything. IMHO Nix i the best for servers and enterprise
desktop and Manjaro is the best for individual desktop/laptop.

~~~
matthewbauer
I think it would be really cool if someone made a NixOS-based distro focused
on individual users like Manjaro does. NixOS is pretty modular so it wouldn't
be all that hard.

------
CMCDragonkai
We use Nix to manage our entire machine learning pipeline. ML pipelines have
crazy number of dependencies and compatibility ranges from Python to
Tensorflow to CUDA to Nvidia driver version to hardware card... etc.

------
colemickens
I'm so disappointingly late to this thread, but NixCon just happened and they
were publishing the videos in real-time on YouTube (major props for doing it
that way):
[https://www.youtube.com/channel/UCjqkNrQ8F3OhKSCfCgagWLg](https://www.youtube.com/channel/UCjqkNrQ8F3OhKSCfCgagWLg).
Might be a bit out of context if unfamiliar with Nix, but it was exciting for
me to watch. It feels like momentum is picking up and folks are interested in
improving UX and evangelism!

------
lrvick
As much as I like the -design- of Nix as a system overall, I would strongly
discourage trusting it today for any production or security sensitive use case
until some concept of VCS signing, and review/release integrity is in place.

See:
[https://github.com/NixOS/rfcs/blob/d178f63f9a588e463fdc07551...](https://github.com/NixOS/rfcs/blob/d178f63f9a588e463fdc075516fae4b48d9fd5f3/rfcs/0034-expression-
integrity.md)

------
vectorEQ
nice concept. can't find information on if this is based on another distro, or
if it's an all new one, but the underlying idea is solid as for me it tries to
solve one of the fundamental issues with linux which makes people move to
things like containers or complicated deployment tools and scripts. this seems
a lot more straightforward.

~~~
aidenn0
I use it as my daily driver on my laptop and it's _great_. It's very simple to
add new source-based programs.

It doesn't handle binary-only applications though (e.g. NoMachine, games,
&c.). It has a couple of options to make those work, and it's almost always
possible to get it to work natively, so if there's not already a nix
expression for the app I want, I just take the expedient path of having a
docker container with an ubuntu user-space, since pretty much all proprietary
apps run on ubuntu.

~~~
Filligree
If you don't want to bother with the container, `steam-run` will almost always
work. That gives the same Ubuntu chroot (aka. buildFHSUserEnv) as is used by
Steam.

~~~
aidenn0
I found buildFHSUserEnv to be somewhat more fragile than actually using
ubuntu. Again, I could probably get it to work, but the container is trivial.

------
bdz
Do they have a torrent download? Can't see it also this [0] looks like a
different version

0, [https://linuxtracker.org/index.php?page=torrent-
details&id=9...](https://linuxtracker.org/index.php?page=torrent-
details&id=9cdb2b67e3d26aaac61b8bbe7411545a5817e86e)

~~~
colemickens
If you look at the ISO url, you'll notice something that looks like a short
Git SHA hash. That's the exact git checkout of `nixpkgs` used to build the
ISO. All system-level artifacts built with nixpkgs wind up with it as part of
their name. Very handy.

This means you can plug the sha from the ISO that you link to (nixos-
graphical-18.09.776. _6a3f5bcb061_ -x86_64-linux) and get this URL:
[https://github.com/NixOS/nixpkgs/commits/6a3f5bcb061](https://github.com/NixOS/nixpkgs/commits/6a3f5bcb061)

And the ISO URL from NixOS.org ([...]/nixos-graphical-18.09.1023.
_06fb0253afa_ -x86_64-linux.iso) leads us to
[https://github.com/NixOS/nixpkgs/commits/06fb0253afa](https://github.com/NixOS/nixpkgs/commits/06fb0253afa)

If you check both, you'll see they're both commits from the upstream `nixpkgs`
repository, just a couple weeks apart. So it looks like your torrent is likely
an old official ISO that could be upgraded in place the same way the newer ISO
would need. (Note, I haven't confirmed that, someone could've uploaded a
malicious file with a nice filename, etc. Don't take my word for it, etc.)

(edit: ah, and if I had to guess, the 776 and 1023 as part of the filename is
probably the number of commits since the original 18.09 tag was created.)

------
kragen
Nix points the way to what Docker could have been. I don't think it's there
yet, but it's getting better. Guix is, to me, even more interesting (and even
less "there yet"), in that it doesn't use a NIH language, and it's focused on
software freedom.

------
ghuntley
See [https://github.com/ghuntley/dotfiles-
nixos](https://github.com/ghuntley/dotfiles-nixos) which is a source drop
reference for others on how to setup nixos and share configs between multiple
machines

------
equalunique
Recommended. My NixOS workstations have all been very stable, after the
correct configuration.nix has been achieved. Being able to use nix-shell for
development environments is invaluable. Being able to serve my own binary
cache is an efficiency gain for my network.

------
craftyguy
[https://news.ycombinator.com/from?site=nixos.org](https://news.ycombinator.com/from?site=nixos.org)

------
zydeco
I first misread that as "The Purely Fictional Linux Distribution".

~~~
eeZah7Ux
You are not wrong...

------
ackfoo
Just tried NixOS in the VM... the application launcher does not update after
installing new packages... even after a log off or reboot. Running
kbuildsycoca5 fixes it.

See, this is the kind of absolute shit that makes Linux hot garbage. This is a
central and catastrophic bug for a new user. I can't give NixOS to anyone with
this kind of a bug. They'll be calling me at all hours and I'll want to shoot
myself.

Jesus Harold Christ. It has to fucking work. Get the basics down before you
put out crap like this.

I want the old nasty Linus back and I want him to take over a whole distro and
tell the people who make shit like this that they are goofs and they should
feel bad.

Software without a benevolent dictator is trash. Think of the user experience.
Can you imagine the kind of misery that this sort of bug creates for the user
and the sysadmin alike?

NixOS is a great idea. First new distro I've tried in years. But Linux devs
are still stupid crazy little shits who can't get a fucking package to show up
in the menu after an install.

What the actual fuck?

Back to the hated MacOS. The ghost of Nasty Steve still lurks in its
passageways, so it hasn't gone to complete shit yet... even though they're
trying.

