> Eighteen months ago, Elon Musk shocked the datacenter industry by building a 100,000-GPU cluster in four months. Multiple innovations enabled this incredible achievement, but the energy strategy was the most impressive.

> Again, clever firms like xAI have found remedies. Elon's AI Lab even pioneered a new site selection process - building at the border of two states to maximize the odds of getting a permit early!

The energy strategy was to completely and almost certainly illegally bypass permitting and ignore the Clean Air Act, at a tangible cost to the surrounding community by measurably increasing respiratory irritants like NOx in the air around these communities. Characterizing this harm as "clever" is wildly irresponsible, and it's wild that the word "illegal" doesn't appear in the article once, while at the same time handwaving the fact that permitting for local combustion-based generation (for these reasons!) is one of the main factors to pushing out timelines and increasing cost.

[1] https://time.com/7308925/elon-musk-memphis-ai-data-center/

[2] https://www.selc.org/news/resistance-against-elon-musks-xai-...

[3] https://naacp.org/articles/elon-musks-xai-threatened-lawsuit...

As a result, the question is more Framework vs. Dell or Lenovo, and that creates a much smaller gap in capability in the 13" form factor.

Billions of dollars in cost, run 24/7 with virtually no downtime during regular operations, in underground tunnels with circumferences in the tens of miles, and all throughout is actively-coordinated super conductors and beam collimation in a high-vacuum tube attached to absurdly complex, ultra-sensitive, massively-scaled instrumentation (not to mention the whole on-site data processing and storage facilities). Certainly open to bring convinced otherwise, but aside from ISS in pure cost, so far it's my understanding that those are the pinnacle of large-scale machines.

[1] https://news.ycombinator.com/item?id=46183657

I don't really feel like comments with LLM output as the primary substance meet the bar of "thoughtful and substantive", and (ironically, in this instance) could actually be used as good example of shallow dismissal, since you, a human, didn't actually provide an opinion or take a stance either way that I could use to begin a good-faith engagement on the topic.

Comments URL: https://news.ycombinator.com/item?id=45908898

Points: 2

# Comments: 0

[1] https://qz.com/1346926/the-hidden-logic-of-peter-thiels-lord...

[2] https://fortune.com/2025/07/07/peter-thiel-palmer-luckey-ere...

Cars, dogs, and water.

These are the big three common things that children interact with regularly that can, and will, cause irreparable harm or death with functionally no warning and virtually instantaneously. Kids also don't have the experience or the intuition to figure out if a situation is dangerous; cars move too fast, dogs are too hard to read, and water danger is hard to grasp even for adults (the number of people, including grown adults, I've seen panic and had to get pulled out after gleefully jumping into water where it turns out they can't reliably touch the bottom is fairly high).

The first two require some strictness (i.e. being very clear about rules like never going near a road without an adult, and never hitting a dog or pulling it's ears), but water basically requires regular swimming lessons from qualified instructors. It's something I wish happened earlier, and that more families had easy access to.

I wish these disclaimers went upfront, the way a newspaper by-line would have been. I've never engaged much with Fortune anyway, but this makes me much less interested in doing so moving forward--if I wanted to know what an LLM thought of airport lounge crowding, I could ask one myself.

I'd actually be surprised if I got robbed at a mobbed-up restaurant; my naive understanding was that they actual put a lot of effort into keeping places like that above-board so they have legit businesses to attach their name/revenue/employees to, while still retaining muscle in case a rival tries something. It's arguably one of the last places I'd expected to get robbed outright.

What they would (and do) sign-off on is a one-time purchase of a desktop from an approved vendor for that desktop, which comes with out-of-the-box support for the NVIDIA GPU I've selected. That's more the niche that I feel System76 is really filling.

I know it's a classic "don't blame your tools!" situation, but the ability for even moderately-experienced programmers to accidentally build high-incidental-complexity tooling that becomes a nightmare to re-learn once you've lost your mental model of the program is, in my experience, unique (and frightening).

I once spent weeks trying to get a LabView-based tool up and running that a senior engineer in another section had written. Sketching out the relationships between components, documenting I/O, etc. After finally giving up the ghost, I went to that engineer for help. After spending hours (like, 5-6 hours, not 1-2) sitting next to him in my lab, he said "yeah, I'm not really sure what I was doing with this...", and proceeded to need to take the entire program back to his desk for nearly a week before he could finally explain how it worked.

This situation wasn't a one-off; it's happened with nearly every non-trivial codebase that I've ever touched that used it. In my experience, LabView is really fantastic in only two situations:

a) Very simple GUI-based DAQ tools that the person who wrote the program, and them alone, will need to use

