Hacker Newsnew | past | comments | ask | show | jobs | submit | floating-io's commentslogin

> Blue Moon HLS is considerably less complex than Starship HLS

That's the one thing in your comment I disagree with. Starship-based HLS has basically one base vehicle, modified into three variants (tanker, depot, and the lander itself). Refueling is done in LEO.

Blue Origin's HLS has three completely unique vehicles with no commonality (New Glenn, Transporter, and the lander), and refuels in multiple orbits, one of which is NRHO, which is likely to be far more challenging. And they're doing it with hydrogen.

Blue Origin's Mk1 cargo lander is simpler; their HLS architecture is not.

JMHO.


I do think that Blue Origin HLS is less complex overall, but I agree that they aren't dealing with the same kind of complexity. Both companies are playing to their strengths there.

A major weakness of SpaceX's HLS approach is that it requires them to launch a lot of the same vehicle in a fairly short succession. But SpaceX are the kings of high volume aerospace manufacturing, and they are the driving force behind US launch cadence going up. Even if Starship reusability isn't truly perfected in time for Artemis HLS, they are already building those Starships pretty fast, and can eat some refueling vehicle losses.

Blue Origin doesn't have the raw performance figures of Starship, or SpaceX's unmatched manufacturing and launch cadence. So their HLS architecture is lighter and less launch hungry. That comes at an engineering cost of having to use more specialized vehicles. And they are using LH2 fuel - which delivers more of a punch per weight, but is even harder to stay on top of than CH4. More engineering effort would be required to store and transfer that in orbit, dealing with boil-off and all - but Blue Origin has used liquid hydrogen extensively already, so they have experience with it.


Complexity vs. Tedium. There's a difference.

The SpaceX approach requires a lot of launches, but they're already proven experts at that. They've launched something like 130 rockets this year alone. That's one every couple of days.

High launch cadence is not complexity for SpaceX. It's normal for them. After the first half dozen or so refuels, it will be second nature, just like delivering satellites with Falcon is.

And they are, in essence, developing a single craft for it, just with a few variations.

Blue's architecture requires three distinct vehicles. Each one has to be developed separately. Then we get to the launch; last I saw, here is the comparison:

SpaceX:

* Launch the Depot

* Launch N tankers to fill the depot (this is the tedium I mentioned).

* Launch the HLS to LEO

* Refill the HLS in LEO

* Send the HLS to NRHO

* Rendevous with Orion in NRHO and transfer people

* Land on and then return from the moon

* Rendevous with Orion in NRHO and transfer people back.

That's a fairly complex architecture, but let's compare that against the last I saw of Blue's [1]:

* Launch the Transporter to LEO

* Launch tankers and refill the Transporter

* Launch the Lander to LEO "dry"

* Fill the Lander from the Transporter

* Send Lander to NRHO

* Launch tankers and refill the Transporter

* Raise Transporter to "stairstep" orbit

* Launch tankers and refill the Transporter again

* Send the Transporter to NRHO

* Refill the Lander again in NRHO

* Rendezvous with Orion and transfer people

* Land on moon and return with people

* Rendezvous with Orion and transfer people back

That is far more complex than what SpaceX is proposing.

The number of tanker launches is really quite irrelevant for both in this context. It's less risky for SpaceX due to their extensive ops experience, but both will be fine there I think. That's just tedium for both of them.

The complexity comes in with the number of operations and precisely where BO is doing the refueling. I'm not terribly worried about the LEO ops; they'll manage those. The NRHO refuelling though? That one strikes me much riskier if only due to comms lag.

And the sheer number of steps in Blue's architecture seems crazy to me.

So no, I can't agree that Blue's architecture is in any way simpler. Quite the opposite, in fact.

[1] https://ntrs.nasa.gov/api/citations/20250008728/downloads/25... :: the last slide in the set.

(edit: formatting)


I think the main problem for Starship is that they need to do a large number of tanker launches (about 20 I believe) in a timeframe in which the propellant in the LEO depot doesn't boil off. I assume they need to develop some good sun shielding for that. 20 launches could take quite a long time (multiple months? a year?) since it will probably take quite a few years till Starship, especially the upper stage, is rapidly reusable. They can't wait that long with Artemis 3, with Sean Duffy adding pressure.


On launches, it's conceivable that they can do the launches in 20 days if they do one a day. I ignore reusability, because I don't see it as required to meet the need.

