Live data from Hacker News

What is Nix and why you should try it

yakking.branchable.com

131–140 of 201 posts

Re: What is Nix and why you should try it

#131
post #19

I can vouch for the immense improvement Nix has made to my software development process. I use NixOS on my desktop and laptop. At the OS-level, it gets a lot of things right: reproducible, immutable system configs; lightweight containers; devops with declarative configs. At a software project level, nix-shell is an indispensible tool. Compilers and interpreters aren't even part of my system-wide config; instead each…

Sounds like this solves a similar problem to Docker. Can you comment on what the differences are, and the relative strengths and weaknesses of each approach?

Re: What is Nix and why you should try it

#132
post #19

I can vouch for the immense improvement Nix has made to my software development process. I use NixOS on my desktop and laptop. At the OS-level, it gets a lot of things right: reproducible, immutable system configs; lightweight containers; devops with declarative configs. At a software project level, nix-shell is an indispensible tool. Compilers and interpreters aren't even part of my system-wide config; instead each…

these functions' documentation is either buried in a long manual This is a problem with lots of feature-rich software, even with meticulously-documented APIs. What we need is reverse-indexed documentation. That is, an extensive API reference is only useful for someone who already knows what functions are in the API and just needs to remember how to use them. But even the most thorough API reference does nothing to pr…

I think this is a great idea, and something that could hugely improve semi-automated documentation sites, man pages, etc.

I also think that you could get a lot of people to agree that it is a great idea, and STILL have a lot of trouble enforcing it in a project without very rigid code review policies and very good linting rules.

Re: What is Nix and why you should try it

#133
post #72

Earlier quoted context omitted.

