dljsjr

MCU -> Microcontroller. Low power, less RAM, limited MMU/memory protection features, typically run baremetal firmware or an RTOS. Usually so simple it only needs a single voltage rail. More or less self-contained. Has RAM and ROM on-die.

SoC -> System-on-a-chip. Actually a very vague term. But in broad strokes, an SoC is what it says: An entire system on a single chip. Could incorporate an MCU or an MPU, plus other peripherals, etc. You can almost think of it as a "single chip computer" as opposed to a "single board computer". It's almost more of a marketing term than an EE term. For example, the Apple Silicon stuff is a "SoC" because it has the MPU + GPU + RAM on a single die.

You could also rotate the root password every time there's a departure from the teams that have visiblity if it's that big of a deal.

RE: Sharing.

Nobody should be sharing a password manager account. If this is happening it usually means somebody doesn't want to pay for the seats to have individual accounts. You give each user their own account, and if you need more than one admin, you have more than one admin, but you shouldn't be sharing an admin account.

This would also apply if you're not talking about the pw manager's master password but something more like an AWS root account. That root account needs to exist, but its credentials should be a secret in the password manager vault that is shared with anyone who needs it (based on roles/access rules/principle of least privelege), and you should create additional administrative roles within the system you're securing instead of leveraging those root credentials (as much as possible) operationally.

RE: Bad actors

SSO is the answer here. You use a password manager with SSO integration, and you cancel the person's account the second they depart. At previous orgs they literally cancel the account while the person is still in the building and being walked down the hall to be informed that they're being asked to leave. It's definitely on the cruel side but if you're concerned or wanting to emphasize the security of the data first and foremost, that's what you do.

Both parts of the answer above involve $$$. Most services require paying for a higher tier if you want SSO integration (both on the side of the provider like Google Workspaces and the tool like 1Password), and both require paying for head count.

But this is the answer to "best practices". If there's a financial impediment that prevents you from doing these two things, then you can't use the "best practices". That's the unfortunate nature of the beast, and why there are so many online disagreements about the concept of an "SSO Tax".

I don't know if that's true anymore, if only because the ongoing popularity of the Git Flow branching model; the `git-flow` tools use annotated tags by default for every command that creates a tag (e.g. releases).

†: Redis 6 added threads, but AFAIK this is only for handling connection I/O. Actual database access is still single threaded. The only way I'm aware of to scale Redis is via clustering.

>If you’re a conscientious engineer, you are probably going to find the above suggestions somewhere between counterintuitive and horrifying. You should! They are horrifying! This is how deeply capital’s war on workers is scarring our profession.

>These people are actively trying to take your wealth away from you and keep it for themselves. You need to protect yourself.

>Oh, yeah, we should also have a union. Sure. Let’s get on that one of these days.

They were awesome. When we were growing up most big family trips were in the car because gas and hotels were just so much more affordable than flying an entire family anywhere. I got to be the "navigator" on so many trips by helping family members read the Triptiks.

Apparently AAA still offers these, but they're generated digitally now via their app, and you can print them off if you want. But something about those human-built Triptiks were really really special.

I certainly don't love any corporations.

They might let other engines in, sure; but will they relax the restriction on their memory mapping entitlements to allow for optimizing JITs? Doubt it. Means you'll only be able to use alternative rendering engines that have JS interpreters with no optimizing JIT. Stuff like that.

For one, the JVM isn't sandboxed by default. WASM is. That adds additional overhead.

Another consideration is that the JVM uses garbage collection. This doesn't just apply to the code itself, it includes things like the hot code cache and stuff. The JVM trades throughput for latency. WASM doesn't have a GC model.

Lastly, WASM doesn't define the runtime. There is no JIT for "WASM", that's just a bytecode spec. I'm actually not even sure if when you run it in a browser it will JIT the WASM bytecode.

They're a US storefront but they ship internationally. They do a great job restoring consoles. And they have amazing customer service (one of the SNES Controller refurbs was a no-go and they cross-shipped a replacement with no expectation that I even returned the defective one).

I don't know if they have old computer stuff, mostly just consoles. They have Atari consoles sometimes though.

This necessitates force-pushing to your feature branch after all the fixup commits have been approved and then squashed. At that point you can merge the cleaned up feature branch in to your develop or trunk.

`--force-with-lease` is slightly better than `--force` because in the event that you're also working on a collaborative feature branch you won't overwrite any commits that somebody else pushed up that you haven't fetched yet.

Looks like it works on quite a few systems including Android and iOS.

See the section "Always On VPN": https://support.apple.com/guide/deployment/vpn-overview-depa...

Is it dubious that Apple doesn't let VPN apps do this as well? Maybe. But this is known and documented.

They are far from the only implementation, though. You can find links to other runtimes in other comments here already.

Additionally, there are people in robotics who like to say that simulators are like lightsabers, you haven't become a true Jedi until you've built your own, so there's a lot of home grown physics simulators in robotics.

[1]: https://en.wikipedia.org/wiki/Featherstone%27s_algorithm

For example, Horizon: Forbidden West uses a custom physics engine that started out as one of the core dev's fun side projects: https://github.com/jrouwe/JoltPhysics

Physics engines (at least game quality physics engines) are starting to drift in to "solved problem" territory and there's enough literature now that you can get something reasonable going yourself after doing some weekend reading.

Edit to add: Godot has had its own engine available for a long time, so it's not a totally new effort. It's a heavy refactor and a large improvement but the bones for this were laid years ago so some of that technical debt you're describing has already been paid down.

Being a viable console target will attract more creators and increase the chances of that happening. As laid out in the blog post from my original comment, while Steam is a hotbed for indie games most of them toil in obscurity. Most of the money in indie games is on consoles now.

Juan shared a blog post about the state of console support in Godot shortly before the launch of W4 that gives some more insight: https://godotengine.org/article/godot-consoles-all-you-need-...

Often time folks say that what Godot is missing is a "killer app" that shows that the platform is viable. I think that this could potentially go a long way towards that.