they aren't "your" federal and state tax dollars. if you want to privately provide welfare for PE out of your own pocket, go ahead, but leave the public's tax dollars out of it.
looking at ESO's homepage their main pitch is around NERIS compliance (https://www.usfa.fema.gov/nfirs/neris/) so it looks like this is a case of regulatory capture forcing fire departments to buy new software. An obvious solution here is that any government mandated information system must come with an open source implementation that guarantees compliance.
despicable attitude completely detached from reality. volunteer fire fighting services provide critical public services across broad sparsely populated areas of the United States and those volunteer services benefit everyone by preventing wild fires that threaten everyone. this kind of PE activity is parasitic and directly threatens lives and property by diminishing emergency response capacity. bad business to be in. it will get shut down very quickly.
uWebsockets, which is the foundation of the network and http server stack in Bun, as I understand it, is a compatible 3rd party extension to Node.js that gives it similar performance on HTTP implementation.
The key architectural difference is that Node.js implements the HTTP stack and other low level libraries in JavaScript, which gives it memory safety guarantees provided by the v8 runtime, while Bun/uWebsockets are a zig/C++ implementation. for Node.js, which is focused on enterprise adoption, the lower performance JS approach better aligns with the security profile of their enterprise adoption target.
JS/TS has a fundamental advantage, because there is more open source JS/TS than any other language, so LLMs training on JS/TS have more to work with. Combine that with having the largest developer community, which means you have more people using LLMs to write JS/TS than any other language, and people use it more because it works better, then the advantage compounds as you retrain on usage data.
> Vibe-coded projects get bought by vibe-coded companies
this is so far from the truth. Bun, Zig, and uWebsockets are passion projects run by individuals with deep systems programming expertise. furthest thing from vibe coding imaginable.
> a decade of performance competition in the JS VM space
this was a rising tide that lifted all boats, including Node, but Node is built with much more of the system implemented in JS, so it is architecturally incapable of the kind of performance Bun/uWebsockets achieves.
Claude Code running on Bun is an obvious justification, but Buns features (high performance runtime, fast starts, native TS) are also important for training and inference. For instance, in inference you develop a logical model in code that maps to a reasoning sequence, and then execute the code to validate and refine the model, then use this to inform further reasoning. Bun, which is highly integrated and highly focused on performance, is an ideal fit for this. Having Bun in house means that you can use the feedback from all of automation driven execution of Bun to drive improvements to its core.
There are two layers here: 1) low level LLM architecture 2) applying low level LLM architecture in novel ways. It is true that there are maybe a couple hundred people who can make significant advances on layer 1, but layer 2 constantly drives progress on whatever level of capability layer 1 is at, and it depends mostly on broad and diverse subject matter expertise, and doesn't require any low level ability to implement or improve on LLM architectures, only understanding how to apply them more effectively in new fields. The real key thing is finding ways to create automated validation systems, similar to what is possible for coding, that can be used to create synthetic datasets for reinforcement learning. Layer 2 capabilities do feed back into improved core models, even if you have the same core architecture, because you are generating more and improved data for retraining.
In my view LLMs are simply a different method of communication. Instead of relying on "your voice" to engage the reader and persuade them of your point of view, writing with LLMs for analysis and exploration through LLMs, is about creating an idea space that a reader can interact with and explore from their own perspective, and develop their own understanding of, which is much more powerful.
this is super overblown. what their executive said was that eventually the scale of compute required is so large, that it requires not only investing in new DCs, but new fabs, power plants, etc, which can only happen if there is implicit government support to guarantee 10+ year investment horizons required for the lower level of capital investment. that is not controversial at all and has nothing to do with OpenAI specifically being too big to fail.
I think you are right that the entire analysis is flawed. The Amazon and Microsoft "rental" deals have inflated price tags because of the circular financial arrangements between them and OpenAI, and because those future revenue streams can be used notionally to finance CapEx. All of the Stargate DC build is being done through for-profit SPVs, so the financials are murky, but building the infra gives them collateral for debt, and they are going to lease the compute to the highest bidder, so there is a whole scheme for getting out of the non-profit box, creating a self-perpetuating loop of borrowing to build, using what they build as collateral for more borrowing, raising additional revenue and hedging by leasing compute to 3rd parties, and then using the for-profit SPVs to cross-subsidize OpenAI proper. That plan has enormous risks of its own (can the leadership team of OpenAI effectively build a competitor in the hyperscale compute space?) but whatever happens, it won't just be straight line scaling their current deals with existing hyperscalers.
Google may very well be the Google of this era. They have demonstrated the ability to maintain parity on the engineering side, they have a long running advantage on OpEx with TPU, they have the most data, and the most trusted brand.
AI collapses the value of IP across the board, because AI trends towards being the only IP, which means that the marketplace will be defined by operational efficiency, ability to build and run systems at massive global scale, access to capital, and government connections, so Microsoft, Amazon, and Google probably stay on top.
the real answer is that the applications for the military, surveillance, and population control are proven, and the pathways to scale those capacities are clear, so the money will pour in no matter what. the implication is that we had better come up with some more consumer/humanity friendly applications that create comparable value, or that is all we will get.
for ad networks and social media platforms that provide monetization the click fraud is direct.
there is also a massive industry of fake accounts and fake engagement for social media and SEO (google). bots are designed to create plausibly real engagement, which is used to trick ranking algorithms into boosting content. these bots have to be real enough to bypass platform detection. clicking through on ads is a way of incentivizing platforms not to shut them down and possibly improving the ranking results, working with the theory that platforms give stronger weight to engagement signals from clients that generate more revenue.
developing secure software is very difficult. you have to start from a foundation of immutable data storage. then you need reproducible compilation from source code, to all executables, to bootable images. then you need out-of-band hardware that can verify signatures on the images being booted. all access to the system must take place through accounts with hardware tokens where all data access (r/w) is digitally signed and logged. then you need all developer access to the system to take place through this system. then at the application layer all data must be encrypted with unique keys, and the ownership and assignment of access to these keys must all be logged. this isn't something you can "bolt on later." it has to be a part of the platform architecture before development even begins.
YouTube was built on piracy and then Google bought YouTube and got immunity from copyright infringement claims by selling its user data to LE/IC in exchange for legal immunity. YouTube is still powered by piracy world wide. They only enforce copyright controls in western markets where the potential consumer is expected to have the income to afford streaming services. This is on par for the entire Google empire, which is all built on piracy, whether it is putting their ads on other people's content, redistributing other peoples's content without licenses, or building AI built on unlicensed content. And the whole thing works because they give their users personal data to intel and law enforcement in exchange for back door immunity deals.
this is a lot like the debate over IQ. there is no single measure of intelligence. humans have a broad array of different capabilities with every individuals capabilities sitting somewhere on a spectrum compared to the overall population. some capabilities are highly valuable in particular contexts and so people who are entirely focused on making money over-focus on the capability set that they believe translates into making money.
the people doing the hiring want to hire someone with capabilities they lack (which is why they are hiring in the first place) but then also expect that they will be able to exploit the person they are hiring in order to gain an excess share of the profits they create. the idea that you can hire people for their logic and math skills and expect that they won't be able to calculate their own value is a bit of a paradox.
> design the best system for what your requirements actually look like right now
this is the key practical advice. when you start designing for hypothetical use cases that may never happen you are opening up an infinite scope of design complexity. setting hard specifications for what you actually need and building that simplifies the design process, at least, and if you start with that kind of mindset one can hope that it carries over to the implementation.
the simplest things always win because simple is repeatable. not every simple thing wins (many are not useful or have defects) but the winners are always simple.