gapo

I’m on the Tauri + rust train ( for the first time ) too for the next product I’m leading. I can certainly see the benefits - will know in a few years how things end up.

At the risk of sounding like an ancient dinosaur- It’s not as much a feature parity but more of a maturity/ecosystem parity. I’m pretty sure rust and soon even zig are going to more than good enough. But as someone running a multi person team - it’s way easier to hire / consult on the existing Dino technologies.

As a counterpoint to a lot of the comments on this now portraying this as dated and questioning the stack behind - this is has the guts of great enterprise level software. Once you’ve serious data being thrown at something built on JS and run into OOMs, that’s when good old C(rust in the future maybe) stack shows these up.

Love to see such a strong tasteful take on software heralding back to the age of solid desktop apps.

So this is what they were burning their cash on. Quite a few people did suggest this.

Interesting to see the min requirements. If they manage to bring that down further - this could be a huge turning point .

Very well executed and built ! Great example for what agentic coding can enable for projects run by someone with good 'taste' !

Thanks for sharing

This was very well thought out and written.

Surprised they’re pivoting from the harness to the agent compute ? Now. Always thought they were a great harness fwiw

The hero we don't deserve.

Sign in with Google" = Not happening.

Real-time linux can be thought of taking vanilla linux - configuring the kernel in a certain way, booting your kernel with certain boot params and writing your real-time application in a certain way.

While there quite a few hiccups along the way - you will be able to bring down jitter or OS noise to around 1 us. Of course a microkernel based OS like QNX can take you down to around 1 ns - but then the point of using Linux is that you are able to utilize the ecosystem around it.

Look into isolation, real-time patch and high performance computing.

From the commit msg:

At this point I consider being permission-less the limiting factor: if broad "read/modify data" permission is to be used, than there is not much point for an MV3 version over MV2, just use the MV2 version if you want to benefit all the features which can't be implemented without broad "read/modify data" permission.

Feels like the author was frustrated with agile and took it out in the guise of yocto engineering champion.

Where do people see RISC-V heading in the future ? With ARM arch solidly entrenched in mobile and embedded - is there space for RISC-V ?