Its the static site generator nuxt, detailed herehttps://blog.marciosobel.dev/my-first-blog-post

I'm not the author, but I agree it feels nice on mobile, and the dark and light mode is a nice touch. I think it takes a hint from the browser system settings too.

What do you use to hose your blog? It looks so clean.

Interesting but no mention of Guix. I'm still on the fence.

Requiring an LLM to use a tool is not "sane". Very much the opposite, I'd argue.

He made it look so easy, but I still can't convert my existing config to dendritic without failing completely with the usual inscrutable Nix errors. 😢

Probably rsync -aH would do just fine, but Nix has a tool for this.

https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-copy

Their closest direct example is using SSH:

Copy the entire current NixOS system closure to another machine via SSH:

# nix copy --substitute-on-destination --to ssh://server /run/current-system

The -s flag causes the remote machine to try to substitute missing store paths, which may be faster if the link between the local and remote machines is slower than the link between the remote machine and its substituters (e.g. https://cache.nixos.org/).

rsync has -H flag for preserving hardlinks

The comma command is magic! Of course I use it often to run something that I don't feel like I need listed in my main config - especially a command that I just want to run once. But there are also plenty of cases where I do want to add a package to a config, and I know the command that I want, but I don't know which package it comes from. The comma is a real easy way to find out.

I haven't watched the video - maybe these tips are already in there. If you run a command like , dig you'll often be prompted to choose which package to get the command from, if the same command is provided by multiple packages. So that's one way to get a package name. If you don't get that prompt you can use comma as a lookup tool like this:

$ , --print-packages dig
Packages that contain /bin/dig:
- dig.dnsutils
- bind.dnsutils

Or you can ask comma to show you the path of the executable it would run, and infer the package name from the path:

$ , --print-path dig
/nix/store/qm1hvm2hfryx7xz9k3njsb6gksvs29is-bind-9.20.18-dnsutils/bin/dig

The Nix store path format is /nix/store/<hash>-<pname>-<version>-<output> so that is the dnsutils output of bind, which is bind.dnsutils.

So that gives me package names I can put in my NixOS config, or devshell, or whatever. In this case I could install any of dig, bind, dig.dnsutils, or bind.dnsutils. (They all end up pointing to that binary in bind.dnsutils.)

I really appreciate the comma command.

holy hell, superb! but this is why people buy an Apple TV i guess :)

Great video. Short and descriptive.

the metric that makes sense for that qualifier i guess is customizability. But one can argue its straightforward control of the packages that is clearly different and unique about it

