[HN Gopher] What Is Nix?
___________________________________________________________________
What Is Nix?
Author : elsewhen
Score : 129 points
Date : 2020-05-20 21:01 UTC (1 hours ago)
(HTM) web link (engineering.shopify.com)
(TXT) w3m dump (engineering.shopify.com)
| ninetax wrote:
| We're doing a project right now to try to migrate to using nix
| for our python code that runs on a raspberry pi. It's been great
| in many areas, but pretty annoying when something doesn't work.
| You have to dig deep to fix errors.
|
| Of course we're trying to get numpy to cross compile from x86 to
| armv7 which involves cross compiling gfortran to get blas... so I
| guess a few bugs [1] are expected.
|
| Otherwise I've been really impressed.
|
| https://github.com/NixOS/nixpkgs/issues/88449
| siscia wrote:
| Really looking forward for knowing how Shopify use nix and what
| problem the find with it.
|
| I was advocating for it in my organisation but eventually we
| decided for a different technologies...
| lmickh wrote:
| Burke Libbey has a few talks that are available on YouTube
| including a presentation at NixCon about the work he is doing
| at Shopify. I would highly recommend checking them out if you
| are interested in Nix.
| Rafert wrote:
| Link to that presentation:
| https://www.youtube.com/watch?v=rYzjKCIqUVk
| burke wrote:
| Hi! Yes, and here's the link to my recent Nixology playlist:
| https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4.
| ..
| smabie wrote:
| I have always wanted to try Nix, but not sure how installing
| software from source outside the package system works. With Arch
| Linux, it's pretty easy to create an AUR package if it doesn't
| exist, or simply install it outside the package system. Is it
| easy to create Nix packages (based on the features of Nix, I'm
| guessing no)? What about if you don't feel like creating a
| package?
| burke wrote:
| I think it's about as easy as creating AUR packages most of the
| time, especially after the first one or two. You can create
| them in a more ad-hoc way than you probably expect. For
| example, this video shows an example of creating a totally-
| legitimately-real package:
| https://www.youtube.com/watch?v=1nU_hR2kod4 -- some of the
| follow-ups in the channel also show a little more work with
| that simple derivation ("package" in de-nixified terms)
| abathur wrote:
| You can use Nix on your existing OS with no obligation to
| install all packages with it. On macOS, I use Nix for most
| things, but I still use homebrew for a few things and
| occasionally download+install.
| roblabla wrote:
| Creating nix packages is actually pretty easy once you get the
| hang of it. Maybe a tiny bit more involved than AUR packages
| since it's a new language and all, but it's not _that_ much
| more difficult. When I was using nixos on my desktop machine, I
| made packages for my own personal tools, so it integrated in
| the system.
|
| It's also very easy to customize a package to suit your needs,
| and in fact makes for a very nice system to hack on open source
| projects. You can mostly setup an override in your $HOME to
| make a package's source come from your local disk, and when you
| install the package it will compile locally instead of getting
| a prebuilt binary.
|
| If you don't go through their packaging system... It's really
| easy to end up in a mess. There are ways to simulate a "normal"
| linux from within nixos, essentially making a chroot in which
| the various libraries are in their normal locations (achieved
| through an overlay filesystem). I believe that's what they do
| to run the Steam client. I assume (though never tried) you
| could use this to run other binaries without packaging. But
| then... what's the point?
| mehrdadn wrote:
| I'm still confused. What _is_ Nix? Is it an OS, or a package
| manager? From the looks of it it 's a package manager that I
| should be able to use it on any POSIX system, but I doubt that's
| the case?
| lmickh wrote:
| It is pretty easy to be confused. Especially since it is also a
| language yet all the other replies at the time have writing
| have failed to mention that.
|
| While I like the project as a whole, their naming is horrible.
| Just wait until you get into `nix-env` vs `nix-shell` etc...
| mehrdadn wrote:
| Thanks, yeah. Conceptually I'm having a hard time wrapping my
| head around it since package managers are so tightly tied to
| an OS... I feel like surely I can't just use it in place of
| (say) apt or pacman without causing problems? And I haven't
| even gotten to the language/shell/etc. as you mention...
| saurik wrote:
| Package managers are not tied to the OS. Essentially your
| fundamental misunderstanding here, from reading your
| comments, is that you are expecting a package manager on
| Ubuntu to manage "Ubuntu's packages", when the packages
| belong to a repository as accessed by a package manager,
| and "Ubuntu" doesn't really exist: "Ubuntu bionic" is
| merely "a bunch of deb packages that you can install from a
| particular repository using apt", while "CentOS 7" is
| merely "a bunch of rpm packages that you can install from a
| particular repository using yum".
|
| You can add Ubuntu eoan or even Debian stretch repositories
| to your APT configuration on Ubuntu bionic, and install
| those packages... now, the naming and compatibility of
| dependencies might be different as you get further and
| further from what you were "supposed" to be using, but they
| will download and install (at worst an installation script
| will be missing a dependency and the package will be left
| "half installed", which is a technical APT term).
|
| You can also install rpm on Ubuntu: it is even in the
| Ubuntu bionic repository. Now, what happens if you install
| an rpm file using it? It might very well overwrite
| something from a package you installed by apt, and neither
| might notice that happened. But you can do it. You can
| install yum (this will require manual install as I don't
| think yum is available from any common Ubuntu repositories)
| and then give it a CentOS 7 repository and install all the
| packages and what you will be left with will be
| approximately CentOS 7 (with some detritus from Ubuntu).
|
| So on any system apt is managing deb packages and yum is
| managing rpm packages and where those packages come from is
| just some configuration, so you can install apt on CentOS 7
| and use it to install packages from Debian stretch. You
| can't use apt on CentOS to manage CentOS packages as apt
| doesn't do that (though maybe you could teach it an "rpm
| method" or something but rpm's version numbering and
| dependency management aren't really the same so this is now
| just a confusing digression to avoid "technically you
| could" responses: yes, but then you are coding that
| yourself).
|
| The only real exception to all of this is the kernel, but
| not even always as the kernel is kind of a file, but the
| way it is configured in the master boot record could be
| different... but like, you might have some distribution
| local kernel patches that their tools rely on for some
| reason, and upgrading libc on a running system is fraught
| with peril even when you aren't doing something insane
| this, so like: don't do this, but know it works.
|
| I routinely thereby create a little folder on a
| Debian/Ubuntu box in which I can chroot to install a little
| world of an entirely different set of packages from a
| different package manager maintained by a different vendor
| as provided for some random specific version of their
| distribution. (Alternatively, rpm supports an argument to
| set the system root.) In that world there are no conflicts,
| as you made a folder for it.
|
| When you install packages from apt or yum, _usually_ they
| assume they could go in /. That is going to maximize
| conflicts unless you do the chroot. Nix has chosen to
| package their stuff not like that, and so you can install
| their packages on any other environment without it
| conflicting or overwriting.
|
| So no, you don't "use it in place of apt" to manage Ubuntu
| packages, but maybe Nic and Ubuntu have chosen to both
| package the same thing you want (this is hopefully common
| as both are hopefully quite complete) and so you _might_
| "use it in place of apt" because you don't want to install
| an Ubuntu package, you want to install a Nix package
| instead. And as Nix packages go to special folders
| automatically, it doesn't damage your Ubuntu install.
| lmickh wrote:
| You use the language to define the configuration, packages,
| and etc. NixOS isn't so much an OS configured by a package
| manager as much as it is an OS + package manager that you
| can configure with the Nix language.
|
| Then there is also lot of tooling to hid all of the symlink
| magic. It is very deep rabbit hole. Most of the quick touch
| examples will basically look like magic.
| solarkraft wrote:
| You're right that using 2 traditional package managers in
| the same environment will cause problems almost
| immediately, since both will want to control the same
| resources.
|
| This is less so with Nix, as it mostly operates on its own
| folder called nix-store, the binaries in which are then
| symbolically linked to. It is actually designed to be able
| to be used this way. I know people are using it on Mac OS
| and I intend to install more and more packages through it
| to later possibly transition to NixOS.
| exdsq wrote:
| One really cool thing about NixOS is you declare the OS just
| like you might a DockerFile, and you can choose which
| configuration file you use at booting time. This lets you
| install applications just during up-time (to try out a new
| tool), add it to the configuration file if you like it, and
| roll back to the version before if it breaks something.
| Versions are declarative too (PSql == X.X.X) and
| upgrades/downgrades are set there too. If I want to share an
| environment with someone I can just share the configuration
| file minus the secrets.
| enriquto wrote:
| > One really cool thing about NixOS is you declare the OS
| just like you might a DockerFile,
|
| But DockerFiles have a really terse, self-evident, trivial to
| read language. It is obvious what a given DockerFile means
| even if it's the first one you see.
|
| For nix; well, I have seen a few nix files and each one
| leaves me more confused than the last. Can anybody point me
| to good examples of beautiful, single-file, complete, self-
| contained terse nix examples that describe a few simple
| systems? Everything that I seem to find are small fragments
| of stuff.
| throwaway894345 wrote:
| This is because Nix needs to express a lot more so builds
| are reproducible and incremental. Docker doesn't care about
| these things.
| enriquto wrote:
| Even if Docker doesn't really care about this, the
| DockerFiles themselves can also describe a reproducible
| process, and they are certainly "incremental" due to
| caching (not sure of what you mean by "incremental").
| Does nix power merit such a big compromise against
| simplicity and readability?
| throwaway894345 wrote:
| > the DockerFiles themselves can also describe a
| reproducible process
|
| This is true, but Docker does almost nothing to support
| reproducibility. As soon as you do an apt-get,
| reproducibility goes out the window.
|
| > they are certainly "incremental" due to caching
|
| Caching is layer-based. Docker has no awareness of
| whether or not a particular dependency has changed or
| what is necessary to rebuild it. Docker only understands
| layers, which are inherently linear--you can only try in
| vain to force your dependency graph into that linear
| layer structure. An incremental build tool only rebuilds
| things that have changed (or whose dependencies have
| changed).
|
| > Does nix power merit such a big compromise against
| simplicity and readability?
|
| This is a good question. First of all, understand that
| Nix isn't intended to be a build tool, it's a package
| toolkit. It's intended to replace all of the stuff that
| the debian and centos people use to build and manage
| packages in apt and yum repos. That said, I personally
| think Docker's build system is _sooooo bad_ that under
| many circumstances, Nix does a better job.
|
| For example, if your whole repo is Go or Rust or some
| other language with a sane build and deployment story,
| then they already have incremental, reproducible build
| tools and it's fine for Docker to call into them (or to
| invoke them outside of Docker and just have Docker copy
| in the static artifact). But if you have a heterogeneous
| tree including C or Python or other languages which lack
| sane build tooling, then you need something to stitch all
| of that together in some (somewhat) reproducible,
| incremental fashion if you hope to be able to build
| reliably and in some timely fashion.
|
| That said, there are a few other tools that are purpose-
| built for this problem; however, they all tend to be
| poorly designed, buggy, and hard to extend. I'm thinking
| of Bazel, Pants, Buck, etc--all of which are clones of
| Google's internal build system, Blaze. So far, Nix seems
| to be the best in class, even though it doesn't aspire to
| be in the class at all.
| progval wrote:
| Because Dockerfiles delegate all the complexity to a
| package manager (apt, apk, ...), which has its own
| languages (eg. debian/rules for apt).
|
| Using Docker without any package manager doing this job
| would be a completely different story.
|
| And btw, you can also use Nix to build docker images. For
| example, here is what would be the equivalent of a
| Dockerfile but with Nix:
| https://nixos.org/nixpkgs/manual/#ex-dockerTools-
| buildImage
|
| > the DockerFiles themselves can also describe a
| reproducible process
|
| It's trickier. You need to pin all versions of all
| packages you use, even indirect dependencies.
| catern wrote:
| Dockerfiles which just pull packages from distribution
| repositories are not reproducible in the same way that
| Nix expressions are.
|
| Rebuilding the Dockerfile will give you different results
| if the packages in the distribution repositories change.
|
| A Nix expression specifies the entire tree of
| dependencies, and can be built from scratch anywhere at
| any time and get the same result.
| exdsq wrote:
| This file explains how to configure the system when you
| first set it up [0]. I've just added the one I currently
| have set up on my dev box to Github - it's not complex by
| any means but has what I need :) [1]
|
| [0] https://nixos.org/nixos/manual/index.html#sec-
| configuration-...
|
| [1]
| https://github.com/oneEdoubleD/nixos/blob/master/config.nix
| unzadunza wrote:
| I don't know if it's beautiful, but here is one of mine.
|
| It sets up me as a user: https://github.com/cswank/dotfiles
| /blob/master/nix/configura...
|
| Sets up a hobby app I built via systemd: https://github.com
| /cswank/dotfiles/blob/master/nix/configura...
|
| Defines a cron job that backs up my music files: https://gi
| thub.com/cswank/dotfiles/blob/master/nix/configura...
|
| Opens up ports in the firewall (they are all closed by
| default): https://github.com/cswank/dotfiles/blob/master/ni
| x/configura...
|
| The rest is pretty much boilerplate from the default
| configuration you get when starting from scratch.
| [deleted]
| yjftsjthsd-h wrote:
| > From the looks of it it's a package manager that I should be
| able to use it on any POSIX system, but I doubt that's the
| case?
|
| No, that's basically true. It's fully supported on Linux and
| Darwin, assorted BSD support is underdeveloped but in scope.
| mossity wrote:
| I started reading this thinking Nix was a programming language,
| became very confused when it started talking about files and an
| object database.
| tel wrote:
| It's kind of a mess.
|
| Nix is a collection of tools and systems that together form a
| highly reproducible build system.
|
| Nix is also a declarative, largely pure and lazy programming
| language that you use to design and specify the different build
| outputs for the Nix build system.
|
| Nixpkgs is, more or less, the only project written using Nix
| (and a lot of shell). It's a collection of many thousands of
| "derivations", many of the things you'd expect to be able to
| fetch from brew or apt. Each derivation encodes the steps to
| use Nix (the build system) to construct that output.
|
| NixOS is a Linux distribution built atop Nix, Nix, and Nixpkgs.
| The basic claim to fame here is "totally declarative system
| setup" where you write all of the configuration for your system
| in Nix, using Nixpkgs and some other NixOS specific tooling and
| libraries, and then "build" the entire system with high
| repeatability.
|
| Then there are a few other related projects such as Hydra (a CI
| server and binary cache builder--most of the time you don't
| build with Nix, just download the proper thing from the cache)
| and NixOps (an extension to NixOS which provisions whole fleets
| of servers declaratively).
|
| Finally, you don't need to run NixOS in order to benefit from
| Nix. Nix and Nixpkgs are (largely) compatible with MacOS and
| Linux. That means you can install Nix onto your existing MacOS
| or Linux system and use it a lot like you'd use brew or apt.
| That said, the premiere Nix experience is always NixOS.
| eloff wrote:
| This comment was better than the article at explaining what
| is nix, thanks!
| mehrdadn wrote:
| Thanks! So let's say I start installing Nix packages. What
| distro's packages would they end up most similar to? Say,
| maybe Arch (which mostly leaves things unmodified)? Does that
| mean you basically end up with Arch no matter which distro
| you're on?
| catern wrote:
| Trying to put it politely, but your question seems a bit
| confused.
|
| Arch is not the only distro that strives for minimal
| modifications on upstream packages. In fact, most
| distributions work that way - it's Debian and its
| derivatives that's the outlier, and these days, even Debian
| rarely patches upstream packages.
|
| There is much more to distributions than what patches they
| apply to their packages. The package manger they use, their
| default configurations, their compiler toolchain, their C
| library, their init system, their stance on software
| freedom, etc etc - much more than just what patches they
| apply to their packages.
|
| But, yes, Nix packages are mostly close to upstream, with
| occasional patches to improve determinism and
| reproducibility.
| mehrdadn wrote:
| Thanks for explaining. I'm (obviously, I thought) not
| suggesting distros are _only_ about the patches, but
| patches are a very significant aspect of their raisons d
| 'etre to me. I thought most distro maintainers do things
| like backporting changes though, for
| security/stability/etc.? Including RedHat, Canonical, the
| Debian maintainers, etc.? Arch (and I guess Gentoo, and
| maybe their derivatives like Manjaro) are the only ones I
| know that minimize upstream package changes. With other
| popular distros like Fedora, Ubuntu, SUSE, etc. I fully
| expect they've made custom modifications to some popular
| packages, but it's been years since I've touched other
| flavors. You're saying this is wrong and only Debian
| derivatives tend to do this?
| catern wrote:
| Fedora stays close to upstream: https://fedoraproject.org
| /wiki/Staying_close_to_upstream_pro...
|
| Ubuntu is a Debian derivative, they patch things heavily,
| just like Debian.
|
| SUSE, I don't know about their policy. I assume they're
| like RHEL, which starts from Fedora, which is close to
| upstream, and then backports bugfixes from later versions
| on to stable branches.
|
| Many distros maintain stable branches and just update the
| packages on that branch when they have security issues.
| Backporting security fixes has (somewhat) gone out of
| favor, because backports executed by package maintainers
| that weren't familiar with the code have caused serious
| security issues in the past. Of course, distros like RHEL
| and (I guess) SUSE still do backport security fixes to
| their stable branches. But they start from a base which
| is close to upstream - it just diverges more and more as
| their stable branch gets older and older.
| tel wrote:
| In addition to other answers, I think it's important to
| note that Nix is comparatively very small (but growing!).
| To that end, the Nixpkgs policies are still in flux and
| defined somewhat culturally (at least compared to older,
| larger distros).
|
| There's a release schedule for NixPkgs which is being
| continuously updated, you mostly subscribe to a fixed
| "channel" which gives you the default set of derivations.
| If you need something more fresh then you either modify a
| derivation yourself (hot-patching the distro) or pull
| something temporarily from master on NixPkgs.
|
| This is hugely facilitated by the way Nix allows you to
| install multiple package versions in parallel without
| conflict.
|
| Finally, Nix is still sometimes a bit of a research
| project. The "best" way to manage a distro that's being
| built using this technology is still being uncovered. For
| instance, there's an upcoming feature (flakes) which hopes
| to seriously change the way you talk about and consider
| versions of NixPkgs and NixOS.
|
| Using Nix definitely requires some patience with living on
| the edge of tech. It can be frustrating and less reliable
| than other repos due both to the bigger challenge of
| building a repo using Nix's technology and the smaller
| contributor base.
|
| That said, the returns on using this weird technology are
| really high. The short pitch is something like "zero
| runtime cost, highly repeatable Docker containers for
| everything". Of course, the technology works nothing like
| that, but it really hit some of the big position
| independence value props of Docker in a way that's
| lightweight enough to use it for everything.
| ninetax wrote:
| Unfortunately there's a pretty annoying bug with MacOS which
| resulted from Apple making /nix non-writable by default. And
| since /nix is hard coded in all the cached packages it's not
| easy to fix.
|
| This is one big thing that's preventing us from adopting nix
|
| https://github.com/NixOS/nix/issues/2925
| geofft wrote:
| I'm trying to understand why macOS can't use a different
| path (since it's a different OS anyway, and you can't run
| Linux Nix binaries on macOS). From the end of the thread,
| it sounds like
|
| > _The main consequence of using a separate prefix for
| macOS is that you can 't have Hydra jobsets anymore
| containing jobs for macOS and Linux. It would also make it
| harder to deploy from macOS to Linux._
|
| i.e., if the same package builds for both Linux and macOS,
| you can't write a single shell script that runs on both
| Linux Nix and macOS Nix and calls that package? Maybe I'm
| misunderstanding how people deploy things, but is that a
| huge problem in practice?
|
| (I don't quite follow the thing about Hydra jobsets. Aren't
| you building once for Linux and once for macOS anyway?
| Figuring out how to make the build do that seems like it
| would subsume any complexity of using /nix vs. /opt/nix.)
| statenjason wrote:
| What is Nix?
|
| Nix is a powerful package manager for Linux and other Unix
| systems that makes package management reliable and
| reproducible. It provides atomic upgrades and rollbacks, side-
| by-side installation of multiple versions of a package, multi-
| user package management and easy setup of build environments.
|
| What is NixOS?
|
| 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.
|
| [1]: https://nixos.org/
| mehrdadn wrote:
| Thanks, but that makes me wonder how that's even possible
| given that distros make their own modifications? Do people
| port each distro's packages to Nix then? Are they kept up-to-
| date? Or does it automatically translate from apt/pacman/etc.
| databases somehow? Or does it just basically install vanilla
| packages on all distro?
| throwaway894345 wrote:
| Yeah, there is a giant repo of package definitions at
| https://github.com/NixOS/nixpkgs. Those definitions tell
| nix how to build everything from the ground up.
| tathougies wrote:
| > how that's even possible given that distros make their
| own modifications?
|
| Own modifications to what? All the packages in nixpkgs
| depend only on other packages in nixpkgs. If you install
| nix on an ubuntu system and then install a package from
| nixpkgs, then that package won't use any ubuntu libraries.
| mehrdadn wrote:
| > Own modifications to what?
|
| To the packages. e.g. I believe Ubuntu modifies Python so
| that sudo pip install uses /usr/local instead of /usr.
| Lots of other patches and backports I'm not necessarily
| aware of. That's basically what makes Ubuntu Ubuntu,
| otherwise it'd be more like Arch. So how does Nix deal
| with this? Do you get the value-add from your distro or
| do you basically end up with pseudo-Arch wherever you
| start?
| markandrewj wrote:
| The Nix packages are independent of the OS, this is
| actually one of the advantages of using Nix. It means
| that similar to when using Python virtual environments
| user packages are not mixed in with system packages. Nix
| also versions package changes. When switching between
| versions, Nix just updates the paths in your environment.
| If you wanted to stop using the packages all together you
| only need to remove the environment path.
|
| Another advantage is that you define installs as part of
| configuration file, similar to Ansible/Chef/ect so things
| become repeatable.
|
| The difference between Arch and Ubuntu is not so much
| that patches are applied to packages though, it's that
| packages are precompiled for Ubuntu, where as packages
| for Arch are often compiled from source.
|
| Nix can compile packages from source, or use a binary
| from cache if it is available.
| fwip wrote:
| If you install python through nix, you get the nix
| version.
|
| If you install python through apt, you get the ubuntu
| version.
| mehrdadn wrote:
| I get that part. I'm asking what the Nix version is like.
| Is it like the Ubuntu version with all the patches and
| backports and everything, or is it like the Arch (i.e.
| basically original unmodified) version?
| catern wrote:
| Nix packages are typically close to upstream, but low-
| level packages sometimes have patches to make them more
| reproducible and deterministic, so that they work better
| with Nix's efforts for determinism and purely-functional
| packaging.
|
| Nix packages are created from scratch, not copied from
| another distro. Nix is typically one of the most up-to-
| date distros: https://repology.org/
| mehrdadn wrote:
| Okay thanks, so it sounds like I'll (roughly) end up with
| Arch (i.e. mostly-unmodified) whether I start on Ubuntu,
| Fedora, or whatever. I have another on that front: what
| about things like kernels? Don't those conflict with the
| OS?
| thequux wrote:
| If you install the "linux" package using nix on Debian,
| you get a directory in your nix store (the collection of
| "installed" packages) containing a bzImage, a System.map,
| and a `lib` directory containing all of the kernel
| modules. It would then be up to you to build an initrd
| and wire it into your bootloader, if that's what you
| wanted to do.
|
| In other words, Nix packages are _just_ files in their
| own special place on the disk (under /nix). If you want
| to configure binaries from those packages to run as
| daemons, or otherwise be wired into the system globally,
| that's up to you.
|
| In fact, this is also true for the packages that you've
| "installed"! The nix package manager creates a package
| that represents your "user environment", and that package
| just merges all of the packages you installed using
| symlinks, and a symlink to _that_ package is added to
| your $PATH.
| mehrdadn wrote:
| "Just files" doesn't quite capture the complexity of the
| situation to me though. Say I happen to install package X
| via apt and Y via nix, and both of them depend on Z (in
| apt and nix respectively), and Z needs to bind to a port,
| then I imagine both will install but one of them will
| break. Or if I install a package on Nix that expects a
| certain syscall that's not in the Ubuntu kernel yet
| (maybe like the recent /usr/bin/sleep issue with WSL),
| then that either breaks Nix or my ability to keep using
| an Ubuntu kernel. Right? And there are probably other
| things I'm just lacking the imagination for right now.
| But it seems to me there are all sorts of conflicts that
| can come up in practice. I've seen enough trainwrecks
| when upgrading even across OS versions that I have a hard
| time seeing how running 2 package managers can work on a
| single OS without breaking something?
| catern wrote:
| Those are handled by NixOS - that's the purpose of NixOS,
| it was built on top of Nix explicitly to manage such
| things. You can read some about NixOS at
| https://nixos.org/nixos/about.html
| l3s2d wrote:
| Not a Nix user, but my understanding is that it's a
| standalone package manager with its own repositories. On a
| non-Nix distro, installing a package with Nix is akin to
| installing a Python module with pip, instead of the
| distro's package manager. It would not be managed at all by
| the distro's package manager. On NixOS, Nix is the distro's
| package manager.
| mehrdadn wrote:
| Thanks, but I already got that much. It doesn't answer my
| question though. If Ubuntu has made a modification to a
| package (that's basically the entire point of most
| distros, otherwise they'd be Arch), should I expect those
| changes in whatever Nix installs?
|
| It also leaves so many other questions unanswered, like
| what happens if I install GRUB or a new kernel or
| something else that's supposed to modify the system
| globally... but that's secondary.
| solarkraft wrote:
| NixOS only has nixpkgs modifications, not Ubuntu's, as
| much as Fedora doesn't have Ubuntu's modifications. My
| understanding is that packages available for Nix are
| patched to work within its context, but otherwise kept as
| original as possible, with optional configuration
| switches.
| catern wrote:
| No, you should not expect Ubuntu's modifications in
| packages installed through Nix.
|
| Things like GRUB or the kernel version are handled at the
| level of NixOS, because, as you say, they affect the
| system globally.
| Fnoord wrote:
| The documentation [1] mentions the possible configuration
| flags for a package, including Grub (which is not the
| default bootloader, btw).
|
| [1] https://nixos.org/learn.html
| ymse wrote:
| Nix packages can not modify the system globally, by
| design. Not even on NixOS. This is why Nix allows
| unprivileged users to install anything.
|
| When you install a package on Nix, all you are doing is
| drop a symlink in your ~/.nix-profile pointing to some
| /nix/store/<unique-identifier> item.
|
| When you build a package on Nix (also does not require
| root privileges), it happens inside a container that can
| only write to /nix/store/<unique-identifier>.
|
| The <unique-identifier> is a cryptographic hash based on
| all the inputs to the package (also /nix/store/<hash>
| items) as well as the build script.
| gnulinux wrote:
| > From the looks of it it's a package manager that I should be
| able to use it on any POSIX system, but I doubt that's the
| case?
|
| That's exactly the case. It works by installing apps per user
| and not globally, so they're put into your home directory.
| leadingthenet wrote:
| It's a package manager that underlies NixOS.
|
| It can also be run under any other Linux distro, and macOS.
| X6S1x6Okd1st wrote:
| And of course Windows Subsystem for Linux
| choward wrote:
| > What is Nix?
|
| It's everything you could ever ask for and more. On a more
| serious note, I get the question though. This article isn't
| very compelling.
|
| NixOS is a linux distribution that allows you to specify your
| system in a declarative way. This means instead of running
| imperative bash commands like "apt-get git". You declare that
| you want git installed with something like
| environment.systemPackages = [ git ... ]; This may not sound
| that interesting you but it makes your system reproducible. So
| you have some plain text files that describe you entire system.
| You can check these into git or whatever. If you reinstall and
| use the same configuration as before you will be back at the
| same state so it makes no sense to do a reinstall of the entire
| OS. If you want to upgrade NixOS versions it doesn't really
| make sense to do a complete reinstall also. Rollbacks are also
| built in in case you make a mistake you can quickly go back.
| Your previous "generations" are shown in the boot menu if you
| restart your computer. NixOS also can run virtualized
| environments like docker, vms, etc. With docker it can be used
| run docker containers and startup. It also has it's own concept
| of containers which can be thought of like docker containers
| except they run NixOS so you specify them the exact same way as
| any other NixOS configuration. Unlike docker, it allows you to
| share packages between containers and the host system while
| also having isolation.
|
| Nix packages are packages like in most other package managers.
| It's also relatively easy to create your own packages. You can
| use NixOS configuration to install packages or use it on it's
| own as a non-root user to install nix packages while on other
| OSes to for example replace homebrew on Mac OSX. It also allows
| you to install multiple versions of the same package. You can
| also us it build docker images so you don't actually need a
| Dockerfile and you can install the docker images which get
| saved to the nix store. You manage them just like another
| package. That's right, this means you can both build and run
| docker images without actually using docker.
|
| NixOps is a tool for deploying NixOS to multiple computers. It
| builds everything on the host and copies it to the nodes. If
| two of your nodes use the same package it's only downloaded
| once. This means no configuring an apt-cache or something like
| that if you don't want all your machines downloading their own
| copies of everything. It also allows you to provision and
| deploy to the cloud. It basically replaces terraform,
| cloudformation, etc.
|
| Nix is the language used to configure NixOS and NixOps as well
| as to create packages that can be installed. Nix files
| themselves don't do anything. They just build a configuration
| object. You can almost thing of them as glorified JSON
| generators that generate the configuration which the respective
| nix tool uses to get whatever job done it needs to.
|
| Now don't get me wrong, the learning curve is very steep but
| once you learn it you "get it" and realize how it all ties
| together and it starts to make perfect sense. I left a lot out
| here (like development) but It basically solves every need I
| have programming, infrastructure, and computers in general and
| I won't go back to anything else.
| kdtsh wrote:
| Nix is a package manager. NixOS is an OS which includes the Nix
| package manager. My understanding is that a feature of Nix is
| you can declare an OS (I.e. declare the collection of
| configurations and software etc for an OS) which Nix will
| process to provide you with an OS called NixOS.
| prox wrote:
| So it processes the config file (and thus all needed
| packages) one time or does it process it every time you boot?
| heisenzombie wrote:
| You type nixos-rebuild switch
|
| and it builds you an entire OS and drops you into it. It
| also makes the new OS the default on startup.
|
| Because it's all purely declarative, your old OS is still
| there. If things go wrong then you can just pop back to it,
| either in the command line with: nixos-
| rebuild switch --rollback
|
| Or when you reboot, the previous 'generations' of your
| operating system show up in GRUB, so just choose an older
| one to boot.
| pjkundert wrote:
| POSIX (eg. Linux), Mac and Windows. Yes, it is magnificent.
|
| Immutable, deterministic software on all 3 major platforms.
| Combined with cached build artifacts, builds and their outputs
| (including complete target system updates/upgrades) are
| blisteringly fast, cryptographically secure and completely
| deterministic.
|
| EDIT: Sorry, yes; Windows only via WSL, not natively on Windows
| proper.
| mehrdadn wrote:
| _Windows_? You 're kidding me! Where do I see Windows
| support? On their website I only see Mac and Linux.
| exdsq wrote:
| You can use it on WSL1 and WSL2 but you can't use it
| natively on Windows. I used it on WSL2 just this afternoon
| and it was seamless but that makes sense because WSL2 is
| basically just a Linux VM anyway.
| _hl_ wrote:
| Although I don't see why it wouldn't work on Windows
| natively. Sure, it would probably need a complete
| reimplementation to replace all the POSIX stuff with
| Windows stuff, but fundamentally it ought to be possible?
| exdsq wrote:
| Sure in theory but there are a few open bugs:
|
| https://github.com/NixOS/nix/issues/2651
| https://github.com/NixOS/nix/issues/2292
| https://github.com/NixOS/nix/issues/1203
|
| There's a locking issue with SQLite and the Sandbox has
| some namespace issues where Linux and Windows behave
| differently. I don't know how eager they are to make it
| work on Windows either, but at least WSL works :)
| genr8 wrote:
| Stumbled upon NixOS yesterday and today its frontpage, 1st link.
| Same thing happened with OpenBSD the day before. Whats tomorrow,
| Qubes? I wonder what the chances of coincidence are if I
| investigate one new OS per day.
| https://www.foxypossibilities.com/2018/02/04/running-matrix-...
| https://en.wikipedia.org/wiki/NixOS
___________________________________________________________________
(page generated 2020-05-20 23:00 UTC)