emn13

There _will_ be constraints on running programs altering other stuff. Sandboxes _will_ get even stricter. The benefits are so large that this trend will inevitably continue, and rightly so.

To protect the ability to tinker we'll need to instead talk about who gets to control those sandboxes, ultimately. How can we poke holes without allowing abuse by malware or creative (ab)use rendering the system pointless? How can we ensure the poked-holes exist by user choice, not at the behest of a tiny handful of software behemoths?

On a technical level, I don't think that arbitrary and surreptitious dll injection is a line in the sand worth defending. It's not a great abstraction; it's tech debt.

Requiring a few hoops - and it sounds like e.g. requiring a developer edition sounds like such a hoop - to ensure a likely misconfiguration was actually intentional and the user is capable of dealing with the consequences is not a bad idea.

In particular, debugging when things go wrong can be an insurmountable task.

Better isolation of software components has been a trend for decades; to the point where I think we can safely say that the old unix and windows model of permissions was a fundamentally insufficient idea. Devs flock to using VMs and containers precisely because uncontrolled interaction between stuff even controlled by the same nominal "user" is a huge pain - and that's before malware and privacy concerns come in.

Were software more isolated by default, and interaction more controlled and/or explicit, then indeed I think the argument against this kind of controlling-the-"user" features would be stronger. But as is? The alternative is clearly much, much worse.

After all, certainly here and often in other cases too - it's not like it's actually impossible to circumvent these restrictions. It's simply technically inconvenient in a way that happens to also prevent many unintentional bugs and some malware vectors.

In an ideal world, a devs for a piece of software would be hard-pressed to even do this, let alone feel the need to do it. But that's just not the world we live in; we're not even really close yet - except on really locked down platforms that go much further than needed to prevent the risks, and into the territory of quite openly restricting the user, not the software.

But consider also e.g. https://afontenot.github.io/image-formats-comparison/#reykja... - even at "large" quality settings avif pretty visibly distorts the sky and there's some blur it the nearby trees too.

In any case, comparing to even the fairly good (for jpg) mozjpeg encoder it's clear both of these codes are much better than the status quo, and not that different from each other - neither wins universally vs each other, but both pretty clearly do vs. jpeg.

A fairly simple heuristic seems be that if want images at the tiny size - pick avif. At small, pick avif unless you really, really want to preserve texture over detail. At medium, pick jxl for texture, and avif for detail; and at large, pick jxl.

Browsing through these images in general, I think I'd usually pick jxl at medium or even sometimes large settings; small simply has too many artifacts in general (but if I had to use that - avif), and at better quality I (personally) find the distortion to texture more noticeable than loss of detail. I guess it depends on how important compression ratio is to you?

I don't know the people driving these cars well; perhaps they modded them (seems unlikely, given the neighborhood), or perhaps they're old enough to have escaped new requirements; regardless - they're too quiet here in my sample size of 1 neighborhood in NL.

Irrespective of the volume it is remarkable why any car designer thought that this was the right _kind_ of noise for the car to emit. Somebody chose that soundtrack, and you kind of have to wonder why...

Positively: as a device, having such a solid iGPU is pretty much exactly what I've always wanted in this kind of device. Having performance that's PS5 ballpark clearly is enough for a hell of a lot of things. Who really wants something much faster at the cost of much worse battery life?

But the air of incredibly ground-breaking technical greatness that apple manages to weave around its silicon seems a tad overdone. Given the amount of silicon, the process node, and the target tuning - this kind of result seems competitive with rather than outclassing their rivals.

While the perf/watt is impressive, apple is also using 4 times the number of transistors on TSMC's latest process - and the comparison here is samsungs 8nm, I believe. It's not really all that impressive that that huge silicon investment has some results...

It's a tantalizing hint at what might be possible, but as it stands, I'm not really all that impressed, personally.

Are you saying the typical EVs you hear are _louder_ than ICE cars where you live?

As to the pleasantness of the noise - yeah, that seems to be a manufacturer's choice, or perhaps even driver choice? And let's hope just like annoying ring-tones of years past that the current selection dies out soon...

In effect, your deposit is directly, causally linked to the ability of the bank to keep more interest _earning_ loans on the books; i.e. your deposit helps back those loans, and were it not for deposit insurance (assuming your account is below the limit) you would be on the hook for risks the bank took.

Your deposits are thus both necessary, and (barring FDIC) risk-carrying when it comes to the loans the bank makes. Isn't that in essence "your" deposit being lent out? If not in a literal sense; then at least what's the value in emphasizing the distinction?

The underlying issue is that even uninsured risks in banks must de-facto be largely covered by some central authority (whether FDIC or otherwise) otherwise the whole system is at serious risk of pretty catastrophic failure. The interaction of the lack of (formal) insurance for large deposits and the fluidity of those deposits make bank runs at the first sign of serious risk inevitable.

