SIGTERM, Goose, DORA, FMAC, TC, Btrfs, COMINT

1. STOPped processes on Linux, do those exit cleanly when system shuts down or are those discarded immediately? I checked if the system sends CONT + SIGTERM when shutting down. Answer was no... After some back and forth, I realized it's actually SIGTERM + CONT. Duh! Classic X/Y problem. Both are functionally almost the same, because the SIGTERM before CONT remains in queue. Yet the CONT + SIGTERM is slightly more efficient and better, because the process when continuing immediately jump to the SIGTERM handler. That's good example why questions should be generalized without going into too much detail. Are stopped processed going to exit cleanly when system shuts down or are those just discarded should have been the original question instead of asking about CONT + SIGTERM. If I want to prevent potential swap-in of a stopped process consuming a lot of memoryy, which contains all discardable state in RAM, I should send SIGKILL to it before shutting down the system.

2. Agentic Development, now I've got podman (docker, OCI) containers running Mistral Vibe (Devstral-2), Gemini CLI (Gemini 3 Pro) and Goose (with multiple backends, including local Ollama) - And lots of tinkering with it, doing many small test projects. Like Signal Notification push script in Python, which allows to send Signal messages from CLI.

3. Spent a day studying DORA - PDF - (@ https://eur-lex.europa.eu PDF). I personally see this beneficial, this might finally force demand for EU cloud and lead to high quality providers offering European cloud solutions. I personally often use lower level open source components and OCI containers. Because I've always hated the vendor lock-in as I've said it for decades in my blog. But using something like OCI layer is too low for many organizations. - kw: EU, DORA, Governance, Strategy, CSO, DPO, Compliance, Continuity, Resilience, Availability, Confidentiality, NIS2

4. Anti-Privacy features, as example Mistral prevents using Firefox Multi-Account Containers (FMAC). If it's enabled, they'll trigger endless new window creation loop which crashes browser after uh, way too many windows. Kind of fork bomb. Thank you for that. I did look for any sane solution to that, and there's none. Great. Many solutions were suggested and none of those work in any sane way. Bleep. Companies taking anti-privacy actions should be completely ignored and deeply hated.

5. The whole FMAC / Temporary Containers (TC), is absolutely broken freaking s-show.... I used 1,5 hours trying to configure very simple things, and it still fails... As example Hacker News articles always open TWICE in two new tabs and containers, whatever options you try to deal with. And the best part, these problems have persisted for years, and there's no plan to fix these. - Exactly the type of situation I really deeply love hating. Haha.

6. Btrfs Data Corruption - Sick and Tired - It seems that Btrfs regularly corrupts data integrity when using nocow. The corruption is not predictable and appears random. However, the fact is that data=writeback with ext4 works just fine, but Btrfs nocow does not. The way to fix this is not to use the nocow mode, but this is frustrating. It seems that for some data sets, it's better to have ext4 partitions, as Btrfs just can't deal with the data reliably. There is a lot of arguing about who is to blame, but that doesn't really matter. The whole point is that it doesn't work and repeatedly corrupts data. It seems that the problem may be an unfortunate combination of preallocation, sparse files, the nocow flag, and non-flushed writes to the file at random offsets. I wrote a test program and, most annoyingly, was not able to reproduce the problem. I created a large file with fallocate in a nocow directory, wrote data randomly into it without fsync, and then called system shutdown immediately. As long as there isn't too much data in the write buffers to timeout on shutdown, it works as expected. I tested this on two different hardware systems and four different Btrfs file systems on different disks. Of course, this is exactly what I hoped for as a sysadmin, but hmm... What's the problem then? Because I actually have enough memory for efficient write buffering, I decided to disable both preallocation and nocow. Let's see what happens.

7. Something different? Saab’s Sirius Multi-Domain COMINT & ELINT fusion sensors suite for communication signals (COMINT).

2026-09-13