unhinge

What do you like about ansible? I guess it abstracts away the need to check for OS/init system? How else does it help in place of shell scripts?

Also after using NixOS, it's amazing what NixOS does and disappointing that ansible is not so great for deterministic config [^ansible_drawback], its more or less a batch of commands executed together. The closest thing, to NixOS, I've been able to achieve is load a variables file in playbook.yml and enable/disable service or install/purge pkg based on variables declared. I might be nitpicking/wrong given I've not been using long enough but directory layout is kinda too verbose. I say that because it'll get really messy very quickly when writing modules for more services. NixOS is great, you only have to have configuration.nix or flake.nix+flake.lock too (if using flakes) and rest you can import however you like.

[^ansible_drawback]: I know that nix stores its state in /nix and ansible doesn't have any such assumption about the target host so it can't rollback to previous state

~~Then, what does a package maintainer rely on?~~

Edit: I'm so dumb. It's obvious they'd check original developer's repo or issue tracker. I'm sorry

I wouldn't be so sure it doesn't affect NixOS^[1].

I am not a security researcher, nor a reverse engineer. There's lots of stuff I have not analyzed and most of what I observed is purely from observation rather than exhaustively analyzing the backdoor code.

Also, it may take 10 days to downgrade the package^[2].

You are right. I shouldn't have used diff. I'll fix that

Also, incremental changes from subvolume to its snapshot might be incorrect as that will be new data added to subvolume, rather that old data deleted from subvolume while still present in snapshot. I'll have to check carefully.

just comparing the subvolume with its snapshot with btrfs send -p /example/subvol /snapshot/of/example/subvol >examplediff.btrfs.

From man btrfs-send

generate a stream of instructions that describe changes between two subvolume snapshots

Thanks for btdu, it seems useful as 'btrfs fi du' probably doesn't account for compression, will check it out sometime.

Thanks that helped. I have one snapshot of home. ~~Size of diff between btrfs subvolume and~~ Additional space used by snapshot is 11GiB (probably) and btrfs fi du -s / is 72GiB, making 83GiB (closer to btrfs fi df /).

Between btrfs filesystem usage / and btrfs filesystem du -s / there's nearly 11GiB difference for used space. ~~I have checked btrfs du -hs <path/to/subvolume> for all subvolume in the filesystem, and total seems to be 72 GiB, hence the confusion. Still I don't know if I'm using the tools properly or something else is at fault here.~~

To correct myself, 11GiB is additional space used by snapshot probably ~~used space difference between btrfs fi usage and btrfs fi du -s / is because of diff between snapshot and parent volume (didn't consider that while adding all used GiB of subvolumes)~~. So btrfs filesystem usage works well to check used/free space.

edit: fix incorrect args; additional space is not diff

I remember seeing a post on lemmy blocking posts with certain words on firefox (and its derivatives) with ublock origin.

1. Open My filters tab in ublock origin extension settings.
2. To block posts with word random on lemmy.ml, add this to text field lemmy.ml##div.post-listing:has(span:has-text("/random/i"))'. i after random/ matches case insensitively.

user's password can be totally different from luks password if you're using autologin. You can keep it same but that's totally optional. You can login without entering any password at all if not using luks (or using autodecrypt), you can see that in live isos.

oh, I forgot. Thanks for mentioning that :)

grep -i fried menu

I have no idea what TPM is

Read Skull giver's reply or look it up.

Re-reading your post, I take you want to avoid typing long and tedious password? And that's why you want to auto-decrypt?

1. (Recommended) You could use strong memorable passwords that are not difficult to type and enable autologin. Related xfcd comic:

2. systemd-cryptenroll: For TPM usage, I highly recommend using secure boot. Though not sure if you can easily do that. A less secure alternative using systemd-cryptenroll would be use tpm2-pin and bind key to no pcrs (discouraged). But then you'll have to use luks2 for encryption. Notice from man systemd-cryptenroll regarding tpm2-pin:

Note that incorrect PIN entry when unlocking increments the TPM dictionary attack lockout mechanism, and may lock out users for a prolonged time, depending on its configuration. The lockout mechanism is a global property of the TPM, systemd-cryptenroll does not control or configure the lockout mechanism. You may use tpm2-tss tools to inspect or configure the dictionary attack lockout, with tpm2_getcap(1) and tpm2_dictionarylockout(1) commands, respectively Also tpm2-pin is not disk encryption password and short alphanumeric password needed so tpm decrypts the device; so encryption password should be secured in a safe place. Also check if your distro supports systemd-cryptenroll.

3. usb drive: read previous comment

4. clevis: It probably isn't as simple as systemd-cryptenroll but I guess you can use zfs and combine that with tpm2-pin if not using secure boot (discouraged).

You'll have to make a compromise somewhere between security and convenience. Even if you use pam mount, you'll have to enter the password, biometrics won't do.

Edit: remove unnecessary user tag and add img uri