dljsjr

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:

https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user_s...

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.

Posted two days ago: https://news.ycombinator.com/item?id=37124639

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.

This is amazing! It's exactly how I remember them in my head!

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.

Would ruffle + WASM + Electron work? https://ruffle.rs

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.

Okay, "I love Apple Products" then.

I certainly don't love any corporations.

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.

When you work with a rebase-oriented workflow, it's very common to submit a PR for review and then address incoming review comments as fixup commits: https://blog.sebastian-daschner.com/entries/git-commit-fixup...

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.

https://github.com/e-dant/watcher/blob/989147b183ee0547d71a1...

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

It's written that way because the target audience is enterprise IT folks who are managing fleets of employee devices, but you can freely use MDM profiles as a consumer. It's certainly not user-friendly which is why I commented that the way it works for VPN clients installed as apps could be seen as a dubious implementation.

Always-on VPN that tunnels everything requires MDM commissioning. It's documented by Apple.

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.

The Bytecode Alliance is a nonprofit group with members from all over the industry working to provide what is ostensibly a reference implementation of a WebAssembly runtime w/ full WASI support. Wasmtime is their implementation.

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

Lots of simulators for robotics use ODE or Bullet, actually, and they're quite good for lots of things that you might want to simulate. But there are some people who would argue that they aren't the best for it, especially for simulating legged locomotion, because of the way physical constraints such as joint limits are enforced (via Lagrange multipliers). A popular alternative formulation is Featherstone's Method[1], which is becoming more widely available and goes by other names sometimes; for example, Rust's `rapier` physics engine refers to this type of dynamics model as "reduced coordinates" (they don't yet support it, but it's on their roadmap). Featherstone's method is becoming more popular but it's still not widely used in a lot of physics engines because most physics engines are targeting games and Featherstone's doesn't always have the best performance characteristics, instead favoring physical fidelity. Bullet can run using Featherstone's Method, by the way. One of the few FOSS engines I know of that supports it out of the box.

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

A few years ago, as someone who has worked on physics engines for robotics simulations, I would have agreed with you. But now a lot of people are doing greenfield physics engines for games and having it work out pretty well. There's a ton of established academic and conference literature in the area now and it's not nearly as scary as it used to be.

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.

Simple Storage Service (3 S's).

By "killer app" I meant a really amazing game made with the engine that makes people stand up and say "oh hey Godot is legit".

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.

W4 Games's CEO Juan Linietsky is the creator and lead dev of Godot. Their primary mission, from my understanding, is providing the non-open-source tooling and support that's needed to make it feasible to use Godot as an environment for developing console games. The SDK's and their APIs cannot be included in the FOSS Godot code directly.

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.

Clicking on "Licensing Information" and drilling down a few more links gets to the meat of what this is[1] (TL;DR: It's an archive of a Creative Commons licensed edition of an undergrad college text book. For those wondering who the target audience is: undergrads):

What is this?

First off, this is not the website for the original publisher. Instead, this is the archive of a small project by aschmitz to archive Creative Commons-licensed copies of all the books which were available online from a specific publisher at the end of 2012. (That publisher has asked to remain unnamed here. For more information, see the attribution page.)

That publisher is a textbook publisher, focusing on (mostly entry-level) college textbooks. From their beginning until the end of 2012, they licensed all of their books under a Creative Commons by-nc-sa 3.0 license, allowing anyone who so desired to copy them, give them away, or modify them, as long as they acknowledged the authors, released the copies under the same license, and didn't do so for commercial gain. This was an unusual model, but they hoped it would work. (They sold access to additional study materials, as well as copies of books that would fit well on e-readers.)

In late 2012, they decided that the process of giving away access to their textbooks online wasn't working, and decided to switch to a different model, requiring students to pay for access to the books starting in 2013. (At least initially, these fees ware rather cheap compared to normal textbook prices, but still not free.)

Because the books were still available under a Creative Commons license at the end of 2012, I downloaded them to have copies known to be available under a Creative Commons license. I then repackaged them so that they are available outside of the publisher's website, and can be used by anyone under the terms of their Creative Commons license.

[1] https://2012books.lardbucket.org