AirBreather

Since you’re still a Windows user at least for now, and assuming that you’re planning on continuing to be open-source, I can recommend Certum for this. https://shop.certum.eu/open-source-code-signing.html

I gave up trying to initialize the USB thingy using Linux (I tried regular Arch [btw] and an Ubuntu distrobox IIRC), but once I got through the initial steps using Windows, I was able to sign ongoing builds with Linux just fine. It took a LOT of trial and error since there seem to be very few people who simultaneously

• pathologically dislike using Windows regularly
• still want to make it easier for people on Windows to minimize Windows Defender complaints when running software that they build
• have the motivation and resolve to send a lot of PII to one of a handful of companies whose longtime business model is based around reputation and trust in order to get a usable certificate
• are stubborn enough to go out of their way to still figure out how to do a subset of this stuff on Linux
• are capable of actually succeeding at that, and
• are willing to show how they did it in a way that should be reasonably easy enough to understand and adapt to your situation

I didn’t renew after my first year - I switched from publishing an executable to publishing it on the web, so I no longer had a need for it - so I don’t know how things have changed (if at all). Most of my information came from eventually stumbling upon this wiki page for a Ruby-based tool where they figured out the last bits I needed to get it to work.

• It also has instructions for initializing the USB thingy on Linux too, so if I were to renew, I’d give that a fair shot… but seeing “icedtea” and a link to a web application that no longer resolves, I’d still only recommend it if you can use a Windows machine once a year.

JPEG also supports lossless compression.

Technically, the spec does require it, but given that we’re in a thread about ecosystem support for a file format that’s approaching its 15th birthday, it’s worth considering how many image viewers will actually be able to work without the DCT step that is the essence of what typical JPEG does.

I don’t have a Windows machine handy to test, but it’s entirely possible that maybe lossless JPEG won’t display in its default viewer.

These are fun rabbit holes to go down. Everything here is true, of course: Big-O complexity isn’t everything, context always matters, and measurements trump guesses.

But also, how many times have you encountered a performance problem with a slow O(n) solution that you solved by turning it into a fast O(n²) solution, compared to the other way around? The difference between 721ns and 72.1ns is almost always irrelevant (and is irrelevant if it’s not on a hot path), and in all likelihood, the same can be said at n=500 (even 500x these numbers still doesn’t even reach 0.5ms).

So unless context tells me that I have a good reason to think otherwise, I’m writing the one that uses a hash-based collection. As the codebase evolves in the future and the same bits of code are used in novel situations, I am much less likely to regret leaving microseconds on the table at small input sizes than to regret leaving milliseconds or seconds on the table at large input sizes.

As a trained practicioner of “the deeper magics” myself, I feel the need to point out that there’s a reason why we call these types of things “the deeper magics”, and that’s because heuristics like “better Big-O means better performance” generally point you in the right direction when it matters, and the wrong direction when it doesn’t matter.

Another older blog post saying the same: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

To be fair, await is a bit more like comefrom, and it’s been around for a few releases now.

Rockwell Retro Encabulator: https://youtu.be/RXJKdh1KZ0w