How important that problem is - I'm not informed enough to have an opinion on. But that problem didn't start in 2008, that's for sure. I am curious as to what actual subject matter experts think ideal solutions would be, and what haphazard lobbyist inspired patch-job we'll actually get.

To me, this does not seem like a win that's worth much, especially since it's likely to shrink considerably even with naive fast compression.

Furthermore, as messages grow in size, the explicitly named closing tag actually kind of starts helping.

Both of these syntaxes have their annoying quirks, for sure, and I understand you really dislike the closing tag; that clearly doesn't bother many people.

But regardless of personal preference, I'm really skeptical any of this really explains json's relentless path to replace (most) xml. Other reasons, such as the extreme wordiness some xml apis chose, the poor implementation of namespaces, the problems with embedding arbitrary data (in particularly control characters), the inconsistency between attributes and elements, the lack of support for numbers, the lack of (conventional) support for key-value pairs - all of these surely played a much greater role than a fairly limited syntax issue.

And it's not even like json is without impractical quirks; lack of comments, the ban on trailing commas, and the need for quotes in object-keys spring to mind. Yet those don't mean json is likely to die out soon - even though even javascript itself from which it is derived doesn't suffer from those (anymore)!

The MITM-at-the-start risk is of course real, but I think this new everyone -restarts-simultaneously risk is qualitatively different enough to be worth at least considering.

I mean, stuff like https://www.anandtech.com/bench/CPU-2020/2758 still exists, but I get the impression they no longer have the resources they once did to really fill it the way they used to; and similar things goes for other sites. I think the best option I know about that remains is https://www.techpowerup.com/review/, but they're much less in depth than what used to be available. It's still great to have such a broad set of reviews, mind you, and they're doing a great job. I get the impression there's much less funding for stuff like this, making the last few survivors all the more impressive.

I think this affects far more than just coolers; it's simply that for categories that have few options (say, CPUs) it's easier to slog through all the youtube videos, and there still exist a few text-based reviewers.

But cases, ram, motherboard AIB versions, GPU AIB versions... even power supplies often - reviews are suprisingly sparse and hard to compare and rarely comprehensive.

I still rarely use stackoverflow to ask questions, but I've given up on answering them. I don't mind giving answers elsewhere, but stackoverflow specifically discourages that, somehow.

A few effects that are clearly harmful (IMHO):

- Stackoverflow's game mechanics strongly discourage duplicate questions. But this is pretty dispiriting when it happens to you - both as questioner, and as answerer. Additionally, duplication is often not exact; there can be significant difference that are sufficient to really change the appropriate solution. Stackoverflow is really bad at finding those.

- Even where questions are in essence duplicate, that is clearly not always obvious to the novices asking the questions. It's just not very helpful to close their questions in a rather toxic fashion and effectively berate them for not already seeing the parallels they were looking for in the first place.

- Stackoverflow discourages discussion. However, discussion is useful in finding the best solution or even merely discovering the context and limits of that solution.

- When discussion happens despite the SO UI, gamification rewards almost exclusively the primary asker and answerer; to the extent discussion is permitted, it's not encouraged to be constructive or healthy therefore.

- Stackoverflow's attention algorithm highlights new questions and highlights first answers to those questions. However, this encourages answers that are essentially "First post!!1!", and then maybe editing those into something better. It discourages well thought out responses. This isn't intrinsic in gamification; it's simply due to the way they've tuned the knobs.

- There's an intrinsic tension in how they've tuned their gamification: on the one hand, they encourage knee-jerk responses because speed is of the essence, and on the other, they discourage questions that benefit from quick-n-dirty answers. That tension doesn't lead to a healthy middle ground, it just leads to frustration and a bad experience.

Fora like this one and reddit also use gamification - we all see and respond to votes - but they do so differently. Stackoverflow could try to learn from that. And stackoverflow could make the gamification more collaborative, and less zero-sum. Whether they'll do so... I guess at this point I kind of doubt it.

'course, with the general urge to be "tough on crime" and the inevitable occasional horror-story of truly heinous behavior discovered many decades later there probably isn't a lot of political will to support reasonable statutes of limitations, so I wouldn't be surprised if some of this stuff never expires.

The OGL does explicitly use the phrase "in consideration for", which you'd hope would make this non-gratuitous. Then again, IANAL.

> A lot of the discourse around password hashing gives the impression that there is some magic number you can pick that actually makes passwords safe to use for this kind of thing. There isn’t. They are not. Either your password has sufficient entropy to resist brute-forcing, in which case it is already probably a cryptographic key, or it doesn’t – in which case it will eventually be cracked no matter how many iterations you apply to it.

