when fiddling around with stuff, rebuilds even after the slightest configuration change take a really long time compared to the classical "edit config files directly" approach. Waiting 30s for your change to take effect can be frustrating.
While most of the packages in nixpkgs are reasonable up to date, there also are a lot of them that are (at least essentially) unmaintained. In most other distros you can expect every package in in the repositories to be actively maintained (in the packaging sense), but this isn't really the case in nixpkgs where everyone and their mother is a maintainer.
Packaging stuff is is still usually harder than for more conventional distros (at least ones with a somewhat sane build system), but nixpkgs has a lot of nice tooling for most "types" of software.
Documentation seems to be somewhat lacking. It feels like a lot of stuff is just glued together by hearsay and random blog posts you must know about. I also wish there was a nice way to access the documentation of the nixos modules that does not involve going to search.nixos.org all the time (Obligatory manix mention though).
You can't really make (local) changes to more central packages of your system without degrading your system to a gentoo.
Stuff not managed in configuration.nix is very prone to having security vulnerabilities as dependencies are never patched (by design). The fact that 100% of the GPG keys listed at https://nixos.org/community/teams/security.html are expired also does not make the best impression.
The command line sucks compared to the one of the lispy competition.

> What exactly is home-manager, and how to learn to use it

Optional nixos-like tool which can be thought of as "nixos, but for a user". There's overlap in what NixOS and home-manager should do, so usage is up to you. And if you want that separation of concerns.

> How do I go around when it comes to developing stuff e.g in C++ or Clojure..?

Some languages have documentation on the manual: https://nixos.org/manual/nixpkgs/stable/#chap-language-support.

For C++, this is largely taken care of by stdenv. For cmake, meson, autotools, and other toolchains, the documentation isn't as centralized. There's https://nixos.org/manual/nixpkgs/stable/#ssec-setup-hooks for some top level material.

> I can't find too much information how to go around using openVPN... Like, I Just want to be occasionaly connected to specific VPN, but not by default.

services.openvpn.servers.<name>.autoStart = false;

Use man configuration.nix to find relevant options.

I just had a look at the new documentation site and it's markdown sources and I have to say that I am loving it. Well done.

Create FHS environment with buildFHSUserEnv with the necessary libraries and run the binary from that environment. It provides you with a temporary environment with the standard linux directories like /usr /lib etc using nix-shell. It is for exactly these reasons that the buildFHSUserEnv is provided.

I want this too. However, in case this is useful to someone, a trick I learned recently from the docs is viewing package version changes after an upgrade:

$ nix profile diff-closures --profile /nix/var/nix/profiles/system Version 92 -> 93: electron: 15.3.1 → 16.0.1, +1633.7 KiB emacs-gcc: -247.3 KiB extra: ∅ → ε, +27990.9 KiB firefox: 94.0.1 → 94.0.2, +382.2 KiB firefox-bin: 94.0 → 94.0.2 ...

You basically write a systemd unit file:

# Define a systemd unit named "example.service" systemd.services."example" = { # Enable it enable = true; # Write a description to help future-you understand what it does description = "Example service";

# Describe the [Service] section of the unitfile serviceConfig = { # simple -> normal, non-forking daemon Type = "simple"; # Run as root - This is not desirable in most cases, as it is insecure User = "root"; # Will "always" restart on an error/problem (see manpage) Restart = "always"; };

# Add to the target wantedBy = [ "multi-user.target" ];

# Require networking after = [ "network.target" ];

# Add iputils to the $PATH of script path = [ pkgs.iputils ]; # Define the script script = '' ping 127.0.0.1; ''; };

This will execute ping 127.0.0.1. You might want to have a look at the NixOS options for <code>systemd.services.&lt;name&gt;</code>.

Also, systemctl cat example.service will be your friend, probably.

Yes, Nixos is actually the only sane way of doing this (Ansible, etc. might be another solution, but these are way more complicated).

You basically have two options. Either you have a git repo setup with your configuration.nix file in it and you simply ssh into the servers, pull and rebuild. The more sophisticated option would be to user Nixops, which allows you to do more. You can specify a service (possibly consisting of many servers) and deploy them via a couple commands to different cloud providers. You can also test it locally by spawning up a bunch of Docker containers. This is e.g. being used by Simple Nixos Mailserver (shameless plug) for continuous integration testing. Unfortunately it takes a little work to get the hang of it, in my opinion it is totally worth it though.

If you haven't taken a look yet, the Nix Pills can be informative.

The other thing I would mention is that there are 3 manuals, one for nixos, one for nixpkgs, and one for nix the language. I think reading about the language help me out a bunch in the early days.

Not really directly answering you, but I would try something like LXC to create a container with another distro, either NixOS or Arch, and use RDP or X redirection to have GUI apps running natively. Those kind of containers are like VMs but uses a lot less resources.

Ok, I already found the answere here.

I needed to change the line `nvim-treesitter` in my configuration.nix to `(nvim-treesitter.withPlugins (plugins: pkgs.tree-sitter.allGrammars))`. Thanks anyway!

Great idea, I'd suggest writing it as a collaborative project, maybe using something like mdbook backed by a public GitHub repository.

Nix(Os) keeps evolving faster than a single person can document it's state. This is a good thing since it shows the development and community is very active, but would make a book outdated by the time it's ready. If you allow others to contribute/update sections or chapters, it could be a solution. Personally I like how the unstable nix manual is written, mdbook is simple but it renders nicely.

You should figure out though, if it's worth creating a new resource you will have to maintain, or you'd rather contribute to existing ones like the wiki or the manual.

The most direct way to do per-user package installation from the system configuration is to use the <code>users.users.&lt;name?&gt;.packages</code> option. If you want to go beyond package installation then I second /u/ayyjayess's suggestion of Home Manager, e.g., if you want to set up dot files or per-user services.

This is the UI of the new shorthand nix command. See the release notes for Nix 2.0, or just navigate through it's thorough nix COMMAND --help screens.

