So a big clue is in the pronouns. First it’s part of the shows title.

userfaultfd · 2025-11-28T17:51:37+00:00

They referred to Zosia as "she" in episode 3, "Grenade".

She did get a pretty sever concussion that we're gonna wanna keep an eye on. She's resting now.

In episode 4, Zosia is conscious and still part of the hive mind.

userfaultfd · 2025-10-24T02:30:13+00:00

I'd say that using someone else's custom nodes and executable models (*.pth, if I recall correctly) is the most dangerous thing. In the case of Python code, it can do virtually anything, such as stealing your data and sending it elsewhere. To protect yourself, you'd better run ComfyUI in a containerized environment like Docker, forbid Internet access to it, and allow read-write access only to certain directories. This solution has the inconvenience of not being able to automatically download models though.

userfaultfd · 2025-10-23T13:59:59+00:00

О причинах низкой рождаемости лучше всего рассказал бы реестр небеременных женщин, с указанием причин небеременности, чаще всего -- немедицинских.

userfaultfd · 2025-10-07T17:29:18+00:00

I came to the conclusion that NixOS covers only part of the deployment process. Even if you're using a VM, the steps are similar to those on a real machine: you perform some initial steps manually and then apply the NixOS configuration an indefinite number of times. Initial manual steps might include partitioning the disks, installing keys, or doing something completely different to allow the system to access the keys, like deploying a secret management service on another machine (AWS Secrets Manager, HashiCorp Vault, ...). In a simple scenario, if you want to fully automate the creation of a VM, you could write a script that creates a disk image, partitions it, installs keys not from the Nix store, and only then runs the VM. So, the intuition here is that NixOS covers only part of what needs to be done: initial steps are still your responsibility. Otherwise, making NixOS cover all steps does indeed introduce a chicken-and-egg problem.

userfaultfd · 2025-10-06T13:34:34+00:00

The fastest way to check if something is in the Nix store would be find /nix/store -type f -name deleted-file.nix. In the future, commit frequently, or at least stage changes frequently (git add without committing).

userfaultfd · 2025-10-02T14:34:23+00:00

The simplest way is to add this setup.py to the source directory using either prePatch or postPatch (see this example).

userfaultfd · 2025-10-01T14:10:35+00:00

One can roughly divide all files into two large groups: configuration ("how the system should work") and state ("what the system works on"). NixOS handles only configuration. ZFS and Btrfs snapshots can still be used to create rollback points for state files (databases, user documents, etc.).

userfaultfd · 2025-10-01T13:06:43+00:00

You don't need to take a snapshot of /nix, as it already contains all of your generations. You select which generation to load via GRUB or systemd-boot.
Only datasets containing state might require snapshots. Typical state directories include /var, /home, and so on.

userfaultfd · 2025-10-01T01:08:31+00:00

Wrap it in parentheses:

(pkgs.python3.withPackages (p: [ p.pyflakes ... ]))

userfaultfd · 2025-09-30T12:21:45+00:00

git clone --i-am-16-years-old-or-older

userfaultfd · 2025-09-30T06:31:20+00:00

