MPU -> Microprocessor. MPUs typically have features that let it support a "full" OS; MMUs, speculative execution, advanced CPU pipelining features, etc. They also have a much higher RAM capacity. Often has more complicated power requirements when doing board design due to needing different voltage busses for different peripherals. Usually can't be run standalone, you have to bring some of your own peripheral hardware. For example, you usually need to bring your own RAM.
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.
If you're not using an MFA mechanism attached to your SSO (Google Authenticator or Okta or something) then that's a completely separate issue. There shouldn't be that much risk in letting all of your SRE's have access to the root credentials; you can lock down who can see what in your vault based on roles for any PW manager worth anything.
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.
Others have already mentioned that you shouldn't be sharing a master password, and that's definitely true. I'll try to answer the question more holistically:
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".
EDIT: Lots of comments about sharing the root passwords in general. I made a few assumptions here that I thought were implied but outside of the direct scope of the question, so I'm going to add them here.
- MFA should be required, full-stop, and it should be provided by something connected to your SSO. Okta or Google Authenticator, or even better if you use hardware keys like a Yubikey. There's still risk in having shared access to the root account credentials but this helps mitigate it, as even if the person takes the password with them it'll be much much harder for them to use it.
- Password rotation. That's an obvious one. Just change the paswords every time there's a departure.
- Clarification on role-based access. With shared vaults on enterprise/team plans you can restrict who is able to actually see the items once dropped in to the password manager. You shouldn't expose the AWS Root Account to the whole org. You should expose it to whoever actually needs it, and you should use it as little as possible, that's what was meant by this statement:
> you should create additional administrative roles within the system you're securing instead of leveraging those root credentials (as much as possible) operationally.
As an example, here are AWS's guidelinesn for securing the root account:
Most of them get distilled down to "don't actually use the root account for anything unless absolutely necessary, and share it with as few people as possible", with nuggets such as:
1. Don't create access keys for the root user
and
2. Never share your root user password or access keys with anyone
The idea being that even though this account needs to exist, you should be providing access at the individual level with the necessary permissions instead of relying on the root credentials at all.
> Many people are only aware of the default lightweight tags
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).
How is it misleading when the whole point is that Redis can only be single threaded†? That's why Dragonfly (claims) to scale better. If anything, it's the Redis rebuttal that comes across as misleading; the posted announcement is very up front that Dragonfly's value proposition is that you get vertical scaling for free without having the additional ops overhead of a Redis cluster, which is very much not free in terms of maintenance and opportunity cost.
†: 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.
This is exactly what the article says to do. I also paused at that section that listed all those crazy things, if you power through and get to the end you'll find this:
>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.
Anybody remember Triptiks from AAA? You'd go to a AAA office or call them on the phone, tell them where you were going, and in return you'd get a printed spiral top-bound pad with your trip broken down in to multiple legs, the roads/routes pre-highlighted, gas stops and prices estimated in, a list of sites for stopping off at, etc. All human curated and human annotated (the roads on your route were literally gone over by a person with a Highlighter). I'm sure it was all pulled from some sort of centralized/normalized/standardized data source but the human touch was definitely there.
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.
That is not even remotely close to what this article is about. Tweetbot is the name of an extremely popular iOS Twitter Client. This article has nothing to do with bots, at all.
Alexa also had a 4-year head start on the HomePod. I don't know if that's the most apt comparison. Additionally, while it is an absurd price tag, the rumors are also that this is being aimed at Apple's famed "Creative Pro" segment and not gamers/casual VR users.
Caml 1.0 was released in '85 and OCaml (the O is for Object Orientation) was 1996. Multithreading wasn't a high priority for anybody back then. The JVM didn't even have threads until 1997 and those threads were green threads, OS threads came to Java later.
As the other commenter said it's not a LAN issue. Z-Wave is a mesh radio protocol totally independent of the LAN. There are in fact issues with older Z-Wave specs and versions bogging down due to congestion.
I love Apple but I also know that in these situations where they're being forced to punch a whole in their walled garden that they'll usually just go about making the solution as shitty to use as possible.
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.
The JVM has a ton of different things going on, it's not an apples-to-apples comparison.
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.
I don't know if it's device specific but I use "Hey Siri, turn on the overhead lights and the floor lamp" for example all the time. I have a HomePod though.
It's only about 60% of what you're asking for but I'm a fan of DKOldies: https://www.dkoldies.com
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.
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.