floating-io

I would be much more interested if they fully open sourced an S3-compatible git backend that anybody could use with any S3-compatible service.

Does such a thing exist? Hmmm...

I don't know enough about rust to confirm or deny that -- but unless rust somehow puts a limit on in-flight async operations, I don't see how it would help.

The problem is not resource usage in go. The problem is that they created umpteen thousand TCP connections, which is going to kill things regardless of the language.

You can have this problem with any kind of thread -- including OS threads -- if you do an unbounded spawn loop. Go is hardly unique in this.

Goroutines are actually better AFAIK because they distribute work on a thread pool that can be much smaller than the number of active goroutines.

If my quick skim created a correct understanding, then the problem here looks more like architecture. Put simply: does the memcached client really require a new TCP connection for every lookup? I would think you would pool those connections just like you would a typical database and keep them around for approximately forever. Then they wouldn't have spammed memcache with so many connections in the first place...

(edit: ah, it looks like they do use a pool, but perhaps the pool does not have a bounded upper size, which is its own kind of fail.)

Can't really speak to the point of the guy you're replying to, but the FreeIPA implementation via SSSD does more than just Kerberos tickets. Actually, I think the Kerberos based stuff as it relates to SSH is GSSAPI as part of sshd itself and has little to do with sssd, though I could be wrong.

That said...

If I'm remembering things correctly (and it's been a looong while since I've played with this), FreeIPA's client configures sshd with an AuthorizedKeysCommand that executes a program that queries sssd for the list of authorized keys for a given user. Sssd then uses a plugin to query the LDAP server @ FreeIPA to get the list of keys.

There's also SSHFP (I think) records in DNS if you're using FreeIPA's DNS servers. These provide the host keys for servers for your ssh client to check against. Not sure if that's integrated into ssh itself or something else -- I can't remember how it's implemented offhand -- but it's fairly nifty since you never see the TOFU prompt (or it would be if DNS was actually secure, anyway).

I think the hate is more about the fact that nobody gave enough of a damn to catch the error before it went public...

No need to worry, that's what the B Ark is for.

Yes. The "official release" is just so old as to be useless at this point. They should either update it or take it down and point people at github or something, IMO.

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.

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.

[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. :)

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.