Sounds like a great way to have outages because you can’t tell what legacy features are still in use or not. Or even worse, not being able to ever refactor or clean up because you have no means to discover your dependencies.
I use GCP, but it also has the idea of a metadata server. When you use a Google Cloud library in your server code like PubSub or Firestore or GCS or BigQuery, it is automatically authenticated as the service account you assigned to that VM (or K8S deployment).
This is because the metadata server provides an access token for the service account you assigned. Internally, those client libraries automatically retrieve the access token and therefore auth to those services.
Not game dev related, but I program in both Go and Python, and there really is no difference in my feedback loop / iteration because Go builds are so fast and cache unchanged parts.
I also have to run Defender on my MacBook at work.
If you have access to the Defender settings, I found it to be much better after setting an exclusion for the folder that you clone your git repositories to. You can also set exclusions for the git binary and your IDE.
There are two solutions GitHub Actions people will tell you about. Both are fundamentally flawed because GitHub Actions Has a Package Manager, and It Might Be the Worst [1].
One thing people will say is to pin the commit SHA, so don't do "uses: randomAuthor/some-normal-action@v1", instead do "uses: randomAuthor/some-normal-action@e20fd1d81c3f403df57f5f06e2aa9653a6a60763". Alternatively, just fork the action into your own GitHub account and import that instead.
However, neither of these "solutions" work, because they do not pin the transitive dependencies.
Suppose I pin the action at a SHA or fork it, but that action still imports "tj-actions/changed-files". In that case, you would have still been pwned in the "tj-actions/changed-files" incident [2].
The only way to be sure is to manually traverse the dependency hierarchy, forking each action as you go down the "tree" and updating every action to only depend on code you control.
In other package managers, this is solved with a lockfile - go.sum, yarn.lock, ...
I prefer “—really-do”, so the default behaviour of the tool is to do nothing. That’s more fault tolerant for the scenario you forget to add “—dry-run”.
I agree with the CEO, while also feeling a bit nauseous at the MAGA Musk suck-up at the end - I suppose this is the game you have to play with this current administration.
Not everyone has the same threat model as you, $BIGTECHCORP.