What is Reddit's opinion of NixOS?

For people who don't want to install completely different OS, but still want the benefits of NixOS: You can also install the nix package manager on every Linux distribution and even macOS.

Then there is the Home Manager project based on Nix which gives you the (almost) same benefits as the NixOS configuration file for every Linux distribution. The only difference is Nix can this way you can only manage your userland programs and not for example the kernel itself!

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.

You can try other distros that use Elementary’s desktop environment (Pantheon). For example, [NixOS](/r/nixos) has a config option to use Pantheon if you prefer it over Gnome or others. I’m sure some other distros probably have this option too (I’d be surprised if Arch didn’t).

> I know, there are dependencies and what not, but is there any possible way one could package an app in its own repository and have it "just work" regardless of platform within reason?

You can bundle an application with all of the libraries and such that it needs. The downsides to this are:

Disk usage increases dramatically. There's various deduplication-strategies, but none "just works" quite as well as not having duplicates in the first place.
Security update responsibility then falls on each and every application for every and every security issue for each and every dependency. From a security point of view, that's very worrying. Remember the recent bash bug? On most effected Linux systems, the distro maintainers just had to update one bash executable and every application which uses bash had the issue fixed. If each packaged their own version of bash, they'd each have to have their version updated. Not every application maintainer is quite on the ball for that to be a reliable strategy.

One potential solution for this is Nix, or at least something like it. Essentially this allows every application to have its own dependency chain such that dependencies don't conflict, but at the same time there's no unnecessary file duplication and it is easy to check if any package, across the entire system, is using a security-issue-carrying version of a given library. There's lots of other slick advantages as well. I recommend reading up on it. The question is why aren't the big-name distros moving to Nix, or something comparable, and what can be done about that.

Mod package manager. Preferably something like Nix. Just imagine being able to share configs with other players, and just like that, they have a 1-to-1 recreation of your exact modding setup. Something goes wrong while you are modding? No problem, just rollback to the last known stable state. Testing just became a breeze. Atomic upgrades, rollbacks, and versioning for everyone.

I mostly love it due to so many high quality apps being released on macOS only. And I can still use all the UNIX tools I need by installing them all with Nix package manager. It's pretty awesome.

As /u/andrewthad said, there are methods to make Cabal have deterministic building and dependencies, and of course Stack does this by default. But in addition, Nix is designed for this. It's definitely much harder to learn how to use, but the determinism and capability is much better than any of the other options. It's designed to be a language agnostic build tool, which ends up making it a suitable package manager. This is where the complexity comes from; it's not just meant to be Haskell. I'd probably use stack for small things because it solves the problem quite simply. But for anything nontrivial, I'd immediately choose Nix because of how many guarantees and abilities it gives you.

> Am I the only one who uses all 3, snaps, flatpaks, and appimages? (and PPAs since *buntu)

You forgot nix which is more efficient because it does not do "bundling" and downloads only the packages it needs (but allows multiple versions of the same package so it can still be used for running the latest and greatest).

I think the documentation really improved within the last year. Have you taken a look at the unstable docs? https://nixos.org/manual/nix/unstable/

It seems well more organized to me! (in comparison to the current docs)

for those that aren't familiar, note that Nix (the package manager) can be easily and safely installed and used on Ubuntu, MacOS, Arch Linux, etc. - it has no dependency on NixOS (the linux distro). So you can try this out! Start here https://nixos.org/nix/

> 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.

This is how semantic versioning is supposed to work, which (i think?) most library authors follow or something similar.

But from a package management perspective its a big intertwined landscape where something like this becomes really hard to accomplish, bugs and security issues in previous versions still need to be patched who does this? and for how long? from a distro management perspective you're now triaging bugs from multiple versions of libraries and even more version combinations.

There are distro's trying to solve this though NixOs comes to mind, where you're able to have multiple versions of the same app/library installed along side each other.

Nix has some really great features for building docker images. There is a good description how to build small docker images for Haskell applications here. One thing not discussed there is the fromImage argument that you can pass to buildImage to allow you to make layered images. More details can be found in the docker tools section of the nixpkgs manual.

