u/emn13

Point being, quite to contrary, to skip the platitudes, not that parameterization always pointless.

What to comment and when is and will likely always remain a nuanced and thus relevant discussion. Just because this reviewer is perhaps drawing that line less than ideally (according to the one-sided frustrated-sounded anonymous poster), and indeed choosing to deal with subtle issues like that via code review at all doesn't mean it's categorically unreasonable to consider the desirability of comments and possible alternatives?

Yeah. Overgeneralization is a thing; assuming the original author needs whatever runtime flexibility your parent commenter desires is unwise. And even if you need the flexibility, assuming you'll get a better outcome by going for max flexibility right off the bat is also pretty speculative - sometimes even if you want something general, it's better to start off with something simpler as you explore the problem space. Also, code is data anyhow...

No, alas I did not - as you say, there are signs the problem runs deeper.

Oh no, massive SUVs with confederate flag bumper stickers on UK roads are completely fine. Nothing to see here; that's just normal, right?

I remember playing civilization when I was younger, having fun, but laughing at the idea of a culture "victory". Well, not laughing anymore.

Not the person you replied to, but having read your excellent and in-depth comparisons (thanks!) I think your headline lossy-photo summary seems at odds with the the examples you show, where I expected AVIF to clearly dominate yet quite a few examples show otherwise and differences are pretty small really.

Your summary says - For lossy photos on the web, AVIF almost always produces smaller files than JPEG XL. At default effort settings, the best JPEG XL version is typically 15–25% larger than the equivalent AVIF.

Yet your examples have a quite a few interesting and probably relevant cases where jxl is either very close to the same size, or smaller. For example while the red panda is very slighly smaller in AVIF at high quality, at both very high and medium quality jixel is smaller, and the relative delta at very high is larger in jixel's favor than the delta at high is in avif's favor. Calling that an AVIF win is a bit of a coincidence of the framing. For the weasel, jixel is significantly better than AVIF across the board in your data. For the other 2 photos (excluding your resolution-variations on the F1 car) AVIF wins. Still, depending on how or whether you count the less-clear panda image results, thats AVIF winning in 50-75% of those 4 photo cases you examine and show in detail.

If you include the plain HDR photo (i.e. the PQ versions), that's another win for jixel, but of course the caveat there is whether you care about gain maps.

I did not expect JXL to really even be competitive, and after reading your intro I didn't expect your findings to show anything other than AVIF clearly dominating, yet jixels results in photos are much better than that intro makes them sound. I don't think the way your wrote that smacks of bias, but perhaps the original version of the doc focused on libjxl and some of that is still coloring the introductory summary? Or did you test way more images and these examples are non-representative?

Even if the AVIF win is unreliable - a win is still a win, especially with the decode-time differences. Still, the summary paragraph makes the difference seem more clear cut than it actually is based off the details further down. And as you rightly pointed out, it makes the future a lot more interesting - how much better will these encoders get? The changes recently have been dramatic!

Note that the author explicitly calls that out (or at least calls out what that means):

Both AVIF and JPEG XL (via jixel) have seen massive improvements recently, so it's possible that this recommendation could change in future. There's been a lot of misinformation around this stuff, and your AI will happily deliver that misinformation to you. Instead, test things with your own images.

So it's a good point you're making; and the article's author seems to agree.

Right, so the merge merely makes the pain felt earlier - but the point being, it's odd it's not even earlier, because increased road capacity simply increases travel times without increasing throughput. That's only worth if if the back up would otherwise block unrelated traffic.

https://www.reddit.com/r/drivingUK/comments/1x5775n/comment/pgsumzd/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button speculated it's for the barracks, which I guess could be?

Yeah, that's not a lot indeed, though exactly what that means is unclear from the stuff I read.

That's rather speculative, really. It might; but the first-order effect is to increase the number of cars at the same or decreased throughput, which implies an increase to the travel time. The fact that the road designers left so long a segment for zippering seems superficially questionable. Perhaps the rest of the context explains that, but context matters; if this spillback ends up blocking unrelated traffic we can't see, that's a different story of course.

The next vehicle after the hit-and-run was the police vehicle, so by that time it was too late. But the police car did see her and stop.

Somebody died. The driver didn't even stop. You seemed a little too okay with that.

