It's not 'supposedly'. It's a feature they officially gained just a few crewed flights back. It's a mean of last resort and has to be manually committed to during descend. I assume it may have to cut any remaining or semideployed parachutes.

I could be wrong but I don't think its been tested.

I want to like Helix. Its sane defaults are good. Selection model is even better and superior to everything else.

But its lack of proper API and total lack of server-client model makes it just completely unusable. I've seen people trying to integrate it with their file browsers, file trees, terminal multiplexers or window managers but there is just no normal way to get data into a running Helix instance other than sending keypresses and absolutely no way to get data out of it except of reading its screen. Its basic premise is just absolutely horrible which is of course completely subjective.

Another dealbreakers for me are absence of a proper debug support, code outlines, memory views, variable watchers, registers views etc. for working with embedded (as in running on microcontrollers) Rust.

What do you use instead?

Just curious.

I've been using Helix for some months now but haven't touched Rust. For that I plan to go temporarily back to vscodium + rust-analyzer + probe-rs which I know is a crazy good combination (no stinky openocd configurations, no gdb and connecting it to one of gazillion debug plugins - probe-rs has its own DAP thingy).

In meanwhile I'll look into neovim and making its selection model more like in Helix. For me it's not about motion before verb... I can use visual mode etc.. but about having consistent advanced commands for refining multicursor selections like selecting in selection, searching in selection, spliting selection to even more cursors or collapsing touching selections into one etc.

https://www.rust-lang.org/learn and there is a whole official book with detail explanation and first principles about what you ask.

Learn to use obvious "entrypoints" first which are cmdline help, manpages, and official web documentation instead of searching the web first. Those TONS of tutorials about embedded rust are uninformative at best and actively harmful at worst.

If you plan to use Cortex M based microcontrollers then there is rtic.rs async framework / RTOS. It could teach even 95% C programmers how hopelessly underused/misused NVIC in those core usually are.

Then if you need drivers with bells and whistles there is another async framework / RTOS called embassy-rs but you can combine those drivers and subsystems with rtic.rs async engine.

EDIT: Don't imagine async engine on MCU as some costly abstraction. It's zero cost abstraction for embassy-rs when compared to traditional RTOSes and negative cost for rtic.rs since traditional RTOSes does not use dedicated hardware machinery for scheduling which is present in Cortex M cores.

It is not so strange. Game journalism is mostly completely out of touch with majority of gamers and often part of 'woke' echo chambers with their fallback usually being blaming things on review bombing and other problems.

Fortunatelly we have free market.

Black Myth Wukong and response to it is good proving point. By all reasonable metrics it was massive success in west as well. Million or two million copies sold at least to western market for new studio in freshly launched IP is nothing to scoff at.

It really tells you that buyers of games do not really care about stuff journalist talk about. It really has rather little affect on their purchasing decisions. And that is really what should matter when you are trying to sell something.

Yes it is and it is not the first time having such contigency plan.

Quite recently there was a Soyuz with crippled cooling and the contingency plan for the American astronaut that came with it was to evacuate via Dragon if there was an emergency before new Soyuz arrived.

Do you realize that 10 F9 flights means 10 new second stages and on those second stage someting has to sit and that something whatever that is - is completely dwarfed by ISS and it would have to be a new dedicated vehicle consiting of mostly fuel just to deorbit the sucker in one go.

Original plain AFAIR was to use several Progress vehicles.

And going to graveyard orbit with something like ISS is not just a few whole times more difficult but at least an order of magnitude more.

I use window manager for tabs as it should be. No need for some stinky multiplexer.

I think it's unfair to label tmux "stinky".

It is slower, that's true, but so many times I've had to restart my terminal or I've quit it accidentally and tmux has saved my bacon.

Performance is adequate (for me), it's cross platform and gives me multiple cut/copy buffers.

There does not seem to be any release tag or branch nor production gerber files.

I was hoping to get my hands on some functional DVI/HDMI controller. Well never mind, I'll wait.

rtic-rs

Wake me up when it can do precise 400led 2D mapping under 10seconds and even not be picky about ambient lighting conditions at all like Twinky.

What is the point of posts like this?

What’s stopping you from putting in the effort into an open source system so it can compete with a feature set of a closed source commercial product?

I completely agree. Whether grandparent meant it or not, that language gives an entitled vibe which doesn't fit for open source projects.

I'm super curious about this. I recently tried a one day install with twinkly on a boat and the LEDs were too far away and moving too much to map with my phone. I was thinking about how I would do it differently, maybe with some manual work. Do you know any exciting open source work in the space?

So much this. It seems to detect any bright spots as LEDs. It should make a difference of the current frame with all-leds-off frame and then detect the LEDs.