They're known for moving fast, and they're building multiple pads. They're also building enormous mass manufacturing facilities in the background of all this (Gigabay and whatever). Not sure how many ships they'll be able to produce per month once the design is nailed down, but I'll bet it will surprise everyone.

SH Boosters are already effectively reusable for the purposes of this discussion; a couple of them have already re-flown. That's half the battle right there.

Boiloff prevention is presumably one of the main modifications needed for the depot. I think it's supposed to be easier with methalox than with hydrolox (which BO is using), but I have no idea the particulars of what they'll have to do there to achieve effectiveness. That said, I wouldn't be surprised if they try to cut that corner at least once; should be interesting.

The big risk that I see is neither launch nor boiloff, but rather simple fuel availability. Can they get that much methane and LOX shipped around the country that fast? I have no idea, but it seems concerning to me. Logistics...

Thing about the deadline, though, is who's going to do it faster? Blue has worse issues with their current crewed lander proposal. Nobody else has even started on one AFAIK.

My prediction is that nobody can build and fully qualify a safe moon lander with a more or less clean-sheet design in three years.

On the other hand, I can easily see Starship succeeding in a moon landing in three or four years if things go well with V3 and the refuelling research. It's a stretch -- things aren't likely to go completely smoothly -- but it's conceivable.


In 2024, SpaceX had one Falcon 9 launch per 2.8 days, after having been operational for several years. The first Falcon 9 was used in 2014, and the first booster reused in 2017. It seems it will take years for Starship to match and exceed that flight rate. Of course, Blue Origin faces other difficulties, as you mentioned, and they have a much more distant deadline (Artemis 5). But at this point I don't quite see Artemis 3 happening before a Chinese moon landing, with a much simpler approach that doesn't include any complexities comparable to what SpaceX is facing with its HLS. (As others mentioned, I don't think that's a major problem, as manned space flight is mostly done for abstract prestige, and the US already had Apollo.)

> My prediction is that nobody can build and fully qualify a safe moon lander with a more or less clean-sheet design in three years.

I tend to agree, though there are possible solutions that are technically simpler (if less ambitious) than either Starship or Blue Moon, while not even requiring SLS. Though it is probably too late now to try those. It's all the more surprising that Lockheed Martin still tries to offer an alternative solution:

> In a statement to Reuters, Bob Behnken, vice president of Exploration and Technology Strategy at Lockheed Martin's space unit, said the company this year has been conducting "significant technical and programmatic analysis for human lunar landers."

> "We have been working with a cross-industry team of companies and together we are looking forward to addressing Secretary Duffy's request to meet our country’s lunar objectives," said Behnken, a retired NASA astronaut.

https://www.reuters.com/science/us-seek-rival-bids-artemis-3...

But their offer would likely be very expensive, and it would be very questionable whether it can be faster than Starship HLS. So I don't think they will receive a contract.


I'll be surprised if the noises coming out of LM are anything other than PR, but it's not impossible. That said, I agree, it would probably be far too expensive if it did happen.

I look forward to seeing what happens with all this. :)


> Refueling is done in LEO.

Look up how many refueling launches are required and you'll see the problem, especially because no matter if Elon says so, the upper stage will never be reusable, even if caught.

Every moon mission will require that they pre-build a HLS and probably 15 full stacks.

Ridiculous.


> Look up how many refueling launches are required and you'll see the problem, especially because no matter if Elon says so, the upper stage will never be reusable, even if caught.

The Space Shuttle was reusable, and SpaceX is using an improved variant of the Space Shuttle heat shield, so it seems quite certain that Starship will be reusable. The question is more: how much refurbishment will it need? The Space Shuttle required extensive amounts. SpaceX will likely be able to improve on that a lot, though it isn't clear how long it will take.


You're welcome to believe that. Visible progress to date suggests otherwise to me; I pretty much ignore what Elon says as much as possible. Besides, however ridiculous, 15 full stacks would still be cheaper than a single SLS launch in all likelihood.

Even if I'm wrong, though, it wouldn't invalidate the point I'm making in this thread: BO's Mk2 has the exact same issues in a more complex architecture.


For how many users, and at what transaction rate?

Not disagreeing that you can do a lot on a lot less than in the old days, but your story would be much more impactful with that information. :)


Been a while since I've looked at available APIs, but can't the browser handle conversions into its own local system TZ?

