As someone who's worked professionally with these engines I'd largely agree.
The other thing to keep in mind is that engines are build towards certain strengths/game-types. Trying to do open-world in UE3 required making some fairly invasive and substantial changes as the engine was built more for somewhat on-rails shooter. It didn't support geometry streaming and a number of other things that are needed to seamlessly transition between large open areas. I remember a number of MMO-style games used UE3 purely as a rendering front-end and mostly built the game tick, physics and netcode back up from scratch.
There are "tells" for engines if they aren't tuned properly(i.e. it was really easy to tell UE3 by the 30s frame hitch as the periodic GC ran) but a fair bit of that can be addressed if the team wants to put in the time to enhance or rework the systems involved.
I'm surprised to see someone putting forth the argument that templates are easier to use than macros. I've found the opposite and in many cases the monomorphization of templates to explode code size which has a fairly material impact on performance in my domains. Debugging macros with cargo expand is infinitely easier than debugging template errors.
While you can write high performance C++ my experience is that many people will reach for shared_ptr and their like while Rust will force them into proper structure/ownership as Arc and their like have a lot higher friction.
Look into dead reckoning vs lock step for networking. Lockstep requires determinism at the simulation layer, dead reckoning can be much more tolerant of differences and latency. Quake and most action games tend to be dead reckoning (with more modern ones including time rewind and some other neat tricks).
Very common that replay/demo uses the network stack of it's present in a game.
Multi app works pretty well too, when I need to cross reference between apps throwing them each up on the split halves is way better than swapping back and forth.
Flatbuffers lets you directly mmap from disk, that trick alone makes it really good for use cases that can take advantage of it(fast access of read-only data). If you're clever enough to tune the ordering of fields you can give it good cache locality and really make it fly.
We used to store animation data in mmaped flatbuffers at a previous gig and it worked really well. Kernel would happily prefetch on access and page out under pressure, we could have 10s of MBs of animation data and only pay a couple hundred kb based on access patterns.
One capability mechanism that's in wide use but not really well known or touched on in the article is Androids RPC mechanism, Binder(and a lot of the history predates Android from what I recall).
Binder handles work just like object capabilities, you can only use what's sent to you and process can delegate out other binder handles.
Android hides most of this behind their permission model but the capability still exist and can be implemented by anyone in the system.
That only applies when dynamic dispatch is involved and the linker can't trace the calls. For direct calls and generics(which idiomatic Rust code tends to prefer over dyn traits) LTO will prune extensively.
I think there is something to be said about having good defaults and tools that don't force you to be on every last detail 100% lest they get out of control.
It also depends on the team, some teams have a high density of seasoned experts who've made the mistakes and know what to avoid but I think the history on mem vulns show that it's very hard to keep that bar consistently across large codebases or disperse teams.
That assumes that people know what they're doing in C/C++, I've seen just as many bloated codebases in C++ if not more because the defaults for most compilers are not great and it's very easy for things to get out of hand with templates, excessive use of dynamic libraries(which inhibit LTO) or using shared_ptr for everything.
My experience is that Rust guides you towards defaults that tend to not hit those things and for the cases where you really do need that fine grained control unsafe blocks with direct pointer access are available(and I've used them when needed).
WDT patterns are highly underrated, even in pure software there's value in degrading/recovering gracefully vs systems that have to be "perfect" 100% of the time and then force user intervention when they go wrong.
One of my favorite blogs on the topic https://ferd.ca/the-zen-of-erlang.html that does a great job of covering how Erlang approached the topic, lots of learnings that can be applied more broadly.
I don't really see what having a "developer mode" offers here beyond the existing solution. The current mqtt is already locked down with a unique password and AFAIK the endpoint was read-only anyway.
Don't get me wrong I'm glad they're responding to feedback but the feedback shouldn't have been required in the first place.
I'm all for better security on products(esp ones that heat up to 300C!) but interoperability with open standards makes it a better product overall and given the direction we've seen in the IoT space I think they've done quite a bit of damage(even if not intentionally) by not taking more care in this area.
You could already talk freely to the MQTT on the printer and it was already secured with a unique password. This feels like making it a second class feature that could disappear at a future point.
Yeah that's a huge bummer if so, I've got both a HA automation that shows the printer status without needing to have an app installed and I've got a secondary filtration system that's fully automated which would be a PITA if I had to manage manually.
Totally understand if it's something that could change/break in future updates but the language about it being "exploited" is a bummer, you would think extending/documenting that would actually drive further adoption of the printers by building a more robust ecosystem around them.
You may want to refresh your familiarity with Rust, I haven't touched nightly in ages and much of what you mention doesn't really resonate with what I've seen in practice. Not saying the language doesn't have issues and things that aren't frustrating but in my experience unless you're going to go to the nines in testing/validation/etc (which is the first thing that's cut when schedules/etc are in peril) I've seen Rust code scale better than C++ ever did.
More tools in the C/C++ realm are always welcome but I've yet to see more than 50% of projects I've worked on be able to successfully use ASAN(assuming you've got the time to burn to configure them and all their dependencies properly). I've used ASAN, CBMC and other tools to good effect but find Rust more productive overall.
If your voltage matches one of the PD levels they work okay but many common voltages like 12v usually end up being very charger dependent. I've got one of the 12v pd triggers that on 9/10 of the PD enabled charges I've used just drops to 9v.
We absolutely pinned on consoles, anywhere where you have fixed known hardware tuning for that specific hardware usually nets you some decent benefits.
From what I recall we mostly did it for predictability so that things that may go long wouldn't interrupt deadline sensitive things(audio, physics, etc).
Games absolutely yield, even if the rendering thread tries to go 100% you'll likely still be sleeping in the GPU driver as it waits for back buffers to free up.
Even for non-rendering systems those still usually run at game tick-rates since running those full-tilt can starve adjacent cores depending on false sharing, cache misses, bus bandwidth limits and the like.
I can't think of a single title I worked on that did what you describe, embedded stuff for sure but that's a whole different class that is likely not even running a kernel.
This is probably one of many different types of surveys and other activities that DNR(or DNR adjacent departments) coordinates, it's fairly common to have volunteer lead programs like this for surveys or other activities. As others mentioned there's no shortage of work in understanding and managing a regional ecosystem, the people who take these jobs usually care deeply about the ecosystems and are not doing the job for financial reasons.
Rather than being cynical maybe it would be worth your time to consider volunteering and better understanding how these things are managed. You might be surprised to find it's usually fairly educated folks who care about making sure what we have today is around for the next generation.
The other thing to keep in mind is that engines are build towards certain strengths/game-types. Trying to do open-world in UE3 required making some fairly invasive and substantial changes as the engine was built more for somewhat on-rails shooter. It didn't support geometry streaming and a number of other things that are needed to seamlessly transition between large open areas. I remember a number of MMO-style games used UE3 purely as a rendering front-end and mostly built the game tick, physics and netcode back up from scratch.
There are "tells" for engines if they aren't tuned properly(i.e. it was really easy to tell UE3 by the 30s frame hitch as the periodic GC ran) but a fair bit of that can be addressed if the team wants to put in the time to enhance or rework the systems involved.