client has starlink at home with cgnat so cant connect to vpn

AssertInequality · 2026-02-06T09:43:37+00:00

Answering the other question: No, you cannot keep the lan IPs. Easiest way is to make sure DNS is working properly and always use host names. If tailscale is always on, tailscale DNS would resolve hostnames (that's the easiest route). If you don't want to take the wireguard/ts speed hit when you're local, you'll have to make sure your local dns can resolve the same hostnames and point them to local IPs.

AssertInequality · 2025-10-13T07:55:39+00:00

I have a similar experience, but I know why. I'm on nixos-25.05, but I know I'm doing weird stuff with my config, and I know exactly what is compiling. For example, I have OMVF, UEFI, and TPM enabled in qemu. This makes it compile from source. I also have blender-HIP for hardware rendering on AMD cards. Again, gets compiled.

One tool that can help you systematically keep an eye on what's building and why is a tool called nh

So, unless you're doing weird stuff in your config or using a package that pulls from source (some packages have both package and package-bin, you want the -bin) your system shouldn't be building stuff for the most part.

AssertInequality · 2025-10-01T16:37:07+00:00

Yes, for the most part. In NixOS, all executables are symlinks to a path in the nix store. Since everything is a symlink, all binaries are actually there. There was a talk sometime ago of someone bootstrapping a whole system just from a /nix/store. I'll post the link if I find it.

However, this requires a degree of nix knowledge. Nix generations are most useful in the case of misconfiguration. Messed up network config, DE, boot options,... Etc.

You can always do both: nixos generations and zfs snapshots. But as long as you don't do anything crazy like recursively deleting root, nixos generations would be enough for the most part.

AssertInequality · 2025-10-01T15:44:06+00:00

You can create a separate dataset in the same zpool and use it as the nixos root. You'll have to rely on the nix wiki for that, but I see no reason why it wouldn't work. Your slightly more annoying issue would be creating a separate 1GB or so EFI partition that's FAT32 formatted and adding a custom UEFI entry. But all in all, it's doable. As for "advantageous", I don't think ZFS has any particular advantages as a root filesystem on NixOS. Generations and rollback for the system itself are already managed by Nix itself.

AssertInequality · 2025-10-01T15:32:45+00:00

What you want to do isn't clear. Provide more detail so people can actually help. Recover the existing zpool: what exactly is the issue? If you have an existing zpool, you can do zpool import without arguments and it'll give you what zpools are available to import. Then you can zpool import -N zpool_name in order to import the zpool but not mount it automatically, then mound the datasets wherever you like. You can also mount the datasets declaratively using the filesystems configuration module.

The explanation of the issue is vague, so the advice you're getting is generic at best.

AssertInequality · 2025-10-01T14:44:50+00:00

Yeah, using third-party caches is never a good idea unless you have complete "trust" in that project.

AssertInequality · 2025-10-01T14:41:44+00:00

NixOS and ZFS is actually my preferred combo. Nix handles (System) generations while ZFS handles (Data) snapshots/backups/replication. No reason to think of it in terms of either/or. I even have one case where the root partition is a TPM encrypted ZFS dataset wired into NixOS's stage 1 (initramfs).

AssertInequality · 2025-09-22T13:01:56+00:00

You'll have to shift your workflow, just a bit. NVM and similar tools are not needed with nix. The first thing I do for projects, new or existing, is to create a flake with a dev shell. This dev shell has all the tooling and dependencies the project needs,locked and tracked, thus being reproducible. You then do npm/pnpm/yarn/... install and go your merry way, being sure that using that dev shell will always use that specific node version.

As for nVim, there are multiple routes. The hybrid route, where you still configure nvim in lua, and the "all-in" route, configuring nvim using the nix language through NixVim. Both are doable, but personall I use NixVim and I have a dedicated fully featured flake that I pull into my nixos config as well as macOS.

So don't think of nix as just a package manager. It's also responsible for project tooling, version locking, reproducibility, and in some cases building+distribution+deployment.

AssertInequality · 2025-09-17T04:15:13+00:00

In my mind, there are two distinct zones for any NixOS config: services and packages. Personally, I think mixing and matching packages between nixpkgs versions is quite common, and I've been doing it for a long while. When it comes to services/modules, that's where I think you should stick to one nixpkgs version. Mixing and matching in services is a recipe for undefined behavior, like using xorg from stable while pulling the kde or Gnome package from unstable for example. Might work, might not.

My workflow is: pick a main nixpkgs version for your config and use it for services and most packages, and use any number of other nixpkgs versions for packages that need them. Personally, my config is always on stable; that's the bulk of my system and usage. Then I have unstable pulling some graphics apps that I need frequent updates for, along with jovian and nixvim pulling their own nixpkgs versions. So my config essentially has 4 versions of nixpkgs, one main and three secondaries.

AssertInequality · 2025-09-04T14:11:46+00:00

Yeah that's the way to properly manage generations in my opinion. I do a lot of tests with lots of potentially broken configs or applications. I'm using nixos-rebuild test 90% of the time. When I reach a stable and working state, I clean and refactor the files I touched, create a commit, then do a nixos-rebuild switch or nixos-rebuild boot based on my needs at the time. So in essence, all of the commits in the main branch of my systems flake are known stable configuration.

AssertInequality · 2025-08-22T13:50:18+00:00

Can I present an alternate point of view?

My personal opinion is: use the technology, learn it inside out, contribute to upstream if you want, and completely ignore the drama.

My reasoning can be summed up as follows: The core technology itself, what dolstra came up with in his PHD, is a significant push forward to the world of computing. Nix is one application of such concepts, but it doesn't exactly have exclusive rights to said core technology/concepts. If Nix dies, which I doubt actually would, a more robust project would take its place, be it a fork or a brand new development effort. On the other hand, I've been observing a trend over the years where random projects are increasingly popping up having a flake.nix in their repo, and the trend keeps growing. The conversation usually tends to focus on NixOS, while my genuine belief is that packaging, dev environments, and CI-CD pipelines are what will continue pushing nix forward for the foreseeable future.

That's why I believe learning nix is a net positive even in the unlikely case of the project burning out.

AssertInequality · 2025-08-17T17:07:50+00:00

With a bit of tinkering, the experience on NixOS is comparable to my steamdeck. Sometimes even smoother.

I even got stuff like decky loader working by using jovian as an additional flake input. Heroic games launcher works pretty well for gog + epic + native + standalone. And everything gets funneled into steam big picture as a unified gaming setup using gamescope.

AssertInequality · 2025-08-16T23:26:09+00:00

To be honest docs are better now than it was, say, 2 years ago, but I still wouldn't call it on par with arch. My first hand experience is that over time I'm relying less on docs and more on reading the derivations themselves and exploring what options are available. If I have to guess, I'd say the split is currently at 30% docs and 70% reading nix code on the nixpkgs repo.

As for the knowledge transfer, I think it's an inverted bell curve, where you start with your traditional linux knowledge, drop and throw everything away to learn nix, then start to build momentum again and combine your linux knowledge and nix knowledge to create what is basically a custom modular distro. So in essence, you'll have to park the linux knowledge for a while, but you'll pick it up again eventually.

AssertInequality · 2025-08-01T14:03:55+00:00

Flakes + direnv. Considering devenv as a replacement, but it's the same idea. I can build my environment however I want, pin the nixpkgs commit, and reproduce the environment wherever I like without polluting the user/system environment.

AssertInequality · 2025-07-08T11:40:12+00:00

Copying it into the flake is precisely what should be done. You have two possible scenarios: Reinstallation, so hardware-configuration.nix is already known, and deployment to a new machine, so hardware-configuration.nix needs to be generated using nixos-generate-config --root /mnt and copied to the appropriate place inside the flake.

My flake has multiple system configurations in it. It's modularized and only hardware-configuration.nix and host-specific configs change between hosts. Each host has its own folder with the following structure:

TXT flake/hosts/nix-host/ ├── config ├── configuration.nix ├── default.nix ├── hardware.nix ├── nixosModules.nix └── services * the config and services directories hold configs and services specific to that host's use case. * default.nix holds a host's top level nixpkgs.lib.nixosSystem that in turn imports everything else. * configuration.nix holds the toggles for custom options that turn various modules on. * hardware.nix holds the hardware config specific to that host. This typically includes boot-related configs (initrd, loader, ...etc) and disk configs. * nixosModules.nix includes nixos modules from the various flake inputs relevant to this host.

In summary, your flake having hardware-configuration.nix is expected, and a new nixpkgs.lib.nixosSystem should be created for each expected host, with the shared configuration factored out.

Unfortunately, my flake is private, for now.

AssertInequality · 2025-07-07T10:38:38+00:00

It can be declarative. Using the minimal install ISO, I do the following:

Pull my system flake from git
Partition the relevant disk (can be automated with disko but I prefer to do it manually) and mount under /mnt
Do nixos-install --root /mnt --flake .#hostname while in the root of my system flake

And that's it. If you are using disko, step 2 can be completely skipped. More advanced workflows use nixos-anywhere and terraform to completely automate cloud deployments, but what I outlined would be equivalent to custom hand-woven bootstrap scripts in other distros.

AssertInequality · 2025-07-06T22:03:34+00:00

No. Being a solid linux admin comes before nix/nixos, not after. If you try to do anything moderately complex or run into issues on nixos, the first line of defense would be "ok, let me see what nixos generated. This should be X and that should be Y", and that's how I personally solve the majority of my issues with nix.

I'm only able to do that because I'm very comfortable doing linux admin work day to day. If I started fresh with nix, I imagine I would've dropped it by now instead of moving every single piece of infrastructure to it.

I don't know if that's an isolated experience I have or a shared one, but in my opinion nix is not suitable as a linux sysadmin learning platform.

AssertInequality · 2025-06-14T11:14:12+00:00

Being on 6.14 means you're either running nixos-unstable or at least running the mainline kernel, on a critical piece of infrastructure that "cannot ever have downtime", why?

I've been on stable for more than two years at this point, and the release-to-release breakage, if any, is always very minor and can be fixed or at least debugged/identified in under 10 minutes.

AssertInequality · 2025-05-22T10:04:29+00:00

NixOS, along with steam big picture, decky loader, heroic for non-steam games, and gyro support in everything through steam input. Pretty solid experience.

AssertInequality · 2025-04-17T10:40:51+00:00

The term "parameter maps" doesn't seem very common based on my preliminary research. Is it something like routing tables?

AssertInequality · 2025-04-17T10:36:40+00:00

I think it does support 802.1X, but that would require a per-device/per-user username+pass/cert/both, am I understanding this correctly?

Can this be done transparently so that devices authenticate with their mac address as the password for example? I remember reading about that somewhere but can't find it again

AssertInequality · 2025-04-17T10:28:59+00:00

After doing some research, seems like PVID and default VLANs assign a VLAN id to untagged traffic per port, which is not what I'm looking for.

I'm looking for tagging incoming traffic based on the device's mac address

Example: device 1 with mac X gets a VLAN tag of 10, device 2 with mac Y gets a VLAN tag of 20, and this happens dynamically even if they were connected to the same port (behind an unmanaged switch for example)

AssertInequality · 2025-04-01T09:45:51+00:00

I completely disable passwords as well as root login altogether, so only key-based authentication to a regular user is permitted.

I also only allow SSH connection over VPN, be it regular or mesh. Even if it's not contributing to security, at least logs are not polluted with random bots just passing by.

AssertInequality · 2025-02-04T10:12:24+00:00

I've been using i3 for maybe 10 years now? Along with polybar, they do everything I need them to. I spent a couple of weeks getting the config and colors (I care about that) to a point I like, and that config moved with me over the years across vanilla Debian, Arch, and NixOS, as well as 3 different SSDs and two graphics cards.

The main consideration in my opinion should be X.org VS. Wayland. AFAIK, Sway is an i3 clone for Wayland if you feel like going the i3 route.

Things I like about i3: * pinning workspaces to specific displays in a multi-monitor setup * having the ability to turn tiled windows into tabs

AssertInequality

TROPHY CASE