antx

Tailscale actually has a great write-up on the subject [0]

TLDR; Ideally, IPv6. Otherwise, NAT traversal techniques such as STUN, or hole-punching.

[0]: https://tailscale.com/blog/how-nat-traversal-works/

Not from here, no...

Right?! I was watching a video yesterday by Matthias Wandel and they were using the Emporia smart home monitor. This thing has 16 inputs and it seemed to be built upon an ESP32!

For some reason I can't find the video anymore...

Edit: ha! function_seven beat me to it... (7 hours ago), it's not on his "main" channel

yeah, I scripted my backup jobs, and use good old email notifications to report.

I expect an email every day. If I don't receive one, I know there's a problem with email delivery.

I dropped duplicati after its database got corrupted irreversibly. Also, recoveries were always very long.

I now use restic and I'm very happy. I find it to be very resilient. No more database, only indexes and data packs, which can be repaired.

That's really good advice. Even perfectly edible mushrooms can give you adverse effects. Eating just a piece and wait for 24 hours is how I usually go.

There's no wiggle room. You need to be 1000% certain of identification, if you decide to eat a mushroom.

That's how I've been doing it for the last decade. I forage a lot of mushrooms, but don't consume anything I'm not sure of.

Also, there are "beginner" mushrooms, that don't have any dangerous look-alikes, such as the famous "chicken of the woods" (laetiporus sulphureus). You can't really go wrong with mushroom like these.

Another case in point: my TCL series 5 has made 11K (!!!) DNS requests for scribe.logs.roku.com, just last month.

As a matter of fact, it's now the top-blocked domain in my pi-hole.

It's a shame Roku won't allow you to at least opt-out of telemetry.

The most probable issue related to this kind of behaviour is pastejacking.

It's possible for the server to detect that you're actually using curl (with the help of the user agent of other methods) and also that you're piping it to an interpreter.

Knowing that, the server could send you a malicious payload, that wouldn't be apparent when only downloading the file otherwise.

Some people think this isn't the real issue, that (the lack of) code signing is the real problem. I don't disagree with that, but really, people should look at the code they're going to execute, whenever possible.

And when I say "whenever possible", I sure believe a few lines of shell script deserves to be inspected. Even if you lose the 0.5 seconds of automation the pipe provided. I mean, we're not talking about millions of lines of kernel code, here.

stop encouraging users to pipe curl to the shell, darn it.

And just because I have to be THAT guy, with Arch linux you use pacman -Ql and pacman -Qo to do the same.

Also, man! Do I love the Arch wiki:

https://wiki.archlinux.org/index.php/Pacman/Rosetta

Thanks! I remember watching the BBS documentary part 8, I learned a lot about the history of my childhood's programs

Another example is the "Indian pipe", Monotropa_uniflora. It's completely white, and very beautiful. It is a myco-heterotroph, getting its food through parasitism upon fungi rather than photosynthesis.

Well, we crashed the database. That's not very punny.

Question. Why the cute-bunnies-reminiscent-of-80s-cartoon "mascots" for WinTun?

You're right, the degree was removed in 1967, because Kelvin's units are considered absolute. However, one could argue that, since it has a scale, each "step" or "unit" can be considered a "degree", like in a literal scale. In informal conversation, we should not be so pedantic. Even some modern scientific textbooks still include the degree.

"MariaDB" didn't go proprietary... holy shit, my heart stopped for a minute.

MAXSCALE 2.0, by MariaDB did. Stop spreading bullshit.

In-transit encryption is a no-brainer.

The most secure (from a trust point of view, at least) method of encrypting file is obviously at rest, client-side.

Seafile uses that method, but fails on the implementation on some aspects.

"In-place" encryption versus "volume/disk" encryption both have major drawbacks and are hard to implement correctly.

In case of "in-place", the private key is a possible vulnerability (like leaving the key under the doormat).

In case of disk encryption, while it's mounted, it's worth nothing if (when) you are compromised.

He probably thought he had a backup:

> "All my backups were the encrypted data, so those didn't really help either."

My guess is that the "bad encryption" simply was replicated over his "backup".

If you can't go back in time, a backup is worthless.

Ransomware are a thing, people, when will you learn?

Well, sorry about your loss. Then again, please understand that NO, you didn't have a backup.

What you had was a single copy (probably a simple rsync, am I right?)... that is worth nothing in case of corruption or voluntary mischief.

Learn from your mistakes. Either use a solution that has a retention policy, or don't do backups at all.

Mostly fixed in debian... damn these guys are fast!

https://security-tracker.debian.org/tracker/source-package/o...