summerlight

There is a pretty simple yet disappointing reason. CSAM is much easier to investigate and prosecute. You got evidence, you prosecute. Almost guaranteed conviction. You can even enforce big tech to implement proactive monitoring systems.

Compared to this, CSA is much harder. Every case is different. You have to do due diligence. And it is extremely hard to proactively detect them. Careful criminals will destroy all evidence. The number of case itself is smaller. And there is a good chance to lose in the court and for prosecutors this is a clearly risky move. Good ol' criminal investigation is expensive. There is a structural reason not to prioritize them.

The whole incentive structure is broken. The only thing to fix this is external pressure, but even it does not work these days. Exposing CSA is a rare event but media needs constant, sensitive headlines so they tend to treat CSA and CSAM like the same thing. Hence external pressures do not work, and even worse those work in a wrong way. This creates a bad feedback loop.

Looks like 3.6 Flash is the first model with their newest pretraining run (cutoff date is 2026/03), long after 2.5 series.

The title is kinda misleading. The actual wording is not specific about humanoid robots but "physical AI" which encompasses every machinery that can be potentially integrated with AI, especially focused on mass manufacturing for the Korean case. Basically this project is about all physical infrastructures to automate high tech manufacturing industry.

Looks like a lazy translation; the president used a word "대도약" while the Chinese campaign that you're referring is translated into "대약진운동".

My personal rule of thumb: I am usually okay with agents driving e2e implementations if this won't make life noticeably worse when it does not work. Some analytical code? Perfectly fine. Hobby projects? Fine, though I prefer doing a fun part myself. Refactoring production code generating 10x more revenue than my salary? You'd better be at least understanding what it does.

99% of the server code doesn't deserve trade secret protection,

Unfortunately, it is not you define whether it deserves. It's a court, ultimately SCOTUS.

This is one of the reason why that law will surely be challenged and very likely invalidated by SCOTUS. Trade secret protection is a very fundamental part and if this is forced to be broken by legally compelled speech, then it needs to have very creative interpretations over judicial precedents.

Many developers with good will actually tried that and gave up due to lots of problems. This is not just bad ROI but also a legal minefield. Engineers usually cannot argue against this kind of risks. Enforcing this will unlikely work in higher courts. Though something like open sourcing protocols for server reimplementation may have some chances.

While I see problems in the law but the spirit is reasonable. We need to push toward this direction. At least there should be difficult economical trade-off for publishers when they decide to shut down the game. Nowadays, some random executive just takes look into some excel, see some games have declining revenue and decides to "simplify the business" without much thoughts. This has to stop.

Because of high coupling dependencies between google3 projects, compiling just a single project usually pulls hundreds of thousands of different build targets.

All the developments are done in a virtual remote file system. From editing to compiling, everything is done remotely. Of course this does not fully stop people from doing manual c&p, but it still makes it hard enough to discourage it.

I guess it is much more frequent to maintain internal patches rather than doing all the merging work into upstream, especially the feature is non-trivial. Merging upstream consumes more time externally and internally, and many developers are working with an aggressive timeline. I don't think it is fair to criticize them because they didn't do ideal things from the beginning.

The quality of generated code does not matter. The problem is when it breaks 2 AM and you're burning thousands of dollars every minutes. You don't own the code that you don't understand, but unfortunately that does not mean you don't own the responsibility as well. Good luck on writing the postmortem, your boss will have lots of question for you.

This is not very surprising. I've always thought that it's more of correlation than causation. If you're a good problem solver, then there is a good chance that you are probably good at both college admission and software engineering. So companies have been using it as their proxy for hiring because... why not. I'm not saying college curricula are useless, but this dependency on (imperfect) correlation might have caused significant opportunity costs for talent acquisition and now companies are slowly acknowledging it.

Yeah, meet and chat (where each has their own bloat) are now integrated into the mail app as well. This contributes a lot.

I guess if they want to eventually deprecate the 2.5 family they will need to provide a substitute. And there are huge demands for cheap models.

I just hope them to provide an option to get rid of all those predictive models and just use a static, consistent layout. At least I can blame myself if my typo is from my own mistake.

This looks interesting. This project has some novelty as a research and actually delivered a promising PoC but as a product it implies that its training was severely constrained by computing resources, which correlates well with the report that their CFO overruled CEO's decision on ML infra investment.