Building the image will only work with Nix on Linux (not macOS), but the docker images will work anywhere of course.

While NixOS doesn't implement all the stuff you've been talking about, I think NixOS is such a huge improvement over what you see elsewhere in OS design that anyone who wants to theorize about how to improve OSes better have used NixOS in anger. This is analogous to the fact that, although Haskell is an incomplete implementation of FP ideas compared to, say, Idris, it has such a mature and developed ecosystem that by working with it you'll get a better perspective of the challenges and tradeoffs in language design (in this analogy, MS Windows would be COBOL, macOS would be Pascal, Debian would be C, Gentoo would be C++, Arch would be Java, NixOS would be Haskell, and Genode/seL4 would be Idris).

It may not look like it, but NixOS is surprisingly production-ready (Awake Security ships a product running it, IOHK runs it on the Cardano core nodes, etc.), and the community around it is fantastic (especially #nixos on FreeNode).

BTW, if you want more exposure to NixOS's ideas (beyond the advertising copy on the website), you might be interested in the PhD thesis in which Eelco Dolstra originally described it.

This is able to be done in NixOS.

We don't have a graphical installer, but installation instructions are here: https://nixos.org/manual/nixos/stable/index.html#sec-installation

NixOS with ZFS root instructions can be found here: https://nixos.wiki/wiki/NixOS_on_ZFS#How_to_install_NixOS_on_a_ZFS_root_filesystem

However, NixOS is very different from other distro's. I would not recommend it for people who want to "get up and running". Once you become familiar with NixOS it's an extremely liberating and empowering distro, it's just not an easy journey to get to the promised land.

Bazel only supports a few languages.

For the languages it does support, you get great granularity of build products, and bazel is a great tool in this case. However, I would say Nixpkgs has more support with around 28 languages.

But nix isn't aware of the underlying language, so granularity of build artifacts is up to you. However, it generally encompasses a full vertical slice (compliation + linking in C for example).

For this I generally use nix. In particular, I would strongly recommend you look into the haskell.nix infrastructure, which makes cross-compilation a breeze (thanks for /u/angerman).

Awesome, thanks a lot for the detailed explanation! Especially the "concepts" section did manage to answer quite a lot of my questions. I'd say the focus of Nix is mostly to solve dependency issues and provide safe, stable and flexible package management. At least the research paper it all started with was about that.

But yeah, after you explained the main motivation behind Bedrock Linux, I don't know how I didn't understand that before. I myself ditched NixOS for Arch on my desktop install because I just found Arch a lot more comfortable to use for common tasks. But sometimes, I do run into problems that NixOS would have solved, but that apparently could be solved by Bedrock Linux, too. I think I'll just give it a shot, many questions will probably answer themselves simply by using the distro.

For whatever reason a lot of Rustaceans use Nix, and it made to me to switch as well. I'm very pleased. The abandonment is not that severe because how easy it is tu just submit a PR to update software one cares about. ~~Do you happen to have donations/patreon for individuals that would like to support the proejct?~~ Found it: https://nixos.org/nixos/community.html . Please consider Patreon or something like that.

I used NixOS for a few days before going back to Arch. As mentioned, NixOS lets you declare pretty much everything instead of configuring through commands. For example, if you wanted to start an OpenSSH server, you'd edit your configuration.nix file and add services.sshd.enable = true, then run nixos-rebuild and it would install the relevant packages for you and enable the service. If you remove it from your config and rebuild, it disables the service and removes the packages.

Another example is editing sudoers. In Arch and other distros you'd typically use visudo to change your sudoers file but in NixOS you'd change the security.sudo options (you can see a list of them here; you can also click on them to see descriptions and example values).

It's very nice to use but the lack of documentation made me switch back. Here is the documentation for cross-building packages, which is very unclear to me (I think this is part of nixpkgs so it probably applies to Arch+Nix setup as well; I don't use Nix, just Arch). If I had more time to figure stuff like that out I'd definitely switch.

I went through this to learn to use Haskell with Nix.

