Years ago, I did some work on thermal management of small satellites, mostly for cooling higher-power onboard computers. The scale is different, but the physics are the same.
The story of SpaceX is often that Musk tried to buy a rocket, got a price estimate, and did some first-principles evaluation of the materials and engineering costs he believed was involved that came out to be much less than the going price. He ended up (through fast-forward view doing a lot of work) being largely correct.
The data-centers-in-space in space thing does not work out from a first principles approach. The waste heat generated by chips and the cooling method available (ultimately, radiative cooling), and the structures required create those surfaces, would be orders-of-magnitude beyond what could reasonably compete with a terrestrial version with the same capacity. There's no "but launch costs are dropping" adjustment that can possibly make up for that. The physics involved are the blocker.
Starlink is actually a good counter-example of where the execution--building and coordinating satellites in volume--was the bottleneck, not the underlying physics of the networking and SpaceX was in a great position to capitalize with their engineering expertise and reduced launch costs. It's a totally different situation for the data center thing, though.
I often like SemiAnalysis' work, but there's parts of this article that are shockingly under-researched and completely missing critical parts of the narrative.
> 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.
I don't love this comparison, because I have to use Linux, not Mac. It's not really optional for me, and Asahi simply isn't far enough along to fill the gap.
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.
Not that it's super relevant to this discussion, but I think the largest individual machines operated would probably have to go to high energy particle accelerators like the LHC at CERN or those operated by Fermi Lab.
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.
Related to [1]; this topic was discussed earlier today (perhaps inspiring this submission?) in a HN thread on C++ coding standards for the F-35 JSF (search "spaghetti").
You know, in hockey there's sometimes a saying that "if you're too small to carry your gear bag, you're too small to play hockey." Feels like there might be some kind of moral lesson there for this situation.
I'd be interested in seeing these guidelines updated to include "don't re-post the output of an LLM" to reduce comments of this sort.
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.
Here's a 2022 from Quartz article that might have some context on this. Anduril isn't on the list according to the footnote, but Thiel and Lucky have since had a history collaborating on projects with the same naming scheme.
I haven't heard anyone mention this rule, which I think is useful:
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.
> For this story, Fortune used generative AI to help with an initial draft. An editor verified the accuracy of the information before publishing.
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 totally get the point you're trying to make (and don't even disagree) but I think the analogy isn't quite right.
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.
My personal opinion is that System76 isn't really targeting personal users with their desktop line, though, but instead is more focused on professional users. For example, I built my own desktop computer at home, but if I needed one for work for doing ML or just to have the increased compute over my company-issued laptop, there's no way that my organization would sign-off on letting me spec out my own parts from Newegg and spend a day or two building and testing the system, then trying to install NVIDIA drivers on Ubuntu.
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.
This completely differs from my own experience with LabView, which I used a number of times in both undergrad/some grad-level coursework (I have a mechanical engineering background), as well as in internships at a couple of different companies. LabView sits, almost uniquely, in the "absolutely not, with no exceptions, ever again for the rest of my life" tools that I've worked with in my career. I don't think I even list on my resume anymore, because I don't want anyone to know that I've ever touched it and assume I'd be willing to again.
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
If anyone's interested, there's a slightly more recent update on this work at the link below, dated about a week after this post (23 March vs. 16 March 2025 on the main link).
While I think your points about some of the difficulties that arise in multi-language/framework projects is fair, I sort of roll my eyes whenever someone frames Rust as something like the "hip new thing".
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.
> But the point is that I need to now do this with every use of a third party library.
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."
I think you're using the term "assumed" incorrectly. Per Webster's dictionary[1]:
> 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.
The default behavior is unwind, and unless the library is targeting something like bare metal embedded, in all likelihood will never resort to an aborting panic.
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.
There's a such a degree of entitlement to this comment.
> 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.
Respectfully, I think it's more likely that you're just not personally plugged into and/or have your awareness tuned to them but those conversations are definitely happening. There's not a single consensus (at least in the U.S.), but discussion definitely occurs and in many cases has led to concrete action.
The story of SpaceX is often that Musk tried to buy a rocket, got a price estimate, and did some first-principles evaluation of the materials and engineering costs he believed was involved that came out to be much less than the going price. He ended up (through fast-forward view doing a lot of work) being largely correct.
The data-centers-in-space in space thing does not work out from a first principles approach. The waste heat generated by chips and the cooling method available (ultimately, radiative cooling), and the structures required create those surfaces, would be orders-of-magnitude beyond what could reasonably compete with a terrestrial version with the same capacity. There's no "but launch costs are dropping" adjustment that can possibly make up for that. The physics involved are the blocker.
Starlink is actually a good counter-example of where the execution--building and coordinating satellites in volume--was the bottleneck, not the underlying physics of the networking and SpaceX was in a great position to capitalize with their engineering expertise and reduced launch costs. It's a totally different situation for the data center thing, though.