Sure, that was kind of my point, but I think it's important to point out it's the default. I had read somewhere else in the comments that they just "happened" to use 2 passes (that I now realized was also written by you), that I interpreted as them maybe making a bad decision in the comparison page, but I think it's very reasonable to use the default. I also usually prefer to use the default unless I have a good reason not to do so.

And I think that `--layered` is fine as a name, and I had realized that as the docs were right below the docs for `--progressive`, which do mention it encodes a "layered image", although it could use an example on how to use it effectively.

> I'm surprised HN likes progressive loading to be more granular, and use that to push back.

Not necessarily? Using more passes would probably help in specific the metric in the comment I was responding to, by making AVIF possibly look better on a larger fraction of the decoding time. I mostly interpreted your comment as saying that it would have been better if they used more passes, and that's on me.

The reason I was comparing the breakpoints in the decode time was because I was responding to an allegation that "even there, AVIF looks better for 90% of the decode time", and I decided to point out that's not not the case and chose some pretty clear breakpoints that are very hard to argue about. Very subjectively the actual breakpoints could be a lot earlier, for the Poke the AVIF only looks better (in the sense that you can figure out what's there better) in a 6% range (from 2 to 8%) or maybe 9% (from 2% to 11%) of the decode time. There are many (relatively big) seeds that are just not there on the AVIF side, but you can distinguish on the JXL side, even if they're blurry. Percentages used in reference to the JXL side.

> I'm wondering if there are generational differences at play? Maybe it's the difference of being used to the blurhash vs. old-school JPEG loading experience.

Hmmm I don't know, maybe. TBF with today's usual internet speeds progressive loading isn't as important as it was as more steps make less sense if you have a good connection.

> Well, focusing on the "Poke bowl" example: with AVIF you can clearly tell apart each ingredient at 8kB. You can derive enough semantic understanding just from this base layer. Having decent edge preservation helps significantly here.

Sure, I see what you mean, you can distinguish more image element in the AVIF example, that's true. I don't like the lack of consistency and some of the artifacts to the point where I'd prefer not using progressive encoding, so that's not what I'd call "usable", but that seems like a matter of taste. It surely does look closer to a "final image" than the JXL at that point.