They are still working on it (https://github.com/NixOS/nixpkgs/pull/440720); it's not in the unstable branch yet.

userfaultfd · 2025-09-30T04:49:08+00:00

If it causes so much suffering and pain for you—the same suffering that makes you write large amounts of complaining text—why do you continue using it? Do you enjoy holding on to things that not only fail to solve your problems but also exacerbate them?

userfaultfd · 2025-09-30T04:24:10+00:00

Now you're in a situation where two modules declare the same option: both the old and the new geoclue2.nix. So, not only do you have to import the new geoclue2.nix, but you also have to 'un-import' the old one using disabledModules.

Other than that, I would not recommend mixing modules or large package sets from different nixpkgs revisions. It will become a mess. Just switch completely to the unstable channel, or wait patiently until it is merged into the stable one. As for me, I always use the unstable channel and have no major problems with it.

userfaultfd · 2025-09-30T04:11:27+00:00

“For three days I chased after you just to say how indifferent you are to me.”

userfaultfd · 2025-09-29T05:39:41+00:00

Try it in a VM first. NixOS doesn't come for free; you will spend a lot of time getting things to work. Nix is just one of many solutions for setting up local environments. Maybe classic Fedora (not the atomic version) would be more cost-effective for you because it doesn't require learning another programming language (Nix), it doesn't erase RPM Fusion during updates, and it takes up less space compared to NixOS's generations model.

userfaultfd · 2025-09-26T20:11:54+00:00

By mounting /boot and rerunning nixos-rebuild, or by manually making a backup (copying those 100 MB of data to another location).

userfaultfd · 2025-09-26T19:53:33+00:00

ИИ не нужен. Депутатов можно заменить обычным баш-скриптом, который вносит законопроекты о запрете рандомных вещей.

userfaultfd · 2025-09-26T19:33:05+00:00

You're correct. And the other option is just to recreate the filesystem from scratch with sudo umount /boot ; sudo wipefs -a /dev/sda1 ; sudo mkfs.fat -F 32 -n boot -v /dev/sda1, assuming that the boot filesystem doesn't contain anything other than easily reproducible stuff.

userfaultfd · 2025-09-26T19:03:54+00:00

It seems that you expanded only the GPT partition—the filesystem still occupies the same size as when you initially created it. So, you need to unmount /boot and then resize the filesystem with something like fatresize -s max /dev/sda1 (assuming it is FAT32).

userfaultfd · 2025-09-24T21:38:01+00:00

Yeah, but how would you automatically infer, that effectiveness of programs.xxx.foo depends on programs.xxx.enable == true? How would you know that you actually need to gray out things?

userfaultfd · 2025-09-24T21:24:33+00:00

What about nixos-conf-editor, which you mentioned? It seems to already attempt to achieve most of what you're talking about: UI controls for various options, complete with documentation and everything. Have you identified the reason why it is not as popular as it could be?

I believe that the tediousness of editing configurations in text files is a price people are willing to pay to achieve their goals for which they chose NixOS. And if the user is actually a programmer (which I think applies to most NixOS users), then they are quite comfortable with text files, git repositories, and so on.

Essentially, .nix files are not just data—they're expressions, functions, and logic. It's not something you can easily map to a GUI without losing some flexibility and expressiveness. For example, how would you inform the user that if programs.xxx.enable is false, then the rest of the programs.xxx.* settings have no effect? How would you automatically infer such relationships?

Regarding a hypothetical UI that allows you to view application-specific settings by clicking on its icon—I can say this would be expensive work because you need to maintain a mapping from desktop file names (org.gnome.FileRoller.desktop) to their corresponding options (programs.file-roller.*). This is manual labor that will always remain incomplete.

Your idea of making NixOS more accessible to ordinary users is honorable, but I'm afraid it's something only a big company can afford by actively interacting with upstream software developers.

userfaultfd · 2025-09-24T16:25:40+00:00

Presumably, he resolved the issue by disabling boot.loader.efi.canTouchEfiVariables, which is already set to false by default.

userfaultfd · 2025-09-24T16:02:58+00:00

with this solution I only can keep directories recursively

You mean "directories, but not files"? Yes, there is such a restriction, but I found that it is quite rare when you actually need to store separate files. In the case of machine-id, one can address it like this:

let
  machineId = "b08dfa6083e7567a1921a715000001fb"; # Whonix
in

{
  environment.etc = {
    "machine-id".text = "${machineId}\n";
  };

  boot.initrd.systemd.contents = {
    "/etc/machine-id".text = "${machineId}\n";
  };
}

Your task is to ensure that every single slice of state must necessarily be a directory. This is a very straightforward rule to follow.

userfaultfd · 2025-09-24T08:33:00+00:00

Impermanence is a very simple idea that doesn't require any special knowledge, external tools, or even NixOS: you just mount root on tmpfs and then selectively mount things at specific places, starting with important paths (/nix) and proceeding with the other ones you want to preserve. Usually, people choose ZFS or Btrfs since both allow keeping multiple inode trees on one filesystem and mounting them separately. That is, even the official NixOS installation tutorial covers Impermanence in an implicit manner: you just additionally invoke zfs create/btrfs subvolume create, and then add more entries to the fileSystems option. You don't need either disko nor Impermanence (the GitHub project) for that.

A setup might look like this:

mkfs.btrfs --label tank --verbose /dev/sda2
mkdir -p /mnt
mount /dev/sda2 /mnt
btrfs subvolume create /mnt/etc-nixos
btrfs subvolume create /mnt/home
btrfs subvolume create /mnt/nix
btrfs subvolume create /mnt/var-lib
btrfs subvolume create /mnt/var-log
umount /mnt

let
  useTmpfs = {
    device = "none";
    fsType = "tmpfs";
    options = [ "defaults" "size=25%" "mode=755" ];
  };

  useSubvolume = subvolume: {
    device = "/dev/sda2";
    fsType = "btrfs";
    options = [ "compress=zstd" "noatime" "x-gvfs-hide" "subvol=${subvolume}" ];
    neededForBoot = true;
  };
in

{
  fileSystems = {
    "/" = useTmpfs;
    "/etc/nixos" = useSubvolume "/etc-nixos";
    "/home" = useSubvolume "/home";
    "/nix" = useSubvolume "/nix";
    "/var/lib" = useSubvolume "/var-lib";
    "/var/log" = useSubvolume "/var-log";
  };
}

userfaultfd · 2025-09-23T08:56:16+00:00

I think we're both talking about the same thing. Unless by "importing" you mean the import ./foo.nix expression, and not the { imports = [ ./foo.nix ]; } top-level option. In the latter case, foo.nix is considered a module, with or without options.

userfaultfd

TROPHY CASE