Or, just saying, be critical of ideas and think them through, and take in what experts say about it, and determine for yourself what's up. If a bunch of people who usually seem to know what they're talking about think there's a legitimate shot at something you, as a fellow armchair analyst, think is completely impractical, it makes sense to go and see if maybe they know something you don't.
In this case, it's all about Starship ramping up to such a scale that the cost per pound to orbit drops sufficiently for everything else to make sense - from the people who think the numbers can work, that means somewhere between $20 and $80 per pound, currently at $1300-1400 per pound with Falcon 9. Starship at scale would have to enable at least 2 full orders of magnitude decrease in price to make space compute viable.
If Starship realistically gets into the $90/lb or lower range, space compute makes sense; things like shielding and the rest become pragmatic engineering problems that can be solved. If the cost goes above $100 or so, it doesn't matter how the rest of the considerations play out, you're launching at a loss. That still might warrant government, military, and research applications for space based datacenters, especially in developing the practical engineering, but Starship needs to work, and there needs to be a ton of them for the datacenter-in-space idea to work out.
Or, just saying, we should eat babies because they are abundant and full of healthy nutrition for adult humans. [1]
Just because an idea has some factors in its favor (Space-based datacenter: 100% uptime solar, no permitting problems [2]) doesn't mean it isn't ridiculous on its face. We're in an AI bubble, with silly money flowing like crazy and looking for something, anything to invest it. That, and circular investments to keep the bubble going. Unfortunately this gives validation to stupid ideas, it's one of the hallmarks of bubbles. We've seen this before.
The only things that space-based anything have advantages on are long-distance communication and observation, neither of which datacenters benefit from.
The simple fact is that anything that can be done in a space-based datacenter can be done cheaper on Earth.
I can't tell how many layers of sarcasm are here, but I just want to highlight that aktshually cooling in space is quite difficult because there is no convection, so the only cooling option is radiative. Which gets a bit hard when the satellite gets blasted by the sun.
The ISS doesn't have problems staying warm, it has problems cooling off.
Everything I've heard from Musk in the past decade has been against my will and has made me dumber. (no I do not care to verify or know whether the above is true)
Edit: ah fuck ya got me "the next book in SpaceX and xAI's mission: scaling to make a sentient sun to understand the Universe" what the cultish bullshit is this. In a just world investors would be fleeing in droves from this cuckoo behavior (I know xAI & SpaceX are private)
A large telecommunications satellite operates at about 15kW. A Blackwell GPU consumes 1kW so you would be at 15 Blackwells per satellite. The cooling surface needs to scale linearly so there is little return to scale.
tbh you could just combine them with starlink sats. didn't they just apply for (and get?) a license for 1 million sats? Stick a single racks worth of gpu power on those and hey presto you've just got yourself the largest ai cluster in the world by far.
The problem is, they need so much more power than a Starlink satellite that they need to be placed in a sun-synchronous orbit. The orbits that Starlink satellites need to use are nothing like the orbits that would have to be used for this rejected attempt at an Ed Wood sci-fi tribute script.
And if you accept that the duty cycle of the AI+Starlink satellites will be less than 50%, it would be much better to build the data centers in random deserts and wastelands on Earth and use the Starlink network to talk to them.
Musk is notorious for shuffling assets across his companies to make some financials look better. For example, shuffling Twitter servers (and then all of Twitter) under xAI.
my partner got shingles a couple years ago, it was a very painful experience!
(to be crystal clear, I am making a joke equating the failed SolarCity/Tesla solar shingles to the (generally considered very painful) Herpes Zoster manifestation also called "shingles")
The author did not test the DFU flow, so I'm not sure why they're blaming the DFU port documentation.
Certainly there is a bug in the external disk upgrade sequence if switching the disk to a different (also non-DFU? They didn't specify) port solved their problem. But that's not necessarily related to which port is the DFU port.
To be clear, DFU (Device Firmware Upgrade) is a standard USB protocol (from 2004!), for a device to receive upgrades from a host. It is a specific port on the mac because that's all the boot-rom can support. This system does not come into play when booting from or upgrading an external disk, as the author was struggling with, because the external disk cannot be a USB Host to drive the DFU.
And I'm guessing that the reason macOS doesn't give more details is because macOS is likely not involved in the step that fails (maybe iBoot is?), and they didn't develop a way for the failing step to communicate failure data back to macOS. Yet another UX failure.
Situation:
- The author is running macOS ARM64
- off of a USB disk
- plugged into DFU capable USB-C port
- that shouldn't be the DFU one according to docs
- attempting to run macOS updater
- (supposedly)there's nothing else connected to it
Outcomes:
- updates were failing and rolling back with cryptic errors
- errors persist despite all efforts
- -> later magically solved after changing the port
- -> the problematic port later revealed to be the DFU port
- contradictory to Apple documentation
Or at least that's how it reads to me. As for reasons, I don't know why anything that can boot from USB can't from DFU-enabled USB port, but maybe it's configured as a special non-USB debug connector while bootloader is executing.
This is what I'm contending. No, I don't think this is true. All he found was the upgrading macOS on the external disk, which as documented must not be on a DFU capable USB-C port, did not work when plugged into a port that was documented to not be DFU.
The source the author is referring to, Michael Tsai, indeed found that he had plugged his external disk into the DFU port. The author then (reasonably, but IMHO erroneously) deduced that his problem, also solved by changing ports, must thus have had the same cause. I say it may be confounding factors, and the only way to validate the wrong DFU port hypothesis is putting their mac in DFU mode and then running Recovery Assistant (from another machine) against it, on various ports.
Tangentially, it is infuriating that Apple would swap what the DFU port is across generations, as if it wasn't confusing enough.
Also...
> As for reasons, I don't know why anything that can boot from USB can't from DFU-enabled USB port, but maybe it's configured as a special non-USB debug connector while bootloader is executing.
My guess is it's because DFU requires the port to be in Device mode, whereas booting from a external disk requires the port to be in Host mode. Apple care about boot time, so perhaps they don't want to waste time in the boot process to check the port in Device mode for a few secs, then switch to Host mode to try external disk booting.
>This is what I'm contending. No, I don't think this is true
If you don't think it's true you're "contesting" it not "contending" it. To "contend" is to argue, so you would only use that if you were adopting the argument you quoted.
Fine, but a normal USB stick isn't a DFU capable USB *host*. DFU is a protocol for a *host* to update on a device. Unless you're trying to update the firmware of the USB stick the direction is wrong.
At most the DFU capable USB port on the Mac doesn't support booting of USB mass storage devices for some stupid reason.
The author just wants to apply system update, and it should "just work".
The DFU part is just a distraction, what happened to "just works", as they point out in the article.
We should not even _know_ anything about DFU unless we actually _are_ updating firmware.
I'm not sure that it uses standard DFU protocol. When I had to write firmware from Linux, I had to use some software specifically for Mac (idevicerestore) and I had the impression that it was super proprietary stuff.
> And I'm guessing that the reason macOS doesn't give more details is because macOS is likely not involved in the step that fails
And I guess because of the wide variety of third-party hardware macOS has to support, it's not practical to write a pre-flight check into the update process either.
> This is wrong, a discovery that took me about a half dozen attempts to update macOS on an external disk. I have a 16-inch MacBook Pro with an M4 chip, specifically an M4 Pro chip, and the DFU port seems to be the USB-C port on the right side of the Mac, not on the left side."
It appears that the author is directly contradicting your read.
Now the question is: what is left and what is right. For the user this most logically would be whats left and what's right when they look at the open display. For Apple it may be when you look at the top cover with the logo in proper direction. They have odd priorities like that. :D
> You don't present any alternative theory for the behavior, just assert that I'm wrong.
Not the GP, but it is easy to refute your theory. Just do a DFU with the port indicated by Apple and it works per Apple instructions. I have personally tested this and can attest it works as intended.
I don't think one logically needs to be burdened to come up with an alternative theory for why your macOS update process to be able to conclusively refute your implication of Apple docs about which port is DFU being wrong.
> it is easy to refute your theory. Just do a DFU with the port indicated by Apple
No, it's not easy. I just said, in the comment you replied to, "I'm not even sure that I have all the prerequisites on hand."
> I have personally tested this
On my Mac model?
To be clear, I'm saying that the doc is wrong about my specific, relatively new Mac model, which I bought a year ago. I'm not claiming that the doc is wrong about other, older Mac models.
I have tested DFU restore on multiple Mac models including MacBook Air {M1, M2, M3, M4}, MacBook Pros {M1 Pro, M1 Max, M3 Max, M4, M4 Max}, Mac mini {M1, M4}, Mac Studio {M1 Max, M3 Ultra} off the top of my head (at least a bunch of older Intel+T2). I am sure many other people would have noticed if the DFU port was marked incorrectly. You are simply too quick to conclude what could be a bug in macOS updater is necessarily tied to DFU port designation. Just as an example, I have a USB-C flash device that is so flaky that sometimes does not work with a port on one direction and connect/disconnect and flipping the direction works. There's just any number of possibilities aside from DFU.
I have an M4 Pro, so you have not tested with my specific model.
> I am sure many other people would have noticed if the DFU port was marked incorrectly.
Why? Again, I'm not generalizing to many Mac models. Apple's doc specifies a very limited exception: 14-inch MacBook Pro with M4 or M5 chip.
And among users of the limited exceptions, who would notice except the few who need to DFU or the few who have macOS installed on an external disk? That doesn't sound like so many to me.
> a bug in macOS updater
So vague as to be an unhelpful handwave.
> Just as an example, I have a USB-C flash device that is so flaky that sometimes does not work with a port on one direction and connect/disconnect and flipping the direction works.
This example is not applicable to my case. The external drive otherwise works perfectly. It's not flakey at all. And in fact it boots into macOS Sequoia just fine, and software update on the volume works fine for non-macOS updates, such as Safari. So again, you've given me zero alternative theories.
Moreover, the symptoms that Michael Tsai described in his case of using the DFU port are exactly the same as the symptoms that I experienced.
[EDIT:] I looked around, but unfortunately I don't appear to have the proper cable to perform a DFU test. In fact I usually need to use some damn dongle just to connect to USB-C.
> [EDIT:] I looked around, but unfortunately I don't appear to have the proper cable to perform a DFU test. In fact I usually need to use some damn dongle just to connect to USB-C.
FYI, USB-3.0 C-to-A dongle + USB-3.0 A-to-C cable definitely works (haven't tested USB 2.0). The C side of the cable needs to be plugged in to the machine being DFU'd not the host machine where the dongle goes.
I didn't have the same issues, but I wouldn't say "it just works".
I've dealt with this in the past two weeks, actually.
I had an M1 MBP that I needed to re-pave with Monterey. Yes, it's end-of-support, but it's also only 4 years old. And should run on that Mac.
So, first step, I make a USB installer, and run it. Great. Reboots, and says "FYI, this is an unsupported OS. You can install a newer OS instead, or run Monterey in "Reduced Security" mode." That was fine for me.
"Installation of Reduced Security mode failed." Nothing else. Eventually my understanding of this was because the machine had been upgraded previously all the way to Tahoe, that somewhere along the line some firmware or something in the EFI had been upgraded and was too new for Monterey.
So what then?
Hmm, more research. "Do an IPSW image restore via DFU", i.e. pave it with a largely installed image. Could work, might have the same issue, but I'm stuck right now, with a Mac I can't install anything on, a four year old $3,000 brick.
Alright, I have a Mac Studio. I get the IPSW image, and Apple Configurator. Connect the two as per Apple's instructions, and (different here to OP), the MBP does indeed show up in Configurator as being "not booted, DFU mode".
Apple's instructions, "Drag the IPSW image onto the DFU 'box' for the target Mac". No. It doesn't light up like it's accepting a drag and drop, and indeed it doesn't. Nor does it accept a "restore..." or similar from the Configurator menu options. There's nothing in Configurator that seems to allow you to image the MBP.
Off to ChatGPT, Reddit, etc., I go.
Much repeating of the same. However, ChatGPT pokes a little button. Near the very end of its answer, it says "Newer versions of macOS may have limitations on the age of the image they might restore. You may need a slightly older macOS to do this. Even an Intel MBP running Ventura could work."
As fortune has it, my fiance happens to still have her old i5 MBP with touchbar, and the latest version of Ventura...
Alright, I need Configurator on this laptop.
No, says the App Store, "You need macOS Sequoia to install Configurator".
I find someone who has helpfully zipped up an older version of Configurator that runs on Ventura, and in the end, it works.
But Apple's docs absolutely are incorrect/incomplete about Configurator, and DFU restores.
"You can use Restore... in the Configurator menu to select the software image". No, you can't, even leaving aside the "old/unsupported". It actually means restoring from a "backup" (presumably Time Machine, though it doesn't specify) and you can't select any file or image.
"Drag the image onto DFU". Doesn't work in that situation, no error, no "hey, you're doing the right thing but I can't do this", just acting like a fool trying to drag the image onto DFU only to have it bounce off.
Like I said, I didn't have the DFU port issues, but Apple's docs on how to make this happen were either non-existent, or incorrect about the process, or flat out told me I couldn't do it. But mostly non-existent and overly simplistic covering the most basic scenarios only - which I get for general support, but by the time you are "connect to a second mac in DFU mode and run Configurator" in their own words, we're way beyond simplistic "you can just install a newer macos" type "instructions".
Thanks for the highlight. Doesn't seem like there's much activity on his Ko-Fi for being on the front page of HN. I sent him a tip, although privately.
I've been thinking of something like this for decades, as I mentally compared the utopian displays at construction sites to the existing buildings next to them. Like "wow your fancy new building is going to be so perfectly white and clean, but what will it really look like after 10 years exposed to the elements and no cleaning, like the one next door?"
New construction is sold on a literal blue-sky promise. How does it really look like a decade down the road? All construction has a decades- if not centuries-long lifespan. It's worth thinking about them long-term.
I absolutely love the streak of rust coming off the saddle of arches on the bridge example. That's exactly what I'm talking about.
Edit: years of searches and minutes after I post this I found https://www.youtube.com/watch?v=CaasbfdJdJg thanks to using "continued fraction" in my search instead of "infinite series" X(
Original:
Tangentially, for a few years I've been looking for a Youtube video, I think by Mathologer [1], that explained (geometrically?) how the Golden Ratio was the limit of the continued fraction 1+1/(1+1/(1+1/(...))).
Anyone know what I'm talking about?
I know Mathologer had a conflict with his editor at one point that may have sown chaos on his channel.
I learned about this not from Mathologer, but Numberphile [1]. The second half of the video is the continued fraction derivation. I remember this being the first time I appreciated the sense in which the phi was the most irrational number, which otherwise seemed like just a click-bait-y idea. But you've found an earlier (9 years ago vs 7) Mathologer video on the same topic.
Complete tangent, but, for me, this is where AI shines. I've been able to find things I had been looking for for years. AI is good at understanding something "continued fraction" instead of "infinite series", especially if you provide a bit of context.
Absolutely. In fact my post above originally said "infinite series" instead of "continued fraction", but Googling again, Google AI did mention "continued fraction" in its summary, so I edited my post and tried searching on that which led me to the solution!
100% agree. It’s great if you have a clear sense of what you’re looking for but maybe have muddled the actual terminology. You can find words, concepts, books, movies, etc, that you haven’t remembered the name of for years.
One of the talks I give has this in it. The talk includes Continued Fractions and how they can be used to create approximations. That the way to find 355/113 as an excellent approximation to pi, and other similarly excellent approximations.
I also talk about the Continued Fraction algorithm for factorising integers, which is still one of the fastest methods for numbers in a certain range.
Continued Fractions also give what is, to me, one of the nicest proofs that sqrt(2) is irrational.
Thanks! Do you have a version of that talk published anywhere? I tried searching your YouTube channel [1] for a few things like "golden ratio" "ratio", "irrational"... but didn't find anything.
Aw thanks, but I think the Mathologer and Numberphile videos are sufficient for me if you haven't already uploaded yours. I don't want to bother you doing extra work for little return!
I honestly should sketch out the talk anyway. I haven't seen anyone else bring together the proof that sqrt(2) is irrational, and the Continued Fraction method of factoring.
Yeah, maybe I'll hack out a sketch tomorrow, show it to a few people, and get them to tell me what's missing so I can flesh it out.
> Yesterday I was supposed to have a call. I have the app open and it never once let me know that there was a meeting.
Lol, we use WebEx, and someone actually went and developed an internal app to make it usable by piloting WebEx through accessibility APIs (including starting the call a minute before the meeting starts).
* Do this with "<0" and ">=0" to only test the sign of the result. A
* good compiler would generate better code (and a really good compiler
* wouldn't care). Gcc is currently neither.
It's funny the love-hate relationship the Linux kernel has with GCC. It's the only supported compiler[1], and yet...
[1] can Clang fully compile Linux yet? I haven't followed the updates in a while.
To be fair this comment predates git history (before 2005) when GCC wasn't a very good compiler. The kernel developers at one point were sticking with a specific version of GCC because later versions would miscompile the kernel. Clang didn't exist then.
Even funnier is the history. IIRC, the very first Raspberry Pi was an idea based on a bunch of stock of shitty SoCs for set-top boxes that Broadcom couldn't get sold, so Eben Upton got these for cheap for the foundation he and a few others had started to promote computer literacy.
Honestly, in all my life I've never seen the Pi being sold in EU for €35. The min. price I've found has always been around 45/50, with Pi5 never under 75, because of scalpers
reply