Nix/Silverblue users: How big is the advantage if you already have 100% automated your deployments via Ansible?

wolf@lemmy.zip · edit-2 10 months ago

Nix/Silverblue users: How big is the advantage if you already have 100% automated your deployments via Ansible?

wolf@lemmy.zip · 10 months ago

Nice, thank you very much for this great summary!

In my own words, you describe the difference between declarative vs. imperative configuration and the joy of atomic updates. :-)

I just want to add one point: Theoretically I totally agree, that one might have a bad state in Ansible and the updated state is spoiled, and of course configuration drift is a theoretical problem via Ansible. In practice I never run into this problems in 10+ years of using Ansible. (Of course I treat servers/desktop as cattle, so every major revision of Debian means a complete/clean new installation.)

Atemu@lemmy.ml · 10 months ago

If it works for you, that’s great.

I find it a lot more convenient to treat every change about my system as a nearly complete/clean new installation though and NixOS allows you to do so. An upgrade between major versions becomes a walk in the park due to this; it’s the M.O. The last one didn’t require any modification of the config on my NAS. I remotely rebuilt the system from my MacBook Pro with the new channel, rebooted to get the newer kernel and everything worked just like before.

Shareni@programming.dev · 10 months ago

An upgrade between major versions becomes a walk in the park due to this

For personal desktop use, I see nixos and guixos as spending an hour every day, so that you can save minutes every few years.

When trying out guixos, I spent like 5 days going through the docs and annoying people on irc, just to accomplish the same thing as copying a file to a non-~ directory in a normal distro. Anyways, I powered through the weeks of configuration, and got to actually doing some work in the damn thing. I started off by using the language specific PM to install the dependencies I needed for a project. Welp, guix is not FHS compliant, and can only stand the presence of isolated PMs like nix and flatpak, so that’s out of the question. Since the guix packages were too old, it was time to either:

maintain my own guix definitions of random packages + their dependencies, and then maintain a separate source of dependencies for the project
learn how to nix and then maintain a separate source of dependencies for the project
start figuring out how to use guix to emulate FHS inside of a venv

So I obviously went for the third option, gave up after banging my head some more, and finally nuked the partition.

aint nobody got time for that

Recently I started using home-manager, and tried converting my i3 config so it’s handled by it. Halfway through, it set in just how ugly the syntax looks. I mean just look at a small part from the beginning of both files: nix formatted by nixfmt, i3 config. But ok, I might get used to it, let’s test it out: it fucking added defaults like the keybindings I’ve specifically removed from the config so that the only two i3 deals with are opening the terminal and reloading itself. Then I finally realized I’m wasting my time creating this monstrosity, when literally the only benefit is that it would allow me to skip symlinking directories after a fresh install. So now it’s only managing my packages, doing a great job freshening up stable Debian, and I can reload any config immediately after saving the file instead of going through the entire process of recreating everything home-manager handles.

I might still use it for some specific packages, like firefox (about:config and custom css), which can’t really be stowed easily.

Nix and Guix os are brilliant in specific use cases they were made for, like when you’re creating a large number of ephemeral instances for scientific computing and need extremely precise control of everything that goes into the image. Spending a week to configure something simple is worth it in that scenario because it’ll save you from much bigger headaches down the line. The issue is that they solve problems most users simply don’t face, and so the added complexity comes with practically no benefits.

Atemu@lemmy.ml · 10 months ago

I see nixos and guixos as spending an hour every day, so that you can save minutes every few years.

I see it more like spending an hour every week so that you can save hours to days of annoying and stressful time every few months.

Though there are other benefits rather than just time.

When trying out guixos, I spent like 5 days going through the docs and annoying people on irc, just to accomplish the same thing as copying a file to a non-~ directory in a normal distro

In the beginning when you’re not familiar with things yet, it always takes more time to do something.

I didn’t have that particular use-case yet and I’d have to consult at least one manual to do it correctly but I’d nowadays be able to solve that particular problem with one line of relatively simple code in NixOS. (On Guix, I don’t know how I’d do it though since they don’t use systemd.)
When I started out though? No chance, it’d have taken weeks.

I started off by using the language specific PM to install the dependencies I needed for a project.

Yeah, that’s like mistake #1 for non-FHS-compliant distros. ;)

start figuring out how to use guix to emulate FHS inside of a venv

