[HN Gopher] NixOS Linux
___________________________________________________________________
NixOS Linux
Author : lemonspat
Score : 145 points
Date : 2021-01-10 18:54 UTC (4 hours ago)
(HTM) web link (nixos.org)
(TXT) w3m dump (nixos.org)
| setheron wrote:
| 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.
| pmarreck wrote:
| 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.
| nincompoo wrote:
| 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?
| Ericson2314 wrote:
| > 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.
| ertian wrote:
| 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.
| whateveracct wrote:
| 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.
| ertian wrote:
| 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.
| pachico wrote:
| Just to see if I understand, does this mean you might end up
| having dozens of libcurls?
| choward wrote:
| 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.
| pachico wrote:
| I understand, thanks. It wasn't a criticism, I honestly asked
| out of ignorance.
| 1vuio0pswjnm7 wrote:
| 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.
| rowanG077 wrote:
| 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.
| mcint wrote:
| This is the killer use case, and the initial primary(?)
| design justification.
|
| https://nixos.org/guides/how-nix-works.html
|
| https://edolstra.github.io/pubs/nixos-icfp2008-final.pdf
| ReactiveJelly wrote:
| 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.
| MetaDark wrote:
| 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.
| Ericson2314 wrote:
| 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.
| ertian wrote:
| 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.
| colejohnson66 wrote:
| Is that any different that Docker?
| choward wrote:
| It's better actually since you can share some libraries when
| possible.
| axelf4 wrote:
| Nix derivations are also lighter than containers. Just
| ordinary packages.
| haolez wrote:
| 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.
| fooblat wrote:
| 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.
| dang wrote:
| 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.
| tbenst wrote:
| 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.
|
| [1] https://github.com/nix-community/home-manager
| jackinloadup wrote:
| Can anyone talk to if nixos can reasonably be used to run a
| desktop setup?
| hollerith wrote:
| 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.
| X6S1x6Okd1st wrote:
| 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.
| ertian wrote:
| 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.
| Ericson2314 wrote:
| 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.
| jbboehr wrote:
| > 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.
|
| [0]: https://github.com/NixOS/nixpkgs/issues/100655
| jeppesen-io wrote:
| 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
| amelius wrote:
| 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].
|
| [1] https://news.ycombinator.com/item?id=16443323
| chaorace wrote:
| I 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.
| camehere3saydis wrote:
| > 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.
| tetris11 wrote:
| Still waiting on LDM...
| Ericson2314 wrote:
| > 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.)
| Nullabillity wrote:
| I was using XMonad+KDE on NixOS just fine for about a year at
| my old job.
| jeppesen-io wrote:
| 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
| [deleted]
| indemnity wrote:
| 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.
| techdragon wrote:
| 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.
| tikhonj wrote:
| 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.
|
| [1]: https://hub.docker.com/r/nixos/nix/
| mcint wrote:
| 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).
|
| https://nixos.org/guides/nix-pills/
| tikhonj wrote:
| > _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/
|
| [2]: https://github.com/target/lorri
| indemnity wrote:
| Out of interest, how does this work if using something like
| Visual Studio Code or some other IDE?
| GrantZvolsky wrote:
| 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.
| tikhonj wrote:
| 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.
|
| [1]: https://github.com/politza/pdf-tools
| callahad wrote:
| 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.
| 0xCMP wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-10 23:01 UTC)