Live data from Hacker News

NixOS: Declarative Builds and Deployments

nixos.org

61–70 of 83 posts

Re: NixOS: Declarative Builds and Deployments

#61

Earlier quoted context omitted.

You can pin versions with apt-get install...

What's the model of the pinning? Is it an arbitrary semver? Is it a sha256 calculated by the content of the package (Content Addressed)? Is it a checksum calculated from all the inputs that were used to create the package install spec (Input Addressed)?

All of the above? Nix isn’t the first package manager to do something unique.

Re: NixOS: Declarative Builds and Deployments

#62

I'll be honest, the first few times I tried using Nix I just couldn't get into. It was too complex for the benefits I was getting. But that was using Nix on another OS. I recently switched to NixOS because I wanted what they were selling and the experience this time around was way better. Having no other option but to figure it out made me learn the essentials real quick (like an exchange program to a foreign country…

Having been on NixOS exclusively for a couple years now, it's inconceivable for me to go back to a non-declarative OS. It would be analogous to from from Git to unversioned source code. My operating environment is a piece of compiled software itself now, and is remarkably reliable and predictable. Yes, it's difficult to learn and takes more work, but it's similar to Git in that respect - powerful tools are worth the effort if it's your vocation.

Re: NixOS: Declarative Builds and Deployments

#63

I work on Nix and think this paradigm has already impacted and will continue to influence software devopment in general. I want to make it easier for organizations/companies/groups to adopt it. Ideas and questions are welcome.

I think the fastest path to adoption is to build a front-end for nix so that non-technical users can use it like they would Ubuntu. Users could select packages and edit system config through a GUI, which would be built/deployed when the the user clicks "save" or whatever, with an "advanced" mode where users could edit and add extra text config if they wished. SnowflakeOS [1] and Fleek [2] are admirably starting to work towards that, but there isn't enough of a concerted community effort to make it a first class feature of NixOS. If/when something like this were mature, you could then take it to the next level, where you could have something similar to an "app marketplace" where users could share flakes or sets of config that do things, like "Jake's blinged out desktop" or "Home router setup", essentially adding an additional layer of easy composability on top of base packages that most systems support.

Apologies if there is already something like this in work by the core nix devs.

[1] https://snowflakeos.org/

[2] https://getfleek.dev/

Re: NixOS: Declarative Builds and Deployments

#64
post #53

Earlier quoted context omitted.

Alpine linux has a /etc/apk/world which is just a full list of all the packages currently installed I'm not a fan of nix but I'd say the nixos repository is fairly mature.

And gentoo has /var/lib/portage/world, and pacman has "pacman -Qe", and apt has "apt-mark showmanual". ...I sometimes wonder how the world would be if the "explicitly installed packages" functionality was better exposed and advertised. I never see any guide for "installing development dependencies" use things like "pacman -S --asdeps" so you can clean them up later.

Thank you 'apt-mark showmanual' is useful. Even better using synaptic you can the click the `Installed (manual)` status filter.

Still not as good as something like npm's `package.json` where it's a human edited list of packages you want installed and it's in the order that you added them in (if you ran `npm install $package-name`). Which is nice when you want to remove one you don't need anymore.

I wonder if it's possible hack a declarative package manger into a Debian system. Like a wrapper around apt that can do all of this.

Re: NixOS: Declarative Builds and Deployments

#65

I first looked at nix-shell which you can use to create ephemeral environments just like Docker, with the difference that they are 100% reproducible and you don't need containerd or like. It is awesome to create scripts which run the same on EVERY system. Then looked at NixOS. I geht the point of having a deklarative like OS which you can rebuild in a couple of minutes, BUT the nix language is kind of unituitive and…

> I first looked at nix-shell which you can use to create ephemeral environments just like Docker, with the difference that they are 100% reproducible and you don't need containerd or like. Sounds like podman. What is the big differentiator from it?

nix shell is just another shell instance, with new things brought in via $PATH etc. Not a container, still part of your "current computer environment".

Re: NixOS: Declarative Builds and Deployments

#66
post #57

Earlier quoted context omitted.

I think I remember having issues with the Kate package. There might have been others but that's the one that stuck for me.

it could be a myriad of things. Getting some features working requires searching around the internet, like getting spell checking working was... interesting.

I know. I've looked into it and am pretty sure it was a missing optional build dependency during the build of the package. The feature is obscure enough that it was easily overlooked by the maintainer who in all likelihood doesn't even use kde.

Re: NixOS: Declarative Builds and Deployments

#67
post #23

NixOS is honestly the single most game-changing thing I've been introduced to in my last decade of experience in tech. If you're interested in trying out NixOS I highly recommend either running it as an WSL2 VM[1] if you have a Windows machine or deploying it on a cheap VPS[2] to play around with. I personally still use a Win11 desktop for compat with Adobe software and a few other bits and pieces, but I do all my se…

I keep seeing this from people online but I have yet to see Nix in the wild at any large organization. For such a "game-changing" thing, it certainly doesn't have the meat space following you see online. To me, I tried Nix, got frustrated with packages, realized I'm just using someone else's abstractions for defining configuration files (with the same kind of quality you'd find on Ansible galaxy), and realized it's n…

