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…

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.

Its a fully electric drivetrain with a gas generator. When the battery runs low you can recharge it (even while driving) using the generator.

So you don’t have the complexity of a combined hybrid drivetrain, but instead a normal BEV one plus a power generator, both of which are very well understood problems.

Another benefit is that the generator can always run at its most efficient rpm/power point and is decoupled from the speed of the wheels.

Interestingly Wankel engines have been making a bit of a comeback for this purpose since they can be built more compactly for the same output power.

A drawback compared to hybrid drivetrains is that both components need to be built for “full” load, whilst a hybrid drivetrain can combine powers to reach maximum performance, meaning each of the motors only has to carry half (or part) of the total load.

SYN??

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