rasguanabana

I wonder why they went for ECDSA and RSA and how a freshly initialised sensor obtains enough randomness to create an unrecoverable private key. Other than that the overall protocol looks very interesting.

> So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone.

It’s possible to recover from these with git reflog, though.

Asking for a number between 1–10 gives 7, too.

An alternative to just exporting a variable is to prepend it to the command. This will keep it unexported for subsequent calls in current shell.

var=value some_command

This will still show up in /proc, but a lot of internal tools often rely on environment variables, so it’s kind of inevitable.

There is a live view, but it looks like the machine has broken down

The only thing that comes to mind for me is simpler header, but not sure if it makes much of a difference anyway.

Wouldn’t VLM be susceptible to prompt injection?

For sure string like "zqb" would give me a pause with this letterform, because it looks a lot like "ząb". Maybe it would be clearer in surrounding text, though.

My first instinct was that JPEG XL would produce bigger images, probably for better quality.

I doubt it. There’s a reason you can’t call from iPad (despite having SIM card variant). There’s a reason you cannot use Pencil with Mac on touchpad. There’s a reason you have very limited multitasking support on iPad and none on iPhone.

Apple wants you to buy more devices to fill gaps that another one doesn’t support.

Why go that way. I’m no digital signal processing expert, but images (and series thereof, i.e videos) are 2D signals. What we see is spatial domain and analyzing pixel by pixel is naive and won’t get you very far.

What you need is going to frequency domain. From my own experiment in university times most significant image info lays in lowest frequencies. Cutting off frequencies higher than 10% of lowest leaves very comprehensible image with only wavey artifacts around objects. You have plenty of bandwidth to use even if you want to embed info in existing media.

Now here you have full bandwidth to use. Start with frequency domain, set expectations of lowest bandwidth you’ll allow and set the coefficients of harmonic components. Convert to spatial domain, upscale and you got your video to upload. This should leave you with data encoded in a way that should survive compression and resizing. You’ll just need to allow some room for that.

You could slap error correction codes on top.

If you think about it, you should consider video as - say - copper wire or radio. We’ve come quite far transmitting over these media without ML.

How about Fourier transform (or cosine, whichever works best), and keep data as frequency components coefficients? That’s the rough idea behind digital watermarking. It survives image transforms quite well.

I don’t clearly see how it’s ground-breaking. Non-repudiation could be achieved long before blockchain, because we have cryptography and can sign stuff.

It’s not all about computing. It’s about avoiding conversion from electrical to optical signal (and back) at every network node, which is costly.