@sundogplanets Didn't the USSR try the exact thing that company is trying to sell & determined that it wasn't worth it?

@Furo_Fur RSS time

@starfrosch @signalapp They're crazy today.

@silmaril @signalapp Signal is in the Guardian Project F-Droid repository.

@lexinova @signalapp You have to be trolling.

@gbsills @vkc When someone leaves one of those comments, you can help by replying with "dude you're fucking weird".

Recognize & call out bad behavior when you see it. Not saying anything makes it worse because it teaches those people that they can get away with it. Don't excuse it with "boys will be boys", don't ignore it, don't encourage it.

@catsalad
> look CAT
The CAT is small, weighing 10 POUNDS, it has white FUR, 2 yellow EYES, 4 powerful LEGS, 1 long TAIL, & 10 WHISKERS.
The CAT has the following special abilities:
| Dark Vision
| Climb
| Toxoplasmosis
The CAT's stats are as follows:
| HP 85,000
| MP 12,000
| DEX 60
| SPD 55
| ATK 120
| WGT 10.2
What will you do?
>

@AMS @vampirdaddy I hadn't even thought of that! sshd allows setting a special login shell per user, which doesn't have to be a shell at all!

@vampirdaddy @AMS It also means less time until the filesystem is secured, but if you use SSH you still have to wait for the send to complete before you can delete your SSH keys. Maybe a solution would be to use TLS to an open & write only fileserver so SSH keys can be deleted earlier, maybe something like a pastebin.

@vampirdaddy @AMS What AMS means is that you can wipe the keys from your device & still be able to send the state of your OpenZFS filesystem to a remote even though you don't have the keys anymore. So you can simply have your keys backed up somewhere else, then in an emergency wipe them from the local device (so your filesystem can't be read) & zfs-send to a remote incase you never get the local device back from police or a thief or whoever is taking it. That way you can secure your data without having to wait for the backup to complete first like with most filesystems, simply do the backup second.

This is really cool to me because delta syncing encrypted data is hard, but the way ZFS snapshots work means you're actually copying only new blocks, not actual changes, & those blocks can contain changes.

@vampirdaddy @AMS zfs-send & rsync are two different things with different uses, but do similar things. Both do unidirectional syncs, but rsync is for files only & optionally (SSH by default) uses encryption in transit. zfs-send is for copying a snapshot or the current state of the entire filesystem or specific datasets within it, & those datasets either have or do not have encryption on the disk. If the dataset is encrypted, then the generated snapshot file will contain only encrypted data; if not, then only plaintext data. If the snapshot is streamed to a remote OpenZFS filesystem through SSH, then there is additional encryption in transit equivalent to the default settings for most rsyncs, since both use SSH.

OpenZFS filesystem or dataset encryption is unstable right now & can cause data loss because of keys being dropped & stuff if some storage devices don't appear to the computer in the right order or never appear at all or something. We're talking about at rest encryption, not in transit encryption.

@AMS @vampirdaddy @jgilbert @tom @dianea If only OpenZFS encryption was stable
That's really cool & something I would really like to have once OpenZFS no longer has issues with losing encrypted datasets.