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.

For auditing real-world behavior, some USB-c cables (and interposers) have tiny displays to report live voltage/current.

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).

Nice, thank you

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.

Indeed, I'm biased but often the arguments in favor of shared objs have fundamental misconceptions that betray a lack of lower-level tinkering that makes it hard to take seriously.

The same can be said for any position in this debate.

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.

This isn't true, it is not exclusive to the ISM bands. You can run it on any band you choose so long as you have a license to do so. Case in point: the ham bands

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.

Note that various ham bands have limitations on what types of emissions are allowed. For example some only allow RTTY and data, so no phone or image. And some allow phone or image but no data. Even if the type of information is allowed there might be technical restrictions prohibiting some forms of modulation.

So before using something that was designed depending on some non-ham part of the regulations for its legality, such as part 18 (ISM) in the US, on a ham band I'd want to look into the details and make sure it is not doing something under that part but not allowed under the ham regulations.

Also, the ham bands as a whole cannot be used for profit-motives or any financial gain. People often forget this rule. Not to mention the (kind of absurd, IMO) rule against any form of encryption.

Encryption is permitted for remote control of space borne systems.

Repeaters may use any method to limit access and control to authorized users.

I forgot about that one use case. But it's not allowed for most practical purposes in the U.S. at least.

almost every single repeater I know of uses this method for remote control. I even remember listening to someone sending long strings of high speed DTMF, presumably to try and brute force control of the repeater. One of the managers said they weren't successful

However, I don't believe there's a rule against steganography.

In the US, there certainly is. The rule doesn't mention encryption specifically, it just prohibits "encoding for the purpose of obscuring meaning". The intent is what matters not the method.

would oblivious transfer qualify as OK? if the sender provably doesn't know what's transmitted, will the law rule it a form of obscuring meaning?

You're thinking criminal court standards, like beyond a reasonable doubt for a conviction.

It's a procedural thing. The FCC will tell you did it & tell you the penalties. Your options are zero.

Yes, the FCC would (theoretically) just revoke your license to prevent you from doing it again if they so wanted.

JS8call is pretty similar to FT8, but can do keyboard to keyboard chat. Not quite auto-mesh, but can store/forward through multiple other nodes.

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.

Thanks. It's not really a consolation, but it does give me some happiness.