I'd love it if nixos-rebuild used this by default. It's a little nontrivial since nixos-rebuild has a bunch of extra modes to support that most people don't use. But it could probably be done.

You can do it yourself with nix build '(import <nixpkgs/nixos {})', then doing nixos-rebuild afterward, as nix build will have done all the building (but none of the installing).

Just curious, what are the issues?

If they are with shebangs and you dont mind not using nix, you can always use buildFHSUserEnv with the necessary dependencies to act as if you're on any other distro.

The only thing is that you will no longer be using nix to build but instead the manual pip, but its a good compromise.

Mostly a bad word play on nix flakes. I was thinking about cornflakes because the tablet in the image reminds me somewhat of a serving tablet.

Even better is gitignoreSource which (optionally) reads your .gitignore file but also allows you to add extra patterns to ignore. This is super helpful when you want to use different sets of files for different builds. For example I may want to use just package.json and package-lock.json for fetching my deps, but then I use the full (cleaned) directory for the actual build.

https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-nix-gitignore

The currently best way to introduce a new package locally is to use overlays. For your example, try putting the following inside a file ~/.config/nixpkgs/overlays/extrapkgs.nix:

self: super:

{ gnomad2 = super.stdenv.mkDerivation rec { name = "gnomad2-${version}"; version = "2.9.6";

src = super.fetchurl { url = "mirror://sourceforge/gnomad2/gnomad2/Gnomad%20${version}/${name}.tar.gz"; sha256 = "16jwfgirj53a3wia0x519iy7s0nqpqj6gdhywcx96w8yvzs27m3l"; };

patches = [ (super.fetchpatch { url = "https://sources.debian.net/data/main/g/gnomad2/2.9.6-5/debian/patches/0001-werror_format_security.patch"; sha256 = "1cfsmhgrqmgp6jfghfs6m4apzankshg1n8d299jlysckpx5s8ib2"; }) ];

nativeBuildInputs = [ self.intltool self.pkgconfig ]; buildInputs = with self; [ gtk2 libid3tag libnjb libusb ]; };

libnjb = super.stdenv.mkDerivation rec { name = "libnjb-${version}"; version = "2.2.7";

src = super.fetchurl { url = "mirror://sourceforge/libnjb/libnjb/${version}/${name}.tar.gz"; sha256 = "1dnjd0k36rjqvc4cyxqgy2k79b8vnr0a70ag2ixas46w1f3zrg6c"; };

buildInputs = [ self.libusb ]; }; }

Then you should be able to run nix-env -f '<nixpkgs> -iA gnomad2 (no guarantee that the built program actually would work).

I am currently running NixOS on a Raspberry Pi 3. I did it 'the hard way' by starting with raspbian and compiling the core nix tools. Then I followed the directions on this page to create a native NixOS install,

https://nixos.org/wiki/Bootstrapping_NixOS_on_ARM

It took several days of waiting around for things to compile. But it worked. The 1GB of RAM on the Pi3 was definitely useful.

I have successfully use the GPIO and raspberry pi camera port on the RPI3 under Nix.

I've been working like crazy on a couple projects with deadlines, those are about wrapped up. So hopefully I will have time to create a easy to install RPi3 image soon.

I also recently purchased an ODROID-C2 which has 2GB of RAM. I am hoping to NixOS running on that as well and use it as a build server.

Note that while both the Pi3 and the ODROID-C2 support 64-bit mode, I am currently only interested in building for the 32-bit ARMv7 target. I would like to be able to use the same binaries on the ODROID-C2, Raspberry Pis, and C.H.I.P.

And lastly, I have no previous involvement with the RPi support on NixOS. I just decided to make a go of it a month or so ago. So there is a lot I don't know ;)

Python works great out of the box. I was able to compile Haskell GHC 8.0.2, but had to do a bit of hacking to tell the build system how to find the binaries for bootstrapping. I am currently trying to get OpenJDK 8 built. That also requires some hacking to get the build to know how to obtain the binaries for bootstrapping.

So -- in summary, NixOS works great on a RPi3, but, unless there is an already working image, the installation process is a bit tedious.

Just try this option https://nixos.org/manual/nixos/stable/options.html#opt-environment.noXlibs and fix dependencies that require X11. I hope you would not give up due to the amount of work

Enabling flakes switches you to the unstable version of nix. The documentation you're looking for is online here, or is accessible with nix search --help

TL;DR you need to specify the installable first, e.g. nixpkgs. So to search for emacs you need nix search nixpkgs emacs

So I had a similar issue with python. My answer was using a shell.nix file that would start an impure python environment using venvShellHook. Then I can use pip to install everything normally.

This approach is mentioned as an option in the nix manual under the FAQ section of the python user guide

I'm not sure what is going on, but you can try rapidly pressing up/down arrow keys or shift while booting and see if you get to the menu.

But NixOS does *not* have a graphical installer or anything like that yet. It's a bit like Arch Linux now, where you do the setup on the command line. The disk partitioning part is manual, but the bulk of the initial configuration can be done from `/etc/nixos/configuration.nix`.

You can check out the guide here: https://nixos.org/manual/nixos/stable/index.html#sec-installation

NixOS configuration files use what's called the module system. Modules can declare options, and they can define values for options. When you declare an option, you give it a type, and all the definitions for that option will be checked for conformance to that type. Then, all the defined values for that option (there can be many, as each module can define any option) will be merged according to whatever merge strategy the type defines. For instance, programs.zsh.initExtra uses the type lib.types.lines, which merges multiple definitions by concatenating them with a line in between.

As /u/ajs124 says, you can use mkBefore, mkeAfter, mkForce, and other functions to manipulate the order and priority of definitions.

You will be able to login as root. I don't recommend logging into X as root though, rather do Ctrl-Alt-F1 to switch to a getty terminal and login there with username root and your password. Then add the user to the configuration (see here for how to do this), rebuild and use Alt-F7 to switch back to X and login as the newly created user.