As a note, I think what I'd prefer would be 2 passes, with the 1st pass being around how JXL looks at around 11% / 39 kB. You can get a rough idea of what's the image about and the elements on it, with roughly the right colors, but it's still clearly loading, so there's no confusion, and without many "artifacts" like the progressive AVIF in the example (no idea if AVIF is able to make progressive encoding in a way that's more "blurry"). The caveat is that more steps are better when it takes too long (more than a few seconds) so the user knows it's not stuck.

Also worth mentioning: AFAIK "their choice" here is just the default, i.e. what `avifenc --progressive` outputs, so maybe if the default is suboptimal, it could be improved?

> Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!

Usable for what? As a clearly loading image / placeholder, I personally like the JXL version better (as already indicated in my previous comment). As a final image I think both of them are unusable, and if that's the intention I think it would be better to encode both aiming for very low quality, maybe also reducing the resolution, without progressive loading, then compare. My understanding is that AVIF is usually better at very low bitrates, so it would probably be better, but I don't think this example "proves" that.

I'm not sure I agree? IMO after about 30% most images look better on JXL than on AVIF, the exceptions being the pigeon, which looks better on JXL after 43% (still less than half) and the sunflower, which looks better on 66% (but you can clearly see what's on the image a lot earlier). Also, blurry convey better the idea of loading and the AVIF version may have some weird artifacts / look weirder (although that's subjective), for example the Quechua woman's eyes are very distorted on the progressive AVIF and, on the Poke bowl, some of the seeds on top of one of the top radish pieces are kind of missing / look like a shadow (while other seeds of the same size appear). In contrast the JXL version is usually blurrier and less saturated at the beginning but is more "uniform/reliable" (distorts all of the "objects" more or less the same), and later it looks finished but actually isn't (which may be a problem on its own).

How about the fact that you paid for a service for 10 years and they decided to stop providing it midway? Will you at least get a refund? If not, that's surely illegal right?

    function clipboard-format-json
        # Inspired by https://chris48s.github.io/blogmarks/posts/2021/jsontidy/
        if set -l formatted "$(wl-paste | jq '.')"
            wl-copy $formatted
        end
    end

You probably "just" need to pull down while on the "Latest" or "Updates" tab, to update your repository (it will show a small banner at the top while it's doing that). It's incremental, so it may take a while if it has been some time since you last did it (and auto-updates are disabled).

The way F-Droid works is that it downloads the whole index and then the catalog, version checks, etc, all runs locally, quite similarly to some package repositories actually.

I am not claiming its intuitive, but I think that part works fine once you understand how it works.

Can't speak about the other issues, I haven't had those but I barely use it. Based on comments, it's clear they exist or have existed for quite some time.

[1] https://blog.erinshepherd.net/2026/02/non-contributory-keys-...

[2] https://matrix.org/blog/2026/02/analysis-of-reported-issues-...

JSON: there are a ton of different ways to do serialization and deserialization, each with their own tradeoffs, and serde (the most popular) is far from universally agreed upon. The same goes for JSON specifically, there are many different serialization formats with different tradeoffs.

regex: Owned by the rust-lang organization already. You get the benefits of trust (if you trust std, you trust the rust-lang organization anyway), but without the issues of being in std (backwards compatibility and bloat). The only problem I see with that is that BurntSushi is still the owner of the package and as such can still publish new versions on his own (AFAIK crates.io currently requires at least one user owner, but that's something that can be solved by improving crates.io permissions).

walkdir: It has been been postponed, due to the complexity of WalkDir, but may be added in the future. I agree this should be in std. https://web.archive.org/web/20260820171531/https://github.co...

RNG: rand is still evolving, with breaking changes half a year ago. Preferred generators tend to change over time, so I don't see those getting into std (remember, it has to be maintained forever!). I could see the interface (traits) getting into std, but I see no advantage to it: it's maintained by rust-random, but even if you wanted it to be maintained by the same authors as the Rust language (let's say you trust them more than rust-random), you could just move it back to rust-lang-nursery or rust-lang.

CLI arg parsing: not simple at all! The community's preferred solution has 70kLOC (with support for so many features), but there's also argh, pico-args, and others, each with their own tradeoffs.

> That's why projects end up with 100s of crates, sometimes 1000s.

Also because libraries are split up in many crates. For example, regex is split in 3 crates: regex, regex-syntax and regex-automata, and depends on other crates from the same author, such as aho-corasick.

All that said, there are many crates, such as algorithms like aho-corasick, that I think could me moved into the rust-lang org, like regex was.

See also: https://home.expurple.me/posts/a-big-standard-library-is-ove...

Let's run the math:

EFF's long wordlist[0] (the one used by Bitwarden's passphrase generator) has 7776 words, which is about 13 bits of entropy per word (log2(7776) = 12.92). A 4-word passphrase then has 51.7 bits of entropy, meaning there are 2^51.7 possible options for the passphrase, which is 3.66E15 possible options.

For reference, a password with all completely random characters and symbols, for each character you have 70 possibilities, or about 6 bits of entropy. An 8-character completely random password (no words or the usual patterns) then has about 49 bits of entropy, which is less than a 4 word passphrase.

About the time it takes to crack it, assuming you can test an average of 1 password per μs (you probably can't, as passwords are usually stored using key derivation functions[1][2] with work factors tweaked for current hardware) it would take ~116 years to crack it. I usually see 5-passphrase recommended nowadays, which would multiply the required effort by 7776.

Sure, a 16-character random password has a lot more entropy, but it's also a lot harder to interact with (reading, comparing, typing) if you end up needing to, and it's still easier to crack than an 8-word passphrase.

[0] https://www.eff.org/dice [1] https://en.wikipedia.org/wiki/Key_derivation_function [2] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

The strongest levels require hardware key attestation (which, in my understanding, uses a certificate that's baked in secure hardware and signed by Google): - https://grapheneos.org/articles/attestation-compatibility-gu... - https://developer.android.com/privacy-and-security/security-...

How and whether the same principles can be applied to LLMs, I have no idea. I imagine it would involve discussions about creativity, for example.

Not a lawyer.

https://arxiv.org/abs/0908.1545

> When Windows ME and Windows Vista came out [...]. Microsoft was forced to respond by making [...] Windows XP and [...] Windows 7 respectively.

It's basically from ME and Vista to XP and 7, respectively. AFAIK respectively in this context means that for ME, they were forced to respond with XP, and for Vista, they were forced to respond with 7.

> it's the least intrusive, least effort solution to the problem that will actually work.

Currently, I have no account tied to my phone or my computer(s), except for an older iPad. Also, I have never sent my ID to any FAANG company. This would force everyone (including adults) to tie an account to their devices and a government ID to their accounts. Bans (which Google does not justify, a lot of the time) would gate users from using apps and possibly sites.

In other words, this helps solidify Google's control over Android users. The problem would be the same for Apple, Microsoft, etc, and in many cases it already is the same.

I get that most people probably have a cloud account for their own devices, and I think that's OK. But currently there is the option not to use their services, and I think that's the fundamental issue, they're effectively removing that option by making apps block users who don't have an account, in the guise of age verification (together with Play Integrity, etc). That option is fundamentally linked to the right to privacy, as once you're required to use certain services to be basically integrated into society (making payments, communicating with others, watching turtle documentaries according to the post) you're not effectively able to exert that right anymore.

There are also other related rights and freedoms here, like the rights to repair, tinker and innovate, that are affected by this action, which helps cement an ecosystem where every app requires Play Services, and as such, is hard to be ported or emulated into other ecosystems, and other actions from Google and Apple.

> If you're arguing that it is Google who is dropping support/making people have insecure browsers, we're in agreement. As with Safari (or at least those at Apple who control/fund Safari), the Android team is very anti-Web/Chrome. Lots has been written about all of that at https://infrequently.org.

Oh, haven't seen that blog before. Incredible resource, thanks! And yeah, Google, Apple, and also a situation with vendors (e.g. Qualcomm, due to drivers) that makes it so miserable. Not only due to the way they favor their stores, but also indirectly due to how hard they make to have updated or custom OSes for older devices. I believe it's a consequence of the amount of control they exert, Apple by plainly not allowing bootloader unlocking and Google by gatekeeping essential APIs (especially Play Integrity) on "secure" (read: controlled by Google) OSes.

It's a bit insane that we live in two completely different realities on desktop vs mobile, where it's easy to install a current OS and browser in 15+ year old computers but can't even have an up-to-date browser on an 8 year old device, much less and up-to-date OS.

Which seems to indicate about 4.8% are below Android 9.

But also, Firefox for Android still supports Android 8, of which there are 1.7% below.

There's a discussion to be made here about who is dropping support for these users, is it Google (and especially Apple, who doesn't allow other browsers on iOS) or the site owner? Especially given how insecure it is to use outdated browsers.