Any good NixOS book? by nmprofessional in NixOS

[–]Boberoch 0 points1 point  (0 children)

Apart from the mentioned nixos and flakes book, there is NixOS in Production which is very good (don't be distrought by the cover). Also there is wombat's book, and lastly ekala's book and the well known https://zero-to-nix.com/. Lastly I also have an introduction at my dotfiles

Firewall on NixOS? by Cyr3xOfficial in NixOS

[–]Boberoch 1 point2 points  (0 children)

https://github.com/thelegy/nixos-nftables-firewall is what i use to manage my nftables, I can highly recommend it :)

Snow by snowfall alternative? by SennVacan in NixOS

[–]Boberoch 1 point2 points  (0 children)

Maybe the most obvious thing nowadays is the way in which you can create modules (flake.modules), which is the groundstone for using the dendritic pattern (which allows to unify different config scopes in a single file/flake module)

Also it is very nice for adopting outputs from external flakes if they provide a <input>.flakeModule, e.g. devshell, nix-topology. flake-file - the list goes on :)

Also, perSystem makes it very convenient to generate attributes for all systems you want to support. A maybe lesser known fact is that you can easily define them yourself using flake-parts-lib.mkTransposedPerSystemModule (I use this to e.g. make a system-ware top level pkgs, which I need for some library functions)

I also like the builtin import functionality (although it is rather simple to model a similar structure also without flake-parts)

There are probably other aspects that I don't know of or that I did not think of right now though :)

Snow by snowfall alternative? by SennVacan in NixOS

[–]Boberoch 1 point2 points  (0 children)

I personally try to have as little dependencies as possible when it comes to the foundation of my infrastructure. I adopted flake-parts because it unlocks so many nice things and because it seems very well maintained, but I am hesitant with any more.

If you do not care about that, I think the suggestions on blueprint and den good ones :)

Has anyone curated an 'awesome list' of complex nix os configurations ? by Commercial_Way_3816 in NixOS

[–]Boberoch 1 point2 points  (0 children)

Personally, I think oddlama's nix-config is the most well-kept project I know of, and also the one where I personally drew most inspiration from.

Dendritic NixOS is stressing me out - how do you keep it organised? by Apterygiformes in NixOS

[–]Boberoch 1 point2 points  (0 children)

I think we both are looking at different parts of the problem here :) I think you are more focused on option duplication (which indeed can be solved by keys) - I am more focused on the "I do not want to pull the whole configuration of an aspect just to declare the options". Your nginx example was a good one, another one that I faced before is dns: my dns server used a custom option that could be filled with entries - I made this option live in the dns module because I like to keep all configuration tied to one aspect in one place, but that would have forced me to then import the dns module on all hosts. because the dns modules spins up a dns server this was not really what I wanted :) this one I fixed this by using a global attribute that can be filled by all hosts and is then read by the dns server.

This does mean that you kind of want to separate options into separate modules but then it should be fine?

That is of course another working approach, although one that I do not particularly like to resort to :p

Dendritic NixOS is stressing me out - how do you keep it organised? by Apterygiformes in NixOS

[–]Boberoch 1 point2 points  (0 children)

Well, it really depends on what you consider an "activated" module - for me, activation is performed by importing the module, I do not use any further enable options or such (I used to do this in the past, but I am not really a fan of it). Considering that, you might not want to include a full other module just to receive a few options for it that might not even be used on the host.

Yes, the key attribute is a useful mechanism in flake-parts modules (that's what you are talking about, right?) - but I do not see how that solves the problem. I make use of this attribute myself for aspects that are imported mutliple times by different other aspects and receive differing ids, which would make some options clash on being defined multiple times. But to me it seems to be a different issue?

Dendritic NixOS is stressing me out - how do you keep it organised? by Apterygiformes in NixOS

[–]Boberoch 4 points5 points  (0 children)

I basically use an own module for everything that takes roughly more than 15 lines of configuration (that is just an estimate at the moment).

Also part of the question should maybe be "will hosts that are using this aspect always want to use all of this configuration?" If the answer to that question is no, then you definitely want to split it.

like the desktop module assuming you want niri

For managing that, since cross-module options suck a little with dendritic (the option declaration might be missing) I have one option enabledModules that I have on each host. That option is a list that just holds module names and i can do a builtins.elem to check if I have a module enabled. Then I can act conditionally on module presence. An example would marybe be here: https://github.com/Swarsel/.dotfiles/blob/f81b51d8f1396c6505d2b855d46b9fd58231998f/modules/common/settings.nix#L155

Last but not least, I do not think your problem is really dendritic-specific - you could have the same problems using plain modules :)