It's also used at Repl.it:

"How we went from supporting 50 languages to all of them"

https://blog.replit.com/nix

Re: NixOS: Declarative Builds and Deployments

#68
post #61

Earlier quoted context omitted.

What's the model of the pinning? Is it an arbitrary semver? Is it a sha256 calculated by the content of the package (Content Addressed)? Is it a checksum calculated from all the inputs that were used to create the package install spec (Input Addressed)?

All of the above? Nix isn’t the first package manager to do something unique.

> All of the above?

Nope.

At best, you can do something like this: apt-get install gparted=0.16.1-1

That handles the semver case, but that doesn't address the rest of the "all of the above":

- sha256 calculated by the content of the package (Content Addressed)

- checksum calculated from all the inputs that were used to create the package install spec (Input Addressed)

> Nix isn’t the first package manager to do something unique.

Sure. But it is the first package manager to do the above unique things. After all, the reason for Nix's existence is just that: no other package manager before it has done what it does.

Re: NixOS: Declarative Builds and Deployments

#69

Earlier quoted context omitted.

Docker is not reproducible, you just apt-get install what you want hoping that the RUN commands get you a version that is still compatible with your software and doesn't break anything. With NixOS, you can pin the specific hash of every software, and you don't need the entire Ubuntu 20.04 in a container to deploy a webapp.

You can pin versions with apt-get install...

How does apt-get install handle the following scenario?

You need the following software:

- You need the latest release of Erlang for your app

- A database (like Riak), whicn in turn happens to need an older version of Erlang

- The new Erlang needs the latest libopenssl

- The old Erlang needs an old v1.x libopenssl

- You used some open source software written in C++, so you need libstdc++

- Some of your own C++ code has exposed a bug in libstdc++, so you need yet another libstdc++ with your patches, but just for that software

- Etc

How does apt-get install allow you to have multiple versions of a given dynamic library (with the same SONAME) and multiple binaries (erl, clang, etc) installed at the same time?

The answer: it doesn't.

Nix has no problem handling everything I described above, and it handles it easily.

So, yes, you can pin versions with apt-get install, but you're out of luck if any of those packages have any transitive dependencies with different versions.

Also, the pinning guarantees are higher with nix: you can be guaranteed that your packages and their transitive dependencies are byte-for-byte identical, every time. Pinning end-to-end across all packages (and every transitive dependency thereof) is not a normal, happy-path thing to do in apt, so you would be hard pressed to find anyone that does that, given how onerous that would be -- whereas it's trivial in Nix.

Re: NixOS: Declarative Builds and Deployments

#70

Earlier quoted context omitted.

Better composability and abstraction, see for example how you can configure a process in https://devenv.sh/services/ that has first-class support for development environments using Nix. No need to use containers too, which bring cognitive/workflow overhead.

And Nix doesn't? At least with Docker you can get something useful within 2 minutes

> And Nix doesn't?

If you're asking if installing/running software with Nix requires containers like Docker does: no, it does not.

> At least with Docker you can get something useful within 2 minutes

  % nix shell 'nixpkgs#ruby' -c irb
  irb(main):001:0> puts "Hello, world!"
  Hello, world!
  => nil
  irb(main):002:0>
That took me about 5 seconds to type out, and now I'm in an IRB REPL slinging Ruby code, despite having never installed Ruby prior to running that command. Add another 5 seconds for nix to fetch the necessary files (which are then cached locally, so a second `nix shell` invocation will be immediate) and we're sitting at roughly 10 seconds end-to-end.

If it takes 2 whole minutes to use Docker, Docker must be pretty bad. I guess vintage things have their appeal, but apart from that I don't see why people would be so attached to such archaic, inferior technology.

Post reply on HN