
My NixOS Desktop Flow - pcr910303
https://christine.website/blog/nixos-desktop-flow-2020-04-25
======
_ytji
>> Nix and NixOS ruined me. It’s hard to go back.

I don't know. Not much about all this setup feels appealing. The apparent
learning curve for nix looks...steep. I've been using linux for a pretty long
time (I think kernel 2.1 was fresh when I started). I've done the slackwares
and debians and redhats and arches and gentoos etc. And I have zero desire to
put such effort into having a working system.

I realize the post is prefaced with a warning that it's over-engineered. I
guess my question is- can I use nix without going so hard down the rabbit
hole? I don't think I have the time to invest like my gentoo (read: teenage)
years.

I'm pretty satisfied with doing a minimal install of fedora, setting up i3 and
firefox and calling it a day. Maybe I'm just older and more crotchety than I
thought.

~~~
tinco
So with NixOS your process would look like this. Open up your editor on one of
your devices thats already running. Write up a nix config that sets up i3 and
firefox, could be just a couple of lines. Save it on a usb drive along with
nix itself. Boot your new pc off the USB drive and your set.

And thats just the first time you use nix. Next time you just reuse that
thumbdrive, or redownload it, and get your config from a git repo you are
tracking your config in.

I have a git repo that has configuration for three types of devices I run in
my personal setup (desktop, nas, webserver). They all inherit from my base
configuration which has stuff like the user configuration and maybe my vim how
I like it. The server adds docker and runs the docker containers that it
should. The nas mounts the raid array etc.

If I want to know how I configured my nas three years ago, all I have to do is
read the nix file I checked onto github. Thats powerful.

~~~
qqssccfftt
Why would you want to know how you configured your NAS three years ago?

~~~
tinco
Ran out of disk space, want to run another service, want to check if there's
any software updates.. I don't know, in my case I had it in a moving box for
1.5 years and I was pleasantly surprised it even booted and immediately
started serving up stuff to my TV.

------
ylyn
I think Nix/NixOS is a great idea.

But unfortunately *nix programs are not written to support this, so you see
lots of hacks in Nix to get things to work.

Since GCC isn't really meant to work with headers spread across a varying set
of directories, you end up with this wrapper for every GCC invocation:
[https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-
supp...](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-
wrapper/cc-wrapper.sh)

And this just doesn't sit well with me:
[https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-
level/...](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-
packages.nix)

~~~
jchw
I agree there’s a lot of hacks and maybe the current model of Nix as it is
today won’t survive.

However, I think several aspects of the Nix concept are highly novel and worth
pursuing, and there’s no way to get there without large intermediary steps.

NixOS and GuixSD represent, to me, some of the most exciting OS research not
aimed squarely at security. It’s difficult to fully appreciate until you’ve
really exploited it well.

The hacks that are needed today, indeed, are a bit of a turn off, but I do
still find a remarkable amount of stuff ends up working well in the model. As
a personal example, NixOS not managing dotfiles feels like it would be a huge
deal, but actually it isn’t as big of a deal because you can just manage
system level configs; for example, my SwayWM config is stored at
/etc/sway/config and so forth, and I can neatly provide Nix store paths in my
config files through substitution, allowing me to keep my global namespace
cleaner. (Various approaches for per user config can then be applied as
needed, such as referencing global configs from dotfiles, or wrapper scripts
that have logic.)

My opinion is that it’s unlikely NixOS or Nix are the stable, hermetic utopia
we’re looking for, but they or a successor may very well become it, and the
exploration done today is an important part of the necessary research. I’m
already excited by things you can do today that are not well documented, like
cross compiling to other platforms almost seamlessly (for example, MinGW has
worked quite well in my experience.)

