NixOS

😉

Thanks for your massive contribution to this growing community!

This is REALLY cool. This is how public funding should be allocated.

It’s still fairly challenging and the documentation is probably, at best, dogshit (if I may be so blunt) at the moment.

OCI is probably a more worthy goal anyway, IMO. And it is unsurprisingly much more well-supported.

I think some of these replies have perhaps missed the powerful idea that made me fall in love with Eelco Dolstra’s idea. Here’s what won me over.

For example: THE main feature is that you could have a different version of say Python (for the sake of this example) installed for each dependency in your system. Let’s say you had Brave working with one version of Python and another piece of software needed a previous version of Python. In an FHS style system, this would be challenging and you’d have to manually patch things to make sure the dependencies didn’t step on eachother. When you updated, your patches would likely have to be changed as well. So, system administration and updating can really break things.

In a Nix store where things can be content-addressed and linked by symlinks to their specific dependencies, they would just work alongside each other due to their unique, hash based folder locations. Each folder in the Nix store is named based on the sha256 hash of that piece of software’s ENTIRE dependency graph, which has powerful implications.

Because of this hash, they’re effectively hermetically sealed from each other and cannot step on each other. The software in the Nix store talks to eachother through symlimks that were made upon compilation of the system.

This is the very definition of Nix and taken far enough to define a whole OS is SUPER powerful concept.

I’d actually argue the opposite in regards to clutter. If I switch to a new config without the software I don’t want anymore, that software goes away entirely when I do a garbage collect and there’s nothing left over like there might be in ‘’~/.config’’ on a non-immutable system.

IMO, the actual realization of Dolstra’s dream is flakes and home manager. They allow you to boil your whole config down to a git repo where you can track changes and rollback the lock file if needed.

I find it nice to open my config in an IDE and search by string inside of my config where I can comment out whatever I don’t need. Laziness also makes that pretty convenient too. Nix will only attempt to interpret what is accessible in code. If I comment out an import, that whole part of the config seamlessly shuts off. It’s quite elegant.

I’m even more envious of the atomicity of GUIX but IMO, it’s a little too much building the world from scratch for a newb like me.

I HIGHLY recommend forking a nix-config that uses flakes, home-manager, and whatever window manager you prefer. Since Nix is so versatile (and the documentation of flakes and home-manager are BAD), I found it absolutely crucial to reuse a well-architected config and slowly modify it in a VM to sketch out my config until it was stable enough to try on a real machine.

Clearly, it’s not a skill issue with you but with the dude that inspired this, my assessment was that he was flat out unwilling to learn and flat out unwilling to acknowledge that there are clearly some benefits to this style. Seems like you already grasp it but don’t feel like committing the time. I respect that much more than the blind dismissal that inspired my meme. ✌️

Doh! Ps. Thanks for the correction.

nd of interesting shit you can do in Nix, at one point I had zfs and ipfs entries in one of my configs. I got away from it all before flakes started to get popular.

I tried it as a docker host; the declarative formatting drove me around the bend. I get a fair bit of disaster proofing on my docker host with git and webhooks, besides us

I suspect that the whole Docker thing will improve exponentially now that Nix is on the Docker’s radar. I found the OCI implementation to be superior to the actual Docker implementation in Nix…at least for now. I think the way that Docker isolates things to layers is the biggest barrier to them working together seamlessly at the moment…but I think they’ll start to converge technolgically over the coming 10 years to the point where they might work together as a standard someday.

to try to replicate my current desktop in an immutable model, it would involve a lot of manual labour in scripting or checkpointing every time I installed or configured something, to save a few hours of labour in 2 years time when I get a new drive or do a full install.

If you have only one system, you might find the benefits not to be worth the bikeshedding effort.

However, I suspect that you’d be surprised with how easy it can be using home-manager. I have literally nothing that I need to do to a newly compiled NixOS system from my config because EVERYTHING is declared and provided inside of that config.

If you don’t mind, can you give me an example of something in your config that you think is impossible or difficult to port to the Nix style? I’d be happy to attempt to Nixify it to prove my point. I’ve pretty much figured out how to do everything in the Nix way.

and I don’t mind if I end up being incredibly wrong on this point and promise to be intellectually honest about it if I am indeed wrong. It just sounds like a fun exercise for me.

for a user that isn’t trying to maintain a dev environment, it’s a bloody lot of hassle

I agree but I prefer it to things like ansible for sure. I’m also happy to never have to run 400 apt install commands in a specific order lest I have to start again from scratch on a new system.

Another place I swear by it is in the declaration of drives. I used to have to use a bash script on boot that would update fstab every time I booted (I mount an NFS volume in my LAN as if it were native to my machine) then unmount it on shutdown. With nix, I haven’t had to invent solutions for that weird quirk (and any other quirks) since day one because I simply declared it like so:

{
  config,
  lib,
  pkgs,
  inputs,
  ...
}: {
  fileSystems."/boot" = {
    device = "/dev/disk/by-uuid/bort";
    fsType = "vfat";
  };

  fileSystems."/" = {
    device = "/dev/disk/by-uuid/lisa";
    fsType = "ext4";
  };

  swapDevices = [
    {device = "/dev/disk/by-uuid/homer";}
  ];

  fileSystems."/home/mrskinner/video" = {
    device = "192.168.8.130:/volume/video";
    options = ["x-systemd.automount" "noauto"];
    fsType = "nfs";
  };

  fileSystems."/home/mrskinner/Programming" = {
    device = "192.168.8.130:/volume/Programming";
    options = ["x-systemd.automount" "noauto"];
    fsType = "nfs";
  };

  fileSystems."/home/mrskinner/music" = {
    device = "192.168.8.130:/volume/music";
    options = ["x-systemd.automount" "noauto"];
    fsType = "nfs";
  };
}

IMO, where they really shine is in the context of declarative dev environments where the dependencies can be locked in place FOREVER if needed. I even use Nix to build OCI/Docker containers with their definitions declared right inside of my dev flake for situations where I have to work with people who hate the Nix way.

I really didn’t declare myself the winner. IMO, I won’t have to when the software will do that when this way of working usurps container-style development as the de-facto standard.

As an actual old man who was able to adapt, I simply pointed out that OP sounds like an old man, unable to acknowledge an obvious trend where immutable systems are clearly gaining popularity and are seen by many as the correct way to provision a mission-critical system.

Perhaps! I’m a big fan of immutable distros. This meme was inspired by being called an asshole for agreeing with another commment, calling it a skill issue when this one commenter flat out refused to acknowledge ANY of the positive aspects of them.

Is docker even declarative?

Yes (though not as much as Nix).

Also you can build docker images from nix derivations

Yes. I know.

Imma let you finish but Nix had the best repeatable, declarative dependency management of all times…of all times.

I’d definitely be interested.

I did something like this a while back when I attempted to create an official Cardano dev/Stake Pool operator machine. I ended up realizing that a whole config is too personal to try an standardize but parts of my shared configs DID help other Cardano devs and Stake pool operators get a rock-solid Cardano dev/SPO setup that could be cloned into a myraid of different types of machines and configs.

Any first world nation.

Yes!

Music to my ears. Tax money should go to open source projects.