As the person who implemented a variant of this for Nix (buildFHSEnv), it’s rather straight-forward. Though if it didn’t exist, I’d rather try distrobox or other dev container thingies if there was no reasonable nix support for the thing I’m working on.

I mean just look at a small part from the beginning of both files: nix formatted by nixfmt

I mean, that’s just one particular interface. It’s actually quite flexible to do it this way though as it allows you to dumb it down if you don’t like it with a little refactor:

{
  startup = let
    exec = command: {
      inherit command;
    };
  in [
    #on launch
    (exec "emacsclient -a '' -nc --init-directory=~/.config/emacs" // {
      workspace = "1";
    })
    (exec "nitrogen --restore")
    (exec "~/.screenlayout/shareni.sh")
    (exec "numlockx on")
    (exec "volumeicon")
  ];
}

That’s the beauty of IaC (actual code, not that YAML nonsense): Software environment configuration becomes a software engineering problem and we know how to solve those.

In this specific case though, I probably wouldn’t bother with doing that stuff in Nix and would rather just keep the plain i3config text file and set the option glue to just use that file; effectively a glorified stow.

This more complex interface is only truly beneficial if there are parts of your config that vary depending on some other conditions. Some users may have the need to only run a set of commands or have certain launch options on one machine but not another. Trivial to do with lib.optionals and the like using this kind of interface but very hard to do if it was just a list of strings or one large string.

it fucking added defaults like the keybindings I’ve specifically removed from the config so that the only two i3 deals with are opening the terminal and reloading itself

Well, then tell it to not to do that? I don’t know the module in question but any well-designed module has an option for precisely that. If it doesn’t, I’d consider that a bug. Otherwise, lib.mkForce is usually also an option.

Spending a week to configure something simple is worth it in that scenario because it’ll save you from much bigger headaches down the line. The issue is that they solve problems most users simply don’t face, and so the added complexity comes with practically no benefits.

I wholeheartedly disagree. Declarative stateless system configuration a la Nix solves a lot of issues that users face all the time.

Whether the time investment is worth it at present is debatable but there’s a clear path towards yes IMO because a project focused around proper IaC elevates operating systems onto another level because it abstracts and centralises configuration. It takes one person to figure out how to configure a certain thing in a sensible way and they can publish that work as a NixOS module for everyone’s benefit. Most of the work I put into NixOS is upstream because of this.

Right now, it’s absolutely catered towards nerds and other technologically able people like us but imagine what a further abstracted GUI could do for mere mortals.

Shareni@programming.dev · 10 months ago

Thanks for the detailed response.

I’d nowadays be able to solve that particular problem with one line of relatively simple code in NixOS

I can’t remember the exact details of the whole issue, but that part was for a desktop entry. If I remember correctly, in the end I had to create a system service and there were no readily available examples like for the packages. After days of researching in my spare time, I had to ask in the irc for a snippet from someone’s config.

As the person who implemented a variant of this for Nix (buildFHSEnv), it’s rather straight-forward.

Oh, it seems really cool. I’ll need to look into it.

I mean, that’s just one particular interface. It’s actually quite flexible to do it this way though as it allows you to dumb it down if you don’t like it with a little refactor:

That’s definitely an improvement, but the default config is still far better IMO.

I probably wouldn’t bother with doing that stuff in Nix and would rather just keep the plain i3config text file and set the option glue to just use that file; effectively a glorified stow.

Replacing stow with home-manager has the same issues as replacing a regular distro with nixos. If I can stow all of my dotfiles, why would I use home-manager to handle them instead? In most cases it’s just going to be harder to configure anything, and you also need to rebuild your home every time you want to update a config.

This more complex interface is only truly beneficial if there are parts of your config that vary depending on some other conditions. Some users may have the need to only run a set of commands or have certain launch options on one machine but not another. Trivial to do with lib.optionals and the like using this kind of interface but very hard to do if it was just a list of strings or one large string.

What benefits does it have over just using a shell script?

I guess it’s also great for programs that aren’t following the standards like firefox.

Well, then tell it to not to do that? I don’t know the module in question but any well-designed module has an option for precisely that. If it doesn’t, I’d consider that a bug.

It’s probably a skill issue, but that ties into another problem I’ve had when messing around with home-manager: the only source of options I found was mynixos. So to configure anything I had to first guess potential keywords to search for the option I’m interested in. And that’s after learning about it from some video on youtube, because google left me high and dry.