~~~
mlinksva
There also is a NixOS derivative OS project "aimed squarely at security"
[https://spectrum-os.org/](https://spectrum-os.org/)

------
offmycloud
I gave NixOS a try recently, and generally liked it. I could get over the
arcane packaging language and hit-or-miss documentation. The red flag for me
was the inattention to software freedom. Most other distros like Debian or
Fedora have source packages or SRPMs that include everything needed to rebuild
a package from scratch. Nix pushes binary packages, and even stores them in
S3, but with no matching source packages that I could find. They tout
reproducible builds, but really haven't considered to how to deal with the
"disapearing sources" problem, including vanishing git repositories. I grabbed
some URLs that pointed to sources in the old Nix Tarball Cache and they all
returned 404. Nix has no longer term plan to preserve package sources.

~~~
dTal
I've noticed this seems to be a problem with F-Droid as well. Seemingly half
the packages are marked "the source is no longer available", which renders
them non-free in practical terms. It's great that they tell you, but why is it
a problem at all?

~~~
est31
F-Droid packager here (gotten inactive though so maybe my knowledge is
outdated, beware). F-Droid actually does store source code of the package. A
tarball for each published version. Not like what debian's git mirrors have,
but already some progress. "The source is no longer available" means that the
upstream sources have vanished and no updates can be obtained. The tarballs
are still available.

The build that F-Droid executes comes in two phases: one to obtain source
code, which then gets packaged, the second phase to execute the build. Note
however that the build execution phase does have network access and many
builds actually do use the network to download dependencies, so its certainly
not as advanced as Debian. I'd put what F-Droid is doing to somewhere between
Nix OS (which doesn't have source packages at all) and Debian (whose source
packages are complete so that no internet is needed).

For F-Droid, one could maybe think about running build twice: first with
internet enabled but a recording proxy in between, and second with internet
disabled but that proxy replaying the recorded file. That file is then
published with the sources. There are formats for this, e.g. warc. It would be
a partial improvement although it might still download binaries etc instead of
source code and patching the source code would be also hard (tools would have
to be developed to do this), hurting the FLOSS spirit.

~~~
dTal
Thank you for the detailed explanation of the F-Droid build process. You say
it's possible for an application's build scripts to download binaries that
don't correspond to any published source for the app, and patch them in - that
seems very non-free and indeed dangerous. Is there a way of finding out if an
app does this?

I also think that believing you have the source code to an app but being
unable to build it because of missing, possibly proprietary dependencies is
far more damaging to the FLOSS spirit than any amount of format difficulty.

~~~
est31
The way you can tell is to run the build and inspect the build log. Usually it
prints out if it downloads something.

I think it's pretty common that stuff is being downloaded during the build
phase, mostly from java package hosts like mvn, jitpack, etc. There are checks
in f-droid to ensure those hosts are on a whitelist of FLOSS-policy repos but
the checks don't prevent any custom build logic of downloading stuff via http,
cloning git repos, etc. Also while maven central does not, some of these hosts
also allow takedowns of published artifacts, at least jitpack allows it and
it's on the whitelist (also jitpack's policy isn't FLOSS only, only requiring
that the package is on public github, which still allows for nonfree "source
available" software AND jitpack doesn't have any policy about downloaded
binaries during _its_ build).

------
mjhoy
Nix is very cool, and I encourage anyone to at least install nix on their
machine and try it out. I started using it on my Mac, mostly to set up a
Haskell environment, which at the time meant quicker builds than using other
tools, due to the binary cache.

