89 karma · joined July 12, 2015
main.js:145 Myth browser startup failed Error: WebGPU adapter was not available. at Module.initialize (foster-webgpu.js:400:9) at async main.js:61:3 (anonymous) @ main.js:145 main.js:146 Error: WebGPU adapter was not available. at Module.initialize (foster-webgpu.js:400:9) at async main.js:61:3
- The rules of signed/unsigned are complicated and there is too much auto-conversion - does that mean languages that make this more explicit means this is fine? It just seems ideal to have stronger typing. - It is mentioned that you can initialized an unsigned int to "-2" - but that presumably could also be fixed in the language.
I'm trying to separate out which is "don't do this in C/C++" and which is "don't do this in any language".
In my case, it built a tool for splitting sounds and a tool for defining hitboxes for a game. Tools made exactly for more workflow. Wild times.
I wonder if for closed-source apps if governments can not just force the key collection the same way they would force decryption with centralized keys.
"If user = foo, then send the on device keys elsewhere"?
Or if those keys are part of a TPM, then a software update that just asks it to send in the decrypted messages?
Can judges not order this now, but can order decryption if the keys are stored centrally?
And having less people involved means there is much less communication and alignment.
Not to say it's a panacea.
The database is more complex since there is storage affinity (I use cockroachDB with local persistent volumes for it) - but stateful is always complicated.
Very cool!
At some level, it's like they become your edge router.
Perhaps with a concrete example with and without your product.
I never found this very compelling. What is main in that world is not the source of truth, and it's rare to have a system atomically in one state or the other - but normally there are progressive rollouts. And if you ever need to rollback in production, I assume no one is changing where main is.
> I like the opportunity to force a second set of testing, and code review. Especially if the team is big enough that you can have different people doing code review for each branch.
To be explicit for code review, do you mean there is (1) main, (1) development, and then a bunch feature branches - and that there is review when merging into development and main? Having a two-tiered review process seems extremely difficult to do - versus just having more reviewers on the first merge - especially dealing with merge conflicts and needing to merge again into development.
> You can also have your CI/CD do longer more thorough testing while merging to main vs development.
I think it's fair to do more testing later. I think the equivalent I'm used to (which is pretty close, so not a huge difference), is only building releases from the commit that passed the bigger/slower tests.
But also, assuming there are multiple deployments coming from one repo, if you block merging into main, that means you'd be blocking on all tests passing - while release branches for a given product can select a subset of tests when deciding on release candidates.
> If it's a project with a single deployment, version tagging is kind of pointless, it's much easier to just use a branch to reflect what is live, and roll back to a merge commit if you have to. Then you can still merge directly to main in the event of a hotfix.
I think it's worth maintaining the flexibility of how many releases come from a repo. Needing to fork repos just because you want another deployable release in the future seems painful to me.