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)?
NixOS: Declarative Builds and Deployments
61–70 of 83 posts
Re: NixOS: Declarative Builds and Deployments
#62I'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…
Re: NixOS: Declarative Builds and Deployments
#63I 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.
Apologies if there is already something like this in work by the core nix devs.
Re: NixOS: Declarative Builds and Deployments
#64Earlier 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.
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
#65I 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?
Re: NixOS: Declarative Builds and Deployments
#66Earlier 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.
Re: NixOS: Declarative Builds and Deployments
#67NixOS 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…
"How we went from supporting 50 languages to all of them"
Re: NixOS: Declarative Builds and Deployments
#68Earlier 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.
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
#69Earlier 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...
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
#70Earlier 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
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.