kllrnohj
PHP still powers approximately 70% of websites
Well an XHTML parser (and serializer) is a lot simpler, which is a pretty meaningful problem to solve.
What problems does xhtml create?
Things nobody has said since like 2005? A faster startup is certainly appreciated, but steam's 10 second cold launch time is hardly a big deal. Especially when everyone just leaves it running anyway. There's far more significant aspects like memory usage, game library, and general features.
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.
And of the 4 non-preview JSRs in the Java 27 release, only 1 of them is actually part of the "platform version".
The other 3 are strictly changes to Hotspot internals with no platform involvement at all. They did not change any aspect of any Java platform in any way whatsoever. That is what I'm referring to. I'm not referring to the fact that the core library, language syntax, and runtime specs are all part of the same version. I'm referring to the fact that Hotspot specific behaviors and adjustments are also branded as being part of the platform release.
Like there's no Java 27 platform spec that says that G1 is the default garbage collector. That would of course be an absurd platform spec change. But that is still somehow a "feature" of the Java 27 release according to Oracle.