Like all cabal woes, the answers are probably "cabal is not a package manager" and "try nix", the purely functional package manager. I haven't tried nix yet (sandboxes have reduced the pain enough that I don't feel the need to look for a better solution), but I can see in its documentation that nix supports uninstalling packages.

Yeah, off the top of my head NixOS currently has more packages and services, better tools for a few language ecosystems (Haskell, NodeJS, Go), support for more complicated partitioning, and you'll spend less time compiling stuff using NixOS than Guix System. Guix doesn't have anything like NixOps yet. You can use the Nix package manager on macOS.

Honestly, NixOS is probably the better choice if you need something to completely replace your current system right now. If instead you're looking for cool technology to play with, definitely don't dismiss Guix without trying it. And I don't think it will be too long before Guix is more polished in common desktop and server roles.

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.

Thanks for your feedback! This was very helpful information. Could you please open issue on github with proposed better solution? I don't know how to implement current behavior with stack install because it would be nice to have some embedded configuration which won't be changed at all (thus, it's not desirable you have some config.yaml).

One reason to implemen installing through shell script is because it's done this way for nix (rather popular and considered to be good technology in Haskell world): https://nixos.org/nix/

> "Nixos expression"

You should say "Nix expression". Nix is a package manager written in a purely functional language named Nix (nonrec/not-a-typo). NixOS is a nix-based distributive. Take a look at NixOS wiki, it is extremely informative https://nixos.org/wiki/Main_Page

Also here it is your expression https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/haskell/ghcjs-codemirror/default.nix

If you're interested in some other links, here is a number of blog posts that seemed pretty helpful for me when I has been diving into all that stuff https://gist.github.com/dmalikov/613fa59063604e51d323

And final note. There is no need in installing NixOS to get this feeling of nix usability.

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.

> DLL hell is what linux has now.

Is it really a "hell" though? Unlike Windows, which basically left their developers to their own devices for dependency management, Linux solves this problem with package managers like Debian's APT, or RedHat's DNF. Windows even has Chocolatey now, and Mac OS has Homebrew.

And now there are new technologies like Nix and Guix which take package management to the next level with their own functional declarative package management languages that use content addressable stores to hold packages.

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.

If you have a sufficiently recent version of nixpkgs you can do:

$ cabal2nix --shell https://github.com/commercialhaskell/stack.git > stack.nix $ nix-build stack.nix

If you have a local checkout of stack then instead do:

$ cd /path/to/stack $ cabal2nix . --shell > shell.nix $ nix-shell --run 'cabal configure'

... and then use cabal build and cabal test like normal. See also:

https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure

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).

Nix is a package manager that can support pretty much any language. The main repository nixpkgs supports C/C++, Haskell, Python, Rust, Lisp, .NET and a lot more.

It's not about stable and unstable, but a specific release and unstable. The releases won't receive breaking changes, and they do not get major revision bumps for most software. This means that when updating a specific release, your system configuration is pretty much guaranteed to keep working, and that software won't change from under your feet. A normal upgrade will not upgrade from a specific version (16.09) to another (17.03) unless you change the channel for your system.

Here's the relevant section from the manual:

> * Stable channels, such as nixos-17.03. These only get conservative bug fixes and package upgrades. For instance, a channel update may cause the Linux kernel on your system to be upgraded from 4.9.16 to 4.9.17 (a minor bug fix), but not from 4.9.x to 4.11.x (a major change that has the potential to break things). Stable channels are generally maintained until the next stable branch is created. > * The unstable channel, nixos-unstable. This corresponds to NixOS’s main development branch, and may thus see radical changes between channel updates. It’s not recommended for production systems.

The release notes lists the previous changes from version to version. This might help understanding what can change between versions. The release notes for the next version are available in the nixpkgs repository. I wouldn't know how exhaustive it is at this moment, 1 or 2 months from release. Though, it already describe changes from 17.03 to 17.09. Unstable is going to become 17.09 at some time.