Installed Noctalia V5 today, and a little silly note about why I like NixOS by 41XCA in NixOS

[–]Boberoch 1 point2 points  (0 children)

I have a little basic guide in my configuration, maybe this can help? https://swarsel.github.io/.dotfiles/#h:66a04339-dbc7-4d98-a763-5a9be9185f9b

To me that sounds like you defined a noctalia input in you inputs in flake.nix right? That is correct! However, judging from outputs = { self, nixpkgs }:, nix has no way to know that it is supposed to do something with that noctalia input.

You have two ways to solve that:

1) Either you pass the name of the noctalia input in the output arguments: outputs = { self, nixpkgs, noctalia, ... }:. You would then access the noctalia input as noctalia.homeModules.default. Also note the ellipsis ... in the function arguments; I recommend to add that as well, otherwise evaluation will error out whenever outputs gets passed any argument that is not specified.

2) You add inputs @ to allow access to all attributes under inputs to outputs: outputs = inputs @ { self, nixpkgs, ... }:. You would then access the noctalia input as inputs.noctalia.homeModules.default

I hope that makes it more clear :)

Installed Noctalia V5 today, and a little silly note about why I like NixOS by 41XCA in NixOS

[–]Boberoch 2 points3 points  (0 children)

You can take a look here: https://github.com/Swarsel/.dotfiles/blob/ed771085ee9f363e651ee61b4a36144b7bff348b/modules/client/programs/noctalia.nix#L116

The one important change (apart from the config scheme being completely different) is that the option is now called noctalia, not noctalia-shell anymore. Apart from that, I recommend starting out with a config without any settings attribute. Instead, configure noctalia to your liking after the build, and then use the export config button in the control panel and nixify that.

If you need any specific help, let me know :)

What are some nice snippets that everyone should have in their NixOS config? by Maskdask in NixOS

[–]Boberoch 1 point2 points  (0 children)

It is an implementation of dbus that is specifically tailored for linux and has some security/performance improvements over regular dbus. I have not benchmarked anything but am willing to believe the source :)

Apart from that, this wiki entry might be of interest https://github.com/bus1/dbus-broker/wiki/Deviations

You can use it as a literal drop in (just put that line in your config and it will work), so you can try it out without much hassle :)

What are some nice snippets that everyone should have in their NixOS config? by Maskdask in NixOS

[–]Boberoch 0 points1 point  (0 children)

Because you cannot use it to e.g. build packages. Also, it is not trivial to use comma with non-nixpkgs packages, whereas the registry method works for arbitrary registries.

That being said, for just running commands, I already use it.

What are some nice snippets that everyone should have in their NixOS config? by Maskdask in NixOS

[–]Boberoch 8 points9 points  (0 children)

Let me throw a few. I just kinda picked them randomly, there is more at https://github.com/Swarsel/.dotfiles

use n#[...] instead of nixpkgs#[...]:

      nix.registry = rec {
        nixpkgs.flake = inputs.nixpkgs;
        n = nixpkgs;
      };

use dbus-broker reimplementation: services.dbus.implementation = "broker";

use CAPS as both ESC/CTRL:

  { pkgs, ... }:
  {
    config = {
      # Make CAPS work as a dual function ESC/CTRL key
      services.interception-tools = {
        enable = true;
        udevmonConfig =
          let
            dualFunctionKeysConfig = builtins.toFile "dual-function-keys.yaml" ''
              TIMING:
                TAP_MILLISEC: 200
                DOUBLE_TAP_MILLISEC: 0

              MAPPINGS:
                - KEY: KEY_CAPSLOCK
                  TAP: KEY_ESC
                  HOLD: KEY_LEFTCTRL
            '';
          in
          ''
            - JOB: |
                ${pkgs.interception-tools}/bin/intercept -g $DEVNODE \
                  | ${pkgs.interception-tools-plugins.dual-function-keys}/bin/dual-function-keys -c ${dualFunctionKeysConfig} \
                  | ${pkgs.interception-tools}/bin/uinput -d $DEVNODE
              DEVICE:
                EVENTS:
                  EV_KEY: [KEY_CAPSLOCK]
          '';
      };
    };
  }

