vvanders

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.

From what I recall the PS3 devkit was significantly larger than 1U so it's not that uncommon.

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.

Fear and a scarcity mindset, many people treat things as a zero-sum game when in practice the sum is usually greater than the individual parts.

The advice in the article is great, and much of it resonates with what I have seen over my career as well.

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.

Yes, this is lost in most discussions when it comes to DSOs. Not only do you have the complexity of versioning and vending but also you can't optimize with LTO and other techniques(which can make a significant difference in final binary size).

If you've got 10-15+ consumers of a shared library or want to do plugins/hot-code reloading and have a solid versioning story by all means vend a DSO. If you don't however I would strongly recommend trying to keep all dependencies static and letting LTO/LTCG do its thing.

Sure, that's "technically" correct but most usage of Lora is going to be in ISM since that's where they are traditionally deployed. That doesn't require a license which can be a hurdle if you don't already have one.

I've got a ham license so not a big deal for me but for those wanting to try radios without a huge investment a pair of $20 Lora AT serial radios are a great way to dip into digital radio.

Meshtastic(Lora) also doesn't require a license since it's in the ISM bands.

Lora also has really good FEC and other things that make it work incredibly well(at the cost of throughput). Honestly I wish we saw more things like that in the ham bands(other than FT8).

There's a couple Lora radios out there that are USB serial based and can be controlled with AT commands that would let you so something similar if you want to build up from scratch.

Even with the vendor libraries last time I had to poke at a CAN bus I ended up having to go to that same level because the C helper libraries omitted key features of the interface.

There's a number of micros these days where the same libraries are provided using SVD[1] that will generate interfaces which is handy.

[1] https://docs.rs/svd2rust/latest/svd2rust/

Not just torque, traction too.

VFD AC motors will intrinsically self-correct for overspeed when static traction slips and starts going into dynamic region (due to the frequency being slower than the slip/overspeed) and re-enter static friction region. DC or ICE will react to the lack of traction by turning faster as you hit the dynamic friction region and "spin out". Traction control is always reactive and lags behind. Last I read the difference in traction on rail for AC vs DC was on the order of 50%(!).

It's also why EV cars have stupidly awesome traction in adverse conditions under acceleration, trains had been perfecting that technology for decades.

Fuck.

I had Bruce as a teacher in one of our early CS classes at college, he showed us all sorts of black-magic performance tricks(at least as it appeared to us at the time) and that curiosity in wanting to understand the how/why played a large part in where I am today.

I don't know if it's any consolation but I know he had an outsized impact on a number of us back then.

Android has a surprising amount of core OS functionality in boring managed Java code. ART/Dalvik are quite impressive combined with a few other clever tricks to make a system that ran in a pretty small footprint.

I've built games in the US where we specifically avoided certain features(if I recall correctly around minigames on loading screens) because of those concerns. We never got to find out if they were enforceable but they certainly impacted how we build the title(which never really had a material outcome, the game was doomed for other reasons).

This is giving me strong How to Talk Minnesotan vibes[1] (in a good way :D).

[edit] 10:50! https://www.tptoriginals.org/how-to-talk-minnesotan/

[1] https://en.wikipedia.org/wiki/How_to_Talk_Minnesotan

Can? It always has been :).

We ran Lua for the entire core of a game in a 400kb preallocated on the PSP about 20 years ago. I know of many places that used it long before us.