b) Complex tools that are owned by a team of engineers who have written LabView for years and will now be dedicated exclusively to those tools

[1] https://euroquis.nl/freebsd/2025/03/23/framework.html

The Linux kernel's first "release" was in 1991, hit 1.0 in 1994, and arguably the first modern-ish release in 2004 with the 2.6 kernel. Rust's stable 1.0 release was in 2015, 13 years ago. There are people in the workforce now who were in middle school when Rust was first released. Since then, it has seen 85 minor releases and three follow-on editions, and built both a community of developers and gotten institutional buy-in from large orgs in business-critical code.

Even if you take the 1991 date as the actual first release, Rust as a stable language has existed for over 1/3 of Linux's public development history (and of course had a number of years of development prior to that). In that framing, I think that it's a little unfair to include it in the "hip new thing" box.

Well, yes. You have to manage your dependencies (by either catching potential panics or forking/modifying them to meet your needs) or accept their behavior. You're using someone else's code for free; this is no one's responsibility but yours, nor is your convenience guaranteed. "This software is provided as is, without warranty" and whatnot.

> And what if I want to set panic=abort on my app to prevent data corruption in my code.

I obviously don't have direct insight into your application, but you could likely use std::process::abort if you feel that data corruption is a risk in a given circumstance (to be fair, I've never personally seen data corruption caused by an unwinding that would have been prevented with an aborting panic instead). Globally setting panic=abort is not necessarily the only approach to achieving your desired behavior.

> Setting panic in an app shouldn’t mean it is applied globally.

You could make a case for a more granular approach to specifying panic behavior. Sure. I don't even disagree with this. But do you see how that's moving the goalposts on your original comment? From "there's no way to wrap this behavior" to "It's possible, but I wish managing this was more convenient for my particular situation."

> Presume is used when someone is making an informed guess based on reasonable evidence. Assume is used when the guess is based on little or no evidence.

I'm not assuming they don't know what they're talking about, I'm asserting (or presuming) that they don't know what they're talking about based on supporting evidence showing that it is possible to catch panics. Similarly, I didn't say that they didn't know how to Google. I presumed it was likely they didn't put in a good-faith effort to do so, because in my judgement if they had, it would have been trivial to find the aforementioned information per my experience having just done the same.

[1] https://www.merriam-webster.com/dictionary/assume

I'll bet $20 USD to the open source project of your choice that the authors of whatever PDF library was being referenced here did not go out of their way to abort on panic, and that it's just a normal unwind.

> And there is no way to wrap this behaviour. [..]

As a sibling comment mentioned, this is possible with std::panic::catch_unwind. That is prominent in the std::panic documentation (literally the first function for std::panic) and if you Google "rust stop panics", the first Stack Overflow result (third down on the page for me) describes this directly. Just about anyone who had put in a modicum of good-faith effort would have found this quickly.

> You literally have to beg third party developers to consider what is best for you rather than them.

I'm assuming this means third-party developers that you're paying and have signed a support contract with? Because if you mean any of the three Rust PDF libraries that I just looked at, those are written by open source developers who have no obligation to consider what is best for you instead of them, owe you exactly nothing, and for whom you should be, if anything, only thanking for doing some of the initial legwork that allows you to use that library at all. If you'd like a change, make a pull request or fork the library.

> It is one of the more insane situations I've ever seen in programming in 30+ years.

Great. You've been in the field a while; nothing written about should surprise you.

[1] https://www.npr.org/2021/05/07/982709480/massachusetts-pione...

[2] https://www.nytimes.com/2019/05/14/us/facial-recognition-ban...

[3] https://www.wired.com/story/face-recognition-banned-but-ever...