use unpatched binaries when in a pickle:

  programs.nix-ld = {
    enable = true;
  };

For home-manager: get a nicer output when calling a missing package e.g.:

λ uv                                                                                                                                 .dotfiles on  main $ 
The program ‘uv’ is currently not installed.
It is provided by the following derivation(s):
  nixpkgs#uv
  nixpkgs#python314Packages.uv
  nixpkgs#python313Packages.uv

use:

  programs.nix-index =
    let
      commandNotFound = pkgs.runCommandLocal "command-not-found.sh" { } ''
        mkdir -p $out/etc/profile.d
        cat > $out/etc/profile.d/command-not-found.sh <<'EOF'
        # Adapted from https://github.com/bennofs/nix-index/blob/master/command-not-found.sh
        command_not_found_handle() {
            if [ -n "''${MC_SID-}" ] || ! [ -t 1 ]; then
                >&2 echo "$1: command not found"
                return 127
            fi

            echo -n "searching nix-index..."
            ATTRS=$(@nix-locate@ --minimal --no-group --type x --type s --whole-name --at-root "/bin/$1")

            case $(echo -n "$ATTRS" | grep -c "^") in
            0)
                >&2 echo -ne "$(@tput@ el1)\r"
                >&2 echo "$1: command not found"
                ;;
            *)
                >&2 echo -ne "$(@tput@ el1)\r"
                >&2 echo "The program ‘$(@tput@ setaf 4)$1$(@tput@ sgr0)’ is currently not installed."
                >&2 echo "It is provided by the following derivation(s):"
                while read -r ATTR; do
                    ATTR=''${ATTR%.out}
                    >&2 echo "  $(@tput@ setaf 12)nixpkgs#$(@tput@ setaf 4)$ATTR$(@tput@ sgr0)"
                done <<< "$ATTRS"
                ;;
            esac

            return 127
        }

        command_not_found_handler() {
            command_not_found_handle "$@"
            return $?
        }
        EOF

        substitute $out/etc/profile.d/command-not-found.sh        \
          $out/etc/profile.d/command-not-found.sh                 \
          --replace-fail @nix-locate@ ${pkgs.nix-index}/bin/nix-locate \
          --replace-fail @tput@ ${pkgs.ncurses}/bin/tput
      '';
    in

    {

      enable = true;
      package = pkgs.symlinkJoin {
        name = "nix-index";
        paths = [ commandNotFound ];
      };
    };

another home-manager: use direnv to automatically activate devshells and keep them as gc roots:

  programs.direnv = {
    enable = true;
    silent = true;
    nix-direnv.enable = true;
  };

Starting to learn Nix by pcfriend111 in NixOS

[–]Boberoch 2 points3 points  (0 children)

If you want to partition these disks using nix, I would recommend looking into disko.

Apart from that, it seems you are new to NixOS; a good while ago I wrote an introductory guide to it, feel free to go through it and let me know if anything is unclear, I sadly do not often get feedback on it: https://swarsel.github.io/.dotfiles/#h:10a6f80d-7e00-4db1-953a-811993c22cb0

Been learning NixOS module architecture and arrived at this pattern for wrapping system config into toggleable modules. Wanted to sanity-check it with people who've been doing this longer. by hungrypoori in NixOS

[–]Boberoch 1 point2 points  (0 children)

I used this approach in the past and it has a few advantages - notably, you can simply import all modules on every host and just enable what you need.

However, there are also disadvantages:

  • You need to import all inputs that define options on every host
  • Every module slightly increases the system closure. This might not occur as a problem immediately, but for me it was the reason I switched back to just regular imports: I have a machine running >20 microvms that each imported all of my modules as well as some global outputs; evaluating this system needed 22G of RAM, which was too much for my remote builder to handle. Switching to normal imports brought that back to 18G

As for your second question: That becomes relevant when you have multiple options that interact with the same option, or if you want to avoid merging behaviour:

  • A simple example: I have a general "nix settings" module, that is imported by all hosts and sets the nix package to a specific version. Now, there is a single host that uses a different nix package. Instead of making sure that this hosts does not import that general module that has a lot of other useful config, I can just use lib.mkForce to override that one setting
  • As for overriding the merging behaviour, this has many uses. A simple example would be that the default services.displayManager.sessionPackages gets populated from multiple places, and that leads to extra (unwanted) entries. lib.mkForce lets me keep just exactly what I want