Nix has support for almost 30 ecosystems: https://nixos.org/manual/nixpkgs/stable/#chap-language-support.

C + C++ toolchain support is implied. I don't see autotools in the list, but autoreconfHook essentially takes care of it.

Nix (and NixOS), as stated on the NixOS website try solving the issue of reproducability in software (meaning if something does not work for me it also should not work for anyone else). To an extend that includes running on various distributions and plattforms but is otherwise independent of what Torvalds was talking about.

I haven't tried it but I think adapting the example here could do what you want. (Pro tip: don't open the manual on mobile)

Something like following would do the job:

{pkgs, ...}:

let dmenu = pkgs.dmenu.override( { patches = [ ./patches/foo.diff ]; } ); in { home.packages = [ dmenu ]; }

You might want to read about overriding packages.

HTH

Nix uses garbage collection, which is described quite well in the Nix manual. Simplified, once a Nix store path is not referenced directly or indirectly by a garbage collector root it will be removed when your perform a garbage collection. For example, the collection of packages you have installed as a user, called your profile, is a garbage collector root and is protected from deletion. You can keep old versions of your profile and those old versions will also be protected. Often people remove profiles after a certain time has passed and then perform a garbage collection to release disk space.

If a certain version of a package is important to you then you have to make sure it is referenced from a garbage collector root. There are various ways to do this, but often the simplest way is to make sure it is installed in your profile. That way the software will also be easily launched.

Seems like the new channel update has not been released yet.

If you open https://nixos.org/channels/nixos-18.09 and click on git-revision, you can see the commit hash of the current channel release.

When you run nixos-version you get a version string like this 18.09.1985.749a3a0d00b (Jellyfish). When your is up to date you should see that the revision part of your nixos version matches the commit hash of the current channel release.

I'm also new to nix so there might be a better way, but here's my two cents:

You can use "nix search" to search: nix search firefox
You can get a list of installed packages with nix-env -q
This is also what I want from nix and is (IMO) poorly documented and not very well supported. You can "trick" nix into thinking that a package "my-packages" exists, the basic setup is here: https://nixos.org/nixpkgs/manual/#sec-declarative-package-management

EDIT: Here's my nix setup: https://gitlab.com/jabranham/dotfiles/tree/master/common/.config/nixpkgs/overlays

It should work for you if you copy those files into ~/.config/nixpkgs/overlays/. Obviously you want different packages than me installed so you should modify as appropriate.

Then to update you have to do:

nix-channel --update nix-env -u nix-env -riA nixos.my-packages

You might need to change the nixos part to nixpkgs or whatever your channel is called (nix-channel --list). The first command grabs the new channel (updated packages like firefox), the second refreshes the nix expressions you've made, and the third actually installs the updated expressions. The -r flag removes everything you might have installed that doesn't get pulled in by my-packages.

It has ifs and loops, it's turing-complete. Racket or Haskell would've been excellent choices to meet the requirements they give for the language. As I said, I'm very puzzled by this decision.

https://nixos.org/wiki/How_to_install_nix_in_home_(on_another_distribution)

I'd recommend the proot way. It's not ideal, but doable. An easy and performant way to use nix without root permissions is really the only thing I'm missing from it.

Edit: also check out conda. Might be a better solution when using a supercomputer. They support a lot of scientific software, and it's much easier to setup without root than nix.

First of all, welcome.

Second, don't worry, you'll learn NixOS in no time. It still has some rough edges, but just ask here or in the mailing list about any problems that arise and you'll be fine. Keep in mind that the vast majority of Linux howtos/guides will not work with NixOS, and that Appendix A is your best friend. Once you have tuned NixOS to your liking, there should be little to no maintenance.

We need newbies as well as professionals. Your feedback is important :)

Now about your wifi issue.. Certain Linux-branded Dell notebooks come with proprietary Broadcom drivers and firmware. Did you try hardware.enableAllFirmware? If that doesn't work, could you please post your Notebook model and preferably the output of lspci and lsusb?

Source:

> To allow the use of Lua as a script interpreter in Unix systems, Lua skips the first line of a file chunk if it starts with #. Therefore, Lua scripts can be made into executable programs by using chmod +x and the #! form, as in [...]

— https://www.lua.org/manual/5.4/manual.html#7

It's not even fair to say it's the shebang line it skips, as it would skip any first line starting with #.

You probably want these instructions: https://nixos.org/manual/nixos/stable/index.html#sec-installing-from-other-distro

However you will be able to skip a lot of the steps about setting up Nix since you already have it installed.

IIUC the installer will use your current installation as a source so required packages will be copied from your existing store. If you want to copy the rest of your store you can do that after your install.

If your config is exactly the same on both systems you can also build the config on the old system to get the derivation then just activate in the chroot described there (instead of generating a new configuration). But I don't think there are any docs for that since it is a very uncommon operation.

There’s a section on breaking changes in the release notes, but that’s generally it. Some things will check and display a message if you try to use an old option (such as the change to fish-foreign-env), but not all of them do. Fortunately, if your config is broken by the upgrade, it will usually fail to evaluate and not affect your system.

One thing that tripped me up was the change to Unbound. I use security.acme to provision a certificate for my home network and have Unbound configured to use it for DNS over HTTPS/TLS. One of the breaking changes was that Unbound no longer starts as root. It starts and runs as an unprivileged user now. This broke my config because Unbound could no longer read its certificates.

I was able to fix it, but it’s an example of the kind of syntactically valid but (now) semantically invalid error that won’t get caught until things break at runtime. I expect those probably aren’t too common unless you’re doing something weird like I was (DoH/DoT is not supported by default). In the worst case, you can roll back to a previous generation and try again.

Hooray! Got it working.

Apparenty, I did it wrong initially. After checking https://nixos.org/manual/nixos/stable/index.html#sec-modularity (the last paragraph) I figured out that I was essentially generating configurations on-the-fly that normally are just imported, so this is how it looks in the end:

