one answer would be to make the parking spaces expensive enough to account for electricity. parking meters are pretty widely adopted.

Arguably a lot of parking fees are already expensive enough to account for electricity. In a city charging, say, $15/hour for parking, it seem like we should be able to expect say $0.15/hour to be a drop within the existing profit margin. There's a very simple order of magnitude relationship between the two numbers already.

Manufacturing defects happen, trees fall, and panels get dusty. They don't merely "sit on a roof." They're anchored, the anchors have spacing and a form factor, and the anchors pierce the roof's waterproofness. They're not electrically equivalent if they output a different voltage range.

you can also just use a normal rolling shutter camera at a higher frame rate and blur the frames together.

Java has an excellent GC, but a horrible runtime. .net is probably the best GC integrated into a language with decent memory layout ability. If all you want is the GC without a language attached, LXR is probably the most interesting. it's part of MMTK which is a rust library for memory allocation and GC that Java, Ruby, and Julia are all in the process of adding options for.

LXR isn't that great when the amount of heap memory is actually reasonable rather than being unnecessarily low. Watch the ISMM talk I linked above.

it's self catalyzing, but only above a certain temperature. if you dump enough water on it, it goes out

I think the main point is that these sorts of parsing mistakes shouldn't be so easily exploitable and the problem is that the length is non trivial to parse, so if you mess up the parsing of that it escalates the security of a ton of other bugs.

That just means it's the right size engine for a bigger plane without vtol.

The hard part is that anything designed to be breakable in a week is only ~150x away in strength from being broken in an hour. That means you need to be incredibly confident about how strong your algorithm is. It's much easier to eat a little bit of cost such that you think it's invulnerable for thousands of years because that way you don't need to worry about a factor of 2 here and there.

Right. Strength in a shadow contest like cryptography can be, best case, estimated to sixteen-bit orders of magnitude (+-65000x). Just because you can't break it doesn't mean somebody else secretly knows a game changing way to break it. So you keep padding with huge exponential hedges such that if they scan shave a dozen bits off the strength of the scheme, it's still secure under finite resources.

Playing close to the margin is super dangerous.

Realy ChaCha seems trivially implementable without leaking anything.

The problem is it isn't significant work. You can perform ChaCha8 on pen and paper in ~30 minutes. It's literally 768 single cycle 32 bit integer operations.

768 single cycle instructions to do WHAT? To encode a few bytes or something? You can't convince me that the cost of cryptography is never prohibitive. Boldly asserting that your idea of "significant work" is universal for all applications isn't going to convince me, nor are weird anecdotes about tangentially related things.