Octopus UK has a list of charger models and car brands they support for their special tariff for cheap off-peak EV charging.

The charging cable has a protocol for negotiating power, so either side can pause and restart charging.

EVs charge unattended. It takes less of my own time to leave EV plugged in parked next to a place I want to be at, than to go drive to a gas station and stand there holding a smelly nozzle.

It's simply cheaper to have on-site batteries. It makes installation work with a smaller connection to the grid, and makes it possible to install chargers in more places without upgrading the grid connection.

Energy arbitrage is profitable on its own, so EV charging stations are almost just an excuse to get some land and a grid connection for more batteries.

At least in summer temperatures it reliably charges to 80% under 20 minutes. Its range estimate is quite good, and I can depend on it to know when I can skip a charging stop (when I first drove an EV I was freaking out about the 20% state of charge like it was a cellphone. Now I roll to the chargers with 2% left when it saves time).

It depends where you live, but infrastructure in the UK and EU has got good enough to the point I don't need backup plans. Chargers are as common as McDonald's (often quite literally). If a station is slow or busy, I can just go to the next one (and they are in clumps often enough that even with a low battery it's not a big deal).

For example, if you make sharp Cr and low-res Cb, you'll get sharper red edges with some yellow bleeding instead of completely blurry red edges if Cr was subsampled.

JPEG has 8x8 blocks, modern codecs have variable-sized blocks from 4x4 to 128x128.

JPEG has RLE+Huffman, modern codecs have context-adaptive variations of arithmetic coding.

JPEG has a single quality scale for the whole image, modern codecs allow quality to be tweaked in different areas of the image.

JPEG applies block coefficients on top of a single flat color per block (DC coefficient), modern codecs use a "prediction" made by smearing previous couple of block for the starting point.

They're JPEGs with more of everything.

Later compression algorithms were focused on video, where the aim was to have good-enough low-quality approximations.

Deblocking is an inelegant hack.

Deblocking hurts high quality compression of still images, because it makes it harder for codecs to precisely reproduce the original image. Blurring removes details that the blocks produced, so the codec has to either disable deblocking or compensate with exaggerated contrast (which is still an approximation). It also adds a dependency across blocks, which complicates the problem from independent per-block computation to finding a global optimum that happens to flip between frequency domain and pixel hacks. It's no longer a neat mathematical transform with a closed-form solution, but a pile of iterative guesswork (or just not taken into account at all, and the codec wins benchmarks on PSNR, looks good in side by side comparisons at 10% quality level, but is an auto-airbrushing texture-destroying annoyance when used for real images).

The Daala project tried to reinvent it with better mathematical foundations (lapped transforms), but in the end a post-processing pass of blurring the pixels has won.

Jargon terms like "sum types" or "affine types" may seem complicated, but when you see it's actually "enums with data fields", it makes so much sense, and prevents plenty of state-related bugs.

Proposed "effects" mean that when you're writing an iterator or a stream, and need to handle error or await somewhere in the chain, you won't suddenly have a puzzle how to replace all of the functions in the entire chain and your call stack with their async or fallible equivalents.

"linear types" means that Rust will be able to have more control over destruction and lifetime of objects beyond sync call stack, so the tokio::spawn() (the "Rust async sucks" function) won't have to be complaining endlessly about lifetimes whenever you use a local variable.

I can't vouch for the specifics of the proposed features (they have tricky to design details), but it's not simply Rust getting more complex, but rather Rust trying to solve and simplify more problems, with robust and generalizable language features, rather than ad-hoc special cases. When it works it makes the language more uniform overall and gives a lot of bang for the buck in terms of complexity vs problems solved.

On non-trivial tasks (like adding a new index type to a db engine, not oneshotting a landing page) I find that the time and effort required to guide an LLM and review its work can exceed the effort of implementing the code myself. Figuring out exactly what to do and how to do it is the hard part of the task. I don't find LLMs helpful in that phase - their assessments and plans are shallow and naive. They can create todo lists that seemingly check off every box, but miss the forest for the trees (and it's an extra work for me to spot these problems).

Sometimes the obvious algorithm isn't the right one, or it turns out that the requirements were wrong. When I implement it myself, I have all the details in my head, so I can discover dead-ends and immediately backtrack. But when LLM is doing the implementation, it takes much more time to spot problems in the mountains of code, and even more effort to tell when it's a genuinely a wrong approach or merely poor execution.

If I feed it what I know before solving the problem myself, I just won't know all the gotchas yet myself. I can research the problem and think about it really hard in detail to give bulletproof guidance, but that's just programming without the typing.

And that's when the models actually behave sensibly. A lot of the time they go off the rails and I feel like a babysitter instructing them "no, don't eat the crayons!", and it's my skill issue for not knowing I must have "NO eating crayons" in AGENTS.md.

Electronic synthesisers went from "it's a piano, but expensive and sounds worse" to every weird preset creating a whole new genre of electronic music.

So it seems plausible, like Claude's code, that our complaints about unmaintainable code are from trying to use it like a piano, and the rave kids will find a better use for it.

If they implement something with a not-so-great approach, they'll keep adding workarounds or redundant code every time they run into limitations later.

If you tell them the code is slow, they'll try to add optimized fast paths (more code), specialized routines (more code), custom data structures (even more code). And then add fractally more code to patch up all the problems that code has created.

If you complain it's buggy, you can have 10 bespoke tests for every bug. Plus a new mocking framework created every time the last one turns out to be unfit for purpose.

If you ask to unify the duplication, it'll say "No problem, here's a brand new metamock abstract adapter framework that has a superset of all feature sets, plus two new metamock drivers for the older and the newer code! Let me know if you want me to write tests for the new adapters."

People have needs like "freedom of artistic expression" that we don't need to grant to machines.

Machines can operate at speeds and scales way beyond human abilities, so they can potentially create much more damage.

We can ban air pollution from machines without making it illegal to fart.

Even copyright laws with provisions for machine learning were written when that meant tangential things like ranking algorithms or training of task-specific models that couldn't directly compete with all of their source material.

For code it also completely changes where the human-provided value is. Copyright protects specific expressions of an idea, but we can auto-generate the expressions now (and the LLM indirection messes up what "derived work" means). Protecting the ideas that guided the generation process is a much harder problem (we have patents for that and it's a mess).

It's also a strategic problem for GNU. GNU's goal isn't licensing per se, but giving users freedom to control their software. Licensing was just a clever tool that repurposed the copyright law to make the freedoms GNU wanted somewhat legally enforceable. When it's so easy to launder code's license now, it stops being an effective tool.

GNU's licensing strategy also depended on a scarcity of code (contribute to GCC, because writing a whole compiler from scratch is too hard). That hasn't worked well for a while due to permissive OSS already reducing scarcity, but gen AI is the final nail in the coffin.

iPad works for lots of people, but the things that iPad is best for don't really need a powerful CPU.

There are few "Pro" apps that you can run to prove it's possible to run them (except for plugins, OS-level helper apps, extra hardware, background processing that doesn't randomly die, scripting more fine-grained than shortcuts, competent file browser, etc.) but you can max out the CPU for a few minutes and go back to a macbook for real work.

Whenever I need to get anything done on iPadOS, I feel like I'm wearing boxing gloves.

The device's speed is limited by fiddly animations and DUPLO-sized siloed applications.

Its multitasking power is capped in software.

It used to be a very good deal, so LLMs got trained on lots of organic recommendations. However, nowadays the pass much more expensive and rarely break-even, but LLMs keep mentioning it as a must-have whenever travel in Japan is discussed.

For this administration the law isn't something that binds them, but something they can use against others.