https://nixos.org >NixOS is a Linux distribution with a unique approach to package and configuration management. Built on top of the Nix package manager, it is completely declarative, makes upgrading systems reliable, and has many other advantages.

Tried Nix OS? I only recommend it because I really want to try it but I don't have time right now to learn as different a system as they seemingly have.

If not Nix, it's time to go in the other direction and install Slackware. It meets none of your criteria, so it'll be the most "new" to you.

Most Linux distros have been doing this a long time. Apt was released in 1998, yum in 2003 and there were other solutions before that. Then there are projects like nix that are designed for reproducible environments.

I don't understand why Mac doesn't have a decent solution outside of the third party Homebrew.

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.

The 2 external repositories I use the most regardless of distro are flathub and nix.

Flathub (as a repository added to flatpak) has most of the popular software I need that I can't get in the distro's included repositories, like FreeTube, ungoogled-chromium, for example. https://flathub.org/home

nix (which is available as a package manager for all distros) has almost as many packages as the AUR (nix has over 60,000 at the time of writing). https://nixos.org/

GNU guix is a fork of nix, I don't use it, but there are some packages in there that are not found in flathub or nix. https://guix.gnu.org/en/packages/

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

Thats a great question! The main requirements are some nix knowledge, at least enough to create a package, an understanding of git and github, and a bit of patience. You don't need to be a nix master to just make a package. You can just find similar packages in nixpkgs and use those as templates.

The goal is to get the package in nixpkgs(github.com/nixos/nixpkgs). You will have to create the package expression and submit a PR with it. This is the best place to learn all the specifics: https://nixos.org/manual/nixpkgs/stable/#idm140737317101008. You also have to be patient, it can take a while for packages to be reviewed.

Updating packages is much easier, you usually just change the version and the src sha256 hash. But it can be more complex depending on the package - slack, for example, needs an update script because it has multiple sources. Most packages only have one source though. Update PR's get merged much quicker, because they don't need as much review.

If you need any help with it, feel free to ask and if you post what package it is, I might be able to give you some tips.

Solus covers point 1 and 2.

Is there anything specific you need from AUR compared to manually compiling? If you want package management for compiled binaries there is Homebrew or using Nix package manger as a user space program.

Aside: posting this comment prompted me to try again.
Long story short, on macOS 10.14.1, I installed Nix using the multi-user method[1] and everything seems to be just fine.

Please see my previous comment about "lack of expertise" :)

[1] https://nixos.org/nix/manual/#sect-multi-user-installation

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.

You might want to start by having a read through the documentation in the nixpkgs manual, which outlines a few "flows" as to how you can use the Haskell support that Nix comes with: https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure

The trouble of Linux distributions is that they enforce dynamic linking for everything. In Android (or in the App Store, or in Windows even) there's a set of libraries that are part of the "system" and you can safely link against them; everything else needs to be shipped by the App.

