emn13

While you say many reasonable things and describe a perfectly reasonable setup and desire - surely it's clear that your situation is _extremely_ unusual? Browsers are absolutely _also_ reasonable in prioritizing secure defaults for setups that are not similarly controlled. After all, precisely the thing that makes your situation managageble and reasonable - that being you the knowledgeable admin - is also the thing that allows you better than the average user to change defaults.

Both from a sheer numbers perspective and also from the perspective of qualitative differences between these audiences browsers are doing the right thing - prioritizing security in low-to-no-trust environments assuming low-to-no-competence administration.

Surely there's a nuanced difference between "every app distributes this independently" and "a very small few apps that bear the brunt of hostile exposure support independent mechanisms".

It's also worth remembering that both of these specific organizations were instrumental in major, positive security shifts that eventually hit OS's too, including shorter-lived certs, limiting the point of CAs, adoption of TLS 1.3, and likely other things. If anything, they deserve _more_ trust than the OS distributors on this specific front, perhaps also because they don't share the OS distributor's incentive to prioritize stability for paying customers, which can be at odds at times with harsh, prompt security measures.

Yeah, definitely: having lots of separately distributed and likely rarely and unreliably updated trust roots would not inspire a lot of confidence.

Which models do you primarily use, and can you very roughly list your process? Agentic coding in VSCode with tons of MCPs or... something else? Do you include lots of images or have large codebases? Which agentic harness are you using?

I also find that it's easy to spend like that, but also easy not to with little impact on productivity. At the current moment I'm stuck with rider + copilot (not ideal), but e.g. using GPT 6.1 luna is really, really cheap, and lots of tasks are quickly and decently dealt with even at lower reasoning levels, (added bonus of having low latency). And that model is so cheap, I can't see a hitting 1500$ at api prices realistically - not even close. But it also depends on the harness and codebase.

Sure, but note that a tiny LLM is many order of magnitudes larger than algorithms like this. It might well work better, but you're probably paying for very, very marginal improvements with a solution that's thousands of times larger and slower, unless you're you're being really creative and using a fairly non-LLM network of perceptrons or other ML technique. But it sounds like a fun challenge; if you or anybody feels like exploring that, I bet it'd get quite a few curious clicks here!

The thing is, it's a false dichotomy. Raising the quality bar makes software a lot _easier_ to deliver, in practice. Even for a not techie, the reason is probably somewhat intuitive - if you're trying to add features to something that's a hugely complicated mess, you're going to struggle and cause many bugs; but if your process allows for the creation of high quality code, you have the means to do so with confidence, and that usually means quickly and reliably.

The real issue is one of timing and tech debt - higher quality software is cheaper and better, but... that's only over time. If you want that new software from scratch _now_, and don't have the time to set up a high quality development process, you can hack something together quickly. If the software is small enough, the person or LLM writing it smart enough, and while everything from requirements to code is still fresh in memory - that works pretty well! But that process scales poorly, and yet it's what we've as an industry done far too often, and at far too pervasive a scale.

So even though we know and have examples of how to design software better and more cheaply, actually getting to that situation isn't a simple question of trying harder; it's working entirely differently. And unfortunately, we build more and more of our software on the building blocks of the past, and many of those are themselves of low quality too; the more we do that, the more entrenched low quality becomes. As an end user that kind of isn't perceivable; it just means all software is a bit worse and more expensive, but as humanity, it's absurd how much effort we waste working around fairly trivial mistakes made in the past, typically by organizations that just had no incentives to care about future impacts especially on others.

While I get the instinct to prefer something over nothing as an end user it kind of is exactly that bad habit that got us into the mess we're in today. We don't build and throw away; we copy and tweak - so all the messes are inherited, kind of like a form of pollution.

Note that the uploader apparently still retains control over labeling in most cases; uploaders that intentionally misrepresent AI-generated content might not be discouraged by this. Whether youtube will (and can) ban accounts that do that might determine in practice if this matters or not.

Create an image that displays two seven-pointed stars, two eight-pointed stars, and two nine-pointed stars. All stars are connected to each other, except for the ones with the same number of strands. The lines connecting the stars must NOT intersect.

I think it's not at all a marshmellow test; quite the opposite - docs used to be written way, way in advance of their consumption. The problem that implies is twofold. Firstly, and less significantly, it's just not a great return on investment to spend tons of effort now to maybe help slightly in the far future.

But the real problem with docs is that for MOST usecases, the audience and context of the readers matter HUGELY. Most docs are bad because we can't predict those. People waste ridiculous amounts of time writing docs that nobody reads or nobody needs based on hypotheses about the future that turn out to be false.

And _that_ is completely different when you're writing context-window documents. These aren't really documents describing any codebase or context within which the codebase exists in some timeless fashion, they're better understood as part of a _current_ plan for action on a acute, real concern. They're battle-tested the way docs only rarely are. And as a bonus, sure, they're retainable and might help for the next problem too, but that's not why they work; they work because they're useful in an almost testable way right away.

The exceptions to this pattern kind of prove the rule - people for years have done better at documenting isolatable dependencies, i.e. libraries - precisely because those happen to sit at boundaries where it's both easier to make decent predictions about future usage, and often also because those docs might have far larger readership, so it's more worth it to take the risk of having an incorrect hypothesis about the future wasting effort - the cost/benefit is skewed towards the benefit by sheer numbers and the kind of code it is.

Having said that, the dust hasn't settled on the best way to distill context like this. It's be a mistake to overanalyze the current situation and conclude that documentation is certain to be the long-term answer - it's definitely helpful now, but it's certainly conceivable that more automated and structured representations might emerge, or in forms better suited for machine consumption that look a little more alien to us than conventional docs.

Yep. Still, I think it's a pretty decent benchmark in the sense that it's fairly short, quite repeatable, does have a quite a few subtest, and it's horribly different from the nebulous concept that is "typical workloads". It's suspiciously memory-latency bound, perhaps more than most workloads, but that's a quibble. If they'd have simply labelled it "lightly threaded" instead of "multithreaded", it would have been fine.

As it is, it's just clearly misleading to people that haven't somehow figured out that it's not really a great test of multithreaded throughput.

It's not trash - it's quite nice for its niche. It's just not very scalable with cores, so it's best interpreted as a benchmark of lightly threaded workloads - like lots of typical consumer workloads are (gaming, web browsing, light office work). Then again, it's not hard to find workloads that scale much better, and geekbench 6 doesn't really have a benchmark for those.

For the first 8 threads or so, it's fine. Once you hit 20 or so it's questionable, or at least that's my impression.

I mean, reliably tracking ownership and therefore knowing that e.g. an aliased write must complete before a read is surely helpful?

It won't prevent all races, but it might help avoid mistakes in a few of em. And concurrency is such a pain; any such machine-checked guarantees are probably nice to have to those dealing with em - caveat being that I'm not such a person.