The 12900K MSRP is $589, the AMD 5950X MSRP is $799.
4,272 karma · joined November 3, 2013
That's nuts. Why isn't it the case that the person who failed to properly vet the seller is out of £131,000 and the house? So I can "buy" a local mansion and then say "oops, I didn't know this random guy didn't own it. Oh well."
Off the top of my head: Complete remote state. Open vscode.dev on your desktop, work for a while. Then open vscode.dev on your Macbook Air later, and be in _exactly_ the same state. I don't mean, the same project, I mean the text cursor is at the same position in the same file with the same set of tabs open.
Need a GPU for some CUDA work? The only question is how many GPU cores would you like.
Could your next engineering hire's onboarding guide be: open vscode.dev/company/workspace, click the "run all tests" button. OK, you're done, please pick the topmost "ready to start" ticket from the queue.
Long-term strategy? https://www.businessinsider.com/facebook-allowed-fraud-hacke...
The advanced programmer simply writes "type Ensure<T, K extends keyof T> = T & { [U in keyof Pick<T, K>]-?: T[U] };", thus removing the need to copy the property.
The master programmer copies the property definition.
GitHub Actions tokens are scoped to the single repo they operate in, so for anything that you need covering any cross-repository or org access the official docs immediately tell you to just use a PAT instead. But PATs have no repository scoping whatsoever, it's all or nothing. So although both PATs and GHA Tokens have these complex scope requests, it's completely missing the most basic use cases in my opinion, like creating a PR in repo X, allow installing a package from GitHub Packages in repo Y, check out code from repo Z etc. You either go full mono-repo for everything, or you use PATs for everything with no repository boundaries at all, yikes.
It's perfectly OK to have a completely separate Terraform project that just configures the DB initially (or even manually, I see lots of places running DB's that predate Terraform with immutable infrastructure for everything else), and applies minor non-destructive changes in the future. This way you get the benefits of IaC, but the DB plan doesn't participate with the rest of your infrastructure that IS ok to blow away and re-create at will.
BTW, Amazon RDS backups work the exact same way: Destroy the database and the backups are also destroyed. Therefore, same region automated RDS backups are fine for day-to-day, but in a true "DB goes poof" disaster you should expect that you WILL lose them too! You need cross-region, or even better, cross-account DB replication or snapshots to survive this.
Company teams where the buyer isn't also an user is the only way this is going to make any sustainable money. Sell an MDN Plus Teams and Enterprise flavors as upgrades to the free "hobby" variant, and market it as table-stakes that every valley dev team has an MDN Plus subscription, same as they have a paid GitHub account, because what kind of crappy outfit are you even running here if your devs don't have MDN Plus access day one? MSDN used to be 4-6 figures for teams of various sizes, so asking developers how much they'd be willing to pay doesn't really tell you anything, I'd be surprised if developers know what their GitHub hosting, CI, etc. is priced at.
Some additional good reading https://www.mymoneyblog.com/tether-stablecoin-risk.html
Here's a good write up of the recent disclosures and the bag of shit that is Tether's reserves: https://www.mymoneyblog.com/tether-stablecoin-risk.html
"Instead of 100% risk-free, short-term, liquid assets, Tether is less than 7% risk-free, short-term, liquid assets. Commercial paper? Backed by whom exactly? Fiduciary account? At which remote offshore bank owned by a third-party? They could be pointing to a half-eaten sandwich and calling it collateral."
You can also enforce usage of YubiKeys, but you can't really enforce every developer sets a passphrase on their locally generated SSH key file.
And it's a convenient, and consistent way of authentication: Your work Google Workspace account uses and enforces a YubiKey, your AWS account login uses and enforces a YubiKey, and now your GitHub account also uses (but cannot not yet be made to enforce AFAIK) a YubiKey. It's less hassle than using one-time codes with fifty-seven different apps and cloud environments, so there's not much user push back.
With the -sk keys, you no longer need to install any software (gnupg, pinentry, yubikey CLI etc.), or run gpg-agent which has always had reliability issues etc. It should all Just Work out of the box now. GitHub was the last piece of the puzzle for us, and for example I can now change our team's onboarding docs from "follow this long OS specific guide to setup SSH w/ gnupg and ykman" to "run ssh-keygen -t ed25519-sk".
There's some confusion in this thread, but you can use ssh-keygen to generate either a public and private key pair, with the private file being a stub and the validation still happening on your physical YubiKey, OR you can omit the private key stub entirely with "-O resident" option to ssh-keygen allowing you to add your key to your ssh agent on any machine you plug it in (for good and bad).
The app will display exactly as the provider intended, all compatibility issues will be eliminated, and the performance will be entirely uniform and in the provider's control, provided by AWS, Azure and Google Cloud. Stadia for gaming is OK, but Stadia for Adobe Creative Cloud, Figma and Visual Studio is much more interesting, coming to your browser tab soon.
You can step through the program, reason about what's going on, tracking values as they change. But if you missed the moment, you have start again from the beginning (time traveling debuggers being rare). Or maybe you're looking at the wrong part entirely at this stage, and just wasting time.
With print debugging you write a bit of code to test a hypothesis. Then you run it, and you keep running it, and especially if it's an UI program you play with the UI and see how the values change during that run. Ideally the loop to change the code -> see the result should be a few seconds.
You can then git commit or stash your prints, switch branches and compare behavior with the same changes applied. And at the end of the day if you walk away, your prints will still be there the next morning. The debugger doesn't produce any comparable tangible artifacts.
Once you do know where the problem is, and if it's not apparent what the problem is (most problems are pretty trivial once located), that's IMO the time to break out the debugger and slowly step through it. But the vast majority of problems are faster to solve through rapid iterative exploration with prints in my experience (C, C++ for over a decade, Python, now JS/TS).
The only way to even download the app is if you already knew about it's existence before. It's not a dark pattern, it's just directing people who sign up for 1Password today into their actually supported product instead of the end-of-lifed one. Your app will continue to work for some reasonable amount of time until some version of macOS breaks it, then you can either pick another one from numerous competitors or go with their hosted version. Sounds to me like you'll need look into the alternatives given your requirements. It is what it is, no need to attribute it to malice.
In my opinion, it's not a dark pattern, it's just softly winding down the old app. That's not an unreasonable thing to do. If you want a traditional app, there are other choices.
- First add a security page, I need to know you're doing basic things like encrypting the data on your end etc. Hopefully you're using at least something like KMS for your at-rest encryption (all DBs and disks) if using AWS.
- Then also publicly state on the security page something to the effect of "No Pry employee has the ability to access customer data without your explicit approval, and all access is audited". Meaning, if you need to work a support case for some customer, you have to ask them before you look at their data, and you have to track when this access occurs
- Ultimately you'll get something like a SOC2 cert to show that you actually have these controls in place that you say you do
I think with this, you'll be able to overcome some of the fears. Native apps is a shrinking market and a distraction for you IMO. Your customers are already fine with cloud solutions, since they're using Quickbooks Online, Xero etc. by definition, you just need to convince them you're trustworthy as well.
In general the AWS support has been great. In many cases, they've forwarded our requests to product teams who have even fixed bugs we've run into and contacted us directly.
Our other experience is with paid Azure support, which did little else than direct us to the (not related to the question) docs. They also had a really hard time understanding our technical questions about specific APIs. To their credit, they did eventually escalate to the PM of the service in question.
In general, the team responsible for the service really must be able to help out with support requests. In AWS this is definitely the case, in Azure as well but there's a bit of gatekeeping. Does developers and PMs in GCP participate in support?
Mr. Srinivasan said they could not let that kind of story gain traction.
“If things get hot, it may be interesting to sic the Dark Enlightenment audience on a single vulnerable hostile reporter to dox them and turn them inside out with hostile reporting sent to their advertisers/friends/contacts,” Mr. Srinivasan said in an email viewed by The New York Times