which they have to be, right? since passkeys are "temporary" in that they are easily lost/destroyed/temporarily unavailable, and sites are supposed to support multiple of them?

Linux also built up inefficient abstractions in C that are used simply because they are easy to use. Linked lists being a go-to default choice being an obvious example.

When I bought my Shield TV's I actually liked Android TV. Very nearly every update since then has just slowly made it worse and worse.

Now it's absolutely disgusting as it shows straight up advertisements (not "recommended shows", like literally ads for car insurance or whatever).

So I guess there's really just not much to choose between regardless. It's spyware + adware regardless of price vs. Apple's lack of local backup support :/

It's frustrating that nobody else seems to care about attempting to be the all-in-one box given how much Shield is showing its age now. It's really sluggish

I don't get why Apple just refuses to allow audio pass through or DV Profile 7. They're clearly on board with DV in general and don't hesitate to play Dolby's branding games, so why not profile 7 support???

AVIF and HEIC both use HEIF

software-decoded HEIC is around 100x slower than JPEG.

WebP is something like 20-50% slower than JPEG, so still solidly an order of magnitude faster than best case hardware-accelerated HEIC decoding.

Ecosystem being slow to adopt it is something that can be fixed or improved, but also more importantly (given jpegxl & avif comparisons) are things that will impact any new image format.

Meanwhile annoyances of the codec tend to be things that are dramatically harder to deal with. Like HEIC being a license minefield and also slow as shit. Or that many of these newer image codecs do not have ways to work with them in a memory efficient manner like jpeg does (see eg libjpeg-turbo's sample size & skip scanline options). Or WebP insisted on being in a RIFF container for... uh... absolutely no fucking reason whatsoever afaict. Fortunately RIFF is so trivial that this overhead doesn't actually matter in practice, but then HEIC & AVIF dials up the annoying container bullshit to 11 thanks to their video heritage with ISOBMFF

Funnily enough, self hosting is why I can't use IPv6. I want vlan isolation, but only get a /64 from my ISP.

Fortunately the lack of IPv6 also isn't a meaningful loss anyway so whatever

Fanless just means slower.

It's an Armish not an Androidism. It's an embedded legacy that really doesn't make sense anymore. But inertia is powerful enough that even Apple is still using device trees, even on their M series SoCs ( https://asahilinux.org/docs/fw/adt/ )

Zig and Rust are equivalently "low level". Zig isn't any closer to the hardware than Rust is.

> but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it.

Rust gives you all this, too.

Zig's primary (possibly only) advantage over Rust is that it has much faster compilation times.

The industry where it seems strongest positioned is embedded. Will it actually break into that domain? No idea.

I haven't used the relatively new C++17 polymorphic_allocator, though, maybe it fixes this.

The important part is a language where the standard library isn't special, and Rust has this property, too. So in domains where things like per-frame allocators are useful, you can still have them. That capability just isn't cluttering up the more common path where that isn't useful.