- You can't download the game without internet, including re-downloading because you had to free up space
- You can't download the game after they have retired their servers (or if their servers are down / having issues)
- The game ends up taking a lot more storage space as updates are usually tiny when compared to the base game. For reference, the Switch 1 version of Zelda Tears Of the Kingdom takes 16 GB while the latest update takes only 500 MB.
I think most of that is true for games shipped on cart, too. Games often ship broken or missing features which are patched in at launch. Official physical media has not been a reliable method for future accessibility for at least a decade now. It's way past time to start using other methods of preservation.
> For progressive, JXL shows a blurry mess for the majority of its decode, while AVIF shows a crisp image that clearly shows what is in the image. Go ahead and try the demo yourself! AVIF also supports more than one layer, but I used Team JXL's image on purpose to show that even there, AVIF looks better for 90% of the decode time.
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).
Worth mentioning: their demo only uses two passes for progressive AVIF -- it's just their choice. You can have up to two more intermediate passes, so at 30% you can have something much closer to the original image.
Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
> their demo only uses two passes for progressive AVIF -- it's just their choice
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.
Well, the default in avifenc can always be changed. Do keep in mind there's no "one size fits all" implementation, as customers desire different loading tradeoffs. You might be surprised, but during testing (outside HN), we've seen people actually prefer "2 layer" loading.
I'm surprised HN likes progressive loading to be more granular, and use that to push back. 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.
Anyway, the more expressive mode in avifenc is `--layered` (yes, I know the name is weird).
> Usable for what?
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.
On the other hand, JXL is just too blurry at 8kB to make sense of the image -- only the egg and carrot are recognizable, maaybe the cucumber? IMO JXL needs the pass at ~28kB to make everything salient, including sprouts and beet. Yes, I know there are subjective effects at play and I'm sure we'll disagree on exact image thresholds, but recognizing objects within an image is so important in real-life use cases.
> Well, the default in avifenc can always be changed.
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.
> 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.
Yeah, I can see that. By "happened" I meant that the default is good and serves a common use case, but also it can't be expected for a 2-pass AVIF to remotely match JXL's finely-incremental experience. The tricky thing is coming up with a good-enough compromise -- one extreme wants their first pass be more like a blurhash (quality 0, 1/8 scaling), while the other wants a medium quality image (quality 30-40, full scaling), and everybody else is in between.
For reference, `avifenc --progressive` is currently quality 10, 1/2 scaling.
> 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.
Interestingly enough, I frequently get reminded of spotty internet connections -- turns out you just need to take the subway hah. This is why I'm so passionate about progressive image loading in general.
> 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.
That sounds like you want your first pass be half scaling, around quality 25:
`image1.png` and `image2.png` can be the same source image. You can blur `image1.png` or even better: add a tiny "loading" icon to indicate the image is still downloading.
Oh, i left the wrong quotation whereas i intended to reply to another message. Throughout the blogpost you're quality matching and comparing encoders based on objective metrics whereas it'd be more telling to get the crowd subjective comparisons. I think it's pretty evident that most codecs benchmaxx to the point of objective metrics being useless.
Ah, no worries! I can't speak for Iris and Aperture, but both "tune IQ" modes in SVT-AV1 and libaom had extensive human evaluations to make sure they weren't accidentally being benchmaxxed at the expense of subjective quality.
In this case it arguably helped. I do wonder how much longer that stalemate would have gone on without the blow up.
I don’t think it’s a good policy in general. Mostly I think it would just end up in alienation and people not wanting to work with you. And Martin did leave. But he had a point and it seemed to get resolved.
Let's pretend it's OK for them to just drop your domain, ignoring the stability and security issues that arise from that (and how ICANN should prevent that, in theory).
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?
Loved it! I made this version for `fish` and `wl-clipboard`:
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
By saving it to .config/fish/functions/clipboard-format-json.fish, it should immediately work
I also discovered the joy of shift-selecting a big range of tabs and pressing ^W only once. It also feels pretty good, but in a slightly different way...
> never displays or updates apps correctly. Half the time an app showed up on the website that didn't show up on the phone app. The other half of the time even when I did get something installed, it would just never understand that an update existed and needed to download and update a given app
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.
The last time it wouldn't update an app, I could see in the app store and on the website that my app had a new version, but no matter what I did, I could not make it update the app. I don't know what I was doing "wrong", but I think if I couldn't figure it out or make it happen, there's something very wrong with either the app or how it's "supposed" to work. Neither of which is an acceptable user experience for me.
About the post you linked, see [1] and [2], which makes me question both whether that is an actual vulnerability (Signal, the messenger recommended by the author, also didn't have that check, and it's addition is absent from release notes and CVEs) and whether the post was made in good faith (the check was added to libsignal on the same day that the author disclosed the vulnerability to Matrix, which can be a coincidence, but doesn't seem likely given that the code has been there for years).
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.
> About the post you linked, see [1] and [2], which makes me question both whether that is an actual vulnerability (Signal, the messenger recommended by the author, also didn't have that check, and it's addition is absent from release notes and CVEs)
I've edited the above linked post several times to make this clearer, but people still keep linking Matrix's flawed response as if it actually addressed the issue. It does not.
The issue is not as simple as "did the check exist? [y/n]". There are actually two issues:
1. Did the check exist? [y/n]
2. Did the group key agreement protocol fall to shit if the check was omitted? [y/n]
Matrix was (n, y) due to how Megolm manages keys in group contexts. Signal was (n, n) due to their protocol design.
Matrix tried to defend point 1 when the blog post was about both 1 and 2.
(Post-Quantum MLS, for comparison, would also have been impervious to this issue due to how KEMs work. Another point in favor of MLS adoption.)
> and whether the post was made in good faith (the check was added to libsignal on the same day that the author disclosed the vulnerability to Matrix, which can be a coincidence, but doesn't seem likely given that the code has been there for years).
Even if you assume the worst possible interpretation of this coincidence (which, sure, you're free to if you want-- you would be wrong if you did, of course): What does it even matter?
Like, what is the notion of "good faith" that's even necessary for someone to do independent security research and publish criticism of the cryptography used by a software project that's being propped up by EU sovereignty movements?
In my opinion, this is a stupid and vacuous framing.
Signal omitting the check didn't harm Signal's confidentiality. Matrix omitting the check demonstrably did.
---
Also, if you're going to decry my blog post for not enumerating unrelated security bugs (n.b., the blog post was about Matrix, not Signal, so why would I talk about Signal's code in that post???), be aware that I reported non-cryptographic bugs to Element (Matrix client) and Conversations (XMPP client) around the same time. Only XMPP actually credited me with any fixes.
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).
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.
A big issue here is the complete lack of namespacing. You have these sub crates with zero ability to know whether they are related to a given organization/author/project.
I mean look at the people defending the lack of namespacing:
One of the most obvious problems with the lack of namespacing is that if you have a group of crates belonging together, you have to reserve them all at once otherwise an automated script could detect your package and add common suffixes like -sys and take the name even though you got the non sufficed name.
You cannot add name spacing by just prefixing everything with your preferred prefix, because anyone can publish under that prefix.
> A modern consumer GPU can crack "four random English words" in a day.
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.
> A modern consumer GPU can crack "four random English words" in a day
What you're saying now:
> My mid-tier laptop GPU can crack the usual wordlist in under 12 hours against MD5 (46 billion guesses per second)
So your response to the plain mathematical fact that, no, your consumer GPU cannot crack "four random English words" in a day, is that your consumer GPU can crack four words chosen from a list of a few thousand, in a day. Followed by personal attacks. Okay.
Well, there could be quite a range of performance between a mid-tier laptop GPU (his consumer GPU), the average consumer GPU, and the average (gamer's) consumer GPU.
Trying to pick a strong password assuming the service you’re signing up for doesn’t care about security is pointless. You’ll be pwned regardless of what you do.
Experience? Looking at codebases? The one in question does, in fact, use SHA-256. HN is a bit of a bubble because there's a large demographic of FAANG-tier employees here who work at big tech or unicorn startups, but most software in the world is not made by FAANG or unicorn startups, and the standards are way, way lower than you might think they are if you're used to living in this bubble. For software development practices in general, not just password storage. I think it's taken for granted that every single person on HN uses VCS, but even that is a luxury in many real-world working environments outside of SV.
Even if only 10% of the services you use use MD5/SHA-256 (although I certainly would expect it to be >50% if we could do a large-scale study), why accept your password being easily compromised 10% of the time?
- You can't download the game after they have retired their servers (or if their servers are down / having issues)
- The game ends up taking a lot more storage space as updates are usually tiny when compared to the base game. For reference, the Switch 1 version of Zelda Tears Of the Kingdom takes 16 GB while the latest update takes only 500 MB.
reply