Charitably though - if you're implying (though still not stating) that you just like to poke fun via ambiguity, then surely it's not that surprising that ambiguity is read in various ways.

Literally? ...your use of the phrase "good for you".

Well, that is kind of what the court said; it's one of the two convictions - leaving the scene.

That is indeed one of the crimes he was specifically convicted of - he left the scene (and then didn't turn himself in, so wasn't arrested until the police investigation found him a week later).

The reporting lists multiple other vehicles that drove around her - i.e. clearly this would not have necessarily happened to all other drivers. And as it happened the very next vehicle to encounter her was a police vehicle, which noticed her even after the victim was presumably less upright; and she was also clearly visible on the CCTV footage.

Sure, and that's probably why the sentence is relatively mild; presumably the court did its job and considered the circumstances, in addition to the second crime of leaving the scene.

Of course; but just because the traffic victim was at fault does not mean the driver isn't also at fault. Summary execution by motor vehicle isn't exactly a desirable policy for any potentially momentary nitwittery. And note that the driver fled the scene and did not turn himself in, which was specifically one of the crimes he was convicted of - not just being distracted.

Tragic all around, for sure, though.

Just to back you up: Multiple people did see her and drive around; including the car after she was hit which was a police car; and she was visible on CCTV, and the expert testimony claimed she should have been visible for at least 2.25 seconds. And he chose to leave the scene of the accident and wasn't identified for a week, i.e. fleeing the scene might well have led to loss of evidence (e.g. of intoxication or cell phone use). Could be it was a momentary lapse in attention as he claims, but even that best case scenario seems consistent with the courts judgement; i.e. - not blameless.

The not-stopping bit was specifically one of the crimes he pled guilty to and was convicted of; it's not (legally) optional. And note that he wasn't arrested for a full week, so while it's perfectly plausible there's nothing more to the story - it's also plausible he's not going to provide the self-incriminating testimony after any evidence was gone.

Given the fact that that she was clearly visible on CCTV, that multiple other vehicles drove around her (and presumably their testimony was heard), and that expert testimony stated she should have been clearly visible for at least 2.25 seconds, and that the court probably had a lot more context that any of us do here - I think it's perhaps reasonable to not just literally defer to its judgement, but rhetorically too.

As to package source hacking being not a risk specific to transitive dependendencies - indeed, but it is a risk that a hash-containing lockfile would mitigate.

This is interesting. I wonder why that scenario does not trigger an error instead of a warning. My first thought was that maybe it would be to support rollover from unlisted package versions, but unlisted package versions can restore just fine. The package version would have to be deleted for that graceful upgrade to make sense.

I try to get most projects to eventually adopt a warnings-as-errors approach in modern C#; in my experience it's doable without too much hassle, but if you've got tons of warnings I can imagine the nuget warning might not get noticed - and so your question of why this is a warning is a good one. Maybe because package unlisting is a thing? Seems like a mediocre excuse; I think you're right, this should be an error.

But even if this package-version-gap risk WERE to materialize and you miss the warning - for the vast majority of packages, chances are some OTHER consumer will notice. And that means that for attackers this is a almost certainly a poor tradeoff: they're drawing attention to themselves before actually getting any return on their access. As such, I think that specific vector - unless I'm missing some extra trick - seems really unlikely to matter in practice.

In fact, you could probably pull this off without DD being in on the hack. There are ways to get NuGet support to delete a package version you own, so you can create that non-existing version retroactively.

As to deleting old package versions - the devil in in the details there; does nuget.org then allow re-uploading a different package under that same version number? It might not. And of course, even if you could pull that off, as an attacker you're still stuck with that warning which makes this a pretty unrewarding strategy to pursue over simply hoping people update and keeping quiet.

If there's a more serious risk here, I suspect we've just not thought of it yet; these risks don't sound serious to me.

If you ever do that, then you at that point have lost the lock, i.e. the whole point of a lockfile (sure, just temporarily). And even that "fix" is not free; it's a manual action, i.e. expensive - and for what gain? Don't just handwave "securtiy" - what exactly is at least SOME plausible scenario this matters? Because NPM's issues happen due to it's highest-possible-version algo, and nuget doesn't do that.

Let's just ban these monstrosities instead. Or at the very least tax into oblivion.

Why are these things even legal?