I found it more tolerable running it at 50% resolution.

Still horrible though.

> And this is how backwards compatibility comes to kill innovation.

With all of the novel and esoteric programming languages that exist, I wonder why hasn't there been a "I can't believe it's not c/c++" language that breaks these things, but isn't taken seriously enough to diverge completely from the ISO language standards. (for bonus points, with standardized gcc extensions, and something like embedded asm but for compiled languages (like iso standard c))

Why would it require that much data? I always thought you wouldn't need to add or change more bytes than are in the output.

Also, git hashes aren't just based on source code. You can add that data anywhere that git uses to generate the hash.

That's true of a CRC code, but hashes are a lot harder to break.

Git hashes each file, and puts those hashes into a tree object, like a directory listing. Then it hashes the trees, recursively back up to the root of the repository. Finally the hash of the root tree is put in the commit object, and the commit object is hashed. Thus the two places you can put additional data to be hashed are the file contents (either in existing files or new files), or in the commit message. You can get a few free bits by adjusting less obvious things like the commit timestamp or the author's email address, but not nearly enough to make your forged commit have the same hash as an existing commit.

I'm still not following why it'd require so much data? I thought the goal was to have the commit hash collide with an existing commit hash, is that not enough?

I looked around, and it seems like the right place to hide the added data is in the "trailer" section of the commit. It's where signed-off-by lives and is used to generate the commit hash.

You might want to come up with a plausible reason for random data to go in there though. (likely using a header that wouldn't normally get printed out)

In a CRC-style code, you're essentially adding up all the bytes and letting it overflow the counter, so that the counter is a fixed size (usually 16 or 32 bits). Then you add a few more bytes, exactly the same size as the counter, so that the data bytes plus the extra bytes add up to zero. The extra bytes are delivered along with the data bytes, so that the recipient can repeat the calculation and verify that the total is still zero. If you modify the data, it is trivial to recalculate the CRC code so that the total is still zero.

Hashes are much, much more complex, and they're non-linear. Each bit of the hash output is intended to depend on every single bit of the input, so that changing a single bit in the input creates a radically different hash output.

In a paper published this year, https://eprint.iacr.org/2020/014.pdf, the authors Gaëtan Leurent and Thomas Peyrin changed the values of 825 bytes out of a 1152 byte PGP key in order to generate a new key with the same signature (aka, the same hash). It only cost about $45k, too.

Step 1: Get 3 pigs. Step 2: Number them 1, 2, and 4. ...

When I saw the title, I thought it was going this way.

Or, more specifically, a driver to turn an IDE port into GPIO pins that PC programs can control. Closing the gap on making a feature-complete Windows 95 arduino core.

I think you can do this directly, the linked project just tells the kernel "this is a parallel port here", and it just uses normal I/O instructions. The IDE port is already exactly that, though I think the data-direction register controls the whole port at once, rather than one bit at a time.

A lot of the "breaches" added to the site are from unknown origins. Like, a large mixed collection sold online that somehow found it's way to Troy.

Last time I used HIBP, it told me what site the leak was from.

If your password shows up at all, you should change it wherever you use it.

See also: detaching from, or quitting a tmux/screen session.

Why do you think that? Are you just guessing?

> Somehow I prefer this solution than ubiquitous drones

"When all you have is a hammer..." My only question is where most of that $300 cost is coming from.

Me too, but I would think the price is due to the low batch size in manufacturing. If we want PLB to spread, we would need to integrate them in smartphones. The price of the hardware would probably drop dramatically.

> I am absolutely willing to die on this hill. We need a GDPR-sized hammer to fix this.

Any thoughts on a labelling system? Like, "re-flashable open source firmware", "cannot be remotely bricked", "API-spec and code examples included" stuck on the side of the box.

I'm surprised some hardware hacker supply company, like adafruit/sparkfun hasn't gotten on this yet.