...but I'm not seeing anything to back that up. Using the article's own example of a 72-bit password entropy that would imply that an attacker is willing to spend up to 4722366482869645213696 times as much brute forcing the password as you are to unlock it normally.

That seems like a fairly remarkable claim to make with little to back it up.

For a sense of scale, even if you're password stretching to just 0.01s, that's 1,496,458,366,089.87 years. You can parallelize that, but let's say you used just 64MB in argon2, and memory costs just 1$/GB - if you're willing to spend 30 billion on ram and get energy and everything else for free, then you can reduce that time to just 50 years; a human working life. And of course, those settings are very light; a spending 10 times time+memory more would barely affect the user, yet cost the attacker 100 times more to hit that 50 year deadline.

Put another way, if the attacker spent the entire US annual GDP buying brute force crackers at 1GB/$ and then a year cracking, that could merely reliably brute-force a 1GB Argon2 stretched password up to 156ms.

I'm sure better hardware would help a bit here, and using PBKDF2 rather than Argon2 surely is weaker (I'd be curious how much, though) but this really isn't a a trivial problem, and the claim from the article looks at the very least unsupported.

Clearly still developing; we'll see.

All in all, this sounds more like a technically really interesting challenge, rather than a high-stakes bet. Even a "bad" scheduler probably won't do much harm.

Realistic worst case, quite a few workloads that might have benefited from the new cache don't... but probably aren't hurt much either.

This is incidentally true of (by)laws too, and it's part of the why behind the familiar adage that it's better to ask forgiveness than permission.

And that further underlines the need for a grace period, if this really is the best model cloudflare can come up with (presumably it is).

The evolution of the US ordering feels (I might be wrong!) similar to how spoken numbers are little endian from 11 to 19, yet big endian from 21 to 99. Some languages are even worse in this regard; but regardless, they're unhelpful historical artifacts that we learn to live with, not actually helpful, well-thought-out, or even merely irrelevant. Notably there are considerable differences between how quickly children learn maths in different languages, and digit ordering may contribute (of course other cultural factors may contribute too). I wouldn't be surprised if date ordering too is similarly a small but real drag on learning.

To reiterate, there is an obvious, correct implementation here: let the site specify the content culture much like it does the language, and fall back to the user's choice when unspecified. The spec is asking for user confusion and data corruption as-is, which contributes to why usage of date controls remains fairly low.

Actual human language is context sensitive. The user's date formatting preference is almost a non-sequitur even as a concept. People fundamentally can't pick whatever date formatting they want in general-purpose content; they'll need to be able to understand whatever is the norm in that context. And in most contexts while there are various date forms, they're usually not (problematically) ambiguous. As long as a user stays within one date-formatting bubble, that's fine, but it just works really poorly if a user does not. Within an application that's primarily concerned with dates and in which every date is a specially typed value, like say a calendar - sure, date formatting preferences are feasible. That however describes a rather small fraction of the overall web. And the textual, machine-comprehensible hypertext web itself, while eating the world, is itself still only part of culture; dates are visible in videos, images, books, magazines, etc - and they make sense in those contexts _in context_ - i.e. _not_ using the client's date formatting preferences.

If a user's date-formatting preferences were to really have meaning on the web, you'd need to ensure that even dates in plain text or written summaries satisfy that formatting, and hope that videos and images rarely are mixed with such text. But that's just not the norm, and likely completely impractical; it'll never happen, especially not given the reality that many dates are manually written by humans without any markup at all. And where software tries to "fix" that - well, you get disasters like Excel, which is notorious for causing insidious data-corruption by trying to guess data-types in pretty creative and unhelpful ways.

In practice that's not what sites _actually_ do. They either have really simplistic date handling, in which case date controls can be confusing but rare enough that it's not hugely impactful, _or_ they use custom date controls (the actual norm). And that makes browser date controls _even_ worse, because those will then unpredictably not use the context culture, but instead the client's culture - unlike most sites, which don't use input type=date as far as I can tell.

The correct solution would be to allow a site to specify the site's culture and formatting settings, much like language can be specified. And if none is specified: sure, fall back to the user's date preference.

Yet that's not how browser controls work - browser controls for all major browsers always use the client's date formatting settings when displaying dates (once popped up it's usually obvious which is which). And that just makes them pretty much unusable; it means outside of the US you will have dates in text using 1 format, whereas browser controls use a different one. That's... completely unusable. How all three of the major browser manufacturers managed to agree on this particularly hostile design is beyond me.

It's all rather minimalist - and if a user catches it, that's fine, but if they don't, there aren't any fallbacks or additional hints as to what to do. Additionally, the icon seems fairly small from the screenshot - though on an actual device that may not be an issue. It may be too small to function as a good UX element.