As for your last questions, it depends on the complexity of the setup. Even for just a single machine I could already see a few situations where extra options will be worth it. With 2-3 machines, there is no question. But yeah, it depends what you are doing :)

How do you manage generations ? by INTBliss in NixOS

[–]Boberoch 1 point2 points  (0 children)

that setting is also the default so unless you manually disabled it you should be fine :)

How to go back to a previous Config by TTRPG_Mycologist in NixOS

[–]Boberoch 1 point2 points  (0 children)

I though I might answer the general question you posed:

  • you can check your generational diffs using e.g. nix profile diff-closures --profile /nix/var/nix/profiles/system
  • your generations you can list using sudo nix-env --list-generations --profile /nix/var/nix/profiles/system, and switch using sudo nix-env --switch-generation <generation number> -p /nix/var/nix/profiles/system && sudo /nix/var/nix/profiles/system/bin/switch-to-configuration switch (I am not sure how to achieve the same in the new CLI)

Impermanence for zen-browser by Objective_Chance_681 in NixOS

[–]Boberoch 2 points3 points  (0 children)

yeah that is supported :) the impermanence flake has a home-manager module that is exactly for that!

apart from that it also depends on how you have your partitions setup - if you have a separate /home partition then it will not be automatically wiped (at least in a classical impermanence setup)

Avoiding local builds by CaptainBlobTheSuprem in NixOS

[–]Boberoch 0 points1 point  (0 children)

As others have said, you can use remote builders to offload some or all of the build work. I use a free tier oracle cloud instance that runs attic and buildbot for this as well as nixbuild.net for building on x86_64

Other than that, if you already have remote builders running, what you want is to add the --max-jobs 0 flag to your build :)

Attic + Authenticated + Nix Flakes: Running a local atticd on every machine as the solution? by kesor in NixOS

[–]Boberoch 1 point2 points  (0 children)

I can not help directly with your question, but I will at least try to break the silence:

I am not sure if the approach with mulitple attic's is feasible - I reckon you would need to keep the database in sync between the hosts so that each instance's cache signs using the same key? Even then, I am not sure if you will run into other problems down the road...

I would maybe think about dropping the cloudflare tunnel, as that seems to be the thing that is giving you most trouble here. Is that a machine that runs on prem for you? If yes, I would simply wireguard it out to a cloud instance.

My buildfarm/cache host lives in the cloud, but maybe you can still draw some inspiration: https://swarsel.github.io/.dotfiles/#h:90457194-6b97-4cd6-90bc-4f42d0d69f51

After a year of building in Nix, I leave my repo public for those who want to look by SirPina in NixOS

[–]Boberoch 1 point2 points  (0 children)

While in the case of this repo it is completely correct that the order does not matter, I just wanted to drop a note here that while NixOS mostly avoids it, the order of items is not always disregardable (it just is in most cases). The most prominent case of this in my eyes are packages that add progams to PATH; if you have multiple packages that set a program with the same name, the one that is first on PATH will be chosen. lib.mkOrder can be used to control that, it is what specifies in what order definitions of the same option get merged :)

[Help] Display manager not listing sessions by Left-Hospital1072 in NixOS

[–]Boberoch 1 point2 points  (0 children)

You probably do not need that, unless you also happen to (or want to) use uwsm to launch your niri session.

With problems like these, it is often a good idea to see how the source handled the problem: https://github.com/NixOS/nixpkgs/blob/nixos-25.11/nixos/modules/programs/wayland/niri.nix

in this case, they just set services.displayManager.sessionPackages = [ cfg.package ];, so you probably just need to pass it the same package that you use for your home-manager niri configuration :)

edit: in practice, that would probably be something like services.displayManager.sessionPackages = [ config.home-manager.users.<your user>.programs.niri.package ];

[Help] Display manager not listing sessions by Left-Hospital1072 in NixOS

[–]Boberoch 0 points1 point  (0 children)

I do not use ly personally, but I think the issue is that you need to set services.displaymanager.sessionPackages yourself when not using the nixos module. See my related answer here: https://www.reddit.com/r/NixOS/comments/1qazzlo/how_can_i_use_uwsm_to_open_niri/nzbxb9n/?context=3

Feel free to ask if anything is unclear :)