I ran into the same issue not so long ago and at least for no_std I had to resort to using the async_trait crate. (The project is no_std but has alloc)

I can’t recall the exact error so it might have been due to mixing async and non-async methods in the same trait. I would have to look at it again…

Absolutely. Maybe a poor choice of words on my part. My intention was to state that this is not a thing you simply hang out in the wind and leave, but instead a vehicle that needs to be controlled to stay within its operational envelope.

I can imagine problems like tethers or lines getting crossed when the vehicle makes fast turns due to wind shear or frequent direction changes. You probably can’t operate it in those conditions.

You would think so but even normal ground-fastened wind turbines shut off when winds get too strong.

This being somewhat of an aircraft I absolutely expect them having to land it before storms roll in.

If you land it facing up- or downwards and deflate the balloon segments it would probably be fairly flat and compact for storage.

Source (German)

Would it have cost you so much to leave a link at the bottom of the post?

I have never used them but there are some tools that advertise being able to run GitHub Actions locally, like WRKFLW.

Und alle 39 der insgesamt 11 NichtsBS Nutzer sind hier

Indeed

Also the normal and rpi versions are two completely independent implementations of the same software. So now the LLMs have twice the maintenance load.

I didn’t diff the two files but even the startup and control code appears to be custom for each version.

Rock and stone!

(Without the text I’d assume this was a Deep Rock Galactic artwork)

Since projects of the same language often use the same tooling this makes it easier to clean up the whole directory by running something like this:

for d in ./*/ ; do (cd "$d" && somecommand); done

somecommand could be cargo clean if you’re in the Rust directory for example.

Just out of curiosity I don’t see how 4 sticks die together at the exact same time unless the PSU is/has fucked up hard.

I’d argue that the likelihood of 4 sticks failing together is much lower than the MOBO or CPU or PSU failing in a way that makes RAM inaccessible.

Typically you’d see one stick failing at which point you could take it out and run with the other 3 (or 2 depending on configuration).

Anyway if you ever intend to return its probably best to keep the rest of the components because who knows which of those will be up next for a shortage/crisis.

Depends on the exact system but there will be a method to switch to a newer release channel without reinstalling. Rinse and repeat every x years.

I assume you mean AVIF? Because AV1 is not an image (file) format but a video compression format (that needs to be wrapped in container file formats to be storable).

SpinLaunch versucht ja etwas ganz ähnliches. Mit ~100km Atmosphäre über der Startrampe ist das Unterfangen nicht einfach.

SpinLaunch hat wenigstens den Vorteil, dass es auf dem Mond wesentlich besser funktionieren dürfte.

Stapler sein wie:

Well the front didn’t fall off, so this could be typical for the new boosters.

The std::offload project is kinda cool. Hadn’t heard about that before.

It’ll be interesting to see where that leads.

I mean it sounds like they do have a working lifeboat in case of problems on the station.

Its just that their lifeboat can’t (safely) return to earth.

Die Fahrbahnmarkierungen sehen leider sehr europäisch aus

I was under the impression that the compiler already optimizes out a lot of clones where the clone is primarily used to satisfy the borrow checker. Is that not the case?