Now, the Linux way solves a huge security problem (if there's a security update for a library, it needs to be applied only once and will fix every app using it), but it also greatly complicates package management.

In particular, most systems can't have multiple versions of the library installed (and for those that can, this is often a manual set up), so updating a library for an app may break another. You need to carefully synchronize the update of important libraries. And that's why you need a centralized package repository for ALL software in the first place.

Note that this can only possibly work for free software. Android, iOS and Windows were made with proprietary software in mind (even if some of their components are free software), and simply let each app ship their own libraries. Proprietary OSes always worked that way.

One package manager that solves the dependency problem is Nix (and there's an OS built with it, NixOS). It works because each package is actually independent from others (so it can install the same package with different versions, no problem). But it's an smallish distro and has a lot of outdated packages.

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

That's how it's supposed to, uh, work. On my NixOS VM, everything in /etc/systemd is a symlink to /etc/static, which is in turn a symlink to /nix/store/very_long_string-etc/etc. Nothing in /nix/store is writable by anyone.

The manual has some material about user-specific systemd services, but I'm afraid I can't make heads or tails of it. Maybe there's some way to get everything to work by editing /etc/nixos/configuration.nix. Good luck.

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

NixOS can also be great for this, each system update is atomic and creates an entry in GRUB/systemd-boot. (fyi https://nixos.org/images/screenshots/nixos-grub.png)

If an update messes up your system (so far I haven't had this), or you mess something up, you can just rollback to a previous system version.

Having BTRFS is still handy though for snapshotting your home directory.

Did you hear about nix? It has great ~~sometimes unstable~~ haskell support.

I wrote a blog post Running Haskell Scripts precisely about this. I hope it helps :-)

I have everything in a config file, which I version controlled.

Config file: https://github.com/hsek/nixos-config/blob/main/t480/configuration.nix
configuration.nix manual: https://nixos.org/manual/nixos/stable/index.html#sec-configuration-syntax

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

Definitely NixOS. One of the major complaints of that OS is that documentation is pretty bad.

Ask around their community for pointers on where to start.

https://nixos.org/

edit: Writing docs is probably one of the best things you can do for a project, since it's so undervalued and many programmers can't write. Thanks for volunteering your time and skills.

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.

A lot of the build issues would be solved by using nix, but since you have 5k engineer the move towards nix would be non trivial. (just teaching nix alone would be a significant effort). Your workbench.yaml would be nix files, your caching problems would be solved by the nix store and your OS versions wouldn't matter because the haskell code would use the nix store.

And NixOS as well. You want symlinks, we've got trees upon trees of symlinks. Doesn't even have a /bin, /sbin, /usr or /lib *

^(* /usr/bin/env and /bin/sh exist for compatibility reasons and are linked to the system programs)

You can set up a Factorio server on NixOS just by adding the following to your system configuration file:

services.factorio.enable = true services.factorio.public = true services.factorio.username = "$YOUR_USERNAME" services.factorio.password = "$YOUR_PASSWORD"

Other options: https://nixos.org/nixos/options.html#factorio

Messed around in a vagrant box to test different install methods.

Stack doesn't seem to have it yet:

$ curl -sSL https://get.haskellstack.org/ | sh $ stack --compiler ghc-8.4.3 ghci Writing implicit global project config file to: /home/vagrant/.stack/global-project/stack.yaml Note: You can change the snapshot via the resolver field there. Using latest snapshot resolver: lts-12.0 Downloaded lts-12.0 build plan.
No setup information found for ghc-8.4.3 on your platform. This probably means a GHC bindist has not yet been added for OS key 'linux64-ncurses6', 'linux64-tinfo6'. Supported versions: ghc-7.8.4, ghc-7.10.2, ghc-7.10.3, ghc-8.0.1, ghc-8.0.2, ghc-8.2.1, ghc-8.2.2, ghc-8.4.1, ghc-8.4.2

But Nix worked out of the box:

$ curl https://nixos.org/nix/install | sh $ nix run nixpkgs.haskell.compiler.ghc843 -c ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.3

The instructions in your ghc link installed an old version of GHC, but OP wanted 8.4.3. AFAICT, there's only one GHC version in the package repo.

$ sudo dnf install ghc cabal-install $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.2

The Haskell Platform also came with outdated packages:

$ sudo dnf install haskell-platform $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.2

You can add an unofficial repo though, which is mentioned in that ghc link:

$ sudo dnf copr enable petersen/ghc-8.4.3 $ sudo dnf install ghc cabal-install $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.3

This does not change the GHC version with the Haskell Platform, however:

$ sudo dnf copr enable petersen/ghc-8.4.3 $ sudo dnf install haskell-platform $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.2

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.

Same solution really. Just ignore arch package management and use the appropriate nix manual section. Have had exactly zero problems (specifically related to arch+nix, nix needs workarounds for opengl applications outside NixOS). It's better to have nix update itself anyway.

Definitely agreed there. While not Clojure, it was close enough while being small and fast. I used it to do some shell scripting stuff and it was really nice for that, though I started looking elsewhere for that (Planck and Lumo, Gauche Scheme) after development on it died out.

Despite that I still use something I made with it, and occasionally have to dig into the code to tweak it. I'd gotten tired of using a bunch of disparate nix commands, and nox didn't work correctly for me at the time, so as an excuse to spend some time with Pixie, I hacked together a vaguely apt-like wrapper (named nixie, naturally) to save me some trouble. After Pixie became a bit of a dead end I lost the motivation to polish and release it, but I still occasionally do some tweaking here and there if something comes up.

I noticed there's some activity on the pixie git again, so maybe it will pick up once more.

> This way there would be no disruptive changes over time, they would happen in a more controlled way when you upgrade from one version to another.

Very large upgrades every few years tend to be much more disruptive than small changes now and then, but rolling vs release-based seems to be a matter of taste/priorities.

Stable+backports works well for me and is mostly recent enough. Before that I used testing+pinned unstable, so that you can manually get newer versions in case something is removed from testing.

With stable, for the few cases where I actually want to use/try something newer that is not backported, there are multiple options:

Nix allows you to install new software and multiple versions of libraries in a selfcontained way on top of any linux distro.
On wheezy I have a schroot with jessie for running steam and some other games (newer libc etc.). This is actually surprisingly easy to setup and works very well.
The newer version of this would probably be docker or systemd-nspawn, but this seemed like overkill at the time.
virtualization is of course always an option.

For your desktop suggestion and criticism of testing/unstable, I think a better strategy would be make more use of snapshots and the like (see for example pcbsd), so that any update causing problems can be immediately and effortlessly rolled back. This already is possible now (btrfs, lvm and snapper), but lacks the integration and polish necessary for desktop use.

Thanks. I forgot that other people actually distribute software to end-users! I'm stuck in the web-service world and don't have to think about that.

I got the impression that Nix could be something of an alternative to Docker in the Haskell world. Apparently NixOS also provides its own containers solution ...

IMHO the solution to the dependency thing isn't that programs include their dependencies, but rather explicit support for having multiple versions of something installed.

P.S. Take a look at nix

Hi,

You can take a look at the Nix package manager and the NixOS distribution (not required to use Nix and its environment features) which will fit your demand and many more ;-)

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

The nix package manager of NixOS also works on other operating systems and allows users to install their own packages into their user environment:

https://nixos.org/manual/nix/stable/#chap-quick-start

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.

If you're using Nix (which works on all distros and macOS in a non-conflicting way), you can use my https://github.com/infinisil/all-hies to get precompiled binaries for the GHC versions you need.

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.

You could try using the nix package manager. They have version 3.1 available (not sure if that's the latest version or not). It launched fine for me:

curl https://nixos.org/nix/install | sh . ~/.nix-profile/etc/profile.d/nix.sh nix-env -iA nixpkgs.gnucash gnucash

Depending on what you need to do in your script you might be able to just use the xrandr options:

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

Your config will probably all be in /etc/nixos/configuration.nix which is where you can set the above options. It should have been generated by the nixos-generate-config --root /mnt step in the installation.

I would think you could run this again post install, but I haven’t checked.

It also has decent comments about where to put package and config lines.

Oh-my-zsh is a package you can add to that same configuration file (along with zsh itself, and options to make that the default shell). As well as a bunch of options for oh-my-zsh.

I basically have the following two links open all the time and reference them a lot. Good idea to just browse through to see what’s there as well.

https://nixos.org/nixos/packages.html https://nixos.org/nixos/options.html

After editing your configuration.nix you will want to run sudo nixos-rebuild switch which will switch your system over to your new settings and packages.

Hope that helps.

Have you tried using Nix? It has some really great features for building docker images. There is a good description of using it for building small docker images here. One thing not discussed there is the fromImage argument that you can pass to buildImage to allow you to make layered images. More details can be found in the docker tools section of the nixpkgs manual.

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.

overridePackages was a function made to replace multiple packages at once. As far as know, it was not commonly used. The overlays neither replace the override nor the overrideDerivation functions.

The overlays provide an alternative to the overridePackages function which in addition allows to combine multiple overlays easily. Combining overlays is the major point, and the relevance of it will grow as more actors might want to distribute software, but might not necessarily can/want to push it in Nixpkgs, either for maintaining forks of a limited set of packages, or providing custom versions, ...

If you are interested in overlay, the nixpkgs-mozilla repository provide an example which package all latest versions of the rust compiler by extending Nixpkgs with an overlay.

The release note section about incompatible changes contains an example on how to convert overridePackages uses to the overlay mechanism.

I'll also be looking into this. (https://nixos.org/wiki/How_to_install_nix_in_home_(on_another_distribution)#PRoot_Installation)

edit: [Proot binaries are unavailable (the links no longer work), but I'm able to find the source]

It seems like Guix needs sudo at the very start (https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation)

I've used NixOS a lot before. If you're into programming, it's a lot like functional programming. What makes NixOS unique is the package and system management. You have a file, configuration.nix (a couple others can exist too,) and in that file you declare many things, such as your hardware, packages, users, software configs, and even things like Udev rules. After modifying that file, you rebuild the system (doesn't take long) and most intriguingly, old packages and configurations are saved! So if configuration.nix 45 broke things, you can simply select 44 in GRUB to get back, rollbacks are incredibly easy. It also allows for some interesting features such as non-privileged users being able to use a package manager to install packages.

That's a bit of a layman's overview I think. What happens behind the scenes is fairly complicated. Packages are stored in folders differently from how they're stored in traditional distros to make this possible, with very large automatically generated paths. This makes some things difficult, such as running software off the internet because your libs will be in a different place. For example, the install script for steam has to setup a chroot to make it work. I'd read the handbook if you want to know more about how the system is designed, how the hydra buildserver works, etc..

https://nixos.org/wiki/Real_World_NixOS_Dotfiles here's some examples of how people configure their system.

I'd actually love to get back into NixOS, it's a lovely distro and a lot of fun when you get the hang of it. Sometimes you will have to put in work yourself for getting certain packages, it's not too difficult though.

This is what we are using: https://nixos.org/nix/

It's like those native package managers but we wont have the problem of packages breaking each other and we can ask for EXACTLY the config we want and thats what we get

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?

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.

Nix is probably what you're looking for: https://nixos.org/

Here's my current list of packages that are installed on all of my systems: https://github.com/Atemu/nixos-config/blob/4c76b06c4adb984c764a301435f12db179beb92d/packages.nix

Thanks to the Nix expression language, you can even split this up, load different sets of package sets on different machines and modularise them. I have already done some basic modularisation based on platform and whether or not the machine has a GUI for example but there's basically no limitation to what you can do here.

NixOS can do a whole lot more than just managing a set of packages, so perhaps home-manager would be a more minimal, less intrusive solution too. It has a ton of other features too though.

You can change all the PKGBUILDs you want to use such that they dump their stuff where you want it.

It probably makes more sense to use a system that supports this use case. Even something like nix might be interesting.

You could use the trivial builder <code>runCommand</code> and use sed, <code>wrapProgram</code>, <code>substitute</code> or anything else to perform the substitutions.

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

I agree with almost everything you wrote. NixOS is very different, and not much knowledge (outside of very low-level features) transfer very well from a traditional distro.

Just one comment:

> Writing configurations for services is not easy. You either add the file as a "here-document" in the /etc/nixos/configuration.nix or you need to add it to the nix store and address it in the service configuration (in the same file: /etc/nixos/configuration.nix).

You can write your own modules, then include the paths using the imports mechanism: https://nixos.org/manual/nixos/stable/#sec-modularity. This is used to great effect with nixos-hardware, which has a multitude of fixes for specific hardware / laptop configurations.

With arch, you would go to the wiki and apply some of the suggestions for your new thinkpad t460. With NixOS you would just do:

imports = [ ./hardware-configuration.nix <nixos-hardware/lenovo/thinkpad/t460> ];

What is Reddit's opinion of NixOS?
From 3.5 billion Reddit comments

➔ NixOS website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

What is Reddit's opinion of NixOS? From 3.5 billion Reddit comments

➔ NixOS website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

What is Reddit's opinion of NixOS?
From 3.5 billion Reddit comments