If it's going by IP geolocation, I would call that a bug.


Browsers can handle conversions just fine but they need some context. If that context is somehow tampered with, then the results might be weird.

In this case, SpaceX seems to be using UNIX timestamps(1) which is probably fed to a combination of Date and Intl to obtain a localized date string. Extrapolating the country where the user is located is not really rocket science either. But, if my context is somehow tampered with (VPN, internal clock, browser settings…), then I will get a potentially "wrong" date, for whatever definition of "wrong".

The problem is fundamentally the same on the server side because you can only rely on the information you get… which might be wrong.

So either you take the safest route, which is to display the local time of the organization or its UTC representation and let visitors figure out their local date on their own, or you take a somewhat riskier one, which is to try to display a localized date to your users and accept the potential flaws of the method.

[1] https://sxcontent9668.azureedge.us/cms-assets/future_mission...


it's way easier too. Just parse an ISO UTC date string into a javascript date object and it'll correctly display the local time, no conversion needed.


The choice of name comes off as shady to me; seems like a marketing hack to make it sound like it's some kind of internationally-accepted standard, like oh, X.500.

Oh, and if you were wondering, yes, there is already an X.402[1] out there.

[1] https://www.itu.int/rec/T-REC-X.402/en


Thanks for this. I had no idea this was even a thing, and it explains some discrepancies I've seen with my one subscription.

They really don't make it obvious where to change it, either...


Or, more simply: "lipstick on a pig".


The Honeywell Z-Wave thermostats are trivial to connect and work with via Home Assistant.

Source: I own one. :)


I own two and they are bulletproof with Home Assistant. When away from home I just wireguard in and adjust/monitor as needed.


Does an embeddable XML database engine exist at a similar level of reliability?


An interesting skim, but it would have been more meaningful if it had tackled text documents or spreadsheets to show what additional functionality would be enabled with those beyond "versioning".

Maybe it's just me, but I see the presentation functionality as one of the less used aspects of the OpenOffice family.


What he listed as the first improvement, "Replace ZIP with SQLite" would certainly apply to the other ODF formats.

He advocates breaking the XML into smaller pieces in SQLite. I suppose making each slide a new XML record could make sense. Moving over to spreadsheets, I don't know how ODF does it now, but making each sheet a separate XML could make sense.

Thinking about Write documents, I wonder what a good smaller unit would be. I think one XML per page would be too fine a granularity. You could consider one record per chapter. I doubt one record per paragraph would make sense, but it could be fun to try different ideas.


> I think one XML per page would be too fine a granularity.

If I add a 1/3 page graphic on page 2, it'd have to repaginate pages 2-n of that chapter, modifying n-1 XML files...


Splitting the presentation into multiple fragments makes it more difficult to generate/alter a presentation using xslt.


While reading I was musing one way to handle text could be to use a linked list format as storage? To make it work like that, you’d need the editor to work on a block concept and I don’t think document editors work like that?

Spreadsheets might be a little easier because you can separate out by sheet or even down to a row/column level?

Part of me wants to try it now…


Remains to be seen. That's what they want, but it's never been done before. (edit: clarity: they do NOT want to replace them after each flight.)

They're currently experimenting with things such as actively cooled tiles (which I presume were installed on this ship, since they were on the last two).

I personally think the likely best case is that they'll have to go over the ship and replace some here and there before launching again.


Even if they don't get to a no replacement....they still already have a massive improvement over Space Shuttle. The Space Shuttle basically every tile was unique, and and the pattern was different between the different orbiters. A good bit of the months of refurbishment of the Orbiter between flights was heat shield repairs. SpaceX has already shown from when they completely retiled one of the ships. they have cut down the time to replace a single tile down to minutes instead of the hours it took with the shuttle. The Tiles are also alot more standardized so they can be more mass produced than shuttle tiles.


Absolutely!

I think there are still a few unique tiles on Starship around joints and such IIRC, but either way, the number of tile types is much smaller for Starship.

To my thinking, the sane sequence will be launch; catch; survey and maintain (heat shield and other items); and then launch again 24 hours later if everything checks out.

And that will be an absolutely massive improvement over what we have today, let alone what we had with the Shuttle.

I'm keeping my fingers crossed...


  > the pattern was different between the different orbiters.
I had never heard this before. Do you have anything to back this up? Asking as a huge space shuttle fan.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: