not 100% sure but I think the permittedimsecurepackage option takes effect after the rebuild. Doing the first rebuild with the env-override and --impure should work, and then it should work without for the next ones.

If it's because of the lack of plan for the device, then if it helps, it's an extremely "in-character" and sensible action for the involved characters. It doesn't really need to be a plot device going forward, because the circumstances around it so far is pretty "complete" so to say.

I've tried to stay vague because of spoilers.

no what you really need is backups, isn't it? having an external hdd that you're backing up to is a lot better against data loss than putting that same drive into any kind of raid. (because now you truly have a copy, while in a raid it's still a single point of failure)

I can feel your pain on the ISP part though. (Haven't looked into this, but sounds like a zfs-job) Just saying that backups doesn't have to be offsite, but they do need to be separate from the original data medium. Going offsite is an important early step, but getting it on separate storage is the first step.

If anything, I would argue that especially in a homelab, the risk of misconfigurations or by mistakes when tinkering can increase by using raid. If you've have a couple of years of experience with raid and do not see my above argument, then please share your experiences.

I am sorry for this wall of text, your comment caught my eye while thinking about something else, tl;dr: raid is not a backup

If you are on HDD then looking at what else is using the same disk, and reducing that usage, may yield some results. Forexample, if /var/log is on the same disk and can't be avoided, then reducing log volume or batching writes may reduce the "context switches" your HDD has to do. There should be options for I/O limits/throttling/priority in systemd. If you have only postgres on the HDD, I'd consider giving it 90% of the max bandwidth -- maybe that'd be more effective than going full throttle and hitting the wall. If you have postgres and some other service fighting for the HDD's time, these limits could help. Make sure access time tracking is off (or set to relatime).

Well it's both possible, and has been done. both with mp3s and FLAC, not too long ago. It's not the format itself, but rather the applications parsing the files that are the target.

CVE-2023-37327: A remote code execution vulnerability in GStreamer’s FLAC file parser caused by an integer overflow. Carefully crafted FLAC files could exploit this flaw to run arbitrary code on the target system

https://nvd.nist.gov/vuln/detail/CVE-2023-37327#%3A%7E%3Atext=GStreamer+FLAC%2Ccode+on

In general I agree with you, especially on the image part, but I found the opensuse page to be a decent variation of this.

[I am not an electrician, so this is not a recommendation and I would not be qualified to make one] With that out if the way, what I would do to test this theory is to measure the voltage between a ground pin in each house, using am extension cord or similar to bridge the distance. A decent multimeter should do the job. Note that the cord itself would cause a voltage drop, but the ethernet cable would too so I think that'd if you can't measure a difference with the extension cord (which should have less ressistance than the ethernet one) then it shouldn't matter(?)

Note that while ground is normally "the safe pin" (not really a thing I guess but..) in this case, where the suspicion is a differential, then it should be very much considered live. And that means all precautions should be taken, such as not following a random stranger's advice.

It might be worth looking into those plugin-sockets with ground fault protection in both ends (not sure if they'd do anything in this case), if the ethernet cable is shielded, maybe removing the shield in one end (such that the cable is grounded only to one house) could make things better (or maybe even worse?),

and while maybe not feasible: fiber wouldn't be affected by this as it's just light, and likewise WiFi or other wireless tech could be feasible. with clear line of sight, 5GHz can provide very good speed and latency.