Hi! I guess the problem is with the [0] and [1]. You should use something like head and tail to access elements in that list. Or elemAt if you know the exact index. These are all builtins functions

Maybe you have used the wrong menu entry syntax for your grub version or the wrong disk/partition to boot windows from? I have the following in my /etc/nixos/configuration.nix

boot.loader.grub.enable = true; boot.loader.grub.version = 2; boot.loader.grub.device = "/dev/sda"; boot.loader.grub.extraEntries = '' menuentry "Windows 7" { chainloader (hd0,1)+1 } '';

The mapping between sda1 and (hd0,0) and so on is described in the second answer of this superuser thread: > I believe that sda = hd0, sdb = hd1, sdc = hd2, so on etc. etc. When it says sda1 that would be (hd0, 0) and sda2 (hd0, 1) and sda3 (hd0, 2) and sdb1 (hd1, 0) so on and so forth...

So you need to be careful because the disk letters get mapped to numbers and the partition numbers are decremented.

Since you've run bootrec.exe /fixmbr you now have an additional different problem: There is no grub in your MBR anymore. The solutions that come to my mind are either somehow booting into your NixOS installation and running nixos-rebuild switch again to overwrite the windows MBR again with grub, or reinstall NixOS. For the first solution maybe you could boot a linux from a live cd, then mount your nixos partitions, chroot into your NixOS, and then run nixos-rebuild switch.

An alternative might also be to install a grub from windows with a menu entry for NixOS, then reboot into nixos, update your configuration.nix to contain a correct menu entry for windows, then nixos-rebuild switch to install grub via NixOS again.

Note, that I haven't done these steps myself on NixOS. It's just reasoning transferred from my experience with other linux distributions.

You could try installing a boot manager that knows how to wait for USB drives, such as rEFInd: http://www.rodsbooks.com/refind

If you want to keep grub, you can have rEFInd call grub - it's not either/or.

Not really, evaluation of Nix expressions don't involve any external tools, e.g.:

derivation { name = "me"; builder = builtins.toFile "builder" "false"; system = "x86_64-linux"; }

But all the build phases are run shell scripting. I haven't looked too deep, but stdenv has the attributes shell and shellPackage, both defaulting to bash. Overriding stdenv.shell should give you a system that builds using the specified shell.

https://nixos.org/nix/manual is the language reference. The problems you're describing can be solved by pinning nixpkgs, e.g. ``` {...}: let pkgsSrc = (builtins.fetchGit { # Fetch a specific revision of nixpkgs url = https://github.com/nixos/nixpkgs; # Note that this URL syntax is correct rev = "ed3895a9870816af1e968b1485543212ac2bac13"; # sha1 of commit we want to fetch }) pkgs = import pkgsSrc {}; in { /* Your definitions go here */

nixpkgs = { inherit pkgs }; # pkgs argument in all other config files nix.nixPath = [ "nixpkgs=${pkgsSrc}" ]; # Make all the nix-* commands use our pkgs version }

NetworkManager connections are defined in plain text files under /etc/NetworkManager/system-connections/. You can use environment.etc to create these files.

In the unpack phase: https://nixos.org/nixpkgs/manual/#ssec-unpack-phase

> Directories in the Nix store These are simply copied to the current directory. The hash part of the file name is stripped, e.g. /nix/store/1wydxgby13cz...-my-sources would be copied to my-sources.

And

> By default, they are made writable to prevent problems with read-only sources.

OP, It sounds like you're unwilling to share the code you have. Are you using stdenv.mkDerivation from Nixpkgs? If so, maybe you had something like cd $src in your buildPhase? That's not necessary since stdenv changes directory into the temporary copy of the source for you, and doing the build in $src might have actually caused your problem.

Two things to try:

Add the uas module to your set of kernel modules.
Add the boot.shell_on_fail kernel flag to your boot.kernelParams, as documented in the section in the manual about Boot Problems. See if you can find your root filesystem in the debug shell.

I don't think there's anything wrong with your boot loader. It's loading and running kernel and initrd just fine, based on the screenshot.

Using <code>nixpkgs.overlays</code>;

{...}: # ... { #... nixpkgs.overlays = [ (self: super: { haskellPackages = super.haskellPackages.extend (hself: hsuper: { stack = (hsuper.callHackage "stack" "1.7.1" {}) .overrideScope (hself2: hsuper2: { Cabal = hself2.Cabal_2_2_0_1; hpack = hself2.hpack_0_28_2; }); }); }) ] #... }

That is, assuming your overlay as-shared works.

I tried to install NixOS 4 times, I think, over a course of a 2 years or so, all of which eventually succeeded, but did not get me to a day-to-day usable system.

The biggest problem for me was the documentation - I was eager to learn, but information just wasn't accessible.

I've went through installation of Gentoo, Funtoo, Exherbo, Void, Arch etc. in the past and the only way I was able to do it was by reading the extensive documentation of those distros(Arch wiki FTW), but NixOS just doesn't have such. The manual at https://nixos.org/nixos/manual/ just really doesn't cut it and you have to use IRC to ask questions to people.

Hence, I think the biggest problem with NixOS for people new to it is really the documentation. It's extremely hard to "get in" and even when you are "in", it takes a lot of time to learn all the quirks. Most of the times I ended up "scaffolding" for information on the Internet.

IMHO currently the only way to make NixOS a day-to-day usable system for yourself is to read the source of each and every configuration option you put in the configuration.nix, hence I think using NixOS today requires a lot of pre-knowledge.

Nevertheless, now pretty much all my systems, including servers, run NixOS and I couldn't be happier with that.

I think you're looking for ~/.config/nixpkgs/config.nix where you can use <code>packageOverrides</code>.

Nowadays I think overlays are preferable when overriding packages. The config.nix is mainly for general configuration such as allowUnfree, allowBroken, etc.

That's normal and a rollback won't restore / overwrite the file. Take a look at system.copysystemconfiguration if you wish to have the file backed up on system rebuild.

