MrJohz
As to your second point, you don't know exactly what a person will die of, but you can make statically sound estimates. You generally won't test unlikely potential causes of death (either because the chance of a positive result is too small, or because you know there are other, more serious conditions). But once a vulnerability is known, it is infinitely reproducible, which means the chance of the vulnerability being "fatal" (assuming the conditions exist for it to be exploited) is essentially 1.
The other flaw in the analogy is that in medicine, the patient chooses to do the tests on themselves. But in software security, there is an adversarial attacker as well as the "doctor" trying to defend the software. And in general, if the defender can find a vulnerability, they must assume that an attacker could already have found the same vulnerability (because the attacker and defender have largely the same tools and information at their disposal, especially in open source contexts), in which case, as discussed previously, that vulnerability also needs to be assumed to be fatal.
Firstly, the cost of fixing a bug once you know it exists is usually minimal compared to the cost of discovering that bug. This is the inverse of medicine, where the cost of testing (at least in terms of health outcomes for the patient) is typically minimal compared to the cost of treatment.
Secondly, if you have an asymptomatic illness, this does not typically make you more vulnerable (hence why it's asymptomatic). Like you say, you typically only die of one thing, so if you know the patient won't die of a particular diagnosis because something else is more likely to kill them, then it might not be worth making that diagnosis. But for software, you can be simultaneously vulnerable to lots of things at once, and any of these vulnerabilities can be the one to "kill" you. Some vulnerabilities may be easier to find and exploit (or do more damage) but in principle any active vulnerability can be exploited.
Thirdly, having multiple vulnerabilities makes software more vulnerable overall, because those vulnerabilities can potentially be chained together to create more serious exploits than each vulnerability would have represented on its own. To a certain extent this can be true in medicine as well, but generally it isn't.
Fourthly, we can't cure death (yet?) but we can cure all the vulnerabilities that we've found so far. There is no known upper bound on the lifespan of a piece of software, and we know that older code tends to have fewer bugs in that newer code, presumably because those bugs have been fixed over time. This is different from health issues, where a given condition may be chronic or terminal and therefore at a certain point there's nothing you can do to fix it.
Finally, ultimately in healthcare it's your body, and your decision was to what you do with it (assuming you can find a doctor willing to do what you want). If you have a condition and you want it cured, even if it is completely benign and will have no impact on your life whatsoever, then you can do that. (Again, assuming you have the resources and the condition is curable). But a software vulnerability does not affect you as the developer of the software, it instead affects your users/clients/customers. Therefore there are different dynamics in play. If I sell you a tool and I know it could be vulnerable, but I don't try and find out what those vulnerabilities are, then you're ultimately the one on the hook when all your data gets deleted or leaked.
The answer to Trump cannot be "the Democrats needed to try harder", because if democracy relies on one side never slipping up while the other side can do whatever they like, then of course that system is going to collapse eventually. We have to look at the deeper causes. And one of the most fundamental causes here is that a lot of people in the US looked at a man who openly promised a multi-pronged attack on the constitutional basis of the United States and said "yes, that's the man for me". If your analysis of the 2024 election doesn't include that point, then it's a flawed analysis.
Sure, I might be selling poop in a bag, and maybe nobody wants that. I can't blame people for not buying things they don't want. But the guy next to me is selling the Handmaid's Tale But In Real Life, and people are queuing up round the block to buy it. Those people looked at all the options -including abstaining and not buying anything at all - and still made a decision. They have to take ownership of that decision.
From the perspective of the Democrats, sure, self-reflection is necessary to figure out what went wrong. They should go and do that. But from the perspective of someone voting for Trump, no, you don't get to use that excuse. You looked at an admittedly very limited field of options and voted for the guy who was backed by a group who had literally written a manifesto on overturning the US constitution, the guy who boasted about his ability to sexually assault women, the guy who had already had a full term and caused tremendous damage with it, the guy who had spent four years complaining about rigged elections and threatening to do something about it, the guy who supported an attempted insurrection and promised to pardon the people who were involved, etc etc etc.
Stop blaming other people here - if you voted for Trump, it was perfectly clear what you were getting, and you still made that decision. That's on you.
I do wish some of this stuff would be documented better. I find Node's documentation to be some of the worst for never being able to answer the specific question I have when I'm reading it — IIRC I was also unsure whether the type stripping thing would work for a monorepo, and the closest confirmation I could find online was a comment in a PR somewhere that implied it ought to work, but nothing more specific.
Node does support this! Although it may depend on exactly you link the packages within a workspace — I use `pnpm` and it Just Works™. Because NodeJS looks at the resolved symlink to decide whether a project is in `node_modules` or not, if the symlink resolves to a package in the workspace, then NodeJS will do type stripping as normal.
In fairness, the documentation is very unspecific about this, so I just had to try it out and see what happens, but it does work.
I think NodeJS also has coverage these days, although I could be wrong there.
The big one is anything to do with video calling — things often work but not as well, or you can voice call but not use video, or something like that. Most of the time the call works well enough, or I use a native app anyway, in which case this isn't a problem, but I suspect this is the thing people are most likely to run into in practice.
The other one is WebUSB, which is useful for certain tools that flash hardware (e.g. keyboards) from the browser. This is rarer, but I still have Chrome around so I can still use these tools. And mostly there's another option anyway, it's just that WebUSB makes things more convenient.
I have heard people complain about Cloudflare, but I've never noticed this. I suspect this is less to do with Chrome/Firefox, and more to do with privacy settings that Firefox makes more accessible. But again, I've never had an issue with Cloudflare myself, so I can't say much about this.
Other than that, I genuinely can't think of the last time I wanted to use a website but couldn't because of Firefox. And even in the above situations, it's rare that I actually run into issues, it's just something I'm aware of as a possible cause if something happens. Most of the time things work perfectly well.
Accessibility certainly requires a content-first approach, I agree with you there. If you view each part of an application solely in terms of what it looks like to a sighted user, it's easy to miss the subtleties of what the underlying structure ought to be.
But when you start layering on the presentation, you're still generally binding that presentation layer tightly to the current content. If you, for example, were to restructure the links in the Zen Garden footer for some reason, most of the styles would break because they're bound to the current structure of the content. The separation you talk about only exists in one direction.
By comparison, when I talk about separation and decoupling in terms of code, I mean that there is a single, explicit, and tight API that acts as a clear boundary between two units. By explicit, I mean that I've designed the units specifically so that they expose this API - this is almost exactly the opposite of what I should be doing with content and presentation, as you point out! By tight, I mean that the API is as minimal as I can make it - two units interacting via an API need to understand nothing of each other except that API, and that API is as small as possible.
None of that is happening when it comes to the interaction between content and presentation. The content is not explicit - I'm actively trying to write the content for the design, which precludes making it an explicit API surface. Nor is the content tight - again, I want to build the content without worrying about how I will layer the design on top, and I don't want to limit myself to just a small surface area here.
So to me, it makes sense to see the content and presentation as being coupled together, even if that coupling ideally goes in one direction only. And if two systems are coupled together, it makes sense to do that explicitly by co-locating those systems. Therefore, I tend to prefer systems like Tailwind that let me apply the presentation layer directly in the content layer. (In practice, I mostly prefer other tools that still let me write real CSS syntax, but Tailwind is pretty damn convenient a lot of the time.)
As an aside, talking about accessibility, I'd forgotten how inaccessible some of the Zen Garden designs are with their addition of extra content in the presentation layer alone.
> For the first eval, I tried giving agents the zstd RFC (plus errata) and telling them to implement a complete zstd decoder (agents are stuck in a container without internet access). The tests were not given to agents. For something with the surface area of zstd, it's not really reasonable to expect that the tests cover every possible case. For example, even though zstd is a fairly well-tested piece of software, I once found a data corruption bug in zstd. The test suite isn't intended to find extreme corner cases that might be lurking for years and is instead intended to check various cases that can "easily" be derived from the RFC that should work.
So basically, the agents were given the zstd RFC, told to implement a decoder, and also told to use a particular testing strategy (or not, for the control runs).
That follows largely from what you're saying though, so I think the two of you agree, you're just coming at the same thing from different perspectives. Like you say, you want to avoid/manage coupling tests to implementation details, and typically the best way to do that is to bundle a significant, testable chunk of code into a single module, define a clear public interface to that module, and then test that interface. The internals of that module are then free to change, but the test interface should stay the same.
But the corollary of that is that you can't just design your modules independently of your tests, you need to design them so that they are testable. Which is why the previous comment links testing to code architecture/design.
Regarding dependencies like that, the best situation is where you can either:
(a) design a module so that the dependency is injected with a clear interface (not just "here's an instance of libredis.rs" but "here's a series of callbacks for saving data, those callbacks might save to Redis, but they might be in-memory only, or they might save everything to the blockchain, either way it doesn't matter").
(b) just spin up an instance of Redis and test directly against that — it should be quick enough, and there's plenty of ways to ensure that the tests don't affect each other even while accessing a shared resource.
I agree that it makes sense to link products together ("vertical integration" and all that), but I think it's very confusing to have a DNS dashboard that lets you configure DNS how you like, but then by default doesn't set up the DNS as you configured it. That's a weird choice.
You can disable this, at which point the record will be set as a normal DNS record.
I can see the advantage of Cloudflare's proxy systems, but I wish they'd be clearer about when they're being used and not pretend that this is some DNS feature or that records have been set to one thing when they've actually been set to something else. If nothing else, it makes debugging DNS issues a lot more confusing, particularly if you're not a DNS expert.
Firstly, Farage picked this constituency to run in because it's deeply favourable to him. This is quite common for leaders of parties — if you can't even get your top guy to win an election, how are you going to convince other people to do the same? In the previous election, he ended up with 46% of the vote, so assuming the same people vote for him again, you'd need almost all the other votes to go to a single alternative candidate to beat him — that's very unlikely. So there's not much value in running to beat him.
Secondly, Farage was always trying to sell this as a people vs the establishment election, so it wasn't really in the interests of any of the other parties to indulge him in that. Either it's a resounding victory against the establishment, or another example of the establishment using its power to beat up the little man. (Ignore the reality that Farage is fundamentally part of the establishment — the question is more how Farage would attempt to sell the result.) So even if you take the approach that the big national parties ought to be able to field a candidate in every election, even if they aren't going to win, there's not much value there either because the result will be used against you.
Thirdly, the stakes aren't so large as if this were a vote on the President. Farage is the leader of his party, yes, but right now it's a fairly minor protest party, with only 8/650 seats in the House of Commons. They take up a lot of column inches, but in terms of actual power, right now they're not that important. Gaining that one seat in the Commons isn't so big a deal to the day-to-day running of the country — Labour would continue to have a sizeable majority and control the Government, no matter who won it. So there's no question of "who should run the country" here, it's essentially just a performance to the media and the people.
Fourthly, beating Farage here stops the disciplinary processes from happening, and those are probably going to be more damaging to Farage overall than him losing this one election. As long as he's an MP, he will need to deal with the fact that he failed to declare this particular donation, which means it's kind of in the interests of the other parties to let him stay as MP and hopefully face the music. In practice, the punishment will probably not affect him very meaningfully, but the rigmarole of going through the process itself and having his bribe and associations with crypto billionaires repeated constantly in the media will probably be more impactful.
And fifthly, this is kind of just an optional extra election that Farage has called. If the investigation finds fault (likely) and recommends a long enough suspension (more uncertain), then the people of Clacton can choose to recall Farage anyway, at which point there will be a "real" by-election. I've no idea whether that will happen, whether the people in Clacton will really want that to happen, or whether the other parties will abstain again, but I think because this was an election triggered exclusively by Farage for his own benefit, there is this perception that the election never really counted any way.
Like, I can imagine a browser exposing an API that says "wantsAlgorithmicFeeds: boolean", and websites would be required to respect that setting. In theory, anyone can toggle that setting, so the website doesn't know if the user is under 18 or not. But if in practice the vast majority of people with "wantsAlgorithmicFeeds: false" are children, then websites can use that API as a good enough proxy for identifying information in the vast majority of cases. Moreover, the more of these specific APIs you add, the harder it gets to keep things anonymous — especially if different states have different requirements on age-restricted content, you'd end up being able to triangulate not just age brackets, but also potentially location as well.
I agree that age bucket still has the potential for exposing identifying information (e.g. if you can monitor a user as they move from one bucket to another, you can identify their date of birth), but it's harder, and it reduces the amount of side-information that can potentially get leaked.
That said, exposing the information in the other direction as well would be a good step because it would allow websites or apps to enable OS-level age restrictions without requiring that they also read the "age bucket" bit. It would be nice if "read a person's age bracket" were a permission that an app or website would need to request, rather than one that was given by default, and that could be coupled with the fully-privacy-preserving approach you describe, so that different applications with different requirements could mix-and-match.
All that said, I suspect it would be a lot easier to coordinate on good technical solutions like the one you're describing if the default reaction to anything that even smells like age restriction wasn't the sort of abject horror and moral panic that is so clear in this thread. Like, sure, age verification at any level has all sorts of issues. But that isn't the only possible solution to the problem here, and if technical people react to these proposals by pretending the problem doesn't even exist in the first place, then we're never going to find those better solutions.
However, if I gave my child a laptop with Linux installed, the law would force the OS to provide some setting somewhere that I can toggle that switches the installation to child mode. (On Linux, I imagine it would make sense to have this be a per-user toggle, so my kid's account would be in child mode, and the root account would not.) The applications on that computer would then be required to check that setting if they want to show "adult content" (here defined as algorithmic feeds, notifications between certain hours, the ability to receive messages from identified adults). Similarly (this isn't clear but would presumably be technically required) browsers would pass this setting on to websites in some way.
Another way of seeing it is this: you know the DNT/Do Not Track header that you can optionally set in your browser and (theoretically at least) websites will not track you? This is essentially that but for certain kinds of content. If you set the header, websites won't be allowed to show algorithmic feeds, etc.
Basically all of this is in the article, which lays it out very clearly (if you ignore the Claude-isms).
Moreover, nothing really seems to have changed in the enforcement of that (as far as I understand, specifically focusing on laws like Illinois') — it's still ultimately the responsibility of parents to ensure their own child doesn't access restricted websites. This legislation would essentially provide a mechanism that makes it easier for parents to do that.
So no, I don't think that that is the right take.
I also find your edit somewhat amusing, as the key reason that age verification is such a topic is because of a different missing real-life social feature, which is the ability to look at someone and identify whether they're an adult or a child, alongside the ability to look at someone's ID without recording all their personal details forever. As they used to say, on the internet, no-one knows if you're a dog, which is both a strength and a weakness. Identifying mechanisms like this (ensuring parents have more control over their own computers, but not requiring full verification anywhere) seems like a reasonable approach to fixing some of the weaknesses of internet anonymity, while still preserving the basic strength that identifying yourself is always opt-in.
The danger of a slippery slope comes when one change enables the next change - for example, a law mandating certain kinds of data collection enables a future decision to discriminate or control based on the collected data. But in this case, no data is being collected, there's no step happening here that enables a more dangerous later step.
If anything, I'd argue this makes it harder to implement more invasive measures later, because rather than arguing that some form of age control is necessary, Illinois will specifically need to argue that age verification is necessary over the existing anonymous system. That's harder than saying "there is no protection for children right now, age verification is the only way forward".
I think this is the real reason for its (pre-LLM) ubiquity - it's a really flexible, versatile bit of punctuation, whereas most of its siblings have a more specific meaning or purpose.
Like I said, if you're going to talk about automatic type conversion, then calling it "automatic type conversion" is probably the simplest option - strong vs weak typing doesn't really need to come into it. Then you avoid any definitional confusion.
I'm increasingly convinced that "strong/weak" has no useful meaning. Some people regularly use it interchangeably with "static/dynamic", others use it to vaguely refer to how much casting exists in a language, or how easy it is to transmute a value of one type into a value of a different type. There is no academic definition at all.
Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior.
In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing.
This is in stark constrast to Germany, say, where people colloquially use 24-hour times, with some exceptions for round times (e.g. 17:00 might be called "um fünf", but 17:05 would usually be described as "siebzehn uhr fünf", roughly translated as "seventeen oh five".
This might have changed in the last five years or so since I was living in the UK, but I've never noticed this be different when I was visiting, nor when speaking to British friends or colleagues.
This means that AAV is culturally important, but there's not necessarily the same sense of "this is a separate language" that there is with Scots, even though in many ways it has all the same claims of being one.