By reading your comment and a little bit of the package declarations in some nix packages, it seems like the software package system of nix is very similar to rez. Rez ( https://github.com/nerdvegas/rez ) is used by some visual effects companies (including mine) to manage software packages. It allows us to have great flexibility in the mix & match of software versions and runtime environments.

Does rez handle having an environment with two apps in it that require differing versions of the same dependency?

It takes a list of requested packages, does some dependency resolution to arrive at a matching package list, generates environment variable setting/exporting code (in Python, e.g. setting things like PYTHONPATH and MAYA_PLUGIN_PATH), then launches a new shell with that code. So, yes, you can have multiple shells with different packages in use simultaneously. I don't think it operates below the industry software package level, which makes sense, as most industry software is non-free, closed-source binaries. Each package has a `package.py` with its own list of dependencies, and code for things like manual tweaks to env vars.

>"Using Rez you can create standalone environments configured for a given set of packages. However, unlike many other package managers, packages are not installed into these standalone environments. Instead, all package versions are installed into a central repository, and standalone environments reference these existing packages. This means that configured environments are lightweight, and very fast to create, often taking just a few seconds to configure despite containing hundreds of packages."

Re: What is Nix and why you should try it

#134
post #19

I can vouch for the immense improvement Nix has made to my software development process. I use NixOS on my desktop and laptop. At the OS-level, it gets a lot of things right: reproducible, immutable system configs; lightweight containers; devops with declarative configs. At a software project level, nix-shell is an indispensible tool. Compilers and interpreters aren't even part of my system-wide config; instead each…

Sounds like this solves a similar problem to Docker. Can you comment on what the differences are, and the relative strengths and weaknesses of each approach?

I was confused by this first.

So Nix is ultimately a tool for making and sharing reproducible package builds. It has a binary cache, but it's not necessary. Like Ports, packages get built by default.

Docker, on the other hand, is a distribution and execution mechanism. It provides an abstract way to move around a fully assembled, ready-to-go service or application running in isolation.

It's entirely reasonable to use both. You can use Nix to build and manage docker images and make extremely minimalist docker images. You can use Nix knowing that the entire process is perfectly reproducible, and the Docker containerization is only a final integration step.

With this, you sorta get the best of both worlds. You get a reproducible build (and if done right, also a reproducible dev environment via nix-shell) and with Docker you get the ability to build and run a prepped copy with a well-defined interface.

Docker really doesn't provide a way to reproduce a built image from scratch. You sort of have to trust and build on existing images, and most folks making bulk images appeal to external tooling outside docker files to do this.

Re: What is Nix and why you should try it

#135
post #103

I have used NixOS. It's fustrations led me to develop this. https://github.com/pauldotknopf/darch It is essentially Docker, but you can boot bare-metal with it. It even uses Docker under the hood. Every boot is a fresh boot. You can read-write during boot, but all changes are made to ram. You mount with fstab things you want persisted, like home.

Interesting. Isn't that essentially a livecd? Have you considered using Archiso? If so, what do you see as the advantages of darch?

Archiso/etc are similar, but that lack some things.

---

Layering

----

I can change my inherited build without rebuilding everything.

For example: base > xorg-nvidia > plasma > homepc I can easily switch desktop environments by making "homepc" inherit "i3", or w/e.

Each layer is essentially a "Dockerfile". If you understand docker, you understand how the images are built and managed.

---

Fast switching.

---

I can create images for different dev environemnts/clients. I can create an image purely for gaming. I can create an image steam.

Darch integrates with grub, so entries will dynamically show up on boot.

---

Sharing with DockerHub.

---

Sharing with other machines (and other people).

Since they are docker images, I can easily upload them to DockerHub.

I can update my local build by doing "docker pull && darch extract && sudo darch stage".

I will soon setup Travis-CI to auto build and push to DockerHub. Then, I never have to build locally. A cron job will queue a build every few days to make my image "rolling". I can easily revert back to previously working docker images (all tagged by date).

Re: What is Nix and why you should try it

#136
post #47

Recently, I got the opportunity to play with Nix. To me, it felt to be a very nice way to bundle the dependencies along with the application. But there are few questions which always come to my mind were - how people run it in production. Can they achieve all the things (eg monitoring, debugging..) easily just like the app hosted on a linux machine ?

Sure? It’s still Linux underneath and all the same skills and strategies carry over.

Thank you, I definitely need to play with it more to understand it better.

Re: What is Nix and why you should try it

#137

Earlier quoted context omitted.

But even still you are mixing languages, so the problem remains. The issue is not that Nix uses Bash, but that Nix uses different languages for the host-side and build-side. AFAIK people aren't writing the build-side code in the Nix language, and I'm not sure if it even has the features necessary to do it. Guix unifies the different layers of code execution with a single language, and using a Lisp enabled that design…

> Nix uses different languages for the host-side and build-side. I'm not sure what you mean by that. Nix packages are Nix expressions.

He is probably referring to the thing you see when you look into a .drv file, aka the immediate result of evaluating a derivation in nix. That language/datastructure is what nix-build evaluates to actually build things, otherwise the nix language itself is purely functional and cannot really do anything on it's own.

I guess in guile/scheme the equivalent data structure happens to be an s-expression. Edit: except the paper actually describes that it's a g-expression.

Re: What is Nix and why you should try it

#138

We used Nix to vastly simplify the build process of Simula: https://github.com/SimulaVR/Simula Simula is a bleeding edge VR Desktop project for Linux; virtually all of its dependencies are highly novel and require building from source for almost any distro. Nix allowed us to reduce the effort to building our project from 1hr of sifting through build documentation to a single build command. Nix's only issue is that it…

So, OpenGL is a bit of a weird case. Hardware is the one thing that actually varies between systems no matter how declarative your configuration is - this is normally not a problem, since the kernel abstracts it away. The problem with OpenGL, then, is that every graphics driver provides its own set of OpenGL libraries that is subtly different from all the others. This means that applications need to be built against…

Does the Guix choice of a more expressive language for defining the packages help here?

Re: What is Nix and why you should try it

#139
post #108
post #97

Earlier quoted context omitted.

I'm confused by this statement. `nixpkgs` contains tens of thousands of packages, the majority of which have binary substitutions via the NixOS Hydra build farm. Usually the only time I build things from source on my NixOS laptop are when I override some package to use a patch of my own design. Hell, when I was using Arch Linux I found myself building things from source _way_ more often than after switching to NixOS.

I use void-linux and the only thing that i am building from source(aside from language specific pkgs) are emacs-git and st(terminal emulator). At that time, most packages were old version on nixpkgs and some weren't available. I will look into it again, when i have the mood to switch distros.

I don’t know when you were last looking but for as long as I’ve been using nix (since early 2015) nixpkgs has had definitions of the vast majority of commonly used software, and pre-built binaries of most of those. Definitely worth another look. Also note that you don’t have to switch distros as nix can be plugged into almost any Linux environment without conflicting with whatever else is there.

Re: What is Nix and why you should try it

#140
Software Collections (https://www.softwarecollections.org/en/) give you the power to build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages. Is this what Nix OS is able to do? Install multiple versions of software and select which version to use before running?
Post reply on HN