Is the Damm algorithm strictly better than all of these?

https://en.wikipedia.org/wiki/Damm_algorithm

Back when I switched to Ubuntu 8.04, fifteen years ago, they had the best set of included drivers and non-free (MP3) software.

I switched back to Debian (12/bookworm) a few months ago because of Ubuntu's snap packages. I've not noticed any downside yet.

No more snap, apparmor, telemetry, Ubuntu Pro advertising, etc.

Protobuf over UDP can use the UDP payload length. Likewise for the many variants of self-sychronising DLE framing (DLE,STX..DLE,ETX) used on serial links.

A varint length field prepended to protobuf messages (sent over a reliable transport, such as TCP) seems sane.

How do you avoid condensation on walls and mould problems?

Draughts :-) It's an old place, it doesn't seal. That and sleeping in rooms with the window open just a crack as much as possible. Mould tends to hit when people obsessively seal everything up.

I still have a condensation problem in a few specific places I have to keep an eye on. It's not general.

Why would you have "condensation on walls and mould problems"? The heating circuit is a closed loop.

I think he's asking about the common trap people seem to fall into where, trying to keep heat in, they shut down air changes too far. Human breath puts a surprising amount of moisture into the air, and cooking can too. If you let that build up and have a cold wall it can build up a film of damp very quickly and if it's left damp and cool it can encourage mould. That kind of bad air quality is far worse than a bit of a chill.

The "double-bonus two-liner":

    export vid="sourcevid.mkv"
    ffmpeg -i "$vid" -vf vidstabdetect -f null -; ffmpeg -i "$vid" -vf vidstabtransform "$vid.stab.mkv"; ffmpeg -i "$vid" -i "$vid.stab.mkv"  -filter_complex vstack "$vid.stacked.mkv"

can be a one liner:

    vid="sourcevid.mkv" ffmpeg -i "$vid" -vf vidstabdetect -f null -; ffmpeg -i "$vid" -vf vidstabtransform "$vid.stab.mkv"; ffmpeg -i "$vid" -i "$vid.stab.mkv"  -filter_complex vstack "$vid.stacked.mkv"

Blind Upload uses crypto.subtle to encrypt files in the browser, before uploading them to the cloud and displaying the key only in the browser.

https://www.blindupload.org https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subt...

I use Turnstile: https://github.com/fadedbee/turnstile

You have to be careful with unknown scripts/apps on GitHub.

They may not be reviewed, may disappear or not maintained next year, file formats might be specific or not supported by other tools. The benefits are also dubious over well established tools like OpenSSL (if you just want to encrypt a file from command line).

Use widely-used well-known tools. File encryption is a commodity!

The current encoding is complete, so no future extensions are possible.

A fix would be to change:

  110rrrrr ggggbbbb - copy the last pixel and adjust RGB by (r-15, g-7, b-7)

to:

  1100rrrr ggggbbbb - copy the last pixel and adjust RGB by (r-7, g-7, b-7)

This leaves:

  1101???? ...

available for future extensions.

So I implemented this change and tested it out. Turns out, in my simple test suite, this actually changes the size of images. Not drastically. Often just a 5-10 kb difference (on a 500-600kb file), but that's still more than I expected for changing r-15 to r-7.

Suggests the DIFF16 delta-color mode is responsible for quite a bit of the savings. Maybe it would be worth experimenting the exact encoding.

One idea would be to start a predicted color (calculate the delta of the previous two pixels, apply that, then specify a delta to that). Another would be to encode the delta in YUV or some other color space, and then experiment with the best balance of bits between those channels.

Perhaps it would be better to steal bits from RUN16 instead, I somewhat doubt it's usefulness.

I really like this.

I've now added the sorting and a link to the full list.

Yes, it's a very slow Dutch Auction.

Your suggestions are very welcome. I'll add those features tomorrow.