What does "powerful" distro mean? (no, I've not watched the video - just curious what it means)

For instance, it allows the option to be configured in home-manager, while plugins are set via a home-manager option.

o yea this did work, i went with the first snippet but im curious abt what the better thing abt diong it in multiple files

I tried nixos. But alas, I don't have the time to unlearn traditional Linux management and get into the groove that makes it click for others. I don't run a homelab, my dev environment is my company's macbook that connects to development rhel servers through ssh or vscode. I run popOs for what little time i have to tinker in my free time.

I tried tinkering with NixOS in a VM on apple silicon. The experience of finding what image to download for Apple Silicon and installing the OS was straightforward and i did manage to start getting the hang of it. But very quickly realized you start out maintaining packages through the system config file, invest some time, discover home-manager, and then later discover flakes. Then I also discovered none of the tools like neovim, python work like they do on imperative distros.

At least with python the right way to manage is to forget using pip or uv in the traditional manner and simply use the nix-shell feature per directory which is actually the most frictionless way to do that in my experience.

I can see how nix and nixos are godsend for DevOps, server folks who need reproducible builds, love configuration as code that compilss the same way every time and anywhere, and hate non-deterministic behavior.

But yes. The author is right. I too felt like the OS needs your time until you set it up just right for your needs. Daily driving it is not a install and go affair unless you already have a repo of configs built up.

And if you're like me and anxious about having everything organized "just right" it will be a nightmare of ignorance until you find the best practices which certainly takes a lot more time and kindness on yourself than you might allow or actually possess.

pkgs.symlinkJoin might help:

{pkgs, ...}: let
  plugin1 = pkgs.fetchFromGitHub { ... };
  plugin2 = pkgs.fetchFromGitHub { ... };
in {
  xdg.dataFile = {
    "krita/pykrita" = {
      enable = true;
      source = pkgs.symlinkJoin {
        name = "pykrita";
        paths = [
          plugin1
          plugin2
        ];
      };
      recursive = true;
    };
  };
}

You might also want to manage your plugins in separate files:

# krita-plugins.nix
{
  config,
  lib,
  pkgs,
  ...
}:
with lib; {
  options.yourOptions.krita.plugins = mkOption {
    type = types.listOf types.path;
    default = [];
  };
  config = {
    xdg.dataFile = {
      "krita/pykrita" = {
        enable = true;
        source = pkgs.symlinkJoin {
          name = "pykrita";
          paths = config.yourOptions.krita.plugins;
        };
        recursive = true;
      };
    };
  };
}

# kirta-plugin-a.nix
{pkgs, ...}: {
  yourOptions.krita.plugins = [
    (pkgs.fetchFromGitHub { ... })
  ];
}

# kirta-plugin-b.nix
{pkgs, ...}: {
  yourOptions.krita.plugins = [
    (pkgs.fetchFromGitHub { ... })
  ];
}

THANK YOU

That was what I was missing. I am newish to C and had not heard of pkg-config. I will update my post and read more about it.

Do you know about pkg-config --cflags?

    devShells.${system}.default = pkgs.mkShell {
      buildInputs = with pkgs; [
        pkg-config
        clang
        wlroots_0_19
      ];
    };

pkg-config --cflags wlroots-0.19 outputs -I/nix/store/pkg-hash-wlroots-0.19.0/include/wlroots-0.19

clang your-file.c $(pkg-config --cflags wlroots-0.19) should resolve #include <wlr/backend.h>

I did not know that about gcc and mkShell so that's good to know, thank you. Removing it did not solve the issue however.

It appears that wlroots and wlroots_0_19 evaluate to the same package and neither cause any errors when entering the dev shell. I tried the one with the version number though, but with the same issue. wlroots_0_19.dev also doesn't seem to exist.

I appreciate the suggestions though!

I'm taking some stabs in the dark here. I think that mkShell gives you gcc automatically, wrapped with configuration for C header lookup paths. I think it does the same setup as pkgs.stdenv. Including gcc explicitly might be shadowing that configured gcc? Try removing gcc from your buildInputs.

Another thing to maybe try: I don't see wlroots in a package search, but I do see packages with version suffixes, like wlroots_0_19. So maybe try changing wlroots to wlroots_0_19 or wlroots_0_19.dev

disclosure: i'm an engineer at flox so take this with a grain of salt (or pepper or any spice of your choice).

i've been around the nix community for some time and i've been using nix for over 15 years and i don't plan to stop. but you know what frustrated me the most in all these years? using nix at work. and seeing it being used after i leave. this is what i learned in all these years: everybody wants the benefits of nix, but not everybody is willing to climb "the nix mountain". for some it just makes no sense to spend all those hours and i've learned to accept that. and that is why i joined flox, to bring nix to everybody, especially at work.

if you are interested to see how nix works and why it works the way it works, please learn it. it is an amazing idea and i don't see myself using anything but nix. but if i need to onboard +500 engineers i'm definitely reaching for flox and sharing my nix magic with the help of flox.

tldr; flox was built to bring nix to work.

re the privacy policy concern raised here, i'm happy to answer specific questions about where things stand now

VC funding, presumably.

Talked to one of the founders a bit over a year ago and he essentially said that it's about having something you can present to co-workers and bosses as a way to start using nix that isn't painful to get up and running for people who aren't already in the nix world. At the time, their hub didn't have a good privacy policy and they didn't have answes as to why or when it would change, so I stopped paying attention to them. No clue what it's like now.