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).
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.
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.
> 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.
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.
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.
Does such a thing exist? Hmmm...