My NixOS Desktop Flow(christine.website)
christine.website
My NixOS Desktop Flow
https://christine.website/blog/nixos-desktop-flow-2020-04-25
243 comments
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.
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.
> Write up a nix config that sets up i3 and firefox, could be just a couple of lines
You forget the step "find out what to write in the nix config file". Might take anywhere from less than a minute to forever, depending on experience, google-fu, and documentation.
You forget the step "find out what to write in the nix config file". Might take anywhere from less than a minute to forever, depending on experience, google-fu, and documentation.
Well obviously, I'm just pointing out why you would want to spend some time figuring it out. NixOS isn't just another linux distro, it's the next generation of operating systems.
I don't know, the "benefits" have been well preached for years, and I don't see NixOS gaining popularity (though, I tend to focus on the linux community news, so might be missing the visibility). To me, NixOS is a cool concept, but I think it solves a problem that not a lot of people have. I mean, how often are people "redoing their systems from scratch," deploying to new machines, etc? That's like a once-every-four-year thing for me, and it's way easier to just dump a list of packages.
People mostly don't have the problem because Ansible et al solve it for them. It's the classic situation of a good-enough solution existing, making the superior solution irrelevant.
Agree, what is going for Nix is that is a valuable tool and is very versatile. NixOS is just one application.
From OS point of view you no longer need:
- Kickstart
- Ansible, Saltstack et.al.
- Custom package repo for custom packages (if you need to customize something)
There are other areas too:
- create common developent environment, makes sure every developer has exactly the same tools installed with exactly same versions, so no more "it doesn't work on my machine"
- build system
- CI/CD
- packaging (as mentioned, you no longer need artifactory, instead you can have nix cache)
- there is also potential to use it for IaC, there's NixOps, but currently this is maybe the weakest part of Nix, it only covers deploying a box, but if you want to do something more complex, like autoscaled service it gets in the way. It is great for developing a new image though. There are terraform integrations, I didn't try them yet, might work better.
- you can configure local developer machine to use build system for local builds as well. If caching is configured, then once code is deployed it will already cache good build so it doesn't need to redo it
- for personal use with things like home-manager it can replace dot files as do more, you can have the same environment each time. Let say you change job and get a new laptop you can have it quickly set up the way you want it
From OS point of view you no longer need:
- Kickstart
- Ansible, Saltstack et.al.
- Custom package repo for custom packages (if you need to customize something)
There are other areas too:
- create common developent environment, makes sure every developer has exactly the same tools installed with exactly same versions, so no more "it doesn't work on my machine"
- build system
- CI/CD
- packaging (as mentioned, you no longer need artifactory, instead you can have nix cache)
- there is also potential to use it for IaC, there's NixOps, but currently this is maybe the weakest part of Nix, it only covers deploying a box, but if you want to do something more complex, like autoscaled service it gets in the way. It is great for developing a new image though. There are terraform integrations, I didn't try them yet, might work better.
- you can configure local developer machine to use build system for local builds as well. If caching is configured, then once code is deployed it will already cache good build so it doesn't need to redo it
- for personal use with things like home-manager it can replace dot files as do more, you can have the same environment each time. Let say you change job and get a new laptop you can have it quickly set up the way you want it
https://nixos.org/nixos/options.html massively helps. Sure, some things you have to build for yourself and that may take some time, but a surprising amount of stuff has been done already and you just need to flip one of these options to activate it.
What's the value proposition over something like Debian where it Just Works(tm)?
Maybe if I was a sysadmin managing a herd of boxen I would like this, but for a guy with only two Linux systems (plus my mac, plus my windows boxes, plus my openbsd pcengines etc.), it seems like a lot of fuckery with text files for little to no actual improvement in my UX.
Maybe if I was a sysadmin managing a herd of boxen I would like this, but for a guy with only two Linux systems (plus my mac, plus my windows boxes, plus my openbsd pcengines etc.), it seems like a lot of fuckery with text files for little to no actual improvement in my UX.
It's the same as with git. Some people don't use git when they're working on a project solo. I don't get that at all, NixOS is a fundamentally improved way of managing your operating system. The only real reason not to use it is because you're in a company and your business needs to avoid risks like sysadmins not getting your tech stack, or some component not working because there's a bug in a less battle-hardened setup.
When you're solo there's no such restrictions, you can just use the nicest tech that's out there. I've been amateur-adminning debian/arch/ubuntu machines for 15 years now, NixOS is such a relief to be rid of that mess.
When you're solo there's no such restrictions, you can just use the nicest tech that's out there. I've been amateur-adminning debian/arch/ubuntu machines for 15 years now, NixOS is such a relief to be rid of that mess.
>I don't get that at all, NixOS is a fundamentally improved way of managing your operating system.
In what way? Why are functionally-declarative system configs good? What does the increased workload gain me over my usual list-of-packages-to-apt-get?
In what way? Why are functionally-declarative system configs good? What does the increased workload gain me over my usual list-of-packages-to-apt-get?
I can actually remember what's installed on my system and how it's configured in a centralised place, even when I don't touch the configuration for a few months. It's actually better for "boring" systems that I don't touch the config of much - "why is that set up like that" is a question I can easily answer. Additionally, when I do want to play with new stuff, the various tools I'm given usually let me do that and go back to a clean slate if I'm not interested, without having to deal with heavyweight containers/VMs/etc.
Yep, switching between KDE and GNOME or xorg and Wayland is so much easier than on other distributions.
All your state is in one place - packages and configuration. On a typical system there is tons of hidden state - some little option you had to change but didn't document, some package you forgot you installed ... that's not that easy to reproduce or change-track without backing up the whole system. You could use Ansible to do it, but that's another can of overhead.
... at least that's my experience.
... at least that's my experience.
> The only real reason not to use it
I am sorry but that is fanfiction that nix people want to believe. There are numerous reasons not to use nix, a few: - Incredibly smaller community - Incredibly smaller support from community and enterprise - Yet another programming language - that is difficult to grok
Those alone can kill any technically sound project, but there are lots of others. Such as slow installs, storage requirements etc.
I am sorry but that is fanfiction that nix people want to believe. There are numerous reasons not to use nix, a few: - Incredibly smaller community - Incredibly smaller support from community and enterprise - Yet another programming language - that is difficult to grok
Those alone can kill any technically sound project, but there are lots of others. Such as slow installs, storage requirements etc.
I agree with the programming language, it seems to be more difficult than necessary, I don't get why the syntax had to be so outlandish.
The main value proposition is this:
With a single file, you describe the desired state of your system. That file is configuration.nix.
You put in there what packages you want installed, what users, what SSH keys, what services systemd manages.
Then, you run `nixos-rebuild` and then you switch your system to that configuration. The old state of your system stays around until you run garbage collect. So you can rollback to it, if you want.
You put in there what packages you want installed, what users, what SSH keys, what services systemd manages.
Then, you run `nixos-rebuild` and then you switch your system to that configuration. The old state of your system stays around until you run garbage collect. So you can rollback to it, if you want.
>Then, you run `nixos-rebuild` and then you switch your system to that configuration. The old state of your system stays around until you run garbage collect. So you can rollback to it, if you want.
How often are people doing this, though? I get a machine set up pretty quickly (install list of packages, systemctl enable <foo bar baz>, reboot), and I'm set for several years.
How often are people doing this, though? I get a machine set up pretty quickly (install list of packages, systemctl enable <foo bar baz>, reboot), and I'm set for several years.
It is as often as you change things. Also configuration.nix isn't just a list of packages to install and services to enable, it's also a configuration of various system components.
I'm quite new to NixOS and recently tried home manager, which basically manages your home, primarily all dot files, but goes as far as preinstalling favorite extensions on Firefox for example.
I'm quite new to NixOS and recently tried home manager, which basically manages your home, primarily all dot files, but goes as far as preinstalling favorite extensions on Firefox for example.
>With a single file, you describe the desired state of your system.
I can already do that with Kickstart for rpm distros, though.
I can already do that with Kickstart for rpm distros, though.
Kickstart is just RedHat equivalent of unattended install. NixOS goes way beyond that it also takes over CMS (ansible, saltstack, etc). You can for example modify one of packages (use different configuration option, or maybe sorry patch) and if binary version is not available in the cache it will compile new one. With home manager, it can also take care of your home directory, all configurations so called dot files, down to what extensions you want to have installed on Firefox.
I didn't know about this, thanks. But can you use it to change an existing system?
Honestly, I find it infinitely easier to just do everything in in docker containers. Then the OS doesn't matter except for installing docker, and running docker-compose up.
docker is like nixos for 2yo
If that were all there were to it, I would certainly prefer docker over nixos
Yeah, that argument is weird. If we are taking about state the difference between those two is that docker is just storing a snapshot of a state (BTW Dockerfile by itself is not reproducible and is comparable to a bash script) while Nix is storing information how to get to a given state.
That makes it far more versatile. It is what Docker promised to be, but ended up being an overglorified zip file. Depending on your needs, that might be all you actually want. If you want to make small adjustments to existing state (let say applying a patch, in docker you pretty much have to rebuild from scratch and with non-deterministic Dockerfile you might change more than that), or maybe compose something new from existing components, Nix gives you far greater control to do that.
Honestly what I dislike about docker is the very effectful config file.
Yes, the Dockerfile has serious shortcomings and makes it totally miss the mark on what it was promising, but based on some comments about how nix is hard, it probably helped with adaptation.
Seems like it comes much easier to most people to issue series of (often nondeterministic) commands that mutate state rather than learning a new language that allows describing dependencies and have it figure out steps needed.
Seems like it comes much easier to most people to issue series of (often nondeterministic) commands that mutate state rather than learning a new language that allows describing dependencies and have it figure out steps needed.
Docker is for containing the environment of your apps. NixOS is for configuring your operating system. I use NixOS to define which Docker apps run on my machine, as well as monitoring and administration tools, firewall setup, that sort of thing.
If all you do is apt-get install docker, that doesn't feel like a very complete set up to me.
If all you do is apt-get install docker, that doesn't feel like a very complete set up to me.
I'm saying if you run all your apps in containers, there really isn't much left to configure on the OS. Using Ansible for those few things seems like an easier solution.
But Ansible is an incomplete and extra part of software just to make your operating system behave like you want it to. Why not just pick an operating system that behaves like you want it to from the ground up?
It’s just a matter of doing a good old `man 5 configuration.nix`.
>> 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.
Have you had to deal with breaking changes in the config language? (Does this ever happen? Are there versions/specs of the language that can be pinned?)
Have you had to deal with breaking changes in the config language? (Does this ever happen? Are there versions/specs of the language that can be pinned?)
I don't remember any changes in the language, but I did encounter packages that had their configuration renamed or changed in a way that broke my config.
Basically you pin to a version of NixOS, and opting into the next version is fully optional. So if you change your NixOS version, and you run nixos-rebuild, and stuff doesn't work, then you can just undo your change. NixOS even keeps a backup of itself ready, so say for some reason you update but your new version doesn't boot, you can simply boot into your previous working version.
Basically you pin to a version of NixOS, and opting into the next version is fully optional. So if you change your NixOS version, and you run nixos-rebuild, and stuff doesn't work, then you can just undo your change. NixOS even keeps a backup of itself ready, so say for some reason you update but your new version doesn't boot, you can simply boot into your previous working version.
So nix has ability to pin to specific version and you can get exact same system.
With an OS there is a problem, because most of the time you don't want to do that, you want to get security patches and erratas. For this purpose channels are used. They promise to not break anything within release channels. This is very similar to how other OSes, you need to trust them to not break thighs. There is also option to subscribe to a rolling release, so similarly to other OSes there are more opportunities for things to break (living on the edge and all), but the stuff below still applies.
On top of that there is also variable in your configuration.nix it is set to the version of NixOS that you first installed. That version is version of the configuration file and supposed to guarantee compatibility. The compatibility they mentions are things like for example default version of PostgreSQL that they use if you choose default one you don't want on system upgrade to automatically force you to upgrade your database. Another obvious change is change of defaults, perhaps they decided that service that was previously enabled by default should be now disabled etc.
You can bump the version in that file, but then you have to go through changelog and adapt your config to these changes.
I am relatively new NixOS user, but just did uphrade from 19.09 to 20.03 and it went smooth as if it was just update within the same release.
With an OS there is a problem, because most of the time you don't want to do that, you want to get security patches and erratas. For this purpose channels are used. They promise to not break anything within release channels. This is very similar to how other OSes, you need to trust them to not break thighs. There is also option to subscribe to a rolling release, so similarly to other OSes there are more opportunities for things to break (living on the edge and all), but the stuff below still applies.
On top of that there is also variable in your configuration.nix it is set to the version of NixOS that you first installed. That version is version of the configuration file and supposed to guarantee compatibility. The compatibility they mentions are things like for example default version of PostgreSQL that they use if you choose default one you don't want on system upgrade to automatically force you to upgrade your database. Another obvious change is change of defaults, perhaps they decided that service that was previously enabled by default should be now disabled etc.
You can bump the version in that file, but then you have to go through changelog and adapt your config to these changes.
I am relatively new NixOS user, but just did uphrade from 19.09 to 20.03 and it went smooth as if it was just update within the same release.
Why would you want to know how you configured your NAS three years ago?
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.
If you were happy with it and need to do it again? If there were small gotchas you aren't eager to rediscover?
that actually sounds WONDERFUL.
I had a machine that I let run with an old (private) certificate for years because I didn't remember the how and the what of renewing that specific certificate.
I had another machine that had a hardware failure, and I spent an enormous amount of time recreating it.
I had a machine that I let run with an old (private) certificate for years because I didn't remember the how and the what of renewing that specific certificate.
I had another machine that had a hardware failure, and I spent an enormous amount of time recreating it.
I have been running a personal server (FreeBSD) for close to 20 years now, and upgrading in place since 4.6. And once some hardware components fails (especially disk) I spend extra time figuring once again how I did it then. Having everything described in a configuration would take less time to do such fixes.
As a keen NixOS user/contributor, if your only needs are i3 and Firefox, then I do not recommend NixOS to you. ~Any distribution can meet your needs.
NixOS is great for:
* shortening the divide between the user and upstream: not just release lag, but also the ability to contribute to upstream. NixOS makes it trivial to write a patch and deploy it your system, something I wouldn't usually bother with Debian, for example, because the same process was so frictionful.
* configuring services
* packaging ad-hoc code/scripts
NixOS is great for:
* shortening the divide between the user and upstream: not just release lag, but also the ability to contribute to upstream. NixOS makes it trivial to write a patch and deploy it your system, something I wouldn't usually bother with Debian, for example, because the same process was so frictionful.
* configuring services
* packaging ad-hoc code/scripts
> As a keen NixOS user/contributor, if your only needs are i3 and Firefox, then I do not recommend NixOS to you. ~Any distribution can meet your needs.
I really disagree with this. NixOS is also great for simple use cases like this because it's robust. I know a lot of people who switched to Linux, need to get something to work, follow some online tutorial/directions blindly, and just break shit pretty badly.
This isn't contrived: even seemingly-inoculous commands like "pacman -Sy" on Manjaro/Arch can fuck your shit up (it basically amounts to a partial upgrade).
NixOS doesn't let you break shit like this. (Literally, upgrades are atomic and packages can never have missing dependencies.) And, even if somehow you did, you then have a nice configuration.nix to quickly get back up to speed.
I really disagree with this. NixOS is also great for simple use cases like this because it's robust. I know a lot of people who switched to Linux, need to get something to work, follow some online tutorial/directions blindly, and just break shit pretty badly.
This isn't contrived: even seemingly-inoculous commands like "pacman -Sy" on Manjaro/Arch can fuck your shit up (it basically amounts to a partial upgrade).
NixOS doesn't let you break shit like this. (Literally, upgrades are atomic and packages can never have missing dependencies.) And, even if somehow you did, you then have a nice configuration.nix to quickly get back up to speed.
Sure, but Debian/Ubuntu/Fedora all provide great experiences for "I just want some packages installed".
Fedora nowadays has btrfs-level rollbacks, which although this doesn't interact well with cfgmgmt (unlike NixOS's excellent rollback support), it's perfectly fine for an end user.
Fedora nowadays has btrfs-level rollbacks, which although this doesn't interact well with cfgmgmt (unlike NixOS's excellent rollback support), it's perfectly fine for an end user.
Unfortunately I have to disagree.
I tried to setup a simple NixOS machine this week. From this experience I couldn't manage to install any GNOME extensions via the browser plugin because of some Firefox manifest location that conflicts with the way the NixOS store handles it - there is some workaround in some tickets, but it made me wonder how many other applications are in need for specific workarounds. I then enabled flatpak via the OS configuration, but the first installed app couldn't launch because of some obscure error with gstreamer. I changed to fedora and could setup anything without any of those issues.
I really want to like NixOS (I still do), but I now consider it more for a server environment than a casual desktop environment.
I tried to setup a simple NixOS machine this week. From this experience I couldn't manage to install any GNOME extensions via the browser plugin because of some Firefox manifest location that conflicts with the way the NixOS store handles it - there is some workaround in some tickets, but it made me wonder how many other applications are in need for specific workarounds. I then enabled flatpak via the OS configuration, but the first installed app couldn't launch because of some obscure error with gstreamer. I changed to fedora and could setup anything without any of those issues.
I really want to like NixOS (I still do), but I now consider it more for a server environment than a casual desktop environment.
You can use NixOS on the desktop -- it has a lot of benefit (including atomic upgrades/rollbacks). But it only really works well if you manage everything through Nix. Other mechanisms such as the ones that you mention tend to break very often.
I just gave up using Flatpaks with NixOS and install GNOME extensions through Nix.
I just gave up using Flatpaks with NixOS and install GNOME extensions through Nix.
This is a benefit, but other distributions are catching up. For example, Fedora Silverblue has an immutable root filesystem and provides atomic upgrades/rollbacks through OSTree. Ubuntu 20.04 supports making ZFS snapshots as an APT pre-installation hook and thus also support rollbacks.
And don't forget OpenSUSE, which has been making btrfs snapshots before and after every upgrade for years(?) now. OpenSUSE doesn't seem to ever get the recognition it deserves.
Patching your Debian is not hard: http://beza1e1.tuxen.de/articles/ubuntu_itch_scratch.html
No, but it's cumbersome.
Let's say your patch doesn't get in in time for Terminator 0.96 (following the same example), or it's not relevant for upstreaming. Now you need to go through the same process again to upgrade. So much for `apt-get upgrade`. And it gets even worse if your change breaks binary compatibility: now you need to find and rebuild all packages that depend on it too!
The beauty of NixOS here is that you patch the "repository" instead, so will get applied on top of the current version as long as the patch applies cleanly. And all of Nix's usual logic applies for rebuilding dependendees as required.
Let's say your patch doesn't get in in time for Terminator 0.96 (following the same example), or it's not relevant for upstreaming. Now you need to go through the same process again to upgrade. So much for `apt-get upgrade`. And it gets even worse if your change breaks binary compatibility: now you need to find and rebuild all packages that depend on it too!
The beauty of NixOS here is that you patch the "repository" instead, so will get applied on top of the current version as long as the patch applies cleanly. And all of Nix's usual logic applies for rebuilding dependendees as required.
The steps in that blog post aren't difficult, but it doesn't include all the steps and assumptions:
* how do you roll that dpkg out to your fleet? Now you need a deb archive?
* "For Debian the tool is called reportbug". Note that reportbug is a CLI tool to send an email to Debian's bug tracker, whose status/tags are then also controlled by control emails. It has a notoriously difficult learning curve.
* Many Debian packages expect patches via email, rather than the more familiar git-based approaches. Some Debian packages do accept patches via git, I'm aware. Hopefully the package you're filing a patch against does.
* The blog post also misses out the work the Debian package maintainer has to do: use their own approach (and there are multiple) for doing a package release/signing. NixOS? It's a PR that's built by CI. Like how we usually handle software systems.
* You've patched a single version. What happens when a new package is released but your patch didn't make it in?
IME, after years of using Debian I made a few but barely any patches against Debian because of the frictions involved. The frictionless experience of NixOS has made me more active.
* how do you roll that dpkg out to your fleet? Now you need a deb archive?
* "For Debian the tool is called reportbug". Note that reportbug is a CLI tool to send an email to Debian's bug tracker, whose status/tags are then also controlled by control emails. It has a notoriously difficult learning curve.
* Many Debian packages expect patches via email, rather than the more familiar git-based approaches. Some Debian packages do accept patches via git, I'm aware. Hopefully the package you're filing a patch against does.
* The blog post also misses out the work the Debian package maintainer has to do: use their own approach (and there are multiple) for doing a package release/signing. NixOS? It's a PR that's built by CI. Like how we usually handle software systems.
* You've patched a single version. What happens when a new package is released but your patch didn't make it in?
IME, after years of using Debian I made a few but barely any patches against Debian because of the frictions involved. The frictionless experience of NixOS has made me more active.
I've used NixOS, it's a great project and has some benefits that can't be overstated, however if you're going to give it a try completely you kind of have to go down the rabbit hole. You will basically be learning a programming language that will let you configure your system. It took quite a bit of getting used to to understand how the language nix works, as it wasn't familiar to something I had used before. One might not have as much difficulty getting used to it as I did if they are experienced with functional programming, which I've only dipped my hands into before.
I'd recommend giving it a try if you have some time on your hands to get used to it, but you shouldn't be expecting a quick switch.
I'd recommend giving it a try if you have some time on your hands to get used to it, but you shouldn't be expecting a quick switch.
I disagree. While to be a power user you might have to learn all the syntax of the OS, I have been using NixOS for a couple of years, and have my configuration set up by borrowing other configs from the Web.
Additionally I'm a heavy Emacs user, and couldn't type a single line of elisp. I get that I'd be better in Emacs if I knew elsip, but that doesn't stop me configuring my text editor by borrowing code from others.
Additionally I'm a heavy Emacs user, and couldn't type a single line of elisp. I get that I'd be better in Emacs if I knew elsip, but that doesn't stop me configuring my text editor by borrowing code from others.
I've been able to achieve that same end goal, having deterministic/reproducible/reverting/history/etc with Ubuntu. Essentially, I boot Docker images on bare metal.
https://godarch.com/
My recipes: https://github.com/pauldotknopf/darch-recipes
I have the same exact images, bit-for-bit, running on 3 different machines. I have a zshrc alias that allows me to sync my current machine with my work image that I have stored on Docker Hub.
https://godarch.com/
My recipes: https://github.com/pauldotknopf/darch-recipes
I have the same exact images, bit-for-bit, running on 3 different machines. I have a zshrc alias that allows me to sync my current machine with my work image that I have stored on Docker Hub.
I recently stumbled on Darch, but decided not to try it because the repo seems pretty dead. (last commit Feb 2019)
Is this a non-issue?
Is this a non-issue?
I use it daily. I'm open to any ideas/improvements people want to make, but it's <air-quote> done </air-quote> in my eyes.
A lot of potential users will probably react similarly and think the project is not maintained anymore. Maybe you could clarify that by mentioning in the README that this project is basically done, but still maintained should a problem arise.
Good to know, I'll give it another look.
Heads up though, I will probably be deprecating the "recipes" format for 1.0, opting to use a pure Dockerfile approach.
See my recipes repo for an example.
See my recipes repo for an example.
It's "done" in your eyes, but you're still working towards a 1.0 release? It might just be me, but this is a bit confusing.
You must have been really confused when React moved to 16.X ;)
My scenario is similar. The current version is 100%. However, I'm going to be refactoring a bit, moving some pieces around, to support some new features. The only breaking changes that user's will notice is that ```darch recipes build``` will be moving to ```docker build .```. I've already converted my personal recipes to use it.
My scenario is similar. The current version is 100%. However, I'm going to be refactoring a bit, moving some pieces around, to support some new features. The only breaking changes that user's will notice is that ```darch recipes build``` will be moving to ```docker build .```. I've already converted my personal recipes to use it.
having deterministic/reproducible/reverting/history/etc with Ubuntu
Looking at the recipes this seems to be non-deterministic/reproducible. E.g.
There is no guarantee that you will get exactly the same Go version when rebuilding an image. And all the scripts seem like that: ad-hoc wget and apt command, where package versions, how they are built, etc. can change between runs.
This is only a very weak notion of reproducibility: if the scripts run, you will get an image with the same packages. Nix/Guix guarantee that you get exactly the same versions, built in exactly the same way, from your own package down to transitive dependencies such as glibc or zlib.
(I am not criticizing the project, it may be great, but it is just not reproducible/deterministic.)
Looking at the recipes this seems to be non-deterministic/reproducible. E.g.
add-apt-repository -y ppa:longsleep/golang-backports && apt-get update
There is no guarantee that you will get exactly the same Go version when rebuilding an image. And all the scripts seem like that: ad-hoc wget and apt command, where package versions, how they are built, etc. can change between runs.
This is only a very weak notion of reproducibility: if the scripts run, you will get an image with the same packages. Nix/Guix guarantee that you get exactly the same versions, built in exactly the same way, from your own package down to transitive dependencies such as glibc or zlib.
(I am not criticizing the project, it may be great, but it is just not reproducible/deterministic.)
Sure, it's not bit-for-bit like Nix and friends, but it's as predictable as you'd expect "docker pull ubuntu:bionic" to be, which is perfectly reasonable/comfortable for desktop scenarios.
It's as reproducible as a bash script that you call on first boot to configure your machine.
Yeah, and? Darch does a lot more than just that.
1. Temporary boots. You can "sudo rm -rf /", reboot, and all is well. You can play around with "apt-get install" without having to commit to your changes being persistent.
2. Checkpoints. Each "bash script that you call on first boot" is versioned and you can easily revert back to any image at any point, as simple as running either "docker run ubuntu:bionic" or "docker run ubuntu:focal".
3. Store your builds in Docker Hub (https://hub.docker.com/repository/docker/pauldotknopf/darch-...) so that the same resulting image can be run on any of your machines via "darch images pull your-image && darch stage upload your-image".
Your bash-script approach to building a fresh machine would be a lot more involved than:
1. Make changes to your script.
2. Check in a push to repo.
3. Wait for CI build to push to Docker Hub.
4. "darch images pull my-new-image && darch stage upload my-new-image"
5. Reboot.
6. Enjoy.
1. Temporary boots. You can "sudo rm -rf /", reboot, and all is well. You can play around with "apt-get install" without having to commit to your changes being persistent.
2. Checkpoints. Each "bash script that you call on first boot" is versioned and you can easily revert back to any image at any point, as simple as running either "docker run ubuntu:bionic" or "docker run ubuntu:focal".
3. Store your builds in Docker Hub (https://hub.docker.com/repository/docker/pauldotknopf/darch-...) so that the same resulting image can be run on any of your machines via "darch images pull your-image && darch stage upload your-image".
Your bash-script approach to building a fresh machine would be a lot more involved than:
1. Make changes to your script.
2. Check in a push to repo.
3. Wait for CI build to push to Docker Hub.
4. "darch images pull my-new-image && darch stage upload my-new-image"
5. Reboot.
6. Enjoy.
You still can create a chroot using bash script, it's nothing new and you can do it in any system including NixOS.
I find something like this[1] far more useful, because it actually has some applications.
[1] https://grahamc.com/blog/erase-your-darlings
I find something like this[1] far more useful, because it actually has some applications.
[1] https://grahamc.com/blog/erase-your-darlings
That is a complicated way to achieve the same thing Darch does. I'd prefer to not learn a new DSL. Packages and products are more widely supported on Ubuntu/Debian. In the end, I just want to work and play, not learn a new DSL, while having everything in the article you shared.
No, it's really not the same thing.
You have a very weak reproducibility which relies on Docker's implementation details and a lot of impurities.
In contrary, NixOS has very fine-grained reproducibility (and is not perfect of course) but get us very far [1]
[1]: https://r13y.com/
[1]: https://r13y.com/
It's close enough for desktop purposes, especially for people not willing to make the plunge into a new world with its own DSL.
You don't really hear people complain about the reproducibility of "docker pull ubuntu:bionic".
You don't really hear people complain about the reproducibility of "docker pull ubuntu:bionic".
This is not the same thing darch does, what darch does can be done by chroot, namespaces etc and is not that complicated.
Of course, the tech is different. I meant the end-goal being achieved is the same.
> what darch does can be done by chroot, namespaces etc and is not that complicated.
Exactly my point.
> what darch does can be done by chroot, namespaces etc and is not that complicated.
Exactly my point.
I'm no Linux expert. I used Ubuntu for a few years and then switched to NixOS a couple of years ago. Setup is no more difficult to Arch, and certainly a lot easier than Gentoo.
For me the fact that I can replicate my machines with a couple of config files is the major driver. That and the ability to install a package in a shell, use it, then exit the shell and not have it installed globally is amazing.
Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.
For me the fact that I can replicate my machines with a couple of config files is the major driver. That and the ability to install a package in a shell, use it, then exit the shell and not have it installed globally is amazing.
Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.
>> ... and not have it installed globally is amazing.
Yah, the more I think about it this is the biggest selling point to me.
>> Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.
I actually never thought deeply into nix NOT on nixos (I've probably been conflating the two). As an infra/devops-y person I can think of a lot of cool use cases off the bat in the server-space (theoretically anyways, I've a feeling the details would be quite the devil). But, except for the case of developing for such a system, I'm struggling to see a use case that warrants it in the desktop realm. (I need to meditate on this one..!)
Yah, the more I think about it this is the biggest selling point to me.
>> Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.
I actually never thought deeply into nix NOT on nixos (I've probably been conflating the two). As an infra/devops-y person I can think of a lot of cool use cases off the bat in the server-space (theoretically anyways, I've a feeling the details would be quite the devil). But, except for the case of developing for such a system, I'm struggling to see a use case that warrants it in the desktop realm. (I need to meditate on this one..!)
> That and the ability to install a package in a shell, use it, then exit the shell and not have it installed globally is amazing.
I can't even count the number of packages I have installed because I needed them once. I have an entire Node.js ecosystem installed because I needed to run a frontend from another team for 20 minutes. Could I have done all that in a single shell, then had it automatically cleaned up when I was done? My current solution is to spin up a container, but that becomes a pain and I end up getting lazy and just globally installing everything again.
I can't even count the number of packages I have installed because I needed them once. I have an entire Node.js ecosystem installed because I needed to run a frontend from another team for 20 minutes. Could I have done all that in a single shell, then had it automatically cleaned up when I was done? My current solution is to spin up a container, but that becomes a pain and I end up getting lazy and just globally installing everything again.
> Could I have done all that in a single shell, then had it automatically cleaned up when I was done?
Yes, that is a pretty standard workflow for most nix users. You either set up a shell.nix for your project with all of its dependencies, or if you need a certain tool once you just write for example: ‘nix shell -p iotop’ to enter a shell where iotop is in the path.
Yes, that is a pretty standard workflow for most nix users. You either set up a shell.nix for your project with all of its dependencies, or if you need a certain tool once you just write for example: ‘nix shell -p iotop’ to enter a shell where iotop is in the path.
Wow, that's pretty great. I'm gonna spin up a Nix VM shortly, see how it goes.
Certainly. You'd be just a `nix-shell -p nodejs` away from being in a shell with NPM. And a C^D away from not having it installed, with a caveat that it would be cleaned up periodically and not immediately after exiting the shell. But I think there's an option for immediately removing after use as well.
Yeah, you can just have a couple of config files and spin up a shell that auto-installs everything. The packages are all on your system, so the next time you start the shell, nothing has to be downloaded, but they're not installed globally, and a you can do a garbage collection command at any time to clean up everything.
When I first started using NixOS I had a huge list of globally installed packages, but that has become smaller and smaller over time. For instance, my main browser is Firefox, which is installed globally, but if I need to use Chrome, then it gets fired up in a temporary shell.
When I first started using NixOS I had a huge list of globally installed packages, but that has become smaller and smaller over time. For instance, my main browser is Firefox, which is installed globally, but if I need to use Chrome, then it gets fired up in a temporary shell.
I haven't used it in a while but Vagrant used to be great for "setting this up with apt and the language's package manager would be straightforward, but containerizing it would be a pain" one-offs, to keep it off your base system. And didn't require you to keep an entire image around to do it again, just the vagrant config file.
There is a learning curve to NixOS, but it has saved me huge amounts of time over the last 6+ years. I wrote a configuration.nix file describing my ideal Linux install once and I've been using it largely unchanged for years. Upgrading and migrating to a new machine has been painless. I can also easily change any part of my setup with minimal effort (e.g. to switch from connman to network manager is a one-line change).
The NixOS configuration language is a unifying layer of abstraction and allows people to more easily re-use the work of others (compare with pasting commands from a how-to blog post).
The NixOS configuration language is a unifying layer of abstraction and allows people to more easily re-use the work of others (compare with pasting commands from a how-to blog post).
> I wrote a configuration.ni x file describing my ideal Linux install once and I've been using it largely unchanged for years.
I use custom install and configuration scripts for various Linux distros and Windows installs, this is not a feature unique to NixOS, just a different implementation. I use a shell script for Linux and a PowerShell script for Windows.
I use custom install and configuration scripts for various Linux distros and Windows installs, this is not a feature unique to NixOS, just a different implementation. I use a shell script for Linux and a PowerShell script for Windows.
But the crucial difference is that you maintain your scripts, while with NixOS it's pushed to the OS maintainers for the most part.
> The apparent learning curve for nix looks...steep.
It looks like so, indeed the manual is fairly extensive yet it probably lacks a hands-on approach. That's what I'm aiming to solve by writing a couple of articles explaining pragmatically how to use Nix (not NixOS, I'm not quite there yet), starting as a Homebrew replacement.
And really, at the end of the day the new language is not really harder than having to learn Ruby and the Formula DSL, or ABS idioms and its shell idiosyncrasies in PKGBUILDs.
It looks like so, indeed the manual is fairly extensive yet it probably lacks a hands-on approach. That's what I'm aiming to solve by writing a couple of articles explaining pragmatically how to use Nix (not NixOS, I'm not quite there yet), starting as a Homebrew replacement.
And really, at the end of the day the new language is not really harder than having to learn Ruby and the Formula DSL, or ABS idioms and its shell idiosyncrasies in PKGBUILDs.
I went down the same path as you and now run NixOS. The biggest advantage is that all the tweaks you have to do every time you install are now just a couple of lines in a file you only write once. It's very hard to break the system because you can always boot a previous configuration. Everything is customizable like Gentoo but if you don't modify a package its binary will be fetched from a central server so installation is very fast.
I think the Nix/NixOS debate gets confused by two separate goals:
* A workstation machine where you do everything from development to watching netflix
* A server (whether VM, Metal, Container)
The former wants convenience and flexibility. I agree with you - I also use Fedora because (particularly with Lenovo hardware), you install it and you're done. Everything works. I don't want to have to go and write nix expressions because I want to run a not-very-obscure thing that isn't packaged. It's ok for me that my workstation is a 'pet' and I blow it away every 6 months to a year.
The latter case is more interesting and has some specific requirements on it. We all know about configuration drift. The idea of getting completely deterministic setups, and unifying how you do that across VMs, native and containers is great.
* A workstation machine where you do everything from development to watching netflix
* A server (whether VM, Metal, Container)
The former wants convenience and flexibility. I agree with you - I also use Fedora because (particularly with Lenovo hardware), you install it and you're done. Everything works. I don't want to have to go and write nix expressions because I want to run a not-very-obscure thing that isn't packaged. It's ok for me that my workstation is a 'pet' and I blow it away every 6 months to a year.
The latter case is more interesting and has some specific requirements on it. We all know about configuration drift. The idea of getting completely deterministic setups, and unifying how you do that across VMs, native and containers is great.
I agree. Or at least I used to! I set up a server a few years ago running NixOS and it required a steep learning curve, but it seemed worthwhile at the time. Fast forward to today and I want to add a new service on the server and I've completely forgotten everything I learned about Nix and I'm considering switching back to debian.
"The former wants convenience and flexibility." Thanks but no thanks, if those were my priorities I'd just use my chromebook. Or a mac if I had to run locally hosted stuff old school style.
This NixOS stuff is very interesting, feels like living in the future. Turning it into Windows10 is exactly what would repel me from enjoying it.
To some extent my chromebook is completely deterministic in that there is no setup other than my wifi credentials and google login. Its weird and fun to compare.
This NixOS stuff is very interesting, feels like living in the future. Turning it into Windows10 is exactly what would repel me from enjoying it.
To some extent my chromebook is completely deterministic in that there is no setup other than my wifi credentials and google login. Its weird and fun to compare.
Fedora Silverblue is something I'm keeping my eye on, as a way of getting some of the benefits of NixOS without any of the pain.
I think there are more nuanced value conflicts around the workstation case. There's nothing wrong with the values you're working from, but they've slipped down my list over the past few years.
Nix can certainly be limiting in some ways. But everything can--we just habituate.
It's possible to find interesting tools that aren't at all cross-platform, or that require hours of DIY spelunking to get compiling, or that are only in some other repository. It's possible to find something you want to use that either isn't packaged for or is broken in every package manager.
I use Nix (on macOS and NixOS) for roughly the same reasons: convenience and flexibility. But from a different angle, I guess. It is freeing to know that everything I need to make forward progress on all of my personal and professional projects is specified. I have the flexibility to resume work on the projects I care about with almost no friction beyond securing new hardware.
Nix can certainly be limiting in some ways. But everything can--we just habituate.
It's possible to find interesting tools that aren't at all cross-platform, or that require hours of DIY spelunking to get compiling, or that are only in some other repository. It's possible to find something you want to use that either isn't packaged for or is broken in every package manager.
I use Nix (on macOS and NixOS) for roughly the same reasons: convenience and flexibility. But from a different angle, I guess. It is freeing to know that everything I need to make forward progress on all of my personal and professional projects is specified. I have the flexibility to resume work on the projects I care about with almost no friction beyond securing new hardware.
I am finding that the Nix package manager on top of Fedora works nicely as a middle ground:
You can use it to set up a per-project nix-shell that gives you an experience a little like docker (in terms of speed), but more convenient because your normal machine is available on the PATH (or not, if you run --pure).
I can then use that same Nix config in my CI - just use the base Nix docker image and then apply the nix-env as a pre-script.
You can use it to set up a per-project nix-shell that gives you an experience a little like docker (in terms of speed), but more convenient because your normal machine is available on the PATH (or not, if you run --pure).
I can then use that same Nix config in my CI - just use the base Nix docker image and then apply the nix-env as a pre-script.
Nix can be approached incrementally by starting with the package manager on your current machine. Perhaps use home-manager to build out a user environment or nix-shell for custom local development environments.
Yes you absolutely can just install nix[1] it should work on any Linux, I used it in OS X myself and some things are slightly less smooth than Linux, but it still works well. I also highly suggest to start with Nix Pills[2] it goes so by step how to create derivations and conventions in nixpkgs.
Once you get familiar, you can see how you can make a reproducible dev environment, the author has a blog how to do it for rust[3] but many things still apply, I for example did a template for python [4], I eventually plan to put a less trivial app with unit tests once I get some free time.
[1] https://nixos.org/nix/
[2] https://nixos.org/nixos/nix-pills/index.html
[3] https://christine.website/blog/how-i-start-nix-2020-03-08
[4] https://github.com/takeda/example_python_project
Once you get familiar, you can see how you can make a reproducible dev environment, the author has a blog how to do it for rust[3] but many things still apply, I for example did a template for python [4], I eventually plan to put a less trivial app with unit tests once I get some free time.
[1] https://nixos.org/nix/
[2] https://nixos.org/nixos/nix-pills/index.html
[3] https://christine.website/blog/how-i-start-nix-2020-03-08
[4] https://github.com/takeda/example_python_project
we had to setup a simple linux for the purpose of diplsaying some stats on the attached screen. choices were: debian and nixos. debian would take approx half day to setup (given other project tasks). nix os was chosen and it took 2 weeks and now it is rather hard for non-nix user to fix anything.
To be fair, at one point that was the general Linux experience: half a day on Windows, a week on Linux and then “nobody else can fix it”.
I’m not arguing for Nix (had a look and it seemed more complex than I can bear at the moment), just that new tech in general needs time before it can be properly compared.
I’m not arguing for Nix (had a look and it seemed more complex than I can bear at the moment), just that new tech in general needs time before it can be properly compared.
Well, sure, anything that's unfamiliar to you is hard to fix. For me it would be exactly the other way around, because I'm quite familiar with NixOS and mostly unfamiliar with Debian.
The most complex thing you'll need to do is learn is whatever something like this (taken from my laptop's config, enables acpid, openssh, tlp, sddm, and make plasma5 and E available as sessions):
services = {
acpid.enable = true;
openssh.enable = true;
tlp.enable = true;
xserver = {
enable = true;
layout = "us";
libinput.enable = true;
displayManager.sddm.enable = true;
desktopManager.plasma5.enable = true;
desktopManager.enlightenment.enable = true;
};
};
nix-env -iA nixos.firefox-bin
You might get more mileage from Fedora Silverblue. Toolbox (a regular Fedora ran via podman) gives a disposable container for running dev stuff. The rpm-ostree package manager allows for fearless upgrades as you can always boot into an earlier version of the core OS.
There is small learning curve for getting to know rpm-ostree and toolbox tends to be a hindrance if you want IDE integration. Also you have to reboot after installing packages to the core OS, that's mainly why they recommend using flatpaks, but it's optional.
Note that it's still beta but pretty reliable as you can always downgrade and wait till they fix stuff that may be broken after an upgrade.
When it comes to actual setup needed it's not much different than a regular distro. No language to learn, no additional setup required.
Initially I played around with toolbox, wrote a 30 line bash script for initial setup for it and eventually ditched using it.
You can still use RPM Fusion and install regular .rpm's.
One thing to note is that they recommend to use the default partition layout as custom ones can (and do) break.
There is small learning curve for getting to know rpm-ostree and toolbox tends to be a hindrance if you want IDE integration. Also you have to reboot after installing packages to the core OS, that's mainly why they recommend using flatpaks, but it's optional.
Note that it's still beta but pretty reliable as you can always downgrade and wait till they fix stuff that may be broken after an upgrade.
When it comes to actual setup needed it's not much different than a regular distro. No language to learn, no additional setup required.
Initially I played around with toolbox, wrote a 30 line bash script for initial setup for it and eventually ditched using it.
You can still use RPM Fusion and install regular .rpm's.
One thing to note is that they recommend to use the default partition layout as custom ones can (and do) break.
> I don't know. Not much about all this setup feels appealing.
Exactly. While reading the post all I could think of were flashbacks of dependency hell and not one thing I was reading appeared to be helpful in eliminating it. But now I have to put up with the crazy cryptic language that I've never seen before.
Thanks, but no thanks.
Exactly. While reading the post all I could think of were flashbacks of dependency hell and not one thing I was reading appeared to be helpful in eliminating it. But now I have to put up with the crazy cryptic language that I've never seen before.
Thanks, but no thanks.
LOL, you've must not paid attention or have some weird definition of dependency hell [1], because the way nix operates makes it nearly impossible (I mean you can technically write an app that requires incompatible versions of the same library, that can't work together, but then that app wouldn't work anywhere else as well, not just with nix)
[1] https://en.wikipedia.org/wiki/Dependency_hell
[1] https://en.wikipedia.org/wiki/Dependency_hell
Nix is probably the best solution to dependency hell I've seen. I would read more before dismissing it.
You can absolutely use NixOS without understanding what the article goes through. For example, I use NixOS and I don't know any of this (but I'm looking forward to learning it).
For example, on other *Nixes, you install and uninstall packages, maybe configure them, but you're not BUILDING packages. All of the complexity of this article is in the superset of what you'd normally do.
For the most part, just add things to systemPackages in configuration and `nix-rebuild switch` or install via `nix-env -i` if you want user scoped installs.
For example, on other *Nixes, you install and uninstall packages, maybe configure them, but you're not BUILDING packages. All of the complexity of this article is in the superset of what you'd normally do.
For the most part, just add things to systemPackages in configuration and `nix-rebuild switch` or install via `nix-env -i` if you want user scoped installs.
You can use Nix on your Linux (Ubuntu, maybe Gentoo) for the projects you want without going full NixOS.
And macOS! Catalina's read-only system volume has made the installation a bit more difficult. But once you have set it up, you get many of the same benefits (per-project virtual environments, home-manager, etc.).
We use NixOS on three machines around the house, but I use Nix + home-manager on my MacBook, and various Ubuntu servers at work. It's nice that I can largely use the same configuration across all machines. Just a home-manager switch and I am in my native environment.
We use NixOS on three machines around the house, but I use Nix + home-manager on my MacBook, and various Ubuntu servers at work. It's nice that I can largely use the same configuration across all machines. Just a home-manager switch and I am in my native environment.
i was planning to try out Nix on MacOS, because i always wanted to try out Nix and i use MacOS, but then Catalina happened,a and suddenly there were problems with Nix on Catalina.
last time i checked the install-instructions on Catalina, you had to create an unencrypted volume to store the nix-things, which i'd prefer not to do (i understand those files are probably non-personal, so no need to encrypt them, but i don't want to have to remember that half of my hard-drive is unencrypted)
is that still required or is there a simpler approach now?
last time i checked the install-instructions on Catalina, you had to create an unencrypted volume to store the nix-things, which i'd prefer not to do (i understand those files are probably non-personal, so no need to encrypt them, but i don't want to have to remember that half of my hard-drive is unencrypted)
is that still required or is there a simpler approach now?
The separate volume is still required. As far as I understand if you use an encrypted volume, it does not mount early enough in the login process and you have resort to more hacks to make it work.
Ideally the Nix store would be in some non-root location. But that requires a completely new binary cache among other things (since /nix store paths are hardcoded in binaries, scripts, etc).
Also making /nix a symlink doesn't really work in some cases, since realpath reports the actual path and that may break builds/applications.
It used to work so nicely out of the box :(, but I can also understand why Apple wants to enforce read-only system volumes, since it blocks nastier rootkits, etc.
Ideally the Nix store would be in some non-root location. But that requires a completely new binary cache among other things (since /nix store paths are hardcoded in binaries, scripts, etc).
Also making /nix a symlink doesn't really work in some cases, since realpath reports the actual path and that may break builds/applications.
It used to work so nicely out of the box :(, but I can also understand why Apple wants to enforce read-only system volumes, since it blocks nastier rootkits, etc.
I don't have any OSX boxes, but wouldn't bind-mounting the real the /some/where/nix to /nix solve the realpath problem? No need to write to / either (as you would have to do with the symlink approach).
If it is possible, then I think it should work. I believe this might be the way they are planning to go, because someone mentioned about a separate partition.
Honestly, I think they should just relocate it to a different location that can be persisted and rebuild the packages. I don't think people care about the location as long as they don't have to recompile every single thing. This could also be useful to catch all bugs where /nix was assumed.
Honestly, I think they should just relocate it to a different location that can be persisted and rebuild the packages. I don't think people care about the location as long as they don't have to recompile every single thing. This could also be useful to catch all bugs where /nix was assumed.
Right, sorry, forgot to mention macOS even though I’m using Nix there myself for our commercial project’s dependencies
I, too, have no desire to put so much work into having a working system (but I guess, there’s no way around nix for me, if I want to use haskell and ghcjs). Unfortunately from my own recent personal experience it does indeed have a steep learning curve .
I really like the general idea of nix, I think it’s going in the right direction and I am very grateful for all the people doing amazing work there and I wanted to give it a try for a long time, now.
But my recent experience with nix on MacOs has mostly just been incredibly frustrating. I started using nix one or two weeks ago, because I needed it for a project with haskell-miso (which I very much like, by the way).
As long as I just stuck to using the default.nix provided by Miso, everything worked fine, more or less, but as soon as I tried to go beyond that to customize things for the needs of my own project, the problems started to accumulate.
I needed to google for and apply manual fixes for some very basic things, because nix did not play well with neither macOS Catalina (nix needs access to /nix) nor with fish.
Some haskell packages I need like constructible were broken in the default channel and I had no idea how to fix those packages. In the end I ended up switching to a “stable” version. I do not understand why nixpgs-unstable is the default channel, by the way.
Sometimes things seem easy in some guides and I thought I understood them, but then when I tried them they just won’t work. For example I was hoping that
I tried following guides and didn’t try to do anything especially crazy, but somehow I ended up fucking up my haskell build environment so much, that I couldn’t do anything Haskell-related anymore. Still don’t how I managed to do that.
I tried rolling things back through
When I was 15 years younger I really enjoyed playing around with the configuration of my computer, trying different window managers and editors etc., but nowadays I have work I care about and limited time and I want my computer to just work and not get in the way. Nix really, really got in the way. It’s been incredibly frustrating the last few days, when I wanted to work on my project, but spent several days fighting with nix instead.
Sorry for the rant, again, I very much like the project and I really hope it succeeds, I just wanted to share my own experience with it, as a beginner.
I really like the general idea of nix, I think it’s going in the right direction and I am very grateful for all the people doing amazing work there and I wanted to give it a try for a long time, now.
But my recent experience with nix on MacOs has mostly just been incredibly frustrating. I started using nix one or two weeks ago, because I needed it for a project with haskell-miso (which I very much like, by the way).
As long as I just stuck to using the default.nix provided by Miso, everything worked fine, more or less, but as soon as I tried to go beyond that to customize things for the needs of my own project, the problems started to accumulate.
I needed to google for and apply manual fixes for some very basic things, because nix did not play well with neither macOS Catalina (nix needs access to /nix) nor with fish.
Some haskell packages I need like constructible were broken in the default channel and I had no idea how to fix those packages. In the end I ended up switching to a “stable” version. I do not understand why nixpgs-unstable is the default channel, by the way.
Sometimes things seem easy in some guides and I thought I understood them, but then when I tried them they just won’t work. For example I was hoping that
nix-shell -p 'haskell.packages.ghcjs.ghcWithPackages (pkgs: with pkgs; [ miso ])’
I tried following guides and didn’t try to do anything especially crazy, but somehow I ended up fucking up my haskell build environment so much, that I couldn’t do anything Haskell-related anymore. Still don’t how I managed to do that.
I tried rolling things back through
nix-env -G 1
When I was 15 years younger I really enjoyed playing around with the configuration of my computer, trying different window managers and editors etc., but nowadays I have work I care about and limited time and I want my computer to just work and not get in the way. Nix really, really got in the way. It’s been incredibly frustrating the last few days, when I wanted to work on my project, but spent several days fighting with nix instead.
Sorry for the rant, again, I very much like the project and I really hope it succeeds, I just wanted to share my own experience with it, as a beginner.
> The apparent learning curve for nix looks...steep.
How is that not a good thing? I enjoy nothing more than learning a lot in a short amount of time.
How is that not a good thing? I enjoy nothing more than learning a lot in a short amount of time.
I really dislike Nix/NixOS, but I think it's kind of unreasonable to claim something is unappealing because of a learning curve. Pretty much everything on the planet has a learning curve; if a project is genuinely innovative or aiming for a paradigm shift, and you find the benefits of it worthwhile, there's probably always going to be a learning curve.
That said, are we really reading the same post? What's presented here is...really simple, and you should be pretty much familiar with most of it if you actually set up Gentoo and Arch in the past; pretty much everything directly translates that requires user interaction in this, and the package format is pretty similar to write & read, too.
That said, are we really reading the same post? What's presented here is...really simple, and you should be pretty much familiar with most of it if you actually set up Gentoo and Arch in the past; pretty much everything directly translates that requires user interaction in this, and the package format is pretty similar to write & read, too.
> it's kind of unreasonable to claim something is unappealing because of a learning curve.
It's not unreasonable at all. It all depends who is claiming that. Consider Mac OS and compare it to any Linux in terms of the learning curve. Can my mother say that Linux is unappealing because it's to hard to learn it? Of course.
Even among engineers there are people to prefer just getting the stuff done without spending hours or weeks on configuring their environment (even if it could pay off).
It's not unreasonable at all. It all depends who is claiming that. Consider Mac OS and compare it to any Linux in terms of the learning curve. Can my mother say that Linux is unappealing because it's to hard to learn it? Of course.
Even among engineers there are people to prefer just getting the stuff done without spending hours or weeks on configuring their environment (even if it could pay off).
Like game developers, graphical developers, app developers, actually anyone selling desktop and mobile OS software.
The domain still waiting for Desktop Linux to happen.
The domain still waiting for Desktop Linux to happen.
The appealing features of whatever it is are still appealing despite the learning curve. To highlight what I object to, because I feel I may have come across ambiguously:
Not much about all this setup feels appealing.
The good features about, say, OS X, are not made less appealing because of the rest of OS X. They're still appealing properties.
Not much about all this setup feels appealing.
The good features about, say, OS X, are not made less appealing because of the rest of OS X. They're still appealing properties.
I think you're missing a variable: point of view.
Give positive points to any feature you find appealing.
Give negative points to any feature you find unappealing.
If you have the person you're speaking to go through the same process, you might find you've assigned points differently. And the net sum might be closer to zero for them. That's what makes going through the entire process unappealing for them.
If you have the person you're speaking to go through the same process, you might find you've assigned points differently. And the net sum might be closer to zero for them. That's what makes going through the entire process unappealing for them.
I'm not missing that variable; the comment you're replying to was explicitly written to try and clear up that I was not missing that variable.
> I really dislike Nix/NixOS
I'm honestly curious why you dislike it
I'm honestly curious why you dislike it
In order from most to least, all concerns but some that I'm usually happy overlooking:
* Poorly-implemented versions of theoretically-interesting ideas
* Poor implementations, technically
* Lacking merit compared to its best competitor (insofar as free software has competitors)
* Lacking merit compared to its main competitor
* Deep philosophical and moral disagreements
* Toxic and obnoxious community
This isn't to say it's bad, of course. It's just something I dislike; I seek no wider war.
* Poorly-implemented versions of theoretically-interesting ideas
* Poor implementations, technically
* Lacking merit compared to its best competitor (insofar as free software has competitors)
* Lacking merit compared to its main competitor
* Deep philosophical and moral disagreements
* Toxic and obnoxious community
This isn't to say it's bad, of course. It's just something I dislike; I seek no wider war.
That doesn't really answer much, can you be more specific?
Why is it poorly implemented, what are the problems?
Who is the competitor, and why is it better? (Guix?)
What are the philosophical issues?
How is the community toxic and obnoxius?
Personally there are a few things that annoy me about Nix, mostly implementation and documentation wise. Also, the language is pretty odd and the CLI UX is somewhat messy.
But the community (IRC / Discourse) has been pretty helpful for me thus far.
Why is it poorly implemented, what are the problems?
Who is the competitor, and why is it better? (Guix?)
What are the philosophical issues?
How is the community toxic and obnoxius?
Personally there are a few things that annoy me about Nix, mostly implementation and documentation wise. Also, the language is pretty odd and the CLI UX is somewhat messy.
But the community (IRC / Discourse) has been pretty helpful for me thus far.
I'd prefer not to be more specific, actually; at least on most points. Complaining about popular new things in threads about them is a trend I find irritating, and using a thread about how someone finds something cool to give reasoning as to why it's distasteful is completely off-topic and kind of rude, anyhow.
However, I will note that I listed two competitors, not one, and while I think both have more merit, I only think the best is worth using out of all three. I'll point out that it's not Guix, and that it's older than Nix, but I don't think advertising alternatives is a particularly nice thing to do in a thread about any given piece of free software.
However, I will note that I listed two competitors, not one, and while I think both have more merit, I only think the best is worth using out of all three. I'll point out that it's not Guix, and that it's older than Nix, but I don't think advertising alternatives is a particularly nice thing to do in a thread about any given piece of free software.
>Complaining about popular new things in threads about them is a trend I find irritating
It's a little too late for that. Complaining in a vague way across several comments and then not elaborating further is, I think, definitely more rude than making some concrete complaint (like the original comment's complaint about learning something new)
It's a little too late for that. Complaining in a vague way across several comments and then not elaborating further is, I think, definitely more rude than making some concrete complaint (like the original comment's complaint about learning something new)
I didn't complain, and I didn't even criticize it in "several" comments; the only comment with anything resembling criticism is the second one I wrote, and it's just a single comment!
I said I didn't like something as a way of making it clear that I'm not trying to brigade for Nix and don't really have any incentive to defend it, and I gave an argument on why I believe the initial comment was being unfairly negative to Nix.
I was then asked why I disliked Nix. I made no complaints, I just listed my opinions. When I was asked to go into actual complaints implying fact rather than personal opinions, I said I'd prefer not to.
I said I didn't like something as a way of making it clear that I'm not trying to brigade for Nix and don't really have any incentive to defend it, and I gave an argument on why I believe the initial comment was being unfairly negative to Nix.
I was then asked why I disliked Nix. I made no complaints, I just listed my opinions. When I was asked to go into actual complaints implying fact rather than personal opinions, I said I'd prefer not to.
In my opinion, you probably don't have good reasons.
> I don't think advertising alternatives is a particularly nice thing to do in a thread about any given piece of free software
I don't think throwing unsubstantiated claims around is a particularly nice thing to do. I don't mind you having these opinions. But if you're not ready to properly argue them, it's probably better to just abstain from the discussion entirely. That's how I handle my own opinions as well.
I don't think throwing unsubstantiated claims around is a particularly nice thing to do. I don't mind you having these opinions. But if you're not ready to properly argue them, it's probably better to just abstain from the discussion entirely. That's how I handle my own opinions as well.
I was asked why I dislike something. I answered. "Unsubstantiated" is a really weird thing to use in the context of opinion. An unsubstantiated claim exclusively applies to fact, while I was very clearly giving my opinion. None of the things listed can be objectively measured.
I'd be perfectly happy to argue for them, but I don't think this is the right place to do it. Frankly, I don't care about how you handle your own opinions. When I am asked about my own, I'll tell them. I won't try and sell them as factual to anyone else, though, which is what going into more detail would require me doing in this particular instance.
I'd be perfectly happy to argue for them, but I don't think this is the right place to do it. Frankly, I don't care about how you handle your own opinions. When I am asked about my own, I'll tell them. I won't try and sell them as factual to anyone else, though, which is what going into more detail would require me doing in this particular instance.
Fair enough, although I don't see how mentioning the names of competitors and giving well-reasoned comparison is somehow worse than calling a project "poorly implemented", "lacking merit", and having a "toxic and obnoxious community" without providing any verifiable arguments.
All three of those can be easily written off by anyone who likes the project. Claim that 4chan is toxic; people who like 4chan will think you're an idiot, but it won't really ruin their mood. Point out specific examples of their favorite board criticizing something they love, however, and they probably will feel upset for one reason or another.
But in a public forum such as this, calling a community toxic can, and will, keep people from looking in to to the associated project any further. If you have specifics, you should say them - public spaces are the right place to out toxic communities. But, people on the internet throwing around words like "toxic" without substantiation can be really damaging to communities by preventing growth.
Please substantiate - I'm not involved in the Nix community much but whenever I've been in the #nixos IRC channel, they've been super helpful.
Please substantiate - I'm not involved in the Nix community much but whenever I've been in the #nixos IRC channel, they've been super helpful.
What's the third competitor? There is no reason to be so evasive in a technical discussion.
It wouldn't be a technical discussion any more than a Solaris vs. Linux flamewar is a technical discussion, in my opinion.
Could you at least, at some point, when the comments have died down, share what this third alternative is? I'm really very curious - everyone replying to you is.
- It can't be GoboLinux, because that post-dates Nix (by a small amount)
- I've never heard anyone suggest environment modules have more technical merit than Nix, though they do predate Nix
- Could it be portage, which has some of the same features as Nix? Nix explicitly cited portage as a predecessor, and IMO it surpasses it, so that would be surprising...
I really don't know anything other than Nix or Guix that follows Nix's philosophy. I'm really interested to know what you're referring to!
- It can't be GoboLinux, because that post-dates Nix (by a small amount)
- I've never heard anyone suggest environment modules have more technical merit than Nix, though they do predate Nix
- Could it be portage, which has some of the same features as Nix? Nix explicitly cited portage as a predecessor, and IMO it surpasses it, so that would be surprising...
I really don't know anything other than Nix or Guix that follows Nix's philosophy. I'm really interested to know what you're referring to!
You're being unnecessarily cryptic.
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...
And this just doesn't sit well with me: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
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...
And this just doesn't sit well with me: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
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.)
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.)
There also is a NixOS derivative OS project "aimed squarely at security" https://spectrum-os.org/
As a user of NixOS I have not been bitten by any such hacks.
As a contributor to NixOS, I have barely noticed this. That said, I mostly apply contributions to applications, not to toolchains.
As a contributor to NixOS, I have barely noticed this. That said, I mostly apply contributions to applications, not to toolchains.
That is definitely unfortunate, but Nix is such an obvious improvement on the standard Unix way of "Just mix all the files into one big /usr soup" that it seems silly to not do it because some programs need a bit of hackery to get them to work.
Hopefully one day Nix's approach will be popular enough that GCC or Clang will be changed so that the hacks aren't needed.
Hopefully one day Nix's approach will be popular enough that GCC or Clang will be changed so that the hacks aren't needed.
Having just learned about Nix a few weeks ago, and after an (admittedly cursory) glance at the language and documentation, my main intuition for why it hasn’t been adopted is that it could be more standard. For example why not use an established language instead of creating one from scratch? The syntax and features of the language look similar to Nim for instance. The benefits would be network effect as well as developer tooling support for newcomers.
I don't really understand the criticisms of Nix being non-standard or a hard to grasp language. The language is basically JSON with semicolons, scoping and lambda functions. It has a really minimal syntax and few built-in functions, it's untyped and comes with no complex concepts like typeclasses, exceptions, monads, etc.
Replacing it with a general-purpose language is almost guaranteed to increase the cognitive load required to write a simple package or configure NixOS. This complain sounds a lot like "Why didn't you pick <my language>, which I already know?", to me. Nim, besides being newer than Nix (~2003), has support for metaprogramming, parellism features, OOP... which is all nice but it's far too much for a language intended for writing packages and configuration.
I agree that the documentation is a major problem when learning Nix/NixOS but the situation is improving. My recommendation is to start by reading the Nix pills[1], which are a great introduction to Nix but also develop into a detailed explanation of the inner machineries of Nix and Nixpkgs.
[1]: https://nixos.org/nixos/nix-pills/index.html
Replacing it with a general-purpose language is almost guaranteed to increase the cognitive load required to write a simple package or configure NixOS. This complain sounds a lot like "Why didn't you pick <my language>, which I already know?", to me. Nim, besides being newer than Nix (~2003), has support for metaprogramming, parellism features, OOP... which is all nice but it's far too much for a language intended for writing packages and configuration.
I agree that the documentation is a major problem when learning Nix/NixOS but the situation is improving. My recommendation is to start by reading the Nix pills[1], which are a great introduction to Nix but also develop into a detailed explanation of the inner machineries of Nix and Nixpkgs.
[1]: https://nixos.org/nixos/nix-pills/index.html
Agree Nix is actually very simple language and it being purely functional and lazily evaluated is what makes Nix packaging so powerful, these properties are actively utilized.
I think what the problem is is not the Nix language but its stdlib - nixpkgs. It is rapidly changing (as they figure out better ways of doing things) often breaks backward compatibility (for example not long ago they removed fetchGitPrivate and the built-in is not a drop in replacement), large parts of it aren't well documented, or even not at all (people often add great features, but forget to update manual and it still gets merged).
Initially this was the hardest part for me about Nix, and I guess it still is, but once I understood the structure of nixpkgs it no longer takes effort to find what I'm looking for (unfortunately many times I still have to look at the code, but now I can find it easily).
The thing is that this problem wouldn't been solved with different language like scheme or even Python. The language won't help much with learning the structure of nixpkgs and the conventions used. While Nix Pills cover some parts of it, there's so much more it could talk about.
BTW for those who are struggling with this. There is also very useful command to immediately find the derivation: nix edit <derivation> which should be emphasized more.
I think what the problem is is not the Nix language but its stdlib - nixpkgs. It is rapidly changing (as they figure out better ways of doing things) often breaks backward compatibility (for example not long ago they removed fetchGitPrivate and the built-in is not a drop in replacement), large parts of it aren't well documented, or even not at all (people often add great features, but forget to update manual and it still gets merged).
Initially this was the hardest part for me about Nix, and I guess it still is, but once I understood the structure of nixpkgs it no longer takes effort to find what I'm looking for (unfortunately many times I still have to look at the code, but now I can find it easily).
The thing is that this problem wouldn't been solved with different language like scheme or even Python. The language won't help much with learning the structure of nixpkgs and the conventions used. While Nix Pills cover some parts of it, there's so much more it could talk about.
BTW for those who are struggling with this. There is also very useful command to immediately find the derivation: nix edit <derivation> which should be emphasized more.
I agree Nix being new/odd is a barrier, and that NixOS be more popular if the language was more popular.
Guix System partly answers this by using Scheme, but ultimately Scheme is unpopular too.
A NixOS built on a no-side-effects JS/Python (e.g. Skylark, used in Bazel) would be possible.
The build output, a derivation, is just a data type (~ JSON object), and so interoperability between NixOS and something else is possible.
Guix System partly answers this by using Scheme, but ultimately Scheme is unpopular too.
A NixOS built on a no-side-effects JS/Python (e.g. Skylark, used in Bazel) would be possible.
The build output, a derivation, is just a data type (~ JSON object), and so interoperability between NixOS and something else is possible.
Guix has partly answered that question. Scheme (Guile) is used for nearly everything - package recipes, build instructions, service configuration, OS configuration, etc.
I guess the reason is that part of the benefits come from being a (largely) pure functional language. The property that an expression must always evaluate to the same value does wonders to reproducibility.
I agree that adoption would probably be larger if the language was not Nix or Scheme (Guix).
I agree that adoption would probably be larger if the language was not Nix or Scheme (Guix).
> But unfortunately *nix programs are not written to support this, so you see lots of hacks in Nix to get things to work.
You might have said the same thing about the Reproducible Builds project [1] early on. It was a project inside Debian, that required a modified toolchain (gcc, autotools, etc.) on top of Debian Unstable; and many individual Debian packages needed patches as well.
Years later, these toolchain changes are now merged not only in main Debian, but also in other distributions and in upstream software.
[1] https://reproducible-builds.org/
You might have said the same thing about the Reproducible Builds project [1] early on. It was a project inside Debian, that required a modified toolchain (gcc, autotools, etc.) on top of Debian Unstable; and many individual Debian packages needed patches as well.
Years later, these toolchain changes are now merged not only in main Debian, but also in other distributions and in upstream software.
[1] https://reproducible-builds.org/
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.
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?
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.
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.
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.
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.
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).
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).
Doesn't "source no longer available only concerns projects that have migrated to a nonfree license?
This is a problem on F-droid, as the app you're installing will not get updates, and are out-of-sync with upstream. I was pretty sure F-droid archived the source tarball, but i can't find it now.
Disappearing sources are also an issue, as it has every disadvantage proprietary software has, with none of the upsides. It's much harder to patch in case it is needed, for instance. And hard to tell if someone tampered with the binary archives, I guess? (IIRC, the hash in Nix is based on the configuration, not the resulting binary).
This is a problem on F-droid, as the app you're installing will not get updates, and are out-of-sync with upstream. I was pretty sure F-droid archived the source tarball, but i can't find it now.
Disappearing sources are also an issue, as it has every disadvantage proprietary software has, with none of the upsides. It's much harder to patch in case it is needed, for instance. And hard to tell if someone tampered with the binary archives, I guess? (IIRC, the hash in Nix is based on the configuration, not the resulting binary).
> but with no matching source packages that I could find.
This is also something that bothers me. Even Gentoo (!) gives up on building some applications and just redistributes upstream binaries (eg. Cassandra or Kafka), because it's too hard to actually build them.
I mentioned this on the #nixos IRC channel, and they seem open to having a configuration variable to disable packages not built from source (like they currently do for non-free licenses [1]), there is just no one currently working on it.
[1] https://nixos.org/nixpkgs/manual/#sec-allow-unfree
> but really haven't considered to how to deal with the "disapearing sources" problem, including vanishing git repositories
Guix does [2], and Nix is working on it in a similar way.
[2] https://guix.gnu.org/blog/2019/connecting-reproducible-deplo...
This is also something that bothers me. Even Gentoo (!) gives up on building some applications and just redistributes upstream binaries (eg. Cassandra or Kafka), because it's too hard to actually build them.
I mentioned this on the #nixos IRC channel, and they seem open to having a configuration variable to disable packages not built from source (like they currently do for non-free licenses [1]), there is just no one currently working on it.
[1] https://nixos.org/nixpkgs/manual/#sec-allow-unfree
> but really haven't considered to how to deal with the "disapearing sources" problem, including vanishing git repositories
Guix does [2], and Nix is working on it in a similar way.
[2] https://guix.gnu.org/blog/2019/connecting-reproducible-deplo...
For free software proponents there is GuixSD
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...
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...
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.
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.
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.
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
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.
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.
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.
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.
> I really think NixOS and GuixSD are the next generation Linux distributions and want to use it.
I was in a similar boat for a long time and finally started dipping my toes in. FWIW, #guix on freenode is one of the best experiences I've had with friendly online communitities. The channel is fully of friendly and knowledgeable people.
The `info` docs for guix are also pretty darn good for getting you up to speed; however, if you start wanting you write your own packages, I've found that you really do need to consult the sources.
FWIW, I got a Guix System running as a Google Cloud instance. As far as I am aware, it's the first time this has been done. Feel free to email me if you want some details; I don't mind helping you set up an instance for you to play around with.
I was in a similar boat for a long time and finally started dipping my toes in. FWIW, #guix on freenode is one of the best experiences I've had with friendly online communitities. The channel is fully of friendly and knowledgeable people.
The `info` docs for guix are also pretty darn good for getting you up to speed; however, if you start wanting you write your own packages, I've found that you really do need to consult the sources.
FWIW, I got a Guix System running as a Google Cloud instance. As far as I am aware, it's the first time this has been done. Feel free to email me if you want some details; I don't mind helping you set up an instance for you to play around with.
Maybe try Guix because there is a wealth of documentation out there for scheme. Since it's a real language you can also consider it an investment as it will make you a better programmer.
Yes, I read about that, but free software is always a bit of a struggle.
I suggest either using Nonguix [1], or installing Guix on top of Debian or any other binary distribution if the free software part or small ecosystem is going to prevent you from trying a very great piece of software.
[1] https://gitlab.com/nonguix/nonguix
[1] https://gitlab.com/nonguix/nonguix
> 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.
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.
Sure, but a small CLI tool that adds and removes packages in these files would probably go a long way.
> 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?
Yep, that happened, at least somewhat. Most things that you would want to do that used to be argument soup with `nix-env` now uses a program just called `nix`. For example, searching is now just `nix search <query>` instead of whatever the `nix-env` incantation was
Yep, that happened, at least somewhat. Most things that you would want to do that used to be argument soup with `nix-env` now uses a program just called `nix`. For example, searching is now just `nix search <query>` instead of whatever the `nix-env` incantation was
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... [2]: https://github.com/coord-e/magicpak
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... [2]: https://github.com/coord-e/magicpak
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
And here is an article about the hoops needed to run Steam games: https://nixos.wiki/wiki/Steam
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
And here is an article about the hoops needed to run Steam games: https://nixos.wiki/wiki/Steam
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`.
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`.
That's how it works normally, but once you get to the point of having the system configured declaratively, people strive for more.
The home-manager as far as I know is not official component, but a lot of people add it because they love the idea.
I think anyone who is interested in Nix should start with Nix Pills[1] they are concentrating on just nix and nixpkgs, but I think it is minimum getting started. Once you are familiar how to build nix derivations, adding custom components is not that hard.
[1] https://nixos.org/nixos/nix-pills/index.html
The home-manager as far as I know is not official component, but a lot of people add it because they love the idea.
I think anyone who is interested in Nix should start with Nix Pills[1] they are concentrating on just nix and nixpkgs, but I think it is minimum getting started. Once you are familiar how to build nix derivations, adding custom components is not that hard.
[1] https://nixos.org/nixos/nix-pills/index.html
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!
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!
Author of the article here. Ask me anything!
Can you share the list of hardware you choose to build your tower?
Something like this: https://ca.pcpartpicker.com/list/9jgTq3
The SATA SSD is for Windows.
The SATA SSD is for Windows.
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.
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.
Simply to compare the author list to mine and check for compatibility issue if needed. Ryzen 3000 series CPUs are known to have issues with systemd while booting ( which affect nixos https://github.com/NixOS/nixpkgs/issues/64443). And the fact that it works for the author helps me deciding that 3700x suits my needs and budget without worrying that i will need to use old versions of NixOS.
Also the suggestions that you gave are valid, but that doesn't mean I will go with them because as you said I'm doing my own research. For example I will stick with the stock cooler because it got good reviews and my budget won't allow another cooler for now.
Running my computer at full blast (GPU+CPU), the loudest thing in the room is the death metal from Doom Eternal.
Some people use their computer for more than trivial things like video games.
Do you have an axe to grind against the blog’s author?
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.
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.
I use my tower for programming too, Doom Eternal is the fastest way I have to getting full load on the system though.
That's strange considering most games do not put a full load on your system, especially not the CPU. Doom Eternal, in particular, has both low GPU and CPU usage. So I'm having trouble seeing how you got your full load. How did you measure? MSI Afterburner + Riva Statistics Server for OSD is good for this.
BTW: Death metal is a particular genre, and Doom's soundtrack is not it. This crap is death metal: https://youtu.be/482tDopNzoc?t=69
BTW: Death metal is a particular genre, and Doom's soundtrack is not it. This crap is death metal: https://youtu.be/482tDopNzoc?t=69
> 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.
Assuming the 2013 Mac Pro came out in 2013 I'd say that's at most 7 years.
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.
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.
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
Also great post and great blog <3
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
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.
Same for the script parameters. I have absolutely no idea what this does
{ pkgs ? import <nixpkgs> { } }:
function main(pkgs: Package = nixpkgs) {
}
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.
> 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 you also don't need to!
NixOS has a module system, with override/priority mechanics; so your GUI tool could just generate its own Nix file with its own settings, totally ignoring the system-wide settings, and then all you need to do is apply that generated configuration file in your imports; the module priority system does the rest.
But you also don't need to!
NixOS has a module system, with override/priority mechanics; so your GUI tool could just generate its own Nix file with its own settings, totally ignoring the system-wide settings, and then all you need to do is apply that generated configuration file in your imports; the module priority system does the rest.
> 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.
I don't disagree with the overall argument you are making however on this point alone, they aren't meant to be machine-editable. They are functions, they take arguments. So you can make your module or system configuration or whatever, have unassigned variables and then have your function take them as parameters. Your GUI can invoke this function with arguments from the user input.
I don't disagree with the overall argument you are making however on this point alone, they aren't meant to be machine-editable. They are functions, they take arguments. So you can make your module or system configuration or whatever, have unassigned variables and then have your function take them as parameters. Your GUI can invoke this function with arguments from the user input.
I had a similar feeling for the language and I can assure you you do get used to it, and that it's probably not the syntax that's making it difficult but understanding the programming model.
As for not being machine-editable, the nix language has a module system and it's easy to format a file with something that's whatever shape you want and have that machine-editable. Or use any other format and fromJSON etc. functions.
As for not being machine-editable, the nix language has a module system and it's easy to format a file with something that's whatever shape you want and have that machine-editable. Or use any other format and fromJSON etc. functions.
Would be more like
function main(pkgs: Map String Package = (import(sys.path("nixpkgs"))({}))){ }
I'm not sure if it's better at this point...
function main(pkgs: Map String Package = (import(sys.path("nixpkgs"))({}))){ }
I'm not sure if it's better at this point...
Except not everything in nixpkgs is a package! It's closer to a standard library that just happens to include a lot of packages.
In fact, a derivation is not even a type. AFAIK it is only informally defined as an attribute set with an attribute type with the value derivation:
https://github.com/NixOS/nixpkgs/blob/2cd8c35c1fdfdb773df7ec...
I am pretty sure that instantiating a derivation probably requires more attributes. But in the end they are just attribute sets (which is one of the types in Nix besides strings, lists, etc.).
https://github.com/NixOS/nixpkgs/blob/2cd8c35c1fdfdb773df7ec...
I am pretty sure that instantiating a derivation probably requires more attributes. But in the end they are just attribute sets (which is one of the types in Nix besides strings, lists, etc.).
The Nix language is much, much simpler than anything C-like or Python-like. It's basically just JSON with some support for variables and recursion.
It being so simple is why the whole system works.
It being so simple is why the whole system works.
I'd argue that Nix is turing-incomplete. I've also been working on some tools that use Nix AST parsers to replace details like version numbers and hashes of git repos inside of existing .nix files. No fruit yet, but I'm still in the early planning phase.
I'd argue that Nix is turing-incomplete.
What do you mean by this? Nix is a Turing-complete language.
What do you mean by this? Nix is a Turing-complete language.
Nix itself prevents a lot of generalized recursion and side effects. If I recall turing-completeness in functional languages requires generalized recursion in ways Nix doesn't allow.
Nix does allow general recursion, no? I haven’t seen any limitations that would prevent it from Turing completeness.
I really want to try NixOS but the Nix language is just so damn weird...
It's not really weird when you know a functional language like Haskell or OCaml. My experience was actually the opposite: being a functional language, Nix's syntax was so simple that it took me only a few minutes to grasp most of it.
But if you don't have some FP experience under your belt, both the syntax and commonly-used concepts are strange (e.g. fixed points).
For me the learning curve was knowing what extra functions/functionality is provided by nixpkgs, which lacks quite a lot of documentation and discoverability. I found out about a lot of handy functions and techniques while reading derivations.
I should have kept track of the issues while I was learning Nix/nixpkgs. But at that point I was still determining "do I want this?"
It's not really weird when you know a functional language like Haskell or OCaml. My experience was actually the opposite: being a functional language, Nix's syntax was so simple that it took me only a few minutes to grasp most of it.
But if you don't have some FP experience under your belt, both the syntax and commonly-used concepts are strange (e.g. fixed points).
For me the learning curve was knowing what extra functions/functionality is provided by nixpkgs, which lacks quite a lot of documentation and discoverability. I found out about a lot of handy functions and techniques while reading derivations.
I should have kept track of the issues while I was learning Nix/nixpkgs. But at that point I was still determining "do I want this?"
Guix also uses a functional language and it was much easier to grasp for me.
> 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.
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.
Great, but you're making the OP's point:
> the Nix language is just so damn weird... Why didn't they use a [familiar] syntax ...
You wouldn't have to parse data from some other representation if Nix lang was less weird, eh?
> the Nix language is just so damn weird... Why didn't they use a [familiar] syntax ...
You wouldn't have to parse data from some other representation if Nix lang was less weird, eh?
I agree with OP's first point that Nix language being new may hurt its success.
I was replying to OP's second point about Nix language not being machine-editable.
Even if Nix was written in Python rather than Nix language, it still wouldn't be machine editable.
The solution in both cases is to use a simple format that is machine editable, e.g. JSON.
I was replying to OP's second point about Nix language not being machine-editable.
Even if Nix was written in Python rather than Nix language, it still wouldn't be machine editable.
The solution in both cases is to use a simple format that is machine editable, e.g. JSON.
Do you have a more detailed example of this?
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:
The implementation of "backup" is private, but reuses parts of upstream NixOS (systemd.timer, Prometheus, ...)
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;
};
};
}
The implementation of "backup" is private, but reuses parts of upstream NixOS (systemd.timer, Prometheus, ...)
I assume they're talking about the same process you can use to pin nixpkgs. Have a nixpkgs.json with contents like these
{
"url": "https://github.com/nixos/nixpkgs-channels.git",
"rev": "ea553d8c67c6a718448da50826ff5b6916dc9c59",
"date": "2020-02-02T15:39:15+01:00",
"sha256": "0g9smv36sk42rfyzi8wyq2wl11c5l0qaldij1zjdj60s57cl3wgj",
"fetchSubmodules": false
}
let
bootstrap = import <nixpkgs> { };
nixpkgs-pin = builtins.fromJSON (builtins.readFile ./nixpkgs.json);
nixpkgs = bootstrap.fetchFromGitHub {
owner = "NixOS";
repo = "nixpkgs";
inherit (nixpkgs-pin) rev sha256;
};
in
import nixpkgsDoes 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.
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).
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).
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.
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.
Ansible could theoretically be made to work with NixOS by having it manipulate the /etc/nixos/configuration.nix instead of touching files and starting services directly. But you're still going to run into so many incompatibilities between NixOS and other Linuxes (esp. because of the different filesystem layout) that it's probably not a path worth pursuing. It's always a recipe for disaster to have two configuration management systems competing for power on one system, and NixOS very much is a configuration management system.
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.
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!)
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!)
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.
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,
> * 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,
First paragraph talks about build. The build by default happens in sandbox, with many things disabled to force reproducibility. It sometimes makes things annoying, for example there was one Ruby package that was downloading a file during build, so whomever was making a derivation needed to download it in advance)
The second paragraph talks about fetching sources which nix does before build starts, each source is required to be provided with hash, this ensures that it is an identical file that author of the derivation used.
The second paragraph talks about fetching sources which nix does before build starts, each source is required to be provided with hash, this ensures that it is an identical file that author of the derivation used.
The idea is that as long as the downloaded source file matches the hash all inputs are deterministic and so is the build overall.
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.
Nice layout. A fundamental reengagement with the concept of "formatted hypertext".
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/ (The contents of this page is intended for the other students at my college and probably doesn't make a lot of sense standalone)
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/ (The contents of this page is intended for the other students at my college and probably doesn't make a lot of sense standalone)
Noah, I love that menu. Nice work!
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.
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.
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
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
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.
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.
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!
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!
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?
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?
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) but that won't cover ca-certificates generically.
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) but that won't cover ca-certificates generically.
The default nixpkgs channel has over 40,000 packages. I've found NixOS compares pretty well with other Linux distributions in that regard.
https://github.com/NixOS/nixpkgs
https://github.com/NixOS/nixpkgs
In fact, Nixpkgs is only second to Arch in quantity of packages. There was a period where Nixpkgs had more than Arch, even.
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.
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.
Yeah, UX matters, but reliability and robustness are part of UX, too.
I've had innocuous-seeming brew commands foul up my working environment. I don't think Nix would do that in the same way.
Specifically, updating a package in Homebrew can have unexpected knock-on effects due to updating dependencies. Left my working environment badly hosed at one point last year.
Nix's design should ensure that all such updates leave everything else stable, as I understand it.
I've been tempted to try it or Guix for years - I was delighted when I discovered Nix existed.
I'd been thinking about the problems with existing package managers for years, and both Nix and Guix have most of what I felt was missing from the existing tools, along with some other really cool attributes I hadn't thought of at all.
I've had innocuous-seeming brew commands foul up my working environment. I don't think Nix would do that in the same way.
Specifically, updating a package in Homebrew can have unexpected knock-on effects due to updating dependencies. Left my working environment badly hosed at one point last year.
Nix's design should ensure that all such updates leave everything else stable, as I understand it.
I've been tempted to try it or Guix for years - I was delighted when I discovered Nix existed.
I'd been thinking about the problems with existing package managers for years, and both Nix and Guix have most of what I felt was missing from the existing tools, along with some other really cool attributes I hadn't thought of at all.
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.
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.
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.
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.
Oh and you can of course use "man" to read the manual pages for most apt programs if you want more in-depth info.
How is brew different from apt or dnf?
ergonomics oversight:
/nix/store/c99n4ixraigf4jb0jfjxbkzicd79scpj-gruvbox-css.drv
should be
/nix/store/gruvbox-css-c99n4ixraigf4jb0jfjxbkzicd79scpj.drv
/nix/store/c99n4ixraigf4jb0jfjxbkzicd79scpj-gruvbox-css.drv
should be
/nix/store/gruvbox-css-c99n4ixraigf4jb0jfjxbkzicd79scpj.drv
They actually answer that in FAQ: https://nixos.wiki/wiki/FAQ
$ 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)!
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
That video is two years old, and the comments make it clear that dude didn't RTFM, so... YMMV.
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/
[1] https://repology.org/graph/map_repo_size_fresh.svg
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/
[1] https://repology.org/graph/map_repo_size_fresh.svg
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.