Some of their smart devices are using it. They've been focusing on GoogleOS (merging Android + ChromeOS) for a while but when that's done I guess they may adopt some of Fuschia's work. But I doubt if there will ever be scaled efforts to replace the entire Kernel stacks, even with the frontier models it is going to be very hard.
I had access to this over few weeks, and in my impression this was the first Gemini model that I can offload complex tasks that I don't want to do myself because I have to do lots of domain specific researches, which is irrelevant to my daily works. Not 100% reliable, but its outcome is usually better than mine and the cost to verify the outcome is significantly cheaper than doing the task by myself.
The performance ceiling from the pre-training seems fairly high and they demonstrated impressive post-training improvements from Flash 3.6 -> Flash 3.8. If they can reproduce that in this model then this can be a good model for the next year. But the question is whether they can keep this up over coming years; they missed one pretraining cycle due to internal misallocation and it costed them several months of frontier competitions, and I still don't know if they addressed this structural problem.
This is a valid take but at this moment, AI is not trying to solve this fundamental dynamic. But it can still accelerate the process by aggressive exploration of the solution space which cannot be done even with an army of human researchers. Many ideas can be relatively quickly verified (and discarded if needed) by proper simulation even before real world experimentation, but we don't have enough capacity to process all potential ideas. If you can build a good model for simulation and establish a robust methodologies, we can use some ideas which never had a chance before.
It's not a tooling problem. It's more of a layer of policy problems. If you realize that you cannot run a simple experimental code even in non-production environment for weeks due to 10s of privacy, security, access, process and legal issues where you gotta collect a bunch of approvals, this is critical. And the problem gets worse because the tooling is too good when it enforces. There used to be some holes and circumvention which are all gone these days. This is probably why they said "the infra is good for services but not for research".
I would be more careful before assuming 5 years depreciation schedule. Currently price tags are attached to computing power, not the production cost. Computing is not getting meaningfully cheaper with newer GPUs but it only allows better scaling, which makes older hardware more relevant for many use cases. This is why A100 is still selling like hotcakes. I don't think this trend will change soon.
Apple can enjoy because it controls a significant fraction of consumer computing platform so they can simply collect tax from everyone else. This is not true for the rest of big tech. Only Google has Android but it cannot sit and enjoy because they still don't control hardware and AI is an existential problem for their search business.
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.
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.
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.
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.
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.
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.