JG's recent departure and follow up massive reorg to get rid of AI, rumors on Tim's upcoming step down in early 2026... All of these signals indicate that those non-ML folks have won corporate politics to reduce the in-house AI efforts.

I suppose this was a part of serious efforts to deliver in-house models but the directional changes on AI strategy made them to give up. What a shame... At least the approach itself seem interesting and hope others to take a look and use it for building something useful.

Don't forget to mention automatic enrollment of your production group into access-on-demand. Any minor access on the production now requires the group manager's approval. I had a fun time with some production fire where only director level folks can approve the access. Even funnier thing is that this "refactor" was done without any prior notice.

Basically it all boils down to budget. Those engineers knew this is a problem and wanted to fix that but that costs some money. And you know, bean counters in the treasury are basically like, "well it works well, why do we need that fix?" and the last conservative govt. was in a full spending cut mode. You know what happened there.

Internally, TPU is much cheaper for the same amount of compute compared to GPU, so I don't see much reasons why they need to use GPU. Probably >99% of compute budgets are spent on TPU. It might be true if you say these <1% still counts, but I guess it is pretty safe to say all of its meaningful production workload are running on TPU. It is simply too expensive to run a meaningful amount of compute on non-TPU.

Just to clarify, TPU has been in development for a decade and it is quite mature these days. Years ago internal consumers had to accept the CPU/GPU and TPU duality but I think this case is getting rarer. I guess this is even more true for DeepMind since itself owns a ML infra team. They likely be able to fix most of the issues with a high priority.

So do a currency swap?

It is the US who refuses to do.

One condition that Washington has been broadly mandating is, when they ask for the money then it should be deposited in the treasury's account within a short period. Basically they control the pace of the investment and the detail is not even a part of the deal.

Agreed that template itself is not the problem but people are. It is still arguable that template is much more of fun to write clever codes because of its meta programming capability as well as its runtime performance advantages.

With a pure virtual interface you can at least track down the execution path as long as you can spot down where the object is created, but with template black magics? Good luck. Static dispatch with all those type traits and SFINAE practically makes it impossible to know before running it. Concept was supposed to solve this but this won't automatically solve all those problems lurking in legacy codes.

When people are obsessed with over-abstraction and over-generalization, you can often see FizzBuzz Enterprise in action where a single switch statement is more than enough.

in C++, you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language.

Only if you have full control on what others are writing. In reality, you're going to read a lot, lots of "clever" codes. And I'm saying as a person who have written a good amount of template meta programming codes. Even for me, some codes take hours to understand and I was usually able to cut 90% of its code after that.

Waymo already had the permit, but they're just being (overly) cautious.

Unless we see unexpected side effects (like a lower number of housing or even more housing demands due to SB 79) I guess this will indirectly help the buyers looking for larger properties since so many people have no choice but purchasing a unnecessarily spacious house thanks to inflexible zoning.

since required fields don't contribute to b/w incompatibility at all, as every real-world protocol has a mandatory required version number that's tied to a direct parsing strategy with strictly defined algebra

At least I know 10 different tech companies with billion dollars revenue which does not suit to your description. This comment makes me wonder if you have any experience of working on real world distributed systems. Oh and I'm pretty sure you did not read Kenton's comment; he already precisely addressed your point:

This is especially true when it comes to protocols, because in a distributed system, you cannot update both sides of a protocol simultaneously. I have found that type theorists tend to promote "version negotiation" schemes where the two sides agree on one rigid protocol to follow, but this is extremely painful in practice: you end up needing to maintain parallel code paths, leading to ugly and hard-to-test code. Inevitably, developers are pushed towards hacks in order to avoid protocol changes, which makes things worse.

I recommend you to do your homework before making such a strong argument. Reading a 5 mins long comment is not that hard. You can avoid lots of shame by doing so.

would’ve been a “nature is healing” moment for the web.

A more likely scenario is that some other big techs like MSFT or Meta would acquire Chrome and replace the monopolist position. This is the sad truth that many people try to underplay; Nature won't heal by itself. The market is already structured to incentivize monopolist behaviors, thanks to the scaling nature of big techs. You need correction to the market itself, which can only be done by an extremely competent legislative body but we won't have that anytime soon. But at least the EU has done something with DMA so there are still some hopes.

Because the rule of law, specifically the principle of proportionality, does not allow us to penalize some entities only to hurt them. That might be something entertaining to see for many of us, but civilized societies typically limit the public power from being used in such a way.