When I see things like "facial age verification", I have major concerns, whether we're talking about a site like Roblox (whatever that is — I don't know, and don't really care), social media, porn, or any other site. How are you going to do it without violating the privacy of every person who creates an account? And how are you going to verify that the person using the account is the person who created it without causing an even bigger privacy violation?

We do need some sort of age verification system, but we need it to be designed in a way that protects privacy. I have less than zero faith in any individual website to come up with such a system, and approximately zero faith in any individual government to do so. There really needs to be an international age verification working group that spends the next five years coming up with a system, then pressures everyone to implement it.

Doing it the other way around, with companies or governments shoveling bad, partial, or even dangerous solutions to the problem down everyone's throats, can only result in greater levels of push-back by the general public towards a proper scheme if someone ever creates it.

They did review and change the policy. Just too late to do any good. The point is that evidence-based medicine has to be treated as a starting point for diagnosis and treatment decisions, not a rigid decision tree.

Of course, none of that makes the CDC's new claims that "vaccines don't cause autism" isn't an evidence-based statement any less absurd. You can't ever realistically prove definitively that X cannot cause Y, because that would require knowing that there exists no combination of recognizable human genetics in which X would cause Y. Evidence-based medicine would mean assuming that X cannot cause Y until evidence exists to prove that it does or can, which has not happened.

What they're doing is rejecting evidence-based medicine based on a belief that the anecdotal information they have should be taken more seriously than the broad evidence to the contrary. This would be fine if that anecdotal information were based on actual brain scans prior to vaccination that showed that the vaccine triggered a change, but it isn't. Rather, involves mistaking correlation for causation, and a post hoc ergo propter hoc fallacy, with a complete lack of any actual plausible explanation for how vaccines could cause autism beyond some vague hand-wavey pseudoscience.

And on top of that, we have a bunch of people who lack enough understanding of the scientific method and/or lack enough understanding of the subject to recognize when it is not being followed properly, and they are getting misled by charlatans with a political or personal agenda, presented in the form of pseudoscientific bulls**t papers that don't hold up to even modest scrutiny by someone with limited understanding of the subject or the scientific method, much less actual scientists in the field.

We also have a bunch of journals that publish papers outside their area of expertise, relying on outside experts that are in league with the papers' authors, and all sorts of other fun scientific fraud, which further contributes to this problem.

I'm not sure how to solve this problem, because it seems like a large percentage of the public simply lacks basic critical thinking skills and the ability to read over a paper and think, "Yes, but did you consider the following twelve common factors that could influence both the proposed cause and effect?" and realize that the paper is garbage. But a good starting point would be to pressure the news media across the political spectrum to hire actual science writers who UNDERSTAND SCIENCE to cover science-based stories.

Another good starting point would be to get more science-based shows on PBS that can talk about these issues and explain them to people and debunk bulls**t every week.

Unfortunately, evidence-based medicine has become a code word for "treat everyone with the same illness identically even when the data doesn't support doing so. That's how I ended up fighting a c. diff. infection. I was hospitalized for a related condition, and the first day of antibiotics put me at no fever, but after a day, I got a fever again, and I asked if the antibiotic had changed, and they said no, but maybe the ER gave me something different. They checked, and determined that yes, I had been on a different antibiotic in the ER, but said that they should keep the current antibiotics, and used "evidence-based medicine" as the reason. I had my doubts.

They were wrong. And six months later, the general standards for treating the condition I came in with changed, and they now treat it with the antibiotic that the ER gave me instead of one of the two that the hospital put me on afterwards, precisely because the standard treatment had a tendency to make c. diff. take over.

Whoops.

So I'm all for evidence-based medicine as a starting point, but when you realize it isn't behaving normally, you should adjust accordingly. Otherwise, patients suffer enormously.

But in theory, I do agree with you that evidence-based medicine is better than evidence-free medicine based on gut feelings and assumptions that correlation means causation and other fallacious reasoning.

When Google sells a 24-inch tablet, I'll care about Google being able to sell me a replacement that can do this. In the meantime, I want this feature on older, non-Google Android devices. :-)

Actually, I was remembering wrong there. Although TB can spread in other ways, it is primarily an airborne pathogen. So the biggest way to reduce the spread would be to add central heat and air with fresh air mixing and reduce the number of people sharing air for long periods of time. The second best way is contact tracing and prophylactic treatment.

But to add further to the comment about vaccine effectiveness, bacterial vaccines can be at least somewhat effective at preventing disease, e.g. the bacterial meningitis vaccine has something like 65% to 85% effectiveness, depending on age group and other factors, which is way better than nothing.

The TB vaccine only reduces infection risk by 20%. And when you're exposed frequently, that's barely even useful. The reason for this is that it hides from the immune system, which, as a result, takes a long time to start reacting to the bacteria, allowing it time to multiply for a while before you get a reaction. In mouse models, the reaction takes a whopping two weeks.

TB actually infects macrophages (primitive immune cells), and manages to literally hide inside them by adapting its exterior to maintain a neutral pH and by synthesizing enzymes that prevent the macrophages from maturing and that slow down apoptosis, which otherwise would release the bacteria, which would trigger T-cell activation. It's unclear whether there is a realistic way to prevent this delay.

