How, tho?

Seriously, how do you even get started? It’s like the tutorials are all, “This is a basic ‘Hello World’ module/flake. Now, you are a master.” I would love to figure it out, but I need a little more hand holding.

Sure I guess if you can manage to get everything to work in the first place which involves following sixteen different guides across twenty-three different websites all of which with conflicting information.

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.

They’re the bee’s knees if you have a homelab, though.

i mean, provided that the OS has a proper graphical configurator (like most normie OSes), isn’t being declarative just a straight upgrade? Configure everything once when installing and then you never have to repeat that process again.

Why Kinoite over Aurora or Bluefin?

Not really. Now they’re old and controversial.

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.

RFC 1925(11) —

(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.

https://datatracker.ietf.org/doc/html/rfc1925

all your time learing to configure an abstraction layer instead of interfacing with the real underlying tooling

Bro it’s state machines all the way down and expressions up top

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.

As far as I can tell it separates the base os from user changes which could break things by forcing you to use containers by annoying you to death any time you’re trying to permanently install a package.

It’s fine but it seems better for servers than users.

Basically the idea is to separate your system packages and your applications.

The system packages are installed and updated “atomically” i.e. in transactions. If a transaction fails, results in a broken system, or you just don’t like it, you can rollback anytime.

Applications on the other hand are usually installed in a containerized form. Basically, flatpak. You should avoid installing applications through the system package manager.

CLI apps is where it all gets interesting, and usually people use distrobox, docker/podman or toolbx to run stuff in containers. Although the universal blue project comes with brew prepackaged for when you want CLI apps installed system-wide without juggling containers.

The benefit is that your OS and your apps are separate. No dependencies breaking or conflicting. And if something does break, well just roll back.

Doh! Ps. Thanks for the correction.

As a child in the US I was taught “The Principal is you ‘pal’.” which is not true but helpful when spelling it. Like “dessert” has more ‘s’ than “desert” because it’s something you want more of.

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.