NixOS 18.03 Released
nixos.org
nixos.org
let
defaultPkgs = import <nixpkgs> {};
defaultRust = defaultPkgs.latest.rustChannels.nightly.rust;
defaultCargo = defaultPkgs.latest.rustChannels.nightly.cargo;
defaultBuildRustPackage = defaultPkgs.callPackage (import <nixpkgs/pkgs/build-support/rust>) {
rust = {
rustc = defaultRust;
cargo = defaultCargo;
};
};
in
{ pkgs ? defaultPkgs, rust ? defaultRust, buildRustPackage ? defaultBuildRustPackage }:
pkgs.callPackage ./derivation.nix {
inherit rust buildRustPackage;
}1 - https://nixos.org/nixos/manual/index.html#sec-installation
Wow, you are not kidding.
Edit: I could swear this comment was originally replying to someone.
Knowledge is great, but ignorance is bliss, I suppose :P
People really should know just a little bit about stuff they use every day.
Maybe the other developers disagree, but there are already plenty of Linux distributions that try extremely hard to be friendly and gentle, and remove needless technicalities -- and they even make it simple for developers! They could satisfy you or someone else! The developers put a lot of work into them, and that's really fantastic. But we'll probably never beat them at this; our design is a big enough departure from the traditional that it's very difficult to make it transparent. We're better off playing to our own strengths, IMO, rather than trying to polish off every single rough edge for ever user, to do something Linux distros with 10x the users and money, already offer, but better.
It's pretty understandable a lot of people would not like this trade off. I, personally, think NixOS is personally the best Linux distribution there is, of course -- but it's understandable why people would not like it, or these design choices. At all. I don't think I waste as much time as you might expect learning about Linux, but I do spend time doing things you probably wouldn't ever enjoy (like fixing upstream packages...)
-----
All of this said, we really should have a graphical installer. I'd love one. :) I'm just saying even if we fixed that, it's probably going to be the least of your issues in the long run, more or less... The installer is the tip of the iceberg.
1. Copy the ISO onto a USB drive and boot your laptop on it
2. Run `systemctl start display-manager` to start the GUI
3. Format the harddrive however you like using GParted
3b. EDIT: and mount the root drive to /mnt
4. Run `nixos-generate-config --root /mnt` to detect the hardware layout and generate an initial configuration.nix file
5. Open the /mnt/etc/nixos/configuration.nix file with your editor and edit to your convenience
6. Run `nixos-install`
7. Reboot
I wish there were more tips for debugging UEFIon their guide.
I left Nix hoping that in a few years it would be far friendlier. It really feels like the future.
My temporary fix for the latter is using a Docker with Arch for quick and dirty one-time things.
So basically the same problems as every other Linux distribution? Only AppImage doesn't work out of the box either.
The more things change the more they stay the same.
I need them to reproduce other papers so I cannot stay away, sadly.
I think a better FHS or Steam.Env would help me more.
Are you saying that NixOS allows packages to cheat? That seems like a serious flaw.
If there's one thing worse than a non-purely-functional system, then it must be a system that claims to be purely-functional but turns out to be non-functional.
Namely there is:
- Making the Nix store writable. Normally it's mounted read-only, and only the Nix daemon can write finished deterministic builds there. Often wanted by users who haven't learned how to handle Nix packages, as they just want to change some file in the store.
- Disabling the sandbox. Usually all builds are done in a sandbox which doesn't have network access, read access only to the Nix store and write access only to only the destination directory in the Nix store (with some exceptions), which gives strong reproducability guarantees.
nix-env -i firefox
I honestly wasn't aware there was a text file in the home directory but it sounds like something pretty close to the Installation Guide, which is helpful and good to know, so thanks for that.
Like Docker, but it uses install scripts instead of layered images.
Docker scripts that e.g. clone a remote and build from the HEAD are not reproducible. Another example would be downloading fancysoftware-latest.tgz
Nixos will have you either pull from a specific git commit, or will hash the sources, so the default behavior is reproducible.
In a nutshell, it's a purely functional Linux distribution. That means all changes you make to your system are non-destructive. For example, you can always roll back to a previous OS state, which is represented by a hash computed from all packages installed, and all options you've set. In turn, package hashes are computed from the package sources and all inputs (buildtime and runtime package dependencies).
It's also the most convenient system I ever worked with for creating custom packages, which is lucky, because NixOS does have fewer pages compared to other distributions.
It's not bad, though: https://repology.org/repository/nix_stable
Haskell and R packages will be added soon to give a more complete picture.
But as I said, it's all in all really nice to work with Nix.
Is Arch Build System one of the systems you've ever worked with? (I found ABS very convenient.)
(I already get that the design of NixOS prevents the system's ending up in an incoherent state, which will happen on Arch eventually if you wait long enough between upgrades.)
One of the nice things is that you can install many things without having to sudo - the build is run by a daemon and sandboxed. nix-shell can also be used to create a shell in which a given package set is installed - you can use that to use a piece of software as a one-off or create a development environment that doesn't pollute your general system. Tools like home-manager[0] can help with managing your home directory in a similar way to NixOS's management of your system, too - I have redis and postgres installed using home-manager to run as my own user on demand under systemctl.
My experience is mostly with deb and rpm before Nix.
So maybe the Arch maintainers got more disciplined, or maybe I just got better at not breaking things. Probably both.
- No separate AUR that some packages are arbitrarily located in
- Not having to care about binary packages: they are just transparently downloaded and used if available
Pacaur makes the AUR a bit more palatable, but you still notice the split.
I've been using NixOS more or less exclusively for ~2.5 years now. Whenever I want to run software on NixOS which is not already in Nixpkgs, I package it (if I want it bad enough). This week, for example, I packaged KSmoothDock so that I could try it out.
This is the whole thing:
{ mkDerivation, lib, fetchFromGitHub
, cmake, extra-cmake-modules
, plasma-framework, kwindowsystem }:
let
version = "5.9";
in
mkDerivation {
name = "ksmoothdock-${version}";
src = (fetchFromGitHub {
owner = "dangvd";
repo = "ksmoothdock";
rev = "v${version}";
sha256 = "1fbghyd079xk4q5na8msna5zkfg85c4ksyfqy524v2pm96dyl2dr";
} + "/src");
nativeBuildInputs = [
cmake
extra-cmake-modules
];
buildInputs = [
plasma-framework
kwindowsystem
];
postPatch = ''
substituteInPlace CMakeLists.txt \
--replace /usr/share/ share/
'';
}
Once you get a feel for the docs (and the Nixpkgs source, just because it's a treasure trove of examples), packaging for/with Nixpkgs is usually pretty easy, and the results pretty readable.
I should also add that the range of packages already included also seems to me to have improved a great deal over the years that I've been using NixOS. And I think once NixOS gains support for Snap packages and Flatpaks (the latter is in the works and has been making good progress recently), it will become a much more viable desktop OS for those unwilling or unable to deal with packaging the odd missing application.
But it's a great platform for fearless experimentation, because it's so easy to revert any change you later decide was undesired.
If something fails, you can always rollback to a previous revision, and since everything is there, you know your whole system will be working.
If you want to reproduce your system, you can copy the whole content and "checkout" the relevant revision on the new system. Because the hash is the same, every single bit underneath will be the same.
* It makes it trivial to have multiple versions of the same package installed at the same time and allows you to switch between them at will.
* It is trivial to roll back your system after a failed upgrade. Difficult system recovers after you upgrade to a new unstable version are a thing of the past.
* Non-privileged users can install software completely securely.
* Projects packaged with nix have the best possible build reproducibility because nix accounts for ALL of your dependencies all the way down to the lowest level system libraries, compilers, etc.
I have both nix and guix stores on my (voidlinux) system just trying them out. Package availability seems quite different between the two, and guix feels like it's heavier or slower, but I am biased to guix's shepard instead of systemd.
Initially, I really wanted to use Guix over Nix, but Nix is more mature with more packages, maintainers, and features.
Last I checked, for example, there was no equivalent of a channel or overlay in Guix. Their npm importer was also not released, whereas Nix has a very usable node2nix.
Having done virtually no functional programming, learning Guile Scheme was also a barrier to me, but the Nix expression language felt a lot more natural for whatever reason.
It's unfortunate - I'm very interested in the work in reproducible builds and substitutions Guix has done, maybe it'll take off at some point or those features will be integrated into NixOS.
As an end user you don't really need to know Scheme. The OS configuration and package definitions are very "DSL-like", but you do have the full power of Scheme available.
[0] https://www.gnu.org/software/guix/manual/guix.html#Package-M...
Contact me if you want to work with NixOS and K8s in Denmark/Copenhagen. Mail on profile page.
Please correct me if I'm Nix-ing wrong.
I would like to know if there is some common practice/standard around using '/usr/bin/env' in shebangs.
Could you please elaborate more?
That won't work everywhere either as the location of 'env' is not a fixed standard either. Eg. In some *nix's its at /bin/env.
I'm not 100% sure on all of these, but every one of the dozens of Linux distros I've used has `/usr/bin/env`. macOS has it, and it looks like FreeBSD does, too, and so does NetBSD.
Who are the oddballs? Does it include any of the free Unices?
There is also this function which may be necessary for certain software: https://nixos.org/nixpkgs/manual/#sec-fhs-environments
You can compile some software manually in place using, for example, `nix-shell -p libssh2 -p zlib` without having to write a derivation. However, without writing a derivation, it may cease to function after a garbage collection or an upgrade.
Writing a derivation isn't too bad, here's one for one of my repos: https://github.com/jbboehr/handlebars.c/blob/master/derivati...
The correct way to get almost anything installed is to write a Nix package, and install that. This is actually remarkably easy in comparison to other package managers - you write the package definition in a single file, normally just having to set the source code location and list its dependencies, and you can make it available to install with nix-env by adding it to a packageOverrides declaration in ~/.config/nixpkgs/config.nix.
The "stdenv" build system that nixpkgs uses will automatically install anything that can be configured via "./configure && make && make install" - cmake is supported just by listing that as a build dependency. Stuff written in scripting languages is more fiddly, but the nixpkgs documentation usually has examples. The downside is that a significant amount of the time, libraries written in scripting languages aren't packaged either, and you wind up packaging half a dozen libraries just to get some tool working. The <X>2nix tools can be useful in these cases to generate a package definition.
> The downside is that a significant amount of the time, libraries written in scripting languages aren't packaged either, and you wind up packaging half a dozen libraries just to get some tool working.
I've gone down this path a few times and days later when I still don't have the original thing I wanted working installed, then I sort of give up. I realize there are many benefits to Nix and I really enjoy them but I've switched to using Arch for practical reasons. I really, really miss the declarative reproducible style though.
I've used npm2nix and cargo2nix a couple of times with success - they generate package sets from the relevant sources.
I'm curious why not.
Aren't pip/cargo/whatever suitable for long-term use?
Consequently, couldn't nix's upgrading routines be modified to call out to pip/cargo/whatever to upgrade things best upgraded by pip/cargo/whatever?
I guess what I want to know is whether the architecture or the philosophy of nix interferes with nix's being modified in the way I just described. (Maybe it is just that nobody's gotten around to doing the implementation work.)
No. pip/cargo/etc are nondeterministic. Nix packages should not be. Where they are, things often break in bizarre ways.
In order to access the Internet, a Nix package must declare the hash of its output - given that pip can produce different output from run to run (it contains a constraint solver which depends on the versions available in the external package repository) this is impossible.
There's a similar tool for macOS called `nix-darwin`, as well: https://github.com/LnL7/nix-darwin
I feel like AMIs and containers address the reproducible builds problem and blue/green deploys the rollback issue. Could NIXOS still be complimentary in an AWS/AMI environment?
In contrast, if you put each package in its own container or VM, then you end up with 200 copies of L.
So, the different technologies have different strengths and weaknesses. One weakness of Nix is that it is harder for most people to learn or to understand than containers or VMs are.
Some people use Nix or Nixos as part of their process for building containers or VM images.
(I wonder whether there is any build system that uses containers instead of file names containing cryptographic hashes (like Nix does) or chroots (like Arch Build system does) to "enforce package isolation" during building.)
NixOps can also automatically create and destroy EC2 VMs, EBS disks, and so on for you, based on your NixOS config. NixOps also makes it very easy to set up a local copy of your network using Virtualbox.
Personally I use a common baseline image that is preseeded with my SSH key, and then deploy whatever setup I need using NixOps. You can read more about that approach at https://nixos.wiki/wiki/Virtualization_in_NixOS.