This is literally a huge pile of batteries that can charge at any rate at any time. It can soak the noon peak of solar, it can sip late night wind.

It’s a great game. Very good story. The game is mostly serious noir detective story, except that roaring Zootopia setting.

Rust Evangelism Strike Force drops in:

Imagine living your life without maintaining header files.

This has always been the case. When Windows XP came out people hated it needed 64MB (not GB) of RAM, because that was more than the entire disk installation of Windows 95, which was also bloated compared to older Macs and Amigas.

There’s aarch64 version of Linux.

I’ve got an ARM Mac. I’ve got ARM VPSes from Hetzner, and I’m compiling native code for the server.

It’s definitely easier to develop, build, and test on the same architecture, than to deal with cross-compilation and emulation.

So I think Linus is right.

If you run an ARM system inside docker, it works much better!

Many pre-baked images may be x86 only. However, thanks to M processors there’s a real demand for more than Raspberry Pi, so this will get better too.

Epic sponsoring Godot was a 4D chess move against Unity.

https://godotengine.org/article/godot-engine-was-awarded-epic-megagrant/

Use the system webview, you cowards!

Developers bundle all of Chromium, because they’re afraid the OS webview will have a different browser engine. Testing is too hard…

This is such a terrible excuse — usually the same app runs in browsers too, so it already has to deal with even wider variety of browser engines.

Generally yes.

GIF’s ancient LZW compression is remarkably ill-suited for modern CPUs, and more expensive than modern algorithms. Combined with significantly larger file sizes, it costs much more to decode, on top of increased costs of transfer and caching.

GIF might have an edge if the animation is very small (<16px, few frames).

It also gets messy if you need to play hundreds of animations. GIF will be terribly inefficient, but also browsers aren’t designed to have hundreds of video elements, so both will eat memory in their own way, and it will vary which is worse.

Only signed overflow. size_t is unsigned.

I don’t know about C++, but in Rust the push is inline, and still doesn’t always optimize checks away due to an annoying edge case: integer overflow. Reserving (old_len + new_len) could give you a smaller buffer than new_len. The optimizer sees it and is pedantic about it.