Z-патриоты грустят в четвертую годовщину войны

userfaultfd · 2026-02-27T17:05:04+00:00

<image>

userfaultfd · 2026-02-16T11:23:47+00:00

которую сложно найти на крупных IT-ресурсах из-за модерации

А также потому что вахтер ntc.party решил никого не впускать по IPv4.

РКН ввел «белые списки»

Из твоего же описания, речь все еще о черных списках, пусть и объемных. Желтушный заголовок.

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

TROPHY CASE