NixOS Linux
nixos.orgI played with NixOS and am willing to admit that it was too difficult. It's probably great for devops, but it's just slightly too rigid for my own personal use.
Let me give an example: let's say you want to use xmonad on top of Plasma. NixOS doesn't have any simple way to configure that. You have the mutually exclusive options for one or the other, basically.
I know Nix is powerful enough to do this, if I wanted to go offroad and create custom packages/derivations, but that's the point where I am no longer happy with the utility/work tradeoff. It's what ultimately sent me packing back over to arch.
When I came back to arch, I was left hankering for NixOS's declarative package management, if that could be somehow reconciled with the baseline arch package system. This led me to using the aconfmgr utility, which checks in packages and system configuration files into a home-based filetree.
Once you've got it set up, aconfmgr can regenerate your current configuration from scratch, declaratively! I was able to check the aconfmgr tree into my dotfiles repo, so now it tracks my home state AND my system state. Unlike Nix, this still uses file-based configuration, but it's all versioned and fully reproducible, so I no longer particularly care about that caveat.
> Let's say you want to use xmonad on top of Plasma. NixOS doesn't have any simple way to configure that. You have the mutually exclusive options for one or the other, basically.
I was pleasantly surprised to find the contrary to be true: in my experience, NixOS is the only distro to give you _every_ DE+WM combination pre-generated as a login session that you can pick from the display manager.
Still waiting on LDM...
Don't bother with NixOS then. Just use the nix package manager on Arch. You get declarative package management with nix shells, and you can take that configuration with you to any linux distro, or even macos.
I think it's fantastic that we have a declarative, deterministic, idempotent package manager that works across all these OSs. I've used it happily for years now without ever bothering to try NixOS.
That's my other issue. Nixpkgs just isn't as rich as AUR. I'm willing to use mostly nix OR mostly pacman, but not some 50/50 split of both, which is what the current situation tempts. I'd be extremely pleased if there were some sort of adapter plugin that let nix manage external packages so that I'm not forced to choose.
> it's just slightly too rigid for my own personal use.
I get what you're saying, but the reality is the opposite. Nix is _far_ more powerful and flexible than anything you can do in Arch. It sounds to me like you just wanted a particular packages available, and Nix didn't have that. But if you have the inclination to learn Nix, you will be able to customize your system, in a safe and repeatable, declarative approach, far more than you could ever do with Arch.
It was simply too difficult for me to do that. I learned the language, built derivations, then realized it was just way too much work for what I wanted. I like what Nix brings to the table, but, ultimately, I was perfectly happy to compromise the bullet-proof integrity of nix for the simplicity of pacman + aconfmgr. It's the perfect blend for use on my own daily drivers.
With that being said, I would use NixOS over arch + aconfmgr 10 out of 10 times in a production DevOps environment. What time/effort you give up in terms of instant usability is immediately recovered when you start working in terms of modular and widespread system deployment.
I agree with what you're saying. It probably took me about 2 weeks to build my first NixOS desktop about a year ago. Now I manage everything in a single repo, including all my dotfiles, all via nix. It works great. But there was a very steep learning curve.
After that experience, I'd actually hesitate to use NixOS in a production environment. The main problem is Nix and the library functions themselves are incredibly obtuse. It also doesn't help that it's a dynamic functional language, so everything just looks like magic when you're first using it. I think most engineers would really struggle with it. I'd be more comfortable introducing Haskell - I think it's easier to learn and understand!
> NixOS doesn't have any simple way to configure that.
It's been a long time since I last used XMonad, but wouldn't the following configuration suffice?
Even if there isn't an official NixOS option to configure things the way you want, you can always put whatever configuration you like with the "environment.etc" option. For example, the following configuration would create a file in /etc/example/example.conf with the line "name=value".services.xserver = { enable = true; displayManager.sddm.enable = true; desktopManager.plasma5.enable = true; windowManager.xmonad.enable = true; };environment.etc."example/example.conf" = '' name=value '';> xmonad on top of Plasma
I gave up on XMonad + Gnome before I switched from Ubuntu to NixOS 6-7 years ago. Does XMonad + KDE work? I would love to get such combos working in NixOS / home-manager.
(We also need to bite the bullet and get X-less Wayland working properly. I think I might be tempted to plan everything out at once so we don't get conflicting refactors or too much complexity.)
I was using XMonad+KDE on NixOS just fine for about a year at my old job.
Plasma (on X) generally works very good with other WM. Here's how to use i3: https://github.com/avivace/dotfiles
The big idea in Nix is the view that the filesystem is like mutable memory in a programming language.
You wouldn't give access to memory raw without any safeguards. (Typical package managers can just arbitrarily dump files or remove files)
It takes a structured approach. Laying over a graph database on top of your filesystem which is read-only typically.
This helps provide guarantees and also every application has its own hermetic sealed dependency closure.
Nix is truly revolutionary and it's getting steady adoption. Give it a read if you don't know about it. You can adopt it on any Linux distro without using the full NixOS.
I write a lot about it on my blog.
I love the guarantees given by Nix (I'm an immutable/functional-lang dev, Elixir specifically, so I really do get that), and I get that introducing a certain amount of complexity is sort of unavoidable when going in this direction (similarly, functional languages have a learning curve), but Nix for some reason still isn't clicking for me- I don't know if its UI is just terrible, its learning curve too steep, or something... but it's the sort of thing you can't just dabble in, you have to commit 200% to... and I think that's asking a lot of people. To use the cost/benefit analogy of functional languages, it feels like Nix has a much steeper cost to get the (admittedly unique) benefit of a completely deterministic software stack.
I find android way much simpler. On android every app has its own data and app directories, and you can uninstall, clear data or clear cache of apps safely. I know this method doesn't work out of the box with traditional desktop software that assumes a Unix like filesystem hierarchy. But Nix doesn't work out-of-the-box as well. I would be interested to know what other advantages Nix / GUIX bring in practical terms.
Nix is far more than just an app with its own directory (Which is also the flatpack & snap approach):
A little not exhaustive list of features that Nix provides:
- Not only an 'app installer'. It is a fully feature functional build system where reproducible builds are guaranteed (This is unique with GUIX up to my knowledge) on any linux distribution. Safe-reliable distributed builds are also possible.
- Fine grain de-duplication of dependencies (libraries, frameworks) to save disk space
- Safe, unprivileged installation of binaries in a multi-user environment on a single machine.
- Atomic upgrade and rollback
- Allow multiple variations of the same package with different options & versions installed in parallel without any risk of conflict
- Solves definitively all ABI breaks problem you encounter on traditional package manager, even with shared library.
If you want to get in to Nix I think two important things to note:
1. Nix is not a "package manager" and I think it's better at first to not think of it as one because you'll assume how it works incorrectly. It is a package manager, but it doesn't have the same workflow as yarn or etc. That trips a lot of people up.
2. You need to read the Nix Pills documentation. It is not long and guides you through every abstraction so you understand from the basics how it works. Nix is actually pretty self descriptive. I setup my home's Linux Router entirely by just hacking and searching through the nixpkgs repo without understanding things, but if I'd read the Nix Pills things would have been so much clearer to me. Especially when debugging or reading through what a derivation was doing.
I've been using linux based operating systems for 20+ years and I decided to give NixOS a try recently. I had read the install was "difficult" but I found it very straightforward.
The configuration system very easy to understand and work with. I think this is actually the perfect distro for a "one off" home server because configuration management is built in so it is easy to rebuild my server from the backup of a single file.
The install is "difficult" in the sense that there is no wizard-style installer like many other distros have. You can install e.g. Ubuntu or Mint without knowing what a disk partition is. You need to have at least some vague idea of what a disk partition is to install NixOS.
It's much easier than most manually-configured installs (e.g. gentoo) though, because pretty much everything other than partitioning the disks has a default, so you need to make fewer decisions at install time.
NixOS and the nix package manager are revolutionary OS tools, hampered by a convoluted, undocumented language and library (itself called Nix).
Despite this, I think it's totally worth going through the pain of learning Nix to use NixOS. There is nothing else like it. I imagine other OS's will try to copy and borrow the ideas, in fact they are already doing this (see all the half baked immutable OS stuff out there...), but nothing is as good as NixOS at the moment.
Note: A notable exception is GNU Guix, which is another excellent OS/package manager that is very similar to Nix, with the far more approachable Guile (scheme based). Unfortunately the ecosystem is just not large enough to be usable for practical purposes - also it's hampered by the usual aversion to non-free software.
Before installing NixOS, I’d recommend anyone on Linux to give home-manager a go first for the userspace declarative approach with Nix. After a year with full-time NixOS, I switched back to Ubuntu + home-manager as best of both worlds—declarative when feasible, imperative when convenient.
I had the same experience as well. I tried NixOS once as my main desktop environment. I encountered two problems that made me switch to Ubuntu+Nix. And they work perfectly for their own purposes.
One problem is dynamically linked binaries, where the library points to a global position (like /usr/lib). In NixOS, different builds can depend on different versions of the same binary, so there is no single global location. This is not necessarily a bad thing in itself. And normal cases can be fixed with the patchelf [^1] utility. I couldn't make it work with a Z3 binary, so I finally gave up.
The other problem is when I tried to configure jackdbus. There's only one example [^2] configuration. It is marked as outdated by the wiki, and indeed none of the settings work for me.
Then I realized these two are not problems that Nix tries to solve. Pointing to a global binary is okay for some quick fixes. And JACK module is better to work out-of-the-box, I don't want to dive into all of the configurations before I haven't even used it.
Now I use Ubuntu for casual desktop applications and write Nix derivations for projects that need reproducibility. And I think I find my perfect balance.
[^1]: https://github.com/NixOS/patchelf [^2]: https://nixos.wiki/wiki/JACK
Nix is a powerful package manager. I can confidently compile and run multiple incompatible versions of software simultaneously. I can build projects from years ago. I can package large projects from different ecosystems (python 2/3, c/c++, go, Javascript, Octave, Rust) and be confident they will not interfere with each other. I can try bleeding edge software with no risk to it interfering with my system. It is faster and less hassle than juggling various Docker containers and VMs. It protects me from dependency hell. Using Nix to manage an operating system (ie: NixOS) then gives me those benefits for my entire machine. Then I get even more benefits when using Nix on any other (not even necessarily NixOS) machine by pushing around package closures and managing a simple binary cache.
But overall: it makes me more productive. It is my secret weapon to manage the complexity of software development.
Kind of off topic, but I would love to have NixOps (https://github.com/NixOS/nixops) as an abstraction layer for every type of cloud service, and not just virtual machines (e.g. queues, object storages, etc).
There is Terraform and Ansible, of course, but Nix seems like it could combine the strengths of both of them.
There are actual plugins for AWS, Hetzner, GCP and Azure (on an old version of NixOps) and it's quite easy to add support for your favorite cloud if there is a decent usable API.
I use Void now and like not having systemd. Can I install Nix on my Void? Do I then just stop using the native package manager?
Or would it be better to install NixOS? Could I then choose not to use systemd? Would that be hard?
Is the idea that you can define your system in a file and reproduce it more or less automatically?
How does this compare to Guix?
> Can I install Nix on my Void?
Yes. (And you won't need to use systemd with just Nix and Nixpkgs)
> Do I then just stop using the native package manager?
No
> Is the idea that you can define your system in a file and reproduce it more or less automatically?
Yes
> How does this compare to Guix?
Very similar. Guix is a fork -> rewrite, with more Scheme and more FSF policy. But core concepts have not diverged.
NixOS uses systemd pretty heavily under the hood. You configure systemd services in the Nix language as part of your system config. It's quite nice.
Yeah, configuring systemd with Nix changed it from annoyance to a pleasure for me. Instead of fiddling with a bunch of random .service files, you can just do everything in a nix config and have them generated for you. Complex systems involving a bunch of units (services, timers, paths, whatever) can all be in one single place--alongside the service config. You can easily share defaults between units.
It's so much nicer than doing it ad-hoc.
You should probably be able to run Nix on Void. It might get awkward running two parallel package managers, but I've heard good things.
The idea of Nix is that you can specify a package's dependencies very explicitly, and have it build in a hermetic, and reproducible, environment. It can handle all sorts of dependencies, be they same-language libraries, binaries, or native system libraries. You can think of it sort of like firing up a docker container in which to run your build--if it works once, it'll always work, and if it works here it should work everywhere.
NixOS adds to that by essentially making the running system one of the packages managed by Nix. You specify what packages should be installed, how those packages should be configured, what services should be run, users that should exist, etc. When you build, the operating system you're running on is replaced with the new one. If anything breaks, you can trivially roll back. If you build the same config on a different host, you'll end up with the same system (albeit with slightly different package versions).
Guix is basically a fork of Nix (or started that way); it's got a very similar approach to Nix (and GuixSD to NixOS). It uses Gnu Shepherd instead of systemd, and uses Scheme for system config instead of a custom language.
I tried to use nixOS as a desktop system.
Using a special command (nix-shell) whenever I needed to do development things (e.g. Rust builds) was not my idea of fun.
Some other things, like overriding GDM's monitors.xml file, were pretty much impossible to do.
Maybe it's better if you just use it as a base for servers / containers.
> Using a special command (nix-shell) whenever I needed to do development things (e.g. Rust builds) was not my idea of fun.
Funny you should mention that, because that's exactly what got me using Nix everywhere :). I've always hated installing tools and libraries globally—what if I need a different version for a future project?—so I like tools that sandbox as much as possible like virtualenv, cargo, cabal... etc. But these tools are all language-specific and have their own limitations (especially around native libraries and dependencies written in other languages).
nix-shell gives me the equivalent of virtualenv that works for everything. I can have a single sandboxed environment even if my project uses a bunch of different languages and I can manage everything in a reproducible, low-overhead fashion. No more worrying about making a mess by installing tools or packages globally.
Then, once I got really used to that, I spent some time setting up direnv[1] and lorri[2]—both of which are themselves managed with Nix, of course!—so that my environment gets automatically configured as soon as I enter a project directory without needing to call nix-shell explicitly. To be honest, the experience is still a bit rough, but it works well enough day-to-day that I have my reproducible sandbox cake and eat it in an mostly frictionless way too :).
[1]: https://direnv.net/
Exactly. direnv/lorri basically solves the per-language virtualenv nonsense, but universally for anything. I use chezmoi to manage my shell.nix for various directories. That way every project can manage its system libraries independently. Once you get used to it, it's truly amazing. So much so, I almost think the future trend, once enough people become enlightened, will be checking in shell.nix as standard for development projects.
Out of interest, how does this work if using something like Visual Studio Code or some other IDE?
I've had sufficient success cd'ing into the project directory, activating my nix-shell, and then launching VS Code from inside that shell. In which case it inherits the shell's environment and most things work as expected.
There's surely a better way to do it, but I tend to prefer vim + lots of terminals over VS Code, so I haven't looked too closely at that workflow.
I use Emacs's direnv integration. Haven't had any trouble. It straight-up works better than alternatives I tried before like trying to turn pyvenv mode on automatically.
I also manage Emacs, its packages and its packages' native dependencies with Nix.
Having an automatic link between Emacs packages and native libraries has made my life massively easier. For example, earlier today I installed `pdf-tools`[1] just by adding (use-package pdf-tools :ensure t) to my init.el, and Nix took care of building and installing the native software needed to support it. I didn't have to go through any of the installation steps in the pdf-tools README[1], it just worked.
I'm on my laptop now, but when I get back to my desktop, all it will take to get pdf-tools working is pulling the latest version of my config from git and switching to it. As long as there's a version of the native libraries packaged for macOS, getting it working on my work laptop won't be any harder; if there aren't, I might either change the config to only have that package on Linux or I might write a bit of Nix code myself to build a macOS-compatible version.
pdf-tools is a cute self-contained example, but this has been even bigger for using lsp-mode and different language servers as well as other nice-to-have development tools.
For all the hassle that learning and moving to NixOS took—and still occasionally takes—I'm convinced that things like this have more than paid off for me and that I'm saving time on net.
Not who you're replying to, but I just launch the IDE from the shell. e.g. for running qtcreator:
If I need other libraries in there, I can add them to it. I don't use direnv/lorri, but I assume you would have to relaunch the IDE in the case of adding more dependencies, unless the IDE has nix-shell integration (like an emacs user mentions in a sibling comment).nix-shell -p qtcreator qt5Full gnumake gcc gdb cmakeI made a different way of setting up a development environment[1] that would probably work just as well for e.g. VSCode, that doesn't require restarting the IDE. I did this for lisp development, where dynamically loading libraries during development is fairly idiomatic; it took me about 15 minutes to write, and could probably be adapted for other IDEs as well.
edit: this is how my vscode is configured using nix on top of Xubuntu:
vscode is installed globally using the buildEnv-based declarative user environment approach (https://gist.github.com/lheckemann/402e61e8e53f136f239ecd8c1...). Then in individual projects I include language-specific dependencies such as dotnet-sdk_3 or google-cloud-sdk.
> Some other things, like overriding GDM's monitors.xml file, were pretty much impossible to do.
Quite the contrary. Nix makes it easy to override contents of files, even those that are part of a package. Some things to look for are: "mkForce" for NixOS modules; "override", "overrideAttrs", "symlinkJoin", and "meta.priority" for Nix packages.
Has the container situation improved? Last time I looked (quite some time ago) I couldn’t find an official or community blessed container to base anything on.
Nix supports containers as a build target or output format, but the nix tools are considerate (easy to uninstall) so there's no need (& little sense) in putting them in a container. You could run the nix install script in a ubuntu or alpine image.
I use Nix on macOS, wishing I could replace all my brew usage with it. Working on a home-manager derived setup.
The dev workflow mentioned by tikhonj https://christine.website/blog/how-i-start-nix-2020-03-08 (including a "derivation" building a container from the example project).
A nix derivation can be converted directly into a docker image, you don't need a docker file at all. It's actually very simple and quite intuitive.
I wrote a blog post about doing this with python, but it's straightforward to generalise.
I've used the nixos/nix image from Docker Hub[1] to run some CI scripts using Nix to build my projects.
As far as I understand it, it's basically Alpine Linux with the Nix package manager and tools preinstalled, but it worked pretty well for me.
This is the sort of thing I was looking for. There may not be much too it, (and as another comment mentioned, the package management tools can output containers) but having a blessed starting point shows a clear signal to potential user that it's not just an afterthought.
Related - I've been using home-manager on MacOS, WSL2 and NixOS. Very nice to have a single, small file to manage my dot configs and CLI tools on various platforms
I read most of the comments up to this point and was surprised that no one has mentioned how the system config is versioned, and the boot loader allows you to select from past builds, making it incredibly easy to recover from config issues (and thus also easy to experiment with different configs without fear of having to waste hours recovering a certain state).
I enjoyed learning the difference between NixOS, nix (eg, nix-build, nix-env,...) Nix Language, and nixpkgs.
Knowing the difference of tools in the belt is like knowing the blades themselves. You can always make your own tools.
If I can't package something with nix, then I call it "metal"
I'd love to try Nix. But, I'm using an Nvidia Jetson environment, which is based on a preinstalled Ubuntu 18.04, probably with lots of specific driver configurations that I don't want to touch (or reinvent). I've also learned that running Nix on top of Ubuntu is not the greatest idea, see e.g. [1].
A mildly insane possibility would be to install lxc and then use a system container to play with nix in.
I didn't realize how far along NixOS's package repo had come, but apparently it's in the top 3 now, according to this site linked from their news page:
Too many previous threads to list, but here are a bunch:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
The current thread seems pretty good so far, though, so we'll leave it.
I wonder if it's leaking into other distros.
Just like proglangs got destructuring and lambdas gradually.. maybe OSes are influenced by nix.
Oh definitely. The whole concept of immutable OS management - this stuff all comes from NixOS's influence. You see it in Silverblue for example, and other mainstream distros. They are a pale imitation but the influence is there.
There's also the reproducible build effort, which is somehow more parallel to nix, or cross pollinating than influenced.. but same spirit (and great work by lunar and his friends)
The last time I looked into Nix (a few years back) the expression language was very under documented which made it very difficult to use (e.g. searching for lots of examples to copy paste, instead of working from first principles). Has this gotten better?
Can anyone talk to if nixos can reasonably be used to run a desktop setup?
I am writing this to you from my NixOS desktop.
After I gave up on the idea of preserving an existing Linux install (that used a file system, namely, btrfs, that NixOS's installer does not currently handle), and just allowed NixOS's installer to nuke my block device (i.e., my "hard drive"), it was easy for me to set up and configure my NixOS install to my liking -- and I know very little about Nix and NixOS although I consider it worth learning, which probably greatly affected my attitude, which has historically had a large effect on whether I succeed or fail at sys-admin-y tasks.
Where the learning curve gets very steep is when I tried to build something from source code! I would've liked to have built Emacs 24.4 from source, because that is the version against which my Emacs Lisp code is tested, but I gave up. (I'm using Emacs 26 instead and spending time adapting my Lisp code -- something I probably never would've needed to do if I could've built 24.4 because I am moving off of Emacs.)
If you're using x86_64, there are tens of thousands of packages with pre-built binary packages, so it might be you never have to build something from source to get the desktop environment you want.
As long as what you want to do is already in nixpks it's extremely easy, once you stray from that you need to start learning how all of it works, it's not the best in terms of documentation & straight forward concepts, but I've been running it at my main desktop for 6 months now.
Sometimes it shines ex:
I messed up my x11 config as well as drivers and just booted into the previous generation like it was no big deal
I needed to install a version of electrum that was only available on a specific git commit. I just specified the commit and booted into a shell with it
Sometimes it sucks:
Learning to package arrive 3rd party software can sometimes be really complicated and it might be the only way forward.
Lots of steam doesn't work out of the box compared to Ubuntu.
> Lots of steam doesn't work out of the box compared to Ubuntu.
Make sure you're using Proton 5.0 until this [0] is fixed.
Second this. It's mostly been a pleasure, but Steam is a mess. And I just gave up on Android development on NixOS; I used a Ubuntu VM for that.
But starting off with a new computer, copying over a config file from one of your existing files, building...and ending up with _exactly the same system_, including all those tweaks to _this_ file and _that_ config, and the cronjobs you've set up over time, and all your different rc files, is magical.
Steam works fine for me. Also, the "NVidia prime" stuff from https://nixos.wiki/wiki/Nvidia works out of the box since 20.09. (Though i will be happy when Dell finally sells AMD graphics instead.)
Also I've made android packages (albiet ones that don't use much Java) using the Nixpkgs repackaging of the Android SDK.
I run Nix on my workstation and on my laptop, and have been doing so for a couple of years.
Most of the issues I ran into were just nix being different from other distros I use, so I did have to relearn a few things.
The remainder of the issues are the sorts of things one runs into with a non-rolling release distro. For example, a program I use got a feature I want last September. I'm going to have to wait until March for it to hit stable, since NixOS is on a September/March biannual release schedule.
The good news is that I am running the latest version of that package just fine now; Nix lets you install "overlays" of the package system into your home directory (or globally), and I just copied the package definition into the overlay, updated the URL and SHA256 sum to point to the new version and it "just worked."
Downside of course is when I upgrade to NixOS 21.03 (the march release), I'll have to remember to remove my overlay version of the package, or I'll be frozen on that version. There may be some fancy way to work around this which I haven't discovered, but since I have like 1 or 2 packages in that state at any time, I just manually do it when I upgrade.
I started using it as desktop os two weeks ago. I've been quite happy with it. Fast and snappy gnome desktop. Took half a day to install and get comfortable
Then anouther half day to get comfortable with home-manager to configure my user settings
If you're willing, its worth the effort
Just to see if I understand, does this mean you might end up having dozens of libcurls?
Yeah, you potentially could.
Generally you don't specify a specific version as a dependency unless it's necessary, but when 'building' the system, specific versions are used. If things break during an upgrade you can roll back to the previous version. Keeping those older builds around will mean keeping older versions of the packages used in those builds (libcurl, for example). Periodically, you can purge older generations (i.e. builds) and collect garbage, which will clear out packages that aren't used anymore. It would be very strange to end up in a situation where you had dozens of instances of libcurl _being used simultaneously_ (though I guess that would be possible if lots of packages had very special requirements, and ended up building libcurl with different flags or something).
There may be circumstances where you have a _specific_ version dependency, and you can specify that too. That would mean having multiple copies of the same package, even in a single generation. Obviously this usually means major versions, so you don't usually see _dozens_ of them. Having specific dependencies on minor versions would be a major code smell IMHO.
Anecdotally, my NixOS systems (both desktops and servers) can grow up to, say, ~50 gb of system files in a few months, at which point I'll clear out older generations and GC, which gets them down closer to a typical Linux distro size. Once or twice, I've seen a system balloon up over 100G when I was doing a lot of experimenting with packages.
Oh, and incidentally, most of the different versions are only visible to the packages that depend on them. Your 'default' environment is one such package, and only sees one of each of it's dependencies. It's not like you have dozens of instances of packages crowding /lib or anything (since /lib doesn't exist in the first place). You have to go looking in the Nix package store to find the actual files.
You could or you couldn't. It's your choice:
- Traditional distro: you cannot end up with that
- Flatpack, snap etc.: you cannot avoid that
Nixpkgs doesn't wontonly package multiple versions of libraries. But as you upgrade you will accumulate old builds of libraries until you GC. The meaningful question is not how many of X do you have installed, but whether you have multiple versions of X reachable from GC roots.
It could, depending on your use case, but normally all packages from nixpkgs share the same libcurl, so when libcurl is updated, all packages that depend on it will also be updated.
The old libcurl will still exist on your system to allow you to rollback to previous states of your system, but you can always run nix-collect-garbage if you want to free up disk space.
This is similar to the situation in Arch Linux where pacman keeps all downloaded packages, and you have to run paccache if you want to free space.
If any of software relies on different versions, yes. It beats not being able to use something because you can only have one version of a library shared.
How does this work with compiling software. For example, I routinely compile programs that use different versions of openssl. Does NixOS make this process any easier.
This is the killer use case, and the initial primary(?) design justification.
Yes that's one of the greatest things about nix. You can have 100 pieces of software installed that all use a different curl version without issues. You can also develop 100 piece of software/compile that all use a different curl version at once.
I understand, thanks. It wasn't a criticism, I honestly asked out of ignorance.
As an optional fun fact, from my Arch system:
- libcurl is 615,616 bytes
- curl itself is another 192,480 bytes
Not counting man pages.
Not repeating the others: If a package does end up using multiple version of the same lib, nixos can even deduplicate it somewhat, by symlinking one’s documentations to the other’s.
There's an optimzation I'm aware of where nix will de-duplicate individual files with hard links. This wouldn't be safe in almost any other context, but is safe with nix because the files are immutable. So you have have 100 variations of libcurl and only "pay" for the unique files.
Is that any different that Docker?
It's better actually since you can share some libraries when possible.
Nix derivations are also lighter than containers. Just ordinary packages.