2,783 karma · joined March 28, 2014
They are about $50 in quantity. The surprise isn't that isn't happening now. The surprise is it didn't have a couple of years ago. It entered mass production 5 years ago, before the war started.
[0] https://hailo.ai/products/ai-accelerators/hailo-8-ai-acceler...
It looks like it appeared that way to Trump. But you make it sound like it appeared that way to most people. As one of those "most people", I can say that's wrong. The reaction of most people was "WTF is Trump thinking?".
It's been clear he's not the sharpest tool in the shed for a while. But he should be surrounded by very bright people for are able to provide frank and fearless advice. Looks like he fired most of those people, and whats left have been cowered into sycophants.
I dunno. Yes, the stock market dictates they get a return. But the return they get on that R&D isn't easy to determine. The return is high now. When you go from the previous best model only being able to find a handful of security issues, to the next model producing a flood so large Linus is screaming rage into the void complaining that his legion of helpers can't handle the flood of new CVEs (but he can't really blame anyone for this), development is going very fast. They haven't monetised the ability yet, but really does critical infrastructure have any choice now other than to get their entire codebase vetted by Mythos? How much is that monopoly worth? (Granted - it won't last long.)
Their R&D is aimed at discovering - well I'm not sure what you would call it, but it's the same thing that allows a mother to take a glance at her child and know what's troubling them, or a senior engineer to glance at code and spot a bug, or a same thing that a chess master to look at a chess board to produce a move in a second or so that defeats all but the best chess players. There are lots of these areas of expertise to be discovered. They are worth a lot of money. When does it stop?
A hyped exploration of this by bloomberge: https://www.youtube.com/watch?v=JmFKaqJg5X4
Others have posted links here saying inference is about 30% of Anthropic's spend, the other 70% is R&D - things like developing the next model. If you take that into account, add a profit margin, and round to make the figures easy you end up with them selling tokens at $1 / M Token to make money.
Their API cost is currently $25 / M Token. There is no question that's profitable. Someone really pushing their $200/mo Max plan can use 10B Tokens per month, which works out at $0.02 / M Token, so they are eating a huge loss there. That is clearly going to go away at some stage. For the rest of us: look at your average monthly token usage. If you are using 100M Tokens a month with the Anthropic $100/mo plan, they are making money out of you.
You have to be working very long hours, and be really, really proficient at using AI to achieve 10B Tokens a month. The only way to be that proficient is to have been using it for a long time, years in fact, so it was useful to you long before Opus came along. You would be very disappointed to lose Opus, of course - but you are just the sort of person who can make a less capable model sing. It's not so difficult to see those users moving to an in-house-hosted, open-source model in a few years, and it will cost them what they are paying now - $0.02 / M Token.
All that means I'm not convinced by the gloom and doom vibe of the article. Things will change, but it won't mean the end of AI usage.
In my search for alternatived I stumbled across https://passbolt.com/ AGPLv3 and does support sharing single secrets, but no free hosted version. Free if you self host of course.
It guess it's a vaultwarden without "the man in Nebraska" problem.
Interesting. So Urkaine and the EU have been denied USA weaponry, and yet Ukraine is turning the tide of the war anyway.
I guessing this isn't how the current USA administration expected that would turn out. I imagine they thought the collapse of Ukraine would reinforce the USA piston as leader of the western world.
Judging by the West's silence when Trump appealed for help with Iran, that isn't what happened. Instead it looks like the Wests reaction to Trump's USA threatening to the leave their club is "don't let the door hit your arse on the way out".
Urkaine successfully waging war with weapons that cost several orders of magnitude less than what the USA is offering probably has something to do with that, particular given they are right next door and will be greatly appreciative of the EU's support for them through the war. Friendship and helping a mate out in a time of need brings it's own rewards.
Just like renewables, EV's and a lot of other technologies, the expensive toys the US arms producers are hawking are starting to look like relic from another era.
The primary difference between a Chromebook and a Googlebook appears to be the ability to run LLM's locally.
The requirements were spelt out at Google I/O. They boil down to a 40 TOPS NPU and a minimum of 16GB of memory. They appear to be trying to match Apple's M series memory bandwidth using software compression. ChromeOS didn't need an NPU and specified a minimum of 4GB of memory. Aluminium OS looks to have the same relationship with its LLM as a Chromebook did with Google Chrome, and needs the hardware to power it.
If they pull it off you will get GPT-4 performance, running locally.
As for who this is for: your guess is as good as mine. But if their replacement for crostini works (crostini is so hopelessly unreliable it felt like it never got out of beta, so it's a big if), even the minimum specs would be a very good Linux laptop.
Not being reproducible is a bug.
There is no reason for a build to not be reproducible, but somehow we let the built binaries become infested with timestamps, login names and file system paths. We recently moved to reproducible builds at work, and discovered that our login names and local home directory paths were being shipped in every release. No one was was very happy about leaking PPI like that.
You may not consider it worth the effort, but you aren't the one putting in the effort so I'm not sure why that matters to you. It is very much worth the effort to those people doing the work. Debian is a do-orcracy and so the people doing the work get to make the decisions.
You underestimate your own abilities. Tech savvy doesn't mean they think much about crypto.
To get a feel for this I asked Gemini "If you were to survey a group of people who would be called "Tech Savvy", what percentage of them would be aware you could construct a zero knowledge proof for a person's age that revealed nothing beyond they were older than a given threshold?". The answer was 5%..10%. That rises to a surprising low 20%..30% for Software Engineers. It's only once you get to Software Engineers who write security systems that you get above 50%.
Gemini didn't give any references so those figures could be complete rubbish, but in my experience they seem on the high side. Many very experienced engineers I interact with clearly have not thought very deeply about how crypto systems interact with human trust. Granted understanding the implications of crypto is yet another step beyond understanding the maths, but I'm amazed at how many technology curious people haven't bothered to take that step.
The good pollies on the other hand probably have a very good intuitive feel for human trust systems and how to navigate them. They rely on engineers to tell them what is possible of course, and they won't care about the details. But what they will care about is whether the engineers can deliver the system they promised, and there I have to admit our track record is appalling. How many government IT initiatives have you seen deliver what was promised on time and on budget? So when you tell them you can build a ZK system that delivers in all these privacy promises, expect a very sceptical reception.
True for age verification, but not true in general. If you have something that can be used illegally, it's very handy to allow firms to rent / hire it out anyway but make the hirer responsible for any illegal activity.
An example is hiring a car, and the car is used to ram-raid a shop. Today this is solved by handing over a government ID to the rental company. Commit a crime in the car and they hand that over to police, but it has the sad side effect of handing over information to the car rental they can use to track you, and worse sell to others.
Using a zero knowledge proof for a valid driver's licence fixes the privacy problem, but at the expense of the hire company not being able to transfer responsibility for illegal activity onto the hirer. I suspect if that happened no one would hire out cars any more.
You can easily design something that is Zero Knowledge to the car hire firm, but includes an opaque token they can hand over to the government on lawful demand. It contains all the details needed to pursue the law breaking hirer. Thus there is still a role for the law here - you can't always do everything with crypto.
This is a very minor quibble - I agree completely with what I think is your main point. This Google change is a privacy disaster. It's a step towards an enshittified internet with the gateways onto it controlled by a few big tech firms.
But I don't think just yelling "just use ZK" is helpful. It's much harder than that - ZK is only part of the puzzle. Passkeys are currently caught up in the same attestation trap, and there is no workable solution in the offing. Banks and other high trust applications need some assurance your FIDO private key is being handled securely. The solutions on the table are Apple not doing attestation, or Google who does at the low low price of selling your true name to Google. Both "solutions" suck, horribly.
ZK proofs of things like licences and age have to solve the attestation problem, and solve extra stuff as well. I'm not holding my breath.
I've come away feeling that most it looks fixable - but it won't be fixed in Rust. Some of the language choices (like favouring monomorphization to the point of making dll's near impossible) are near impossible to undo now, and in other cases where it might conceivably be fixed (like async) it won't be because the community is too invested with their current solution.
So we are stuck with the Rust we have; warts and all. That blog post convinced me those warts mean the language should be avoided for game development. Similarly sqlite developers convinced me the current state of Rust tooling meant it wasn't a good fit for their style of high reliability coding, so they are sticking with C. Which is a downright perverse outcome.
But for most of us C programmers who aren't willing to put in the huge effort Sqlite does to get the reliability up, Rust is the only game in town right now. It's the first and currently only language to implement a usable formal proof checker that eliminates most of the serious footguns in C and C++. But I am now hoping it becomes a victim of the old engineering adage: plan to throw the first one away, because you will anyway.
I haven't listened to those podcasts, but from Kate's description the recipe is the same as WWE. They appeal to the senses using only bullshit. The outcome is preordained, they are selling the hype only, the reality doesn't matter.
There is clearly customer base for this sort of thing that isn't going away. Amazingly it appeals to all age groups: https://drive.google.com/file/d/1jN2Jxp_o4OtLZl4HuK2jWAtmUyy...
It works so well the USA has president who sold himself to the voters using this very same model.
> Boris Cherny, creator of Claude Code at Anthropic, joins Sequoia partner Lauren Reeder at AI Ascent 2026 to talk about where coding goes from here. He explains why he hasn't written a line of code in 2026, why he now ships dozens of PRs a day from his phone, and why he believes coding is effectively solved — at least for the code he writes.
That explains a lot. I gave up on Claude Code. It's too buggy for me. I could put up with it making a mess when drawing the screen, but often basic commands like /status don't work, and occasionally it looses track of what it's doing so badly you lose the work done in a 5 how window.
Claude Code's major contribution to the profession is as an example of what happens to a product if it is vibe coded for too long without going through tight review by a human.
A little bit of hard evidence would be nice. In fact it would be more than nice. Firm anchors in the form of published results of real experiments on how you can make LLMs produce different styles of code would be golden right now. I'm sure I'm not the only one flailing around looking for good ways to use these newfangled tools.
I thought I could let this fly through keeper, but the idea keeps bugging me.
If the programmer does not vet and understand what the LLM has done, we call it vibe coding. If he takes personal responsibility for every line of code, we call it software engineering.
Lots of people use LLMs to vibe code (I do), and lots of people use them as a software engineering aid (I do that too).
The choice depends on the quality of code you need to produce. If an engineer is designing an aircraft wing, he would choose the highest grade of materials with known parameters. If he is building a kite for his son, an old newspaper would do in a pinch. Using 7075 Aluminium wouldn't just be overkill, it would mean his son doesn't get to see the fun his dad has building a flying machine in an afternoon.
A good engineer understands the properties of every tool at his disposal, and knows when to deploy each.
The difference is profound, and takes more than a couple of days to get your head around the implications. I'd summarise it as: "if you give a computer the same input it always produces the same output, but if you give a model the same input it always produces different output". Add to that the output is often wrong and it can't reliably follow instructions, and the difference is so great it breaks most of your intuitions.
The reward working with this piece of unreliable jelly is it can be far smarter than you (think the difference between a man with a shovel and a 20 ton excavator - they can literally find bugs in minutes that would take a human hours or days), and they know far more than you.
The engineering challenge is to make this near random machine produce a reliable product. It isn't easy.
The hype you see around them is it's trivially easy to get it to produce a feature rich but very unreliable product, as Anthropic demonstrates with their vibe coded claude-cli. I refuse to use it now. Among its other charms, it triggers a BSOD on windows: https://github.com/anthropics/claude-code/issues/30137 (Granted, it's just another Windows bug: https://learn.microsoft.com/en-ca/answers/questions/5814272/..., but if you are shipping to Windows you should be working around such bugs.)
No, as others have said it wasn't always that way. And more importantly it's not that way now. But yes, for a while there it was the epitome of enshittication. How that worked out is kinda hopeful in a way: it went broke, was bought out, and went back to being something usable again. In fact they added a lot of enhancements.
I know because I was one of the ones that went back to it. I didn't like having git being forced down my throat, and sourceforge was one of the few left that supports a whole pile of VCSs. I made my Makefiles [0] support it so I didn't need to deal with the UI, and ended up very happy.
Everyone wondered why I wasn't on github, and queried my sanity at the time. But I say not liking the git cli is perfectly sane. Now jj has come along that excuse has gone, but it was a good one at the time. "github sucks" has conveniently come along as a reason to stay on sourceforge.
Seriously, if you are considering ditching github, take a look at sourceforge. The current owners BizX deserve some reward for the time they've put into it, and their patience.
[0] https://sourceforge.net/p/http-proxy-tunnel/code/ci/default/...
I suspect that attitude is how we got ourselves into this mess.
You have to assume you ultimately don't control what scope your software runs in. Obviously you do, 99.999% of the time. The other 0.0001% is when someone has found another vulnerability that lets them run your program with elevated privileges in an environment you didn't expect, and then they can use it to exploit one of these bugs. Almost all exploits use a chain of vulnerabilities each one seemingly mostly harmless - your "no one can ever exploit this weakness in my program because I control the environment" will be just one step in the chain.
That sounds far fetched. It is far fetched in the sense that it almost never happens. But nonetheless systems were and are exploited because of it. Once the solution was added in 2006 (openat() and friends), it should have never happened again. And indeed in the GNU utils it can't.
The people who build Rust's std::fs should have been aware of the problem and its solution because it was written in 2015. std::path was written at the same time, and that is where the change has to be made. It's not a big change either: std::path has to translate the path into a OS descriptor use that instead of the path - but only if it was available. I suspect the real issue was they had the same attitude as you, they thought it affects such a small percentage of programs it didn't really matter. That and it's a little bit of extra work.
It was a pity they had that attitude, because the extra work would have avoided this mess.
Yes, that's Elon's claim.
I own a Tesla with FSD (hardware V3, so despite Elon's promises it will never work). I would never hire it out as a taxi. The risk of malicious damage is too great. I would have to insure for it, wear not having the car available when it happens, and the emotional impact of people destroying "my stuff" for the thrill of it.
The future of taxi's is a more traditional model like Waymo.
Or conservatively 100m x 100m of panels. About 1/5 of the roof area of a big-box store.
Anthropic is losing money. They need to raise that price to survive in the long term. But they can't because GLM-5.1 exists at 1/5 of the price. Not a lot of people use GLM-5.1, but they don't have to. It merely has to exist at the price it does to prevent Anthropic from becoming profitable.
I'm not sure how Z.ai pulled that off. I assume the price I see (about $4.40/M-token vs $25/M-token for Opus on openrouter.ai when I last looked) covers the margins of the inference providers, so the difference must lie in the R&D costs. The model originated at Tsinghua University, its continued development likely sustained by the Chinese model of state-backed venture capital and strategic subsidies. In effect, the public sector is paying for the R&D, allowing the commercial product to be priced at a level that private Western firms simply cannot match while seeking a profit.
You could imagine the plan always is to destroy the USA's capitalist model of R&D, if it wasn't for the fact that until a few years ago public funding of science to feed fresh ideas into capitalist enterprises (the "Vannevar Bush" model) was also used by the USA.
Generators are an interesting case. For example, if you implemented a Vec iterator as a generator, it becomes:
fn vec_iter(&self) {
for index in 0..self.len() {
yield &self[i];
}
}
fn next(&self) {
if (self.index >= self.vec.len()) {
None
} else {
self.index += 1;
&self.vec[self.index - 1]
}
}
However ... the async implemented all the mechanics needed to get rid of that green thread stack allocation when the size of the stack is known, as it is in this case. The state saving stuff they created for async could be used to translate that stack to a type. It would, surprise, surprise, contain just `index` - analogous the iterator type we have to manually create for event drive code. So compiler could translate the green thread to the same implementation as the event driven code, but you get to use the compact (and very familiar) syntax of a stack machine.
I found it interesting to see what happens for a more complex generator - like something that returns every node in a tree. You can do it recursively, which is simple clear code, but you don't know the size of the stack so the trick used for the vec iterator (translating it to a type) can't be used. Or you can manually store the state you stored in the stack with a recursive implementation in a Vec<> instead. Both require a memory allocation, but they are different. One is just normal malloc that must be reallocated and moved as the allocation grows. The other can use the OS's stack implementation, that doesn't move as it grows. If you re-used stacks, the OS's stack implementation would be faster in a long running program.
Notice that the transformation from a generator to async implementation is arguably more complex than the same transformation for green threads, especially for the tree traversal.
That observation is one of the reasons I'm such a strong proponent of green threads. The other is a simpler mental model. Unlike async, you don't have to expose the inner mechanisms it depends on, like futures.
while (char = read())
process_the_character(char);
element.onkeydown = window.greenThread(processKeyEvents, ...);
...
function processKeyEvents(green_thread, ...) {
while (event = green_thread.yield(...)) {
/* process the key event */
var foo = call_some_function_that_blocks(...);
/* more processing */
}
}
Code is effectively still coloured, because a call that can block can't be called from a context that doesn't allow block (like DOM events). async makes this colouring obvious but it comes at the expense of new keywords, new concepts like promises and futures, and manually creating the stack using linked object on the heap. A real stack is far faster than allocating stuff on the heap. But to repeat the key observation above: async and green threads are semantically near identical, it is only the implementation is different.
One selling point used for async is it makes blocking calls obvious, and that would somehow avoid bugs. The claim (willfully?) ignored that green threads (aka, cooperative multiasking) were the earliest form of multitasking - they have been around for over 50 years at this point. They were never a source of the sort of bugs they claimed would happen.
Turned out 404 didn't mention it because the paper never defines what LLM's can't achieve. Quoting from the paper: "A key insight from our contribution is that resolving the present uncertainty surrounding artificial consciousness does not require a complete and final theory of consciousness."
As you say, Dijkstra neatly penned a response to arguments that don't define their terms in 1983. They are exercises in linguistics, not science or engineering.
Oh, right. As you said, the ship has sailed. I think you could bolt green threads onto javascript now without ill effects - apart from bloating the language. I can't see anything that could go badly (certainly no avalanche of bugs). But in javascript green threads are only mildly more ergonomic than async. I wouldn't be bloating the language for such a small return.
Rust is a different position. The current async implementation has two big black hairs. Firstly, they had to come up with a type-safe way saving the functions current state. By state, I mean what a function normally stores on its stack. What they came up with is a work of art in some ways, but it doesn't work well with the borrow checker. The borrow checker insists you prove that you have exclusive use of a variable while it exists. Things on the stack have a limited lifetime (the function call), so the compiler knows they don't exist for very long. Even with that small lifetime it's a battle, but it's workable. Async persists that state, usually to the heap, which can effectively live forever. That wreaks havoc with the borrow checker, causing comments like this: https://news.ycombinator.com/item?id=37436274, quote: "Yes, async is effectively a much harder version of Rust ...".
The second issue is colouring. In the current Rust async implementation of large chunks of it is left to libraries, like tokio. Each of these libraries has to provide their own I/O. They aren't compatible. So if you want to use a cute new HTTP server, you are out of luck unless they provided a version that talks to the async library you are using.
The library writers do their best to accommodate by providing interfaces to the popular async libraries. That forces them to do a extra work. Whereas before they could just call `std::file::File::read()`, now they have to abstract all the I/O they do to a different module, and provide an implementation of that module for each async library they want to support.
The outcome can only be described as a mess, and that's putting it politely. It's harming uptake of the language. It wasn't like they didn't know it was coming either - there were comments pleading for a better implementation. And it wasn't as if weren't better solutions weren't already apparent - they had green threads before, they made some wrong turns with its implementation that needed to be fixed. And it's not like these solutions were harder to do than the async implementation they came up with. Async needed new standard library features to stabilise (like `Pin<>`) and introduced new keywords - none of which was needed for green threads. (Although some would be useful for an efficient green thread implementation - like knowing the maximum amount of stack a function could use.)
In the face of all that, they persisted with async. You'd need a sociologist to explain how that happened - to my engineering brain it's inexplicable. Unlike Javascript it isn't just mildly ergonomic implementation of the same thing, it's a serious mistake - well worth the effort of throwing out and replacing.
yes.
> But what's the point? How would that be an improvement over what we have now?
> But its basically async/await but without declaring functions as async.
You answered your own question: yes, you get what you have now, without all the overhead of async, await, promises and futures.
> But if you do that, any function call you make could yield before returning.
A green thread could be an instance of a particular type, so `input = self.yield()` would fail if you aren't a green thread. So no, not "any function" - just ones that instances of a green thread, or are passed a reference to one.
> Does it yield to other threads before returning?
It could if you pass it an instance to a green thread, otherwise it can't.
> This would lead to an avalanche of bugs.
It doesn't. Cooperative multitasking is at least 1/2 a century old at this point. The bugs you're imagining will happen mostly aren't an issue. To the extent they do happen, it's because someone hasn't thought about two control flows modifying the same data structure. Yes, that happens, but it happens in all single threaded code - async included. It's why we hate side effects. It's what Rust famously prevents with its borrow checker even in the face of side effects. It's not avoided by async. The explicit colouring does not help to prevent it - it's just overhead.
FWIW the one issue cooperative multitasking does often introduce is that they can take a long time to execute, so other cooperative tasks don't run in a timely fashion. Exactly the same thing can happen with async of course. It's not usually a problem in browsers, but in embedded solutions where cooperative multitasking is commonly used, it's a real issue because they are often real time. Ask me how I know.
> Javascript guarantees that while my (non async) function runs, no other code gets executed.
This remains true. You are getting confused by your mental model of threads as a form of concurrency. There is no concurrency going on there. Semantically it is near identical to async / await. The principle difference is in async / await, the program is explicitly creating each stack frame on the heap using manually allocated objects. In addition to the mental overhead that creates, it slower than using a real stack like green threads do. But now for the truly bizarre twist. Can you guess how modern javascript engines get around that speed issue? Wait for it .... they create an explicit stack ... that looks like what green threads would use anyway! And as a wonderful side effect - you get real stack back traces again. The irony is almost palpable. https://v8.dev/blog/fast-async
> Threads (cooperative or preemptive) would be a massive change to JS. It would cause an endless parade of bugs, and frozen websites. To say nothing of your notion we could casually reinvent DOM events. That ship sailed a long time ago.
I agree the ship has sailed at this point. The rest of the assertions you make there are wrong.
This assertion stands out: frozen websites. Can you tell me how they are going to block? There are no blocking calls in javascript now. The things you would await on now would be passed a green thread handle. But the javascript scripts events called from the DOM have no green-thread handle, so they can't block.
> Personally, I much prefer this information to be explicit. I need to know as a programmer whether or not execution will be interleaved.
You don't. You've just been conditioned to think that because you've never done it any other way. But the reality is people have been using cooperative multitasking for a long, long time. It pre-dates threads and async. The issues and bugs you are proclaiming would happen don't arise.