- 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. :)
- 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.
- 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.
- 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)
- > 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.
- 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.
- 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.
- 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. :)
- 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.
- 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...
- 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.
- I use GitLab locally and push only to that. GitLab itself is configured to mirror outbound to the public side of things.
In a collaborative scenario, doing it that way makes sure everything is always properly synchronized. Some individual's lacking config can't break things.
- While that is certainly true, the idea that they can so rapidly decimate your data without the possibility to restore is still terrifying if that's your only copy of that data.
They should have to hold it for at least 90 days. In my opinion, it should be more like six months to a year.
In my mind, it's exactly equivalent to a storage space destroying your car five days after you miss a payment. They effectively stole and destroyed the data when they should have been required to return it to the actual owner.
Of course, that's my opinion of how it should be. AFAIK, there is no real legal framework, and how it actually is is entirely up to your provider, which is one reason I never trust them.
- My fear of this sort of thing happening is why I don't use github or gitlab.com for primary hosting of my source code; only mirrors. I do primary source control in house, and keep backups on top of that.
It's also why nothing in my AWS account is "canonical storage". If I need, say, a database in AWS, it is live-mirrored to somewhere within my control, on hardware I own, even if that thing never sees any production traffic beyond the mirror itself. Plus backups.
That way, if this ever happens, I can recover fairly easily. The backups protect me from my own mistakes, and the local canonical copies and backups protect me from theirs.
Granted, it gets harder and more expensive with increasing scale, but it's a necessary expense if you care at all about business continuity issues. On a personal level, it's much cheaper though, especially these days.
- Not sure offhand how portable it is, but asprintf() handles automatic buffer allocation, thus not requiring any extra steps afaik.
It does exit on MacOS and Linux, at the very least.
- No problem. =)
- Yeah, that is not a helpful attitude to take when it comes to this sort of thing. If nothing else, a super-long home path can crash your app and leave your user scratching their head. In other words, this is a bug (as is the fact that paths are not necessarily limited to 255 characters in the first place; see the PATH_MAX constant, I think it is?).
As to what could be accomplished with an overflow? I don't know; I'm not in security, and I don't sit around thinking of possible uses for various bugs when it comes to compromising systems.
Perhaps the most important thing to realize, though, is that you're distributing software publicly. Your security situation may not be the same as your user's security situation. Assumptions should not be made.
Something to keep in mind.
- Assuming that code is actually present in your app, env vars can hold more than 255 characters. Easy buffer overflow to trigger. Use length-bounded copies and concats...
That's just off the top of my head; I've not written in C in a while.
- Cloud services in general was the intended reference for the quoted words, not a specific provider.
- Signing up for services with a notoriously complex pricing structure, under the auspices of a company that is infamous for auditing its customers and forcing more money out of them on the basis of technicalities under threat of legal action, seems... unwise... to me.
- No, it's not. You can do very basic selection with resistors, but you can't get above 5V (or more than a couple of amps IIRC) without using the actual PD communication protocol.
- The problem is that design tends to be driven by the marketing department...
- Do you think that "being competent at design" is the only requirement for designers?
I would say that it's more important to be competent in determining how design is going to be understood and used by users in their individual workflows. Few are more competent to judge that than the users themselves.
I'm pretty sure most folks have seen and experienced the negative impacts of designers changing things for the sake of change (or to justify their paychecks).
- Not really that odd. It's easy to live without IPv6 until someone creates the IPv6-only killer app, and that makes it... not worth the hassle for most folks.
I'm in a moderate-to-high technology area in the grand scheme. They laid fiber here roughly two years ago, and lit it about a year ago, whereupon I immediately subscribed.
They don't offer IPv6. At all. That should tell you just how unimportant IPv6 is perceived as outside of its core cadre of proponents. Note that this is not a commentary on how important it actually is; just on perception.
In short, nobody cares.
- Only if you ignore that streaming streams data in records. The creation of a record (or struct, or whatever term you want to use) is not "batching". Otherwise any 32-bit word is a nothing more than a batch of four bytes, and the entire distinction instantly becomes meaningless.
An audio stream can easily be defined as a series of records, where each record is a sample spanning N seconds, probably as provided by the hardware. Similarly, a video frame can also be considered a record. As soon as a record becomes available, it is sent. Thus, streaming.
Optimizing to fully utilize network frames can generally be considered a low level transport optimization, and thus not relevant to the discussion.
I use the latest version all the time. The newer renderer ("manifold", IIRC) is much faster, and there are newer facilities that make it possible to build 3MF files containing multiple objects for multi-color printing, though that takes a bit of thought to do correctly.