I wholeheartedly disagree. Declarative stateless system configuration a la Nix solves a lot of issues that users face all the time.

Can you give me some examples, what issues will I face running MX + nix that I wouldn’t if I ran nixos?

As someone who works with terraform, I understand the benefits of being forced to keep a single source of truth instead of remembering to update my post-installation script and keep things synced across devices. But on the other hand this is everything I need to do to get a fresh install to where I’m currently at:

install the single docker dependency that doesn’t work with home-manager
clone my dotfiles and symlink them
set up nix, home-manager, and switch
remove the few packages I’ve replaced with nix ones
cp the i3.desktop (home-manager and sddm were not agreeing)
clone and install doom

It’s definitely not a lot to maintain, and the issues are either obvious and easy to solve, or just a small waste of space. For example if I forget to remove the debian version of git, it’s still going to automatically source the nix one first. Home-manager with just a list of packages makes the hardest part of that process a breeze, while still being really easy to set up.

The main problem was getting started from 0, so I’m considering writing a post about it when I get a bit more comfortable. Trying to learn nix declarative package management from the nix manual is a bad idea, and almost all of the resources are on nixos. A quickstart guide with a few commands and examples would’ve had me up and running in 10 minutes instead of days.

Whether the time investment is worth it at present is debatable but there’s a clear path towards yes IMO because a project focused around proper IaC elevates operating systems onto another level because it abstracts and centralises configuration. It takes one person to figure out how to configure a certain thing in a sensible way and they can publish that work as a NixOS module for everyone’s benefit. Most of the work I put into NixOS is upstream because of this.

Right now, it’s absolutely catered towards nerds and other technologically able people like us but imagine what a further abstracted GUI could do for mere mortals.

Oh for sure, a home-manager gui that let’s you customize every package from a single place while automatically updating your config would be a complete game changer. But I’m talking about the current state of things. In that regard, currently every linux user can enjoy simple declarative package management with stable and bleeding edge sources. Yet I never see it mentioned, while even beginner threads are being spammed with nixos recommendations. Imagine if casuals could open their software center or discover and install nix packages instead of flatpaks.

Atemu@lemmy.ml · 10 months ago

If I can stow all of my dotfiles, why would I use home-manager to handle them instead? In most cases it’s just going to be harder to configure anything, and you also need to rebuild your home every time you want to update a config.

Yes, yes indeed. That’s why my dotfiles are still in a git repo (don’t get the point of stow), not in home-manager.

If you do in fact need home-manager’s features for some of your dotfiles though, it can effectively act as a stow superset for the rest.

What benefits does it have over just using a shell script?

Declarative stateless configuration rather than imperative stateful configuration.

With a bash script, you’d have to meticulously craft together the i3config file using shell script syntax and remember to run that every time you change something. home-manager just does all of that for you with high-level data types and frameworks specifically made for that purpose.

that ties into another problem I’ve had when messing around with home-manager: the only source of options I found was mynixos. So to configure anything I had to first guess potential keywords to search for the option I’m interested in.

Yeah, it’s not great. https://search.nixos.org/options? is really useful for NixOS.

You have to either use your browser’s dumb search on https://nix-community.github.io/home-manager/options.xhtml or your pager’s dumb search in man home-configuration.nix.

Can you give me some examples, what issues will I face running MX + nix that I wouldn’t if I ran nixos?

All the issues which declarative immutable stateless system configuration solves such as atomic updates, configuration rollback in case you messed something up and trivial recovery. I’m sure I’m forgetting some since I’m so used to having them.

The main problem was getting started from 0, so I’m considering writing a post about it when I get a bit more comfortable. Trying to learn nix declarative package management from the nix manual is a bad idea, and almost all of the resources are on nixos. A quickstart guide with a few commands and examples would’ve had me up and running in 10 minutes instead of days.

Yeah, docs are a pain point. If you think that section is bad (I think so too), everyone will thank you for rewriting it. Feel free to shoot a PR to Nixpkgs and ping a few people from the docs team if you’re motivated.

Yet I never see it mentioned, while even beginner threads are being spammed with nixos recommendations.

I don’t get it either. NixOS is the best thing since sliced bread for a certain kind of person (experienced hacker who has felt the pain points which NixOS relieves) but I’d never recommend it to an inexperienced user in its current state.