I now use it for python, scala, emacs and basically wherever else I can get
away with not using Homebrew. I share the config [1] between my work and
personal machine. This works really well: it's just a git pull, and a `nix-env
-iA nixpkgs.devEnv` and my environment is updated (and I can easily roll back
to the previous state if something goes wrong). It does take a lot of up-front
investment, learning a new language and paradigm, but once things are working
they tend to stay working.

[1]:
[https://github.com/mjhoy/dotfiles/blob/master/nix/nixpkgs/co...](https://github.com/mjhoy/dotfiles/blob/master/nix/nixpkgs/config.nix)

------
k__
I tried to use NixOS a few years ago, and it was reallly hard.

The Nix language didn't have good tutorials and I couldn't use any of my NPM
skills with the Nix package manager.

I saw talk from one guy who wanted to make the Nix package manager use
commands that were more like in other package managers.

Did any of this happen?

I really think NixOS and GuixSD are the next generation Linux distributions
and want to use it.

~~~
Shoue
> I saw talk from one guy who wanted to make the Nix package manager use
> commands that were more like in other package managers.

I'm guessing this is about `nix` and `nix-env` having poor interfaces and
lacking e.g `nix install` – those aren't _really_ meant to do package
management, because it's an imperative approach akin to Apt. I haven't touched
`nix-env` for actual package management in over a year now.

You should instead be writing your system-level package dependencies and
services in your configuration.nix, your user-level package dependencies and
services in home-manager's home.nix, and if you just need to use a package
quickly, you should use `nix run nixpkgs.hello -c hello` or `nix-shell -p
hello`, and if you're trying to set up a dev env for a project you should be
using direnv or lorri. nix-env pollutes your environment and causes headaches
when/if you add the same packages you have installed there to your declarative
files.

>I couldn't use any of my NPM skills with the Nix package manager.

You can – look into direnv and lorri, they let you handle system-level
dependencies while NPM handles its own libraries, on a per-project basis. This
is IMO the best contemporary way to do a developer environment.

~~~
k__
Sure, but a small CLI tool that adds and removes packages in these files would
probably go a long way.

------
aeurielesn
I just tried out Nix (not NixOS) earlier this week in the context of creating
Docker images.

Getting started with Nix is easy but getting the hang of the Nix language
isn't so much (despite having a reference manual.)

My best advice to get you started with the Nix language is looking at what's
already available in <nixpkgs>[1].

Going fast-forward, my Docker image got a lot of unnecessary files in it
(include headers, configuration files, /etc/passwd, /etc/group, etc.) I have
to come back to it and see how I can improve this.

P.S. On the other hand, I succeeded creating a minimal Docker image using
magicpak[2].

[1]:
[https://github.com/NixOS/nixpkgs/tree/master/pkgs/developmen...](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/libraries)
[2]:
[https://github.com/coord-e/magicpak](https://github.com/coord-e/magicpak)

------
Datenstrom
I spent a lot of time setting up Nix and NixOS to replicate my current dotfile
environment on Debian I've spent years developing and which I can deploy on a
new machine with a one liner. I really like Nix and found their DSL fairly
easy to pick up, I didn't keep it for my desktop, workstation, or servers
though for a few reasons.

1) Package availability: this is by far the largest reason. I frequently need
to use software or specific versions that are just not available and while I
did create some packages myself it is just too much work when I need to get
something done.

2) Language Documentation.

3) I still need to use cargo and pip anyway.

4) Even when packages were available they often lacked the configuration
options I needed and I would have to fork and edit them anyway.

I do think Nix is a lot better than current systems though.

~~~
MarcScott
I use pip all the time in NixOS. I just run it in a nix-shell, and install
from a requirements.txt when the Python package is not in the nix packages.

~~~
takeda
I created a template which to the extent that I used it completly replaces the
need for virtualenv and integrates well with declarative setuptools:
[https://github.com/takeda/example_python_project](https://github.com/takeda/example_python_project)

With direnv + lorri when you enter the directory, it is as if you enter
virtualenv, your code behaves as if it is installed with pip -e, if you call
nix build it takes care of all dependencies and the command created in bin/
behave like binaries, have all dependencies needed.

I plan to update nixpkgs code that processes setup.cfg and make this less
trivial example when I find some time.

------
dimitar
I tried Nixos but I found out it is really easy to setup a system but then it
gets harder when you get off the beaten path by messing with npm or steam for
example.

I think a winning approach would be to manage the OS using nix, but let the
user do more imperative stuff in his home directory.

Here is an illustration of how one is supposed to use a package manager for a
programming language (in this example npm) in Nixos:
[https://unix.stackexchange.com/a/381797](https://unix.stackexchange.com/a/381797)

And here is an article about the hoops needed to run Steam games:
[https://nixos.wiki/wiki/Steam](https://nixos.wiki/wiki/Steam)

~~~
Shoue
Regarding NPM, you can do user-level "global" installs on NixOS, see
toraritte's answer in the same Stackexchange question. NPM should work fine
within a project, but if you need specific dynamic libraries that a Node
package implicitly depends on, you can specify them using Nix, and this means
you automate the process of installing system dependencies for anyone else who
touches the project too.

While you could use nix-shell, it is IMO a dated and very manual way,
preferably you'd use direnv or lorri to automatically load a default.nix or
shell.nix from your project root directory where libraries have been specified
in `buildInputs`.

------
indigodaddy
Christine, very attractive and minimal site. Well done.

I see on your “new site” blogpost you mention “This content is markdown
rendered by Purescript.”

..have you considered doing a write up with more detailed information as to
how your site is generated or a howto? I think many might be interested.

Thanks!

------
xena
Author of the article here. Ask me anything!

~~~
chakerb
Can you share the list of hardware you choose to build your tower?

~~~
dr3adward
Why? Do you for some reason assume that the author is an expert on hardware
and authority on picking the best, most compatible parts?

Do you not have your own specific requirements and use cases? It is better you
do some research on your own end and learn to pick the parts that will best
work for you.

Ryzen CPUs run hot, the stock cooler is garbage.

The tower is not silenced, and with the stock cooler you will have a lot of
fan noise both from the CPU fan and chassis fans.

Ryzen 3900 is a much better choice than the 3600, especially for CPU intensive
work like compilation.

The M2 disk is on the slow end.

The motherboard supports 128 GB RAM, but now all 4 DIMM sockets are used for
64 GB. You should go with 2x32 GB, in case you have a need for more RAM later
on.

There are more issues here, but those are the worst.

~~~
xena
Running my computer at full blast (GPU+CPU), the loudest thing in the room is
the death metal from Doom Eternal.

~~~
dr3adward
Some people use their computer for more than trivial things like video games.

~~~
nilkn
Do you have an axe to grind against the blog’s author?

~~~
dr3adward
No, but the author is obviously not a hardware person. And anecdotes about
perceived loudness does not contest reality. It's why we use dBA and
temperatures as benchmarks.

~~~
xena
I do not have a sound gauge, so the best I can give you is anecdotes. If this
is insufficient, I accept donations and could arrange to receive a properly
calibrated professional quality sound gauge to get a more precise answer.

------
alpaca128
> I had been using a 2013 Mac Pro for at least 7 years.

Assuming the 2013 Mac Pro came out in 2013 I'd say that's at most 7 years.

~~~
rvz
Then you also have those who still use unsupported Mac Pros. I know a friend
who was in this dilemma and I asked why they still use it. My friend replied
that it still 'just works' and switching to something else isn't worth the
effort.

By then you can see why when I gave them the choice of either upgrading to the
latest version of macOS + H/W upgrade or just installing either
Ubuntu/Fedora/etc on a second partition in which both are long winded
processes the decision was obvious and clear to them.

They didn't care about either solution and rejected both suggestions to carry
on with the status quo with great reason: 'If it ain't broke, don't fix it.'
So until their favourite app requires a higher version and kills their
productiviy, it is enough of a reason for them to upgrade it. A full blown
switch to any Linux distro would be the worst decision for my friend,
especially NixOS since even with this blogpost it gives little reason why they
should bother switching.

------
YuukiRey
Would be nice to mention that you're using home manager for user space package
management, if I read your config files correctly. User space package
management is a bit of a confusing topic especially since overlays supersede
some of the former overrides but the documentation doesn't mention that
prominently enough.

Also great post and great blog <3

------
IshKebab
I really want to try NixOS but the Nix language is just so damn weird... Why
didn't they use a syntax people wouldn't have to actually read a tutorial to
learn. E.g. C-style or Python-style? This article has a whole paragraph
explaining `with`, but it wouldn't have needed any explanation if they called
it `using` or `import`.

Same for the script parameters. I have absolutely no idea what this does

    
    
      { pkgs ? import <nixpkgs> { } }:
    

Why not:

    
    
      function main(pkgs: Package = nixpkgs) {
      }
    

Or something like that.

My second issue is that the files clearly aren't machine-editable. There's no
sensible way to make a GUI that can edit your hostname if the hostname is
defined in some Turing complete functional program.

But it definitely beats the design of any other package manager.

~~~
eeh
> My second issue is that the files clearly aren't machine-editable. There's
> no sensible way to make a GUI that can edit your hostname if the hostname is
> defined in some Turing complete functional program.

For the times I need to do this, I define the values in a JSON file, which can
be parsed by Nix's builtins.fromJSON into a Nix datatype.

~~~
xena
Do you have a more detailed example of this?

~~~
eeh
As an example, I have a program for regularly backing up directories to cloud
storage (with deduplication, encryption, key management, etc. it's just a
wrapper around Restic), which it does regularly via cron. I manage this in
NixOS: different machines backup different directories, with different keys.

This program has a CLI mode for setting up keys and buckets, which I run
locally, and it writes to backup-metadata.json .

So my workflow for adding a new directory to my system is:

1\. Run CLI tool to create a new bucket, new API key with access to the bucket
(with just the permissions it needs), and new encryption key. This writes to
my backup-metadata.json file locally.

2\. write some NixOS along the lines of:

    
    
      let
        metadata = (builtins.fromJSON "../backup-metadata.json").git;
      in {
        backup = {
          git = {
            path = "/var/lib/git-repositories";
            frequency = "hourly";
            bucket = metadata.bucket;
            key = metadata.key;
            apiKey = metadata.apiKey;
          };
        };
      }
    

3\. Hit deploy. This starts the backups, and some monitoring to check the
cloud storage is being regularly written to.

The implementation of "backup" is private, but reuses parts of upstream NixOS
(systemd.timer, Prometheus, ...)

------
skyfaller
Does anyone know if Ansible works on NixOS? I understand that Ansible requires
a working Linux system before it can operate, but it would be nice to use some
of my existing Ansible playbooks rather than rewriting everything in Nix.

~~~
takeda
Ansible would work, but to use NixOS properly or would have to only modify
/etc/nixos/configuration.nix and run nixos-rebuild switch after that.

Any other changes are not recommend, unless it is home directory and you don't
use home-manager.

At that point you would correctly wonder why would you use ansible it is like
running ansible to run saltstack.

NixOS essentially makes these tools redundant. It is also more powerful.
Imagine that you wanted to for example use libressl instead of openssl with
python, because it is more secure, or maybe introduce your custom patch put
use different configure option. With other tools like ansible, you would start
with building custom package(s), then place that package in repo like
artifactory. Then write your ansible definitions, you would add artifactory to
the OS uninstall the old package install a new one (also worry that replacing
your Python package with a custom version could break other stuff, you might
end up installing your Python under a different path). If you want to revert
it, removing these steps is not enough, you would need to write steps that
would revert it.

In Nix, you make change to the disk that is being installed. If nix won't find
precompiled package in its repo it will automatically pull compiler and
compile it. If you configure caching after finishing it it would populate the
cache so other machines no longer would need to compile it. And if something
else is using old Python version it won't be affected at all, it will continue
using what it was using. If you remove your change nix will restore back the
previous state, no need writing rules about restoring it.

Another killer feature is that nix will never leave your packages in half
state, everything is atomic. So if you incorporate many changes you either get
all or nothing. It also guarantees that all machines using particular
configuration are identical, I often seen rules working on one machine and not
working in another (different OS version, maybe previous state was not applied
everywhere or somebody made changes by hand).

~~~
skyfaller
These are good points, but one reason to use Ansible to configure NixOS is if
you must continue using Ansible to configure other computers / cloud instances
that are not running NixOS. It would be easier to adopt NixOS if you could do
it incrementally rather than replacing everything.

I suppose one could use Nix to configure computers that are not running NixOS?
Switching all of my Ansible playbooks to the Nix package manager is non-
trivial, but perhaps less effort than changing every OS at the same time?

But can you use Nix to interact with the cloud? I currently use Ansible to
spin up virtual servers on Linode using their web API, for example, and I
expect to have to interact with AWS or Google Cloud in the near future.

~~~
ghostwriter
There's NixOps:

\- [https://github.com/NixOS/nixops](https://github.com/NixOS/nixops)

\- [https://ops.functionalalgebra.com/nixops-by-
example/](https://ops.functionalalgebra.com/nixops-by-example/)

------
globular-toast
I would use Guix rather than NixOS, but I wonder if I would feel as in control
as I do as a Gentoo user. I suppose I should set aside some time to try it in
a VM.

~~~
carapace
I tried them both last week. All I did was spin up a server, connect through
ssh.

NixOS was fine. Standard systemd (bleah!) commands to enable and then start
sshd. (Because "enabling" and "starting" are two different things, yeah?)

Guix required editing a file and rebuilding the OS. This wasn't well
documented, and they had forgotten to include the file in the VM image. (The
manual says edit /etc/config.scm (IIRC) but it's not there. There's a bug open
for it.) I had to find a copy of the VM config and hack it up to work, but
after that everything went smoothly. (Can you taste the irony on that last
sentence? I am being sardonic. The experience was hugely demotivating.)

Anyhoo, FWIW, Nix seems great but I don't like the language (and I don't like
systemd, and no, I don't want to talk about it.) Guix seems like it will
approach being a new kind of Lisp Machine, Guile lisp is fine, and integrated
into other parts of the OS. (Shepard seems fine.) But having to edit a file
and rebuild the OS to get ssh access was gnarly.

All in all, something like NixOS or Guix seems to me to be the way of the
future. Other build/package managers seem just stupid and dangerous in
comparison (like operating a chainsaw without kevlar chaps. I have two legs
thanks to kevlar chaps. _Always wear your chaps kids!_ )

------
towb
Used NixOS for a short bit, it was easy to get going with and most things
works good out of the box with a pretty simple config. Didn't want to replace
my linux knowledge with something this different though so moved back to
something more normal for my desktop. Thinking about using NisOS on my home
server though, already have the configuration.nix to get it up and running
very fast which is nice obviously.

------
frabbit
I don't understand the conjunction of the following two phrases in the
article:

> * Nix goes a step further by disallowing package* > * builds to access the
> internet. This allows Nix* > * packages to be a lot more reproducible;*

and

> * The src attribute tells Nix where the source * > * code of the package is
> stored. Sometimes this* > * can be a URL to a compressed archive on the* > *
> internet, _

~~~
tridentlead
The idea is that as long as the downloaded source file matches the hash all
inputs are deterministic and so is the build overall.

~~~
scintill76
Right. More specifically, Nix itself can download files in this way, but the
build scripts (in this case, the mkdir & cp part) are not allowed access so
that the build is deterministic.

------
kristopolous
Nice layout. A fundamental reengagement with the concept of "formatted
hypertext".

~~~
nloomans
I agree! Showing a bit of the markdown in the rendered text really gives the
page a nice hacky feel. I'm doing something similar on my website[1] but this
blog looks a lot nicer then mine!

The biggest problem on my version I think is that links aren't obvious enough
in dark mode, but I like the links used here so I'll look into that.

[1]:
[https://noahloomans.com/tutorials/makefile/](https://noahloomans.com/tutorials/makefile/)
(The contents of this page is intended for the other students at my college
and probably doesn't make a lot of sense standalone)

~~~
aaron-lebo
Noah, I love that menu. Nice work!

------
avodonosov
The functional package management sounds good and clean in theory, but when I
tried nixos Firefox had terrible fonts.

Because of some config files in /etc influencing it indirectly.

So pograms in nixos influence each other via global configs, they are not
isolated.

I was unabne to fix that.

------
gigatexal
The best part of Debian and Ubuntu is package maintainers do all the heavy
lifting for you.

So a simple apt get install package is all I need.

This looks like having to write packages again and that’s the very reason I
use a Debian based distribution is for apt

~~~
eeh
I can see why the blog post gives the impression that packaging is involved,
because the author is creating packages! However, what's novel is that the
author is packaging their own software (a blog). A Debian and Ubuntu
maintainer isn't going to package Joe Blogg's blog.

NixOS also has package maintainers, which the author of this blog post relies
on (see "nixos.graphviz").

Traditional distributions also allow you to package your own software.

The difference between a traditional distribution and NixOS is that NixOS
makes packaging your own software (and config) easily and safely enough to
treat as first-class citizens along with the distro's own packages. So much so
that I don't think of NixOS packages as "packages". Rather, I just see them as
config/code.

~~~
xena
I mainly nix-ified my blog build to make a docker image that is as small as
possible.

Compare my super-optimised dockerfile results:

$ docker images | grep xena xena/christinewebsite latest eb8c27a1a5d2 12
seconds ago 121MB

To the naiive nix results:

$ docker images | grep xena xena/christinewebsite latest b087ad7fb924 50 years
ago 102MB

This image ends up only including my blog (statically compiled), ca
certificates (because of the patreon integration), time zone data files
(because of the go time package), iana port numbers (something to do with the
go net package) and mailcap (for some reason). It's puny!

~~~
asdf-asdf-asdf
so, what makes up the 19MB difference? (i assume it's not caused by the nix
one being MUCH older :-)

couldn't you simply do a multi-stage docker-image (in the not-nix
situation),where you just copy over the go binary into the final docker-image,
and add the needed files?

~~~
xena
The 19 MB difference is alpine linux crud, musl and other base things in my
custom docker base image.

In theory I could do the multi-stage docker approach to get an as-tiny-as-
possible setup (and I actually do this:
[https://github.com/Xe/site/blob/master/Dockerfile](https://github.com/Xe/site/blob/master/Dockerfile))
but that won't cover ca-certificates generically.

------
tbrock
You know, for all the nerding out about how package managers do their work and
how “correct” they are, they all still pale in comparison to how easy and
intuitive homebrew is to use.

I’m running Linux and pacman/yay are great but if something is screwed up I
miss being able to run brew doctor to figure out what’s wrong or add a tap for
some weird thing here or there.

I know I’ll get crucified for saying it but usability counts for a lot and
apt, dpkg, yum, dnf, and yes, even nix suck. All the correctness and
perfection don’t matter if nobody uses or wants to use your software.

~~~
t0astbread
I haven't used a Mac so I don't know what UX breakthroughs I might be missing
but I think even for beginners, apt and the like are fine, given how much
assistance software and online help there is for them.

It does take you a while to understand everything about it but that's always
the case with power tools. You'll likely not need to dive into the guts of
your package manager on day one anyways.

~~~
tbrock
No. apt-get install for installing and apt-cache search for searching?
That’s... not discoverable to say the least: how about brew install and brew
search? Didn’t know they were there? No problem you’ll see they are available
commands when you run brew.

~~~
t0astbread
The exact same applies to apt. You can do "apt search", "apt install" and just
"apt" will give you a short help text. This is the default apt program for
interactive use. Unfortunately few people advertise it in tutorials.

Oh and you can of course use "man" to read the manual pages for most apt
programs if you want more in-depth info.

------
jancsika
ergonomics oversight:

/nix/store/c99n4ixraigf4jb0jfjxbkzicd79scpj-gruvbox-css.drv

should be

/nix/store/gruvbox-css-c99n4ixraigf4jb0jfjxbkzicd79scpj.drv

~~~
takeda
They actually answer that in FAQ:
[https://nixos.wiki/wiki/FAQ](https://nixos.wiki/wiki/FAQ)

------
LockAndLol

        $ docker run --rm --name temp -it nixos/nix
        c343661ad923:/# nix search graphviz
        warning: using cached results; pass '-u' to update the cache
        error: no results for the given search term(s)!
        c343661ad923:/# nix search -u graphviz
        error: no results for the given search term(s)!
    

Well... that's not off to a good start. I don't mind learning something new,
but nix just seems super convoluted.

In many other distros the package manager makes it pretty easy to get a
graphical environment running or even to install and configure software. Not
nix.

Nix is far from easy to use or install
[https://invidio.us/watch?v=QujRHErFG4w](https://invidio.us/watch?v=QujRHErFG4w)

~~~
carapace
That video is two years old, and the comments make it clear that dude didn't
RTFM, so... YMMV.

------
lidHanteyk
For all the folks that can't get into Nix because they find it obtuse: Okay,
fine, don't use it. Nobody is forcing you to adopt it, and moreover, we don't
want an influx of folks who are only embracing the situation reluctantly and
cannot respect the Nix way of doing things.

The top complaints I've seen in this comment section so far are about the Nix
expression language. It's not appealing, hard to learn, weird, etc. Okay,
good. If learning a single simple DSL is completely off-putting, then we
should probably keep the DSL for a while, since it seems to be effective at
weeding out folks who aren't interested in learning about the theory of
package management, while allowing the rest of us to get things done.

The next top complaints I've seen are about how nixpkgs is hacky, lacking, or
doesn't well-support traditional UNIX tools. Well, to the extent that we can
force traditional UNIX tools to respect package-capability discipline, we're
doing quite well. According to Repology [0][1], nixpkgs is amongst the top 5
repositories for number of packages, number of maintainers, number of fresh
packages, and percentage of up-to-date packages.

Seriously, before you downvote or reply, _stop_ and look at [1]. Look at how
nixpkgs is literally _off the charts_ compared to almost any other distro. The
only close contender is AUR, which doesn't have the reproducibility or less-
insecure build model of Nix.

[0] [https://repology.org/](https://repology.org/)

[1]
[https://repology.org/graph/map_repo_size_fresh.svg](https://repology.org/graph/map_repo_size_fresh.svg)

