That means that for every 3 units of heat your chips emit, you will use a 4th unit to spin the pump. If your panels generate 150kW, you will only have 113kW available for compute and the rest is cooling. Radiators will more than halve vs 340K operation, so it's net beneficial.

It's all a giant techno-economic optimization problem: the extra mass of solar panels you need vs saved radiators vs mass of the pump, the die temperatures you achieve and corresponding performance, durability and chip price point etc.

It's one thing to commit to a "everything is deleted when you press delete" automatic policy. It's quite another to say "we'll keep some stuff for up to 30 days, look inside it for any malfeasance, then pinky promise we'll delete it".

The structure of a good argument would be something like: certain tasks are fundamentally human and impossible to automate (which and why?) and by pushing AI use beyond what is optimal you are actually hurting your employees ability to do those hard parts.

A weaker but still useful argument is that most everything can probably be automated, but frontier models aren't there yet.

An RO desalination plant needs electric energy to drive the pumps, which might be generated by panels which are 15-20% efficient. So, if you can have cheap thermal desalination panels, they come out ahead even if 6x less energy eficient, you avoid the whole expensive and fragile desalination plant and you gain a low skill, distributed setup.

The accounting company affirmed the test results, CFO Ed Finger told the board that the auditors observed 157 unique rides and there were no negative findings. These are all public records and board minutes anyone can request and consult.

Essentially, according to what was reported in the media, they had the few hundred volunteers board packed Teslas (3 pax + driver), ride the system, disembark and take another ride, while remaining within the station limits.

I wouldn't call the 4400pphpd result an "extrapolation" - it's a real, instantaneous capacity number once the system reaches steady state, just like you don't have to drive for an entire hour to express your speed in km/h or mi/h.

The figure is of course not indicative for the real rush hour capacity of the station infrastructure, especially the underground stations that have escalators etc., when they are packed with disoriented tourists carrying luggage and not necessarily making an effort to move fast and hit good numbers.

Hence, I think my original point stands firm, Boring has demonstrated vehicle rates that can beat light rail, the basic premise of cheap narrow tunnels is sound. To actually demonstrate competitive numbers in real life scenarios will require larger vehicles, better organized ingress flows and procedures, more and perhaps larger stations etc. But these are all tweakable factors depending on actual demand at a specific station, they can run a mix of vehicles and expand infra where it makes financial sense, but only IF the tunnels have good vehicle rates, ie. no more than seconds of headway with extraordinarily rare in-tunnel break downs.

This is all public info available from unbiased sources; preferring schadenfreude and rage inducing bait is, of course, a choice you are entitled to.

The largest subways in the world can reach 80,000 pphpd (crush load) but the vast majority of US systems are under 20k, and those are numbers Loop can likely reach with larger vehicles:

https://www.reddit.com/r/BoringCompany/comments/s4r6l4/chart...

Only a handful of the largest US systems really hit the capacities the only heavy rail subways can support, and they do so with eye watering costs, see the famous $2.5 billion mile in New York's Second Avenue extension. So a $10-20mil/mile system with 1/4-1/2 the capacity of a full subway could, if demonstrated, completely change the game in many cities.

Now, after Loop demonstrated vehicle rates that would beat most light rail projects and many subway systems too - assuming they get adequate automated larger vehicles - the criticism seems to be that it's not build out yet to a significant size, or that it has minor usability quirks.

I sure hope these people understand just how foolish that position risks to become if Boring Co continues good execution and build outs the entire system as planed.

Isn't that just an instance of the political problem for all ages: who controls what, who gets to rule and who obeys, the fundamental power struggle apparent in all human history.

Extend the definition of technology to the broadest sense, from the material that allow us control over the physical reality: steam, computing; to the organizational, that enable collective human action: states, factories and assembly lines; and the ideological, that legitimize certain power arrangements: religion, nationalism, democracy, human rights etc.

A feudal lord's power rested on land (material), the manorial system (organizational), and the divine right of kings or religious sanction (ideological). Even if peasant revolts happen from time to time, the arrangement is stable because the peasantry accept it as legitimate and have no economic alternative; so even when revolting they cannot imagine a different political order. Technological (broad) leaps like the Enlightenment and the Industrial Revolution change the political possibility space so arrangements like feudalism are no longer stable, but others like capitalism, liberal democracy etc. become possible.

Political actors observe these technological shifts and struggle for control, relevance and power. The old elites are contested by the new kids on the block, wielding the new technologies: the aristocrat by the bourgeois, pastoralist tribes by agricultural states, autocrats stuck with traditional propaganda by the kids with smartphones and social media.

The present struggle around AI is therefore to be expected; what's more interesting is the type of political possibility space it opens up: is it one where having the bulk of society educated and productive, capable of running the machines is the key factor pushing the country forward in the international technological competition, like we've see post-war, forcing the national elites to cater to their needs, invest in their populations and broadly share the economic output and the political power? Or is it more likely one where the key competitive factor is the size of your datacenters and automated defense factories, where the bulk of people are irrelevant for the architecture of power?

Because if it's the latter, the entire idea that democracy will somehow manage to survive and influence who gets what becomes problematic. In the new technological-historical space, democracy becomes structurally unfavorable and thus, unlikely to persist long term.

The answer for most things pertaining to encloudification seems to be "because it's easy and we are already using cloud provider X". Death by a thousand clickops.

The main problem is that the the problem space is vast and highly interconnected, the LLM needs to reason about the entire language every time it suggest an architectural change, but it can't, so it suggests local changes that make sense to me - a language hobbyist - then runs into much more difficult problems down the road.

Maybe Mythos with a lot of (competent) human hand-holding and pre-design can do it.

KYC is a tool to prevent money laundry and it's typically an obligation of financial institutions. Sending money to an anonymous (to you) recipient is generally not a KYC violation if you are not in the money transmitting business and you aren't doing the payment on behalf of someone else.

There are infinite shades of gray in this topic, of course, but I can't see AML being relevant in this particular case.

I had to choose between NSIS and Wix - and while native installer formats were clearly the future even back then, the performance and compression advantages of NSIS were so great that it was a clear choice. Solid LZMA was simply impossible to beat by any deflate/zlib/mszip oriented tool.

The joy of the dev team was palpable, the new installer was about 60% smaller and installed in one third the time.

I question this. Yes, strong enforcement of invariants at compile time helps the LLM generate functional code since it gets rapid feedback and retraces as opposed to generating buggy code that fails at runtime in edge cases.

On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. If the initial architecture is bad or lacking, growing the code base incrementally as LLMs typically do will tend towards spaghettification. So I fear a program that compiles and even runs ok, but no longer human readable or maintainable.