In that case, I would recommend the second option. You would make a derivation who's src would be fetchFromGit... it's easier to just show an example:

stdenv.mkDerivation rec { name = "pywal-${version}"; version = "0.2.6";

src = fetchFromGitHub { owner = "dylanaraps"; repo = "pywal"; rev = version; sha256 = "${something}"; };

nativeBuildInputs = [ pkgs.python35Packages.pip ];

installPhase = '' pip install '' }

I haven't tested this or got the hash of the download, but that's roughly how a package is put together.

After checking the Nixpkgs manual, It's even easier than that because there's a builtin way to build python packages. Alternatively, you can use python2nix, which can generate a complete nix derivation with just python2nix pywal. (nix-shell -p python2nix --run "python2nix pywal" if you don't want to permanently install it.)

Details on how channels are updated

Basically a channel is updated after the binary cache for it as been generated on hydra, so binary packages are available also when using the unstable channel.

Save the .drv for current package (if you use shell.nix replace "." with "./shell.nix"):

nix-instantiate . --indirect --add-root $PWD/shell.drv

Then load it like this:

nix-shell $PWD/shell.drv

(from https://nixos.org/wiki/Development_Environments#Making_a_Persistent_nix-shell_Environment)

For me the major thing has just been lack of packages. The basics are mostly there, but you might have to learn to package some rarer things yourself. Other than that it's remarkably nice. Have you ever tried to automate your Debian configuration with something like Ansible? I think of NixOS as a nicer version of that.

There are some extra distinctions between user vs system packages, and you can have different profiles with their own sets. The cheatsheet explains it pretty well. Personally I try things out in my user profile, then install all the keepers systemwide.

Oh one bad thing. The initial installation isn't nearly as smooth. It's more like installing Arch. But once you get past that (possibly after messing it up a couple times), maintaining a working system is super easy. You don't have to worry anymore about breaking your system, because you can always roll back. And you don't forget how to set it up because everything is written out as code.

Anything that you can connect to with OpenVPN should work. Then NixOS has OpenVPN config options where you can provide a stateful path to the config if it's got secrets in it. I personally use PureVPN and it works great.

Apache is easy enough to manage through NixOS. If you want to use php to throw some of your own sites on the web you can get up and running in no time. If you're looking to host web applications managed by NixOS this is also possible.

Specifically in the mediawiki case I have an open PR (which is not yet ready for merge but should be soon) which will make setting up a mediawiki instance as easy as this:

services.mediawiki.enable = true; services.mediawiki.virtualHost.adminAddr = ""; services.mediawiki.hostName = "example.com";

include your ssl certs and options

For the more general apache case maybe this example can help: https://hastebin.com/ubavisediw.pl

After you build this configuration the very first time you would want to manually activate the acme-example.com systemd job to generate a certificate for you.

If anything doesn't work out let me know and we can resolve it.

> scaling_setspeed > > This attribute is functional only if the userspace scaling governor is attached to the given policy.

https://www.kernel.org/doc/html/v4.14/admin-guide/pm/cpufreq.html

so as long as you don't have the governer set to userspace that won't work.

Okay so instead of going back and forth I say it straight up: If you want the lowest frequency use the powersave governor, no setting the freq manually necessary.

If you explicitly want to use the userspace governor instead, which I assume is not available in the kernel nixos provides by default as scaling_available_governors shows, then you should look into what kernel build options have to be enabled for it to be present and enable them. See https://nixos.wiki/wiki/Linux_kernel#Custom_configuration on how to customize your kernel.

Then your system does not support S3 sleep (suspend to RAM). From the kernel documentation on power states:

State: Suspend-To-Idle ACPI state: S0 Label: "s2idle" ("freeze")

This state is a generic, pure software, light-weight, system sleep state. It allows more energy to be saved relative to runtime idle by freezing user space and putting all I/O devices into low-power states (possibly lower-power than available at run time), such that the processors can spend more time in their idle states.

This state can be used for platforms without Power-On Suspend/Suspend-to-RAM support, or it can be used in addition to Suspend-to-RAM to provide reduced resume latency. It is always supported.

This means that the processor will mostly be idle but it keeps on running and therefore continues to produce heat. That's why it's a really bad idea to put a laptop that is in S2 sleep into a bag. It might overheat and die. Also during sleep the laptop will consume a considerable amount of battery, so after 12h of S2 sleep the battery will likely be drained.

I'm not too sure why modern laptops don't support S3 sleep anymore, but I heard that it's a “Windows thing”.

So as a next step you should scan the BIOS settings for an option to enable S3 sleep and if that is not present write to Lenovo support that you want S3 sleep in a future firmware update.

You probably want to make a python environment? Something like:

environment.systemPackages = let
  pythonEnv = pkgs.python39.withPackages (p: with p; [
    regex
    pip
  ]);
in [
  pythonEnv
];

You could also use:

environment.systemPackages = with pkgs; [
  (python39.withPackages (p: with p; [
    regex
    pip
  ]))
];

If you could use nix-shell for your use case and actually create a per-project environment as such, that would likely be better.

Refer to: https://nixos.org/manual/nixpkgs/stable/#python

Wow, that's very clean. I've got to go reconfigure how I install some trivial scripts...

For the sake of learning, I should point out that pkgs.writeShellScriptBin is just a function defined here in the nixpkgs repo.

It has very limited documentation outside the source. It's notably not listed in Chapter 12: Trivial Builders of the manual, though it is an obvious extension over the functions that are listed.

(I'm still very much learning, so figuring out how these things and where they're documented (so I can see what I should be familiar with) is very useful to me, and I figure it might be useful to others too)

It's a bit of a classic on NixOS: to use /nix/store pre-built binaries are unable to find libs.

You can start looking at missing libs with ldd and find the right derivation (package) via for instance https://nixos.org/nixos/packages.html

Than start an FHS-wrapped shell to test with ldd until all deps are satisfied, like putting the binary in a dir with a default.nix tet file and inside the file for instance

{ pkgs ? import <nixpkgs> {} }:

let fhs = pkgs.buildFHSUserEnv { name = "fhs-env"; targetPkgs = pkgs: with pkgs; [ alsaLib atk cairo cups dbus expat file fontconfig freetype glib libnotify libxml2 libxslt nspr nss strace udev watch wget which xorg.libX11 xorg.libXScrnSaver xorg.libXcomposite xorg.libXcursor xorg.libXdamage xorg.libXext xorg.libXfixes xorg.libXi xorg.libXrandr xorg.libXrender xorg.libXtst xorg.libxcb xorg.xcbutilkeysyms zlib zsh jdk icedtea8_web firefox evince gnome2.gtk ]; multiPkgs = pkgs: with pkgs; [ zlib ]; runScript = "bash"; profile = '' export FSH_ENV='1' ''; }; in pkgs.stdenv.mkDerivation { name = "fhs-env-shell"; nativeBuildInputs = [ fhs ]; shellHook = "exec fhs-env";

}

targetPkgs/multiPkgs are the deps you want to pull in, space or newline separated, runScript the command to be run once the FHS wrapped environment is ready. In this case it just run a bash shell. In that shell you test with ldd until all deps are satisfied. Then for a local usage you can just change runScript to the path of the target binary (providing executable permission) and if anything it's ok write a derivation to be imported by configuration.nix

> and hardware.nix which is hardware dependent.

Minor correction, it's hardware-configuration.nix. Automatically generated by <code>nixos-generate-config</code>

Well, the first problem is that this:

{ map mounts mount; }

is invalid Nix syntax. {} indicates an attrset and it's contents should follow a key = value; format. A bare expression like map mounts mount; is illegal inside there

Now, when you do this:

{ lib, ... }: let mounts = [ { from = "Containers"; to = "Containers"; } { from = "Downloads"; to = "Downloads"; } # ... ]; mount = m: { fileSystems."/home/kuzzmi/${m.to}" = { device = "//192.168.0.2/${m.from}"; fsType = "cifs"; options = [ "username=kuzzmi" "x-systemd.automount" "noauto" "uid=1000" ]; }; }; in lib.mkMerge (map mount mounts)

(I took the liberty to fix the remaining mistakes, like outer { } on the mount function), you are instead passing the result of map (a list of attrsets, each with one element) to mkMerge, which at evaluation time merges each of these attrsets into one.

You are my savior :D. I managed to get far enough along to try and setup a PR for it but couldnt figure out how to call chgrp with the udev rule to pass the tests

here is the pkg file https://hastebin.com/zidiyuhuko.pl here is the module file to install the udev rule https://hastebin.com/ikepamodop.cs

It took me quite a bit longer than expected to spot the mistake.

This is still not working, but it is a step in the right direction I guess.
https://hastebin.com/igebageray.pl

I've tried replacing the %k with a regular * wildcard but this is not working...

I will give it another shot later today (or maybe tomorrow...).

I think it's a better idea to add: rustNightly = (self.rustChannelOf { date = "2017-12-22"; channel = "nightly"; }); to overrides (for nix-shell and nix-env use ~/.config/nixpkgs/overlay/override.nix (name this file as you like)), and then use rustNightly.

https://hastebin.com/juwemopaya

I am sticking to the release-16.09 branch of nixpkgs, so I'm still with awesome 3.5.9 on my nixos setup. I am using 4.0 on my archlinux setup though.

Still, the version might not be the issue. There are some optional dependencies recommended by archlinux. Maybe the theme is using one of those and you have them installed on archlinux. Please share which theme and the errors you get, I will take a quick look at it.

Tip:

When presenting terminal output, place four spaces at the start of each line to format them as a code block, it will keep special characters intact, and newlines will be kept also.

> ␠␠␠␠Some output
> ␠␠␠␠Some output

Will convert to this

> Some output > Some output

If some output is big, it might be better to share it on a platform like github's gists.

Update - yes that did help after all, thanks. The app seems to at least be functional now.

The main remaining problem is that it seems to conflict with Tailscale. When both are running I lose the Internet connection completely.

Also, Mullvad can see all my installed applications and lists them in its Split Tunneling list, but can't start any of them. "Unable to launch selection. Please try again or contact support."

It is indeed (partially) automated. The built-in guix import command can create Guix recipes from several sources, including from Nixpkgs.

Seems to work reasonably well (it's not perfect, but it gets most of the way there), though you need to have a local copy of nixpkgs and you also need to have nix itself installed, if I'm not mistaken.

Please use the iso from the website to install NixOS. Looks like you generated a configuration which expects a /mnt-root path to be mounted.

The official documentation for obtaining NixOS is here: https://nixos.org/manual/nixos/stable/index.html#sec-obtaining

Generally when installing you'll want to do a nixos-generate-config --root /mnt, this will produce a hardware-configuration.nix on the mounted partition which contains all of the partition information. Then you want to run run sudo nixos-install --root /mnt to then apply the changes to the partition.

Please follow https://nixos.org/manual/nixos/stable/index.html#sec-installation closely. Once you get nixos installed successfully initially, it's usually much easier to play with after that.

Discoverability isn't great, but the documentation you're looking for is: https://nixos.org/manual/nixos/stable/#sec-option-definitions-delaying-conditionals

But I essentially already had to know where to look for this to find it. Definitely should be easier to find.

For general nix foundation type stuff the Nix Pills will give you an idea of what nixos is actually doing when you tell it to build a configuration. This is nice for theoretical work but is a bit heady if you want to just get working. For getting something up and running quickly you can give the Nixpgs manual a look. This will be especially helpful for things like python applications since each language family seems to have opinions about how to best get their code running under nixos.

In my projects I usually have a snippet like this in shell.nix

let # https://nixos.org/channels/nixos-unstable nixpkgsGitVersion = "1dc37370c489b610f8b91d7fdd40633163ffbafd"; nixpkgsSrc = builtins.fetchTarball { url = "https://github.com/NixOS/nixpkgs/archive/${nixpkgsGitVersion}.tar.gz"; sha256 = "1qvfxf83rya7shffvmy364p79isxmzcq4dxa0lkm5b3ybicnd8f4"; }; pkgs = import nixpkgsSrc {}; in pkgs.mkShell { buildInputs = with pkgs; [ nix ]; NIX_PATH="nixpkgs=${nixpkgsSrc}:."; }

After you enter the shell, it will use that specific version of nixpkgs and nix. The system-wide nix only has to be compatible enough to bootstrap the shell (nix itself has good backwards compatibility, so that's generally not a problem).

If you haven’t already I would highly recommend reading the nix pills. They don’t go over nixos options directly but do go over everything they are built on.

What you are doing here is overriding the src attribute of a derivation. Have a look at https://nixos.org/nixpkgs/manual/#sec-pkg-overrideAttrs from the manual.

I believe this is similar to what you want to achieve https://unix.stackexchange.com/questions/270342/how-do-i-upgrade-netbeans-with-packageoverride-in-configruation-nix

there does not seem to be a package called sane-epson2, maybe one of the other packages (utsushi / epkowa) as described in https://nixos.wiki/wiki/Scanners#Epson are working for you? Alternatively you can search through all packages via https://nixos.org/nixos/packages.html?channel=nixos-19.09&query=sane%20epson

the package sane-epson2 does not seem to be packaged yet but if you are lucky then sane already comes with epson and epson2 support built-in.

Cheers

NixOps doesn't just provision resources. It also deploys NixOS configs. These configs can contain systemd service definitions, among many other things. Take a look at the NixOS manual and the searchable list of options for details on everything you can control declaratively in a NixOS config. If you figure out how to package your python application in Nix (sorry, I don't know much about python in Nix), you can just declare a systemd service to have NixOps deploy it automatically.

systemd.services.my-app = { wantedBy = ["multi-user.target"]; serviceConfig.ExecStart = "${myPythonApp}/bin/app"; };

That's making a lot more sense! After a bit of research, I've realised that I made something like that:

systemd.mounts.myDevice.what = "/dev/sdx1" systemd.mounts.myDevice.where = "/root/myPath/myDirectory"

When I should have done something like that:

systemd.mounts = [ { what = "/dev/sdx1"; where = "/root/myPath/myDirectory"; } ];

I mixed it up with the systemd.services option, which is kinda similar. Thanks for your answer!

You can use multiple nix channels in parallel.

sudo nix-channel --add https://nixos.org/channels/nixos-19.03 nixos-stable nix-env -iA nixos-stable.wine

Typed this on my smartphone so it might have a typo.

Any options like that are exposed through the modules section of nixpkgs. They can also be viewed on the NixOS options page as well as man configuration.nix for offline searching.

There are a few XFCE options there, but not many. If you extend it, send a PR. The community is very friendly and helpful and always welcomes new contributors.

I use boot.initrd.luks.reusePassphrases which obviates the need for a keyfile altogether, if your happy to use the same password for both drives.

If you really need a keyfile for whatever reason, have a look at boot.initrd.luks.devices.<name?>.keyFile.

Oh, wow, inline docs! <3 Given that they're apparently already backported to 18.09 since 18 days ago, when will the contents on https://nixos.org/nixpkgs/manual get refreshed?

It seems you get scanned by "the internet". If you do not want these messages you can disable them via one of the three options: https://nixos.org/nixos/options.html#firewall+logrefused

My guess is, that your interface does not come up as eth0, but as something different?

You can pin the name of the interface via udev: https://git.shackspace.de/krebs/stockholm/blob/master/makefu/1systems/gum/hardware-config.nix#L25-27 , however i may be wrong as you have explicitly disabled renaming.

It looks like you can set nixpkgs.config.dwm.patches, according to this email. This creates a custom version of the package which includes the patches that you want. I also found an example of dwm and st in someone's dotfiles that uses a slightly different but effectively equivalent technique.

Both these sources are a bit old, so I don't know if they're still accurate. My brief look at nixpkgs makes me think they still work, but I haven't verified them by actually running them.

In NixOS these do not have a static location, but are generated from the <code>services.xserver.displayManager.session</code> config option, and are then passed directly to display managers in the config file, environment variables etc.

> That doesn't really help, nix isn't just looking for any version of GHC but for the very specific version.

I see.

> Sure it's rebuilding GHC every time? That would be rather odd. Did you change the .nix files during builds or maybe update nix-channel?

Yeah, it is weird. I let it run once and that simple build took over a half hour before I killed it. Also, it says that it's going to install it when I start to run it.

And actually, I did update my channels. I added unstable, but after I installed what I needed (the latest version of cabal2nix), I removed it.

If I run "nix-channel --list", i get the following:

nixos https://nixos.org/channels/nixos-17.03

EDIT: I ran it again, after running nix-channel --upgrade, and the building of this simple project above has now passed the hour mark.

Not exactly sure what your environment is, but I'm doing something similar in the context of remotely hosted industrial PCs connecting back to base via 4G connections.

I have a one system deployed with an approach similar to rabidfurby's (but using qmicli and qmi-network) and a bunch deployed using networkmanager and modem manager.

With the network manager/modem manager installs, I run a command such as:

nmcli c add type gsm ifname cdc-wdm0 con-name ISP apn ISPAPN

to setup the connection. This creates a file under /etc/NetworkManager/system-connections

I could probably use nixos to create this file (https://nixos.org/nixos/options.html#environment.etc), but haven't tried that yet.

I also use monit with a stanza in the config like:

check host importantHost with address abc.def.ghi.xzy if failed ping for 20 cycles then exec "/usr/bin/env reboot"

which reboots if the network is down for roughly 10 minutes or so.

If you're trying to learn how to contribute new packages to nixpkgs, then cloning nixpkgs and modifying it there is a good idea.

If you're just trying to learn how to add your own packages locally, you're probably better off adding them in your configuration (packageOverrides) or with an overlay.

I think the purpose of this section of the manual is more the former:

> This section shows how to add and test the GNU Hello package to the Nix Packages collection.

It sounds like you've probably already reviewed the basics in the Nixpkgs manual for R and Python but I think it would be worthwhile to attach the links to your question for future search purposes.

Sorry to be blunt, but [citation needed]

> <code>boot.loader.efi.canTouchEfiVariables</code> > Whether the installation process is allowed to modify EFI boot variables

This is related to the use of efibootmgr (or grub's own implementation) when installing the bootloader on EFI systems to configure the bootloader entries.

This is unrelated to the efivarsfs filesystem which, when used hapazardly could brick computers. AFAIK, efivarsfs will be mounted even if you set this to false.

EDIT: post-deletion of their previous comment, I now feel like a jerk. Sorry.

It’s best if you follow the official installation instructions [0]. In addition to that you learn some mac specific configuration from that guide you followed. The guide is exactly not a substitute.

[0] - https://nixos.org/nixos/manual/

A very universal way to run something is to use a systemd unit, here is an example of one that just runs a script once:

systemd.services.test = { wantedBy = [ "multi-user.target" ]; serviceConfig.Type = "oneshot"; serviceConfig.RemainAfterExit = true; script = '' echo hi there ''; };

However for xrandr stuff it might be better to use <code>services.xserver.displayManager.sessionCommands</code>:

services.xserver.displayManager.sessionCommands = '' xrandr ... '';

For oh-my-zsh you can enable the <code>programs.zsh.ohMyZsh</code>:

programs.zsh.ohMyZsh = { enable = true; theme = "foobar"; }

And I don't get what you mean by "nix pkg" configuration file. There are a couple configuration files on NixOS/Nix:

/etc/nixos/configuration.nix: The NixOS configuration, where you declaratively specify your system, stuff like the things I said above goes in here. The location can be customized btw.
~/.config/nixpkgs/config.nix: user's configuration used for nix-env, nix-build, etc. By default this doesn't exist and you need to create it. Stuff like packageOverrides and allowUnfree goes in there.
/etc/nix/nix.conf The global nix config, used for the nix evaluation. You mostly don't need to touch that. On NixOS you set stuff in this file with the nix.* options.

You could also join us in #nixos on Freenode, lots of people willing to help there :)

Strange, there is support for having bcachefs in initrd, but on bcachefs.org it says that it is not yet in the kernel and the kernel has to be compiled with CONFIG_BCACHE_FS.

So if you need a kernel with it, you'll have to override the configuration as described at https://nixos.org/nixos/manual/index.html#sec-kernel-config and then build an iso as described at https://nixos.org/nixos/manual/index.html#sec-building-cd

Bcachefs looks really interesting, I'll need to try it :)

You need to change the attributes of the derivation, not just the parameters, using overrideAttr, details in the Customizing packages section.

No problem. And rubberducking can lead to learning.

> I have never really touched pam, but as far as I understand it, pam_pgsql would handle the auth part - it does not set stuff like home directories, correct?

I think so. But for creating the home directories you have makeHomeDir:

https://nixos.org/nixos/options.html#makehomedir

Seems like the way would be to define a custom PAM service for Gogs that would use of both pam_pgsql and pam_mkhomedir:

https://github.com/NixOS/nixpkgs/blob/87a8193bf5abf7eba3ab0a7d41fbd733953a65ad/nixos/modules/security/pam.nix#L412

What exactly is not working when using KDE?
Lots of KDE stuff are standalone programs that you need to install alongside KDE to be able to use. You can look at all the KDE software I have in my system here.

As for the touchpad, try adding services.xserver.synaptics.enable = true;
to your configuration.nix.

The manual has a wireless section here that might help you.

I don't think there is any fixed schedule but the hackage packages tend to be updated on master every few days, you can see them among Peter Simon's commits.

The Nixpkgs Haskell infrastructure is documented in the Nixpkgs manual.

I don't know if this will help you, but I switched to using my own cloned nixpkgs repository (not from channel) and this error disappeared.
I really don't know if that was the reason :)
https://nixos.org/wiki/Nix_on_OS_X#Using_a_clone_of_nixpkgs

I couldn't get it working with unetbootin either.

Instead I got the latest <em>unstable</em> iso and used dd:

dd if=nixos-minimal-15.08pre67375.f423ba3-x86_64-linux.iso of=/dev/<your_thumb_drive> bs=10M

What are /r/NixOS's favorite Products & Services?
From 3.5 billion Reddit comments

The most popular Products mentioned in /r/NixOS:

Scholastic Success With Reading Comprehension, Grade 4

The most popular Services mentioned in /r/NixOS:

NixOS

Linux kernel

GNU Guix

hastebin

Lobsters

Apache Mesos

rEFInd - Boot Manager

Super User

GRUB

Arch Linux

Wayland

LXC Linux Containers

Sourcegraph

Kakoune

Kubernetes

The most popular VPNs mentioned in /r/NixOS:

The most popular reviews in /r/NixOS:

include your ssl certs and options

What are /r/NixOS's favorite Products & Services? From 3.5 billion Reddit comments

The most popular Products mentioned in /r/NixOS:

Scholastic Success With Reading Comprehension, Grade 4

The most popular Services mentioned in /r/NixOS:

NixOS

Linux kernel

GNU Guix

hastebin

Lobsters

Apache Mesos

rEFInd - Boot Manager

Super User

GRUB

Arch Linux

Wayland

LXC Linux Containers

Sourcegraph

Kakoune

Kubernetes

The most popular VPNs mentioned in /r/NixOS:

The most popular reviews in /r/NixOS:

include your ssl certs and options

What are /r/NixOS's favorite Products & Services?
From 3.5 billion Reddit comments