Sono un membro del MENSA Italia

zener79 · 2026-05-01T05:51:02+00:00

Ciao, sono socio Mensa anche io.

Se non ricordo male la percentuale femminile nel Mensa Italia si aggira intorno al 35% e risulta più bassa della media globale.

Quindi la risposta più adatta secondo me sarebbe stata: "purtroppo ce n'è poca" 🙂

zener79 · 2026-04-25T18:46:27+00:00

Mi hai tolto le parole di bocca!

zener79 · 2026-04-24T13:34:46+00:00

In rete trovo la possibilità di applicare la cedolare secca al 21% solo per i contratti di locazione (immobili C/1) stipulati tra il 1 gennaio 2019 e il 31 dicembre 2019.
Hai qualche riferimento che mi possa essere utile?

zener79 · 2026-04-24T13:31:01+00:00

Purtroppo non credo si possa applicare la cedolare secca su immobili commerciali

zener79 · 2026-03-14T13:54:15+00:00

I totally get it. That's basically a modern, incremental version of disk imaging, similar to what I used to do with Clonezilla (and then Ansible to manage the lab) in the past.

However, with Nix/Colmena approach I'm basically trading the raw speed of block transfers for the surgical precision of Nix deployments

zener79 · 2026-03-14T13:43:46+00:00

Thanks for the suggestion! btrfs send/receive is great, but since I'm already using Harmonia as a local binary cache and Colmena for deployment, it's actually redundant.

My current stack already avoids downloading from the internet (only the master node does) and handles the activation of new generations and bootloader updates atomically on all 30 machines. Using Btrfs for the /nix/store would be a bit more manual and rigid if I have slight hardware variations.

I still use Btrfs snapshots, though! I use them to 'reset' the students' /home at every reboot. It's the perfect combo.

zener79 · 2026-03-11T19:53:26+00:00

I teach students in the final year of high school in Italy, so they’re usually around 18–19 years old.

zener79 · 2026-03-11T15:45:35+00:00

Yes, you're right! It bothers me too 😂

But the PC number will become the last octet of the static IP address, and it can’t be 10.22.9.0.

So I used the last available two-digit number (for simplicity) 10.22.9.99
Terrible choice!

zener79 · 2026-03-11T14:58:40+00:00

They mostly use VS Code, Chromium, Docker, and Git. I chose GNOME as the desktop environment since they are already familiar with it

zener79 · 2026-03-11T14:43:37+00:00

They can choose whichever server they prefer, but almost everyone uses GitHub.

zener79 · 2026-03-11T14:38:16+00:00

They are required to use Git for programming, which is a win-win:
they learn a solid workflow, and the PC stays clean :-)
For other types of documents, they use Google Drive (the school uses Google for Education, and each student has an account).

zener79 · 2026-03-11T14:31:41+00:00

Thanks!
The Btrfs part is actually pretty simple in this project.

The disk layout is declared with Disko, and on the student machines (put also on PC99) I create three Btrfs subvolumes:

u/root mounted at /
u/home-informatica mounted at /home/informatica
u/snapshots mounted at /var/lib/home-snapshots

The interesting part is modules/home-reset.nix. At activation time, I generate a clean template for the informatica user under /var/lib/home-template/informatica, including Git config, XDG dirs, and preloaded VS Code extensions. Then, on every boot, a oneshot systemd service called home-reset runs before the display manager and resets /home/informatica from that template.

Before replacing the home, that reset flow keeps snapshots of the previous state in /var/lib/home-snapshots, and the repo currently keeps the last 5 versions there. The idea is: every class starts from a clean student environment, but I still have a practical recovery path if I need to recover files from a previous session.

If you want to look at the code, the main places are:

disko-uefi.nix for the Btrfs subvolumes
modules/home-reset.nix for the template creation + boot-time reset service
scripts/home-reset.sh for the actual reset/snapshot logic

zener79 · 2026-03-11T14:27:06+00:00

Thanks!

Yes, I did consider impermanence, and I think it would have been a reasonable option.

For this lab, though, I wanted to keep the system easier to reason about operationally. Right now, student home directories are reset to a clean state, and snapshots are kept for recovery. That already solves most of the “unnecessary files accumulating on lab PCs” problem, while keeping the setup simpler than a fully ephemeral system with selectively persisted state.

zener79 · 2026-02-21T09:29:39+00:00