It also plays tricks like triggering certain antigen-specific CD4+ T cells to the point of functional exhaustion while reducing antigens that would trigger other CD4+ cells so that they don't get detected. It somehow brings mesenchymal stem cells (blood vessel/lymphatic/connective tissue precursors) to the infection site, which further inhibit stem cells.

Presumably any better vaccine would have to either convince CD8+ T cells to react even without macrophages recognizing that something is wrong (perhaps by increasing the number of antigens that are included so that they are more likely to recognizing an antigen on the bacterium itself directly, early in the infection process, assuming this is even possible), convince CD4+ T cells to trigger macrophages in spite of signals to not do so, or overcome one of the design limits of the immune system (preventing T-cell exhaustion, increasing random macrophage apoptosis without an infection, etc.), some of which would likely require changing the person's DNA.

So fast diagnosis (universal health care and widespread rapid TB testing), contact tracing, etc. are critical to bringing it under control, and other prevention, such as not having large numbers of people in constant contact in areas with limited air circulation can also help. Meanwhile, vaccines, although not entirely infeasible, are likely to be more of a long shot.

Bullshit. I live in the western US and have regularly driven through some of the least-populated areas of the country, but I've never seen an area you can go 500 miles without encountering any infrastructure. You might be able to accomplish it if you take careful note of where the truck stops are and go out of your way to avoid them, but on any realistic route you'll encounter truck stops -- if not towns -- at least every 150 miles.

As for charging infrastructure, if you stay on the interstates I don't think there's anywhere in the country you can go more than 100 miles without finding a Tesla Supercharger. Those aren't designed for truck charging, but this demonstrates that building out the infrastructure isn't that hard.

They certainly seem to have completely missed Article I. You know, the part that says that the legislature makes the laws? Even if you think restricting AI regulation to the federal government is a good idea, the right way to do it isn't with an executive order to set up a DOJ task force aimed at litigating state AI regulations out of existence based on complex legal theories about interstate commerce. The right way is for Congress to pass a law barring states from regulating AI. This is simpler, cheaper and should invoke public debate about the issue, which is how things are supposed to be done in constitutional republics.

I don't even think Trump is taking this route because he and his advisors don't believe they have the votes for it. I think they're doing it this way because they don't even consider governing through legislation rather than through executive power. Granted that Congress is fairly dysfunctional, but they actually can and do make laws... and the way to fix the dysfunction is to work the system.

...over 143 years, 46 of which were before the discovery of the first antibiotic.

over six years, all but about one of which were post-vaccine. These two diseases are not really comparable in any meaningful way.

About 1.23 million people die from TB in a typical year, which is not that far off from the worldwide COVID death toll each year. We're mostly not talking about COVID anymore, either.

Vaccines for bacteria are... problematic at best, because they have relatively low effectiveness at preventing infection. The best way to eliminate TB is to get clean water everywhere. Stopping TB through vaccination is like stopping pedestrian deaths with inflatable pedestrian balls. Yeah, it might reduce the mortality, but the real problem is unsafe pedestrian crossings / unsafe drinking water.

The above was already quite long, but allow me to add a bit :-)

I spent a few minutes looking for the state of the art in C++/Rust interop for contexts that don't have a nice intermediary like binder. It turns out that the situation isn't as bad as I thought. The CXX project enables automatic generation of bi-directional definitions between Rust and C++ and is being used at scale by the Chromium project and that seems to be going pretty well.

There's also a Google-funded Rust Foundation project to define a better solution, though I don't see what, if anything, has happened since it was announced last year. Hopefully that's because there's a small group working too hard to waste a lot of time talking about it.

The reason I went to look is that my new team (I left Google a couple of months ago) might need such a thing. I've been asked to define an API that would benefit from being implemented in Rust and usable from C++ and Rust.

We don't, though the laws of supply and demand pretty much dictate that there must be some equilibrium point beyond which people buy fewer tickets and they end up losing money on non-refundable tickets.

Note that I'm not suggesting that raising prices is the right solution. It's a terrible solution.

Telling people that vaccines are bad, ensuring that any parent who wishes to refuse to vaccinate their children is fully supported in that decision, and working to make vaccines harder to get, more expensive and more painful (RFK Jr. wants to separate the MMR vaccine into three shots, each of which will still require three injections, so kids will have to get 9 shots to be fully vaccinated instead of three).

