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...
593 karma · joined April 10, 2023
Does such a thing exist? Hmmm...
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.
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.)
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 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 look forward to seeing what happens with all this. :)
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.
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.
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)
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.
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. :)
If it's going by IP geolocation, I would call that a bug.
Oh, and if you were wondering, yes, there is already an X.402[1] out there.
They really don't make it obvious where to change it, either...
Source: I own one. :)
Maybe it's just me, but I see the presentation functionality as one of the less used aspects of the OpenOffice family.
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...
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.
In a collaborative scenario, doing it that way makes sure everything is always properly synchronized. Some individual's lacking config can't break things.
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.
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.
It does exit on MacOS and Linux, at the very least.
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.
That's just off the top of my head; I've not written in C in a while.