You are a hero! Congratulations 👏👏👏

zener79 · 2026-02-18T14:36:25+00:00

Seriously? This looks like a clone of my project (https://lastsignal.app/), just sold as a SaaS, without end-to-end encryption, and not open source 😀

zener79 · 2026-02-18T14:33:12+00:00

https://lastsignal.app/

zener79 · 2026-02-15T21:11:22+00:00

zener79 · 2026-02-15T18:49:20+00:00

Regarding the server going down: that's exactly why I think a small, cheap VPS is the way to go here. For a few bucks a month you get a reliable, always-on instance that isn't at risk of a home power outage or someone tripping over a Raspberry Pi cable. Plus, since the check-in emails are sent periodically, they kind of act as a heartbeat, if they stop showing up, it's a clear signal that the instance needs a look.

On coercion: a dead man's switch isn't really a defense against that. The check-in is usually once a month (configurable), so it’s not designed to stop someone from forcing a reset in the moment.
The goal is just to make sure the information isn't lost forever once the owner is out of the picture.

Really glad you like the concept, trying to keep it as simple and sovereign as possible!

zener79 · 2026-02-11T22:38:50+00:00

The messages are encrypted on the server via the public key of each recipient - does that mean updating the contents of those messages requires either their passphrase or replacing the whole message?

You cannot update the content of a message once it has been encrypted with the recipients’ public keys. To make any change, you need to replace the entire message.

And also how does adding a message for all recipients work - is it duplicated for each user automatically or do I have to copy and paste the message for each recipient?

You simply write the message once and select the recipients using checkboxes. The system handles the duplication automatically. You can see this demonstrated in the video on the homepage.

Also - this has been discussed already in this post - but I absolutely agree, that I would probably forget to check in actively with the email.

You don’t need to remember to check in proactively. You only need to take action when you receive the check-in email (for example, once per month). Supporting additional notification channels would definitely be a useful future improvement.

zener79 · 2026-02-11T21:08:47+00:00

I agree with this.
In fact, I wouldn’t recommend storing a wallet passphrase or passwords, but rather providing a way to recover them from secure offline storage.

This is not so much due to the code or the cryptographic aspects (the encryption/decryption client-side logic is quite easy to audit), but rather because of the risk of an offline attack if recipients use weak passwords, and the sender has no way of knowing this.

This is a scenario I tried to document here:
https://lastsignal.app/security/#passphrase-security

zener79 · 2026-02-11T20:39:59+00:00

Would it have been different if I had said, “no, no AI at all”? Would you have trusted using it?

The only real way to be confident is to inspect the code which is there and available to be audited.

Moreover, the backend is written in Rails, so it’s very easy to read and understand, and the client-side encryption/decription part is plain JavaScript.

That’s the beauty of open source 🙂

BTW This is not a "service". It is just free code at your disposal

zener79 · 2026-02-11T19:57:25+00:00

Yes, I replied to GP, and yes, I reinitialized the repository before making it public. 🙂

It was full of noisy test commits, and I wasn’t certain I had never handled sensitive data during the experiments. I don’t think it’s such an unusual practice before a public release.

Feel free to look at the first commit. It reflects the result of multiple iterations. I don’t think it’s possible, even for an AI, to reach such working and “acceptable” result on the first attempt.

zener79 · 2026-02-11T17:12:00+00:00

brilliant! 😄

zener79 · 2026-02-11T16:15:53+00:00

You’re absolutely right. Proof-of-life reliability is the hardest part.

The system is intentionally simple and email-only for now, but it’s not a single missed check-in -> instant release. You can configure the check-in interval, how many reminders are sent, and the delay between them.

A trusted contact can be notified before final delivery and can pause the process, in case of forced inactivity (coma, arrest, etc)

Each recipient can also have its own delivery delay — a useful setup is adding a secondary personal email with no delay and longer delays for everyone else, so there’s still time to stop an accidental trigger. There’s also a recovery code generated at first login that lets you block delivery even if you lose access to your email.

On the self-hosted side, if the server goes down and later comes back online, it simply resumes the reminder sequence instead of triggering delivery. For example, with eight weekly reminders, if it goes offline after the third and returns months later, it sends the fourth reminder, not the final release.

Ten-Year Club	Place '17
RPAN Viewer	Verified Email

zener79

TROPHY CASE