This is similar to their plan to fight inflation by imposing tariffs and forcing the Fed to lower interest rates in spite of rising inflation (note that this last part hasn't really happened yet -- the interest rate cuts have been measured, cautious and justified by economic conditions -- but Trump is working on it). Though to be fully fair, by making the tariffs arbitrary and capricious so that business leaders are completely unable to plan, Trump is also causing a contraction in US economic activity that might eventually generate significant unemployment, which actually does reduce inflation. I see no corresponding "silver lining" in the mumps plan, though.

And, ultimately, slavery was a far less efficient and effective economic system. One might think that keeping a big chunk of the populace poor is efficient, since you're not "wasting" a lot of production on providing them with unnecessary goods and services, but it's really not, at least not since the industrial revolution. I think the core reason that it's so inefficient is the same reason that Marxist communism is inefficient: From an economic perspective, both systems value the masses only for their physical labor, and fail to cultivate and take advantage of their brains, which also actually tends to reduce their labor output. Harnessing the distributed ingenuity of your workforce requires giving your workforce some reason to exercise ingenuity and some way to benefit from doing so.

It's going to be interesting (or maybe terrifying, or maybe just sad) to see what happens when we fully automate ingenuity, too, which will mean that the system no longer depends on or benefits from distributed ingenuity because the machines are smarter and think faster, just as the machines are already stronger and indefatigable.

Which in a free market indicates that the price is below what the market would bear. Otherwise, they would be unable to make a profit by reselling them. So the GP is not wrong, at least from a pure price optimization perspective.

This is not to say that there aren't societal benefits from charging less than the market will bear, of course, nor saying that scalping in any way adds value. It is basically rent seeking behavior, which makes it a drain on society. But the point still remains that obviously the ticket vendors could raise the prices to what the scalpers were charging and still sell tickets. Whether the scalpers would then be able to raise their prices further is unknown.

I don't think vibe coding is going to last long as a thing, because it's just a sort of intermediate step to telling the AI to do what you want and having it do that. Right now, people are telling the LLM to write code to accomplish a thing and then running the code to see how it works, then telling the LLM to refine it, but that's a lot of unnecessary extra steps. I'm sure that in the not-too-distant future people will just tell the LLM what they want to do, which may require creating a custom user interface to make user interaction convenient, and may require creating databases or performing network queries or whatever, and the LLM will understand what they want, and do it.

In that future, it's possible that the LLM may generate code to implement the requested functionality, but if it does so that will be a compute-saving shortcut, essentially a way to cache the LLM's work and be able to repeat it with less effort. There won't be any need to show any of the code to the user, or even tell the user that the LLM chose to generate some code.

As an aside, the whole notion of leaning "prompt engineering" is another intermediate step that will die. The whole point of natural language-capable AI is that it will be able to understand what humans want when we express ourselves as we would to other humans. As the LLMs get more capable, it will become less necessary to treat them as something different from an entity that is fully capable of understanding and acting on human communication.

One of the things Android did very right with the Rust transition was to set up a small team of people who were entirely focused on Rust support. It wasn't a large team, only 2-6 people (it varied over time) out of approximately 1500 engineers. Having that core team who either were or became deep Rust language and toolchain experts was critical to smoothing the path for everyone else. It provided a group that had the knowledge and bandwidth to solve the problems that inevitably came up, as well as to offer advice and code review support to the early adopters.

That group no longer provides code reviews and design advice because Rust knowledge is now widespread enough that teams have their own, homegrown, Rust experts (not people designated as Rust experts, just engineers who became enthusiastic and dived deep), but the group still exists to resolve complex technical problems with language integration and to work on improving tooling and performance.

I think any shop adopting Rust (or any new language or complex tool) needs to have some people who become deeply expert in it and are allowed the time and freedom to support others who are picking it up.

So does Android. Google has been a primarily-C++ shop since its inception and although I'm not sure if Android had a lot of C++ in it when Google bought Android in 2005, it definitely became a C++-based system as soon as that happened.

The highly-segmented architecture of Android really helped facilitate the transition. Most of Android is structured as a web of collaborating services that communicate through a common language-independent [*] IPC mechanism (binder). Implementing Rust binder IDL generation and support libraries was a moderately big job, but once that was done it was easy to begin writing new system components (or replacing existing system components) in pure Rust, generally without any unsafe blocks at all.

If your code runs as a monolithic process, or has a lot of different IPC mechanisms, or uses a lot of existing libraries, it will be a lot harder, and the benefits will come slower. You'll have to wrap a lot of C interfaces in Rust -- and they will have to be C, not C++, since there isn't a good way for Rust to interoperate directly with C++. People are working on that, but it's a very hard problem and at present the best option is to layer a C interface on top of your C++ code, then wrap a Rust interface around the C interface. Yuck. Or, in the alternative, insert some other language-agnostic boundary between them.

So in a lot of ways Android got lucky because of its modular architecture and single, language-agnostic IPC mechanism. OTOH, that wasn't really "luck", it was a lot of work, done for good reasons, one of which was cross-language compatibility, notably between Java and C++.

[*] Language independent-ish, maybe I should say. The binder IDL is definitively Java-based, but this maps fairly nicely onto OO languages that support common primitive types (int, char, enum), basic composite types (array, vector, class/struct, string (which is just a vector, but used enough to be worth treating as a first-class thing)) and Java-like methods (fixed argument list, single return value). Further, it's based on "old" Java, before Java acquired functional extensions, when doing things like passing method references as argument was uncommon, and therefore not supported. So it's moderately-expressive but avoids things that get weird and complicated. My one big complaint about it is that I wish it supported unsigned integer types. That's my biggest gripe with Java, too.