From what I've understood of this - it's transpiling the x86 code to ARM on the fly. I honestly would have thought it wasn't possible but hearing that they're doing it - it will be a monumental effort, but very feasible. The best part is that once they've gotten CRT and cdecl instructions working - actual application support won't be far behind. The biggest challenge will likely be inserting memory barriers correctly - a spinlock implemented in x86 assembly is highly unlikely to work correctly without a lot of effort to recognize and transpile that specific structure as a whole.
steventhedev
joined 2 years ago
I have worked remotely on and off for years. Having a physical separation between the space where I work and the space where I play is an absolute must.
Beyond that - the hardware needs for development and gaming are wildly different. If you want something that's going to be good at both, you're going to either going to have to spend a lot of money or compromise heavily on quality.
I'd strongly recommend against it. Nothing to do with specs or viability but psychologically you'll want to play games - they're enjoyable. You can work around that in a few ways: only use the keyboard/mouse for dev work, only play games outside the workroom, etc. it will still take a lot of self discipline, but it's nothing compared to having a different OS, physical machine, etc.
In terms of specs - if it can run vs code, you can use the remote development plugins to run things on a beefier computer if you do heavy data work, etc. I don't know if it will do video editing though.
Seriously though - JIRA isn't always a massive pain in the ass. It's just the way it's used that sucks. Workflow restrictions so devs can't move tickets from testing back to in progress, dozens of mandatory fields, etc.
When your tools start dictating your workflow rather than the other way around then it's time to switch tools.
Friends don't let friends use JIRA
Stripe is a company that operates within the US and are subject to US law. The US passed a law that says that RT is subject to comprehensive sanctions. That means that it is now a criminal offense for any US company or person to do business with them. So Stripe doesn't have much choice and has to immediately stop doing business with RT. In the actual announcement, African Stream is called out by name. No proof needed because they are explicitly added to the list of sanctioned entities, and can enjoy being cut out of doing business with any company with a US or EU connection, just like ISIS, Boko Haram, and the PFLP.
Context: https://cyber.fsi.stanford.edu/io/news/african-stream
tl;dr - They're a front for RT, and subject to comprehensive sanctions
AJ opinion articles back with another spicy take! Where the facts don't matter, and the only important thing is to hate on Israel.
I suppose they'll claim that Nasrallah's speech isn't a declaration of intent to commit ethnic cleansing - after all, it's not a war crime if it's against ~~Jews~~ those dirty Zionist pigs!
That is a valid reason to move to Scotland
I have either written or gotten a variant of every single one of these comments 🫠:
Please include the JIRA task in the commit title.
Did you run any manual testing?
Where's the PRD link in the commit message?
Can you please split this into multiple smaller commits?
Can you combine these two commits?
Did you email Jon about this because he's working on that project with Sarah and you might be duplicating efforts.
This should be named BarFoo instead of FooBar.
Why aren't you using CorporateInternalLib16 that does 90% of this?
Why aren't you using ThirdPartyPaidLibByExEmployee?
Why aren't you using StandardLib thing you forgot existed?
All our I/O should be async.
All our hot loop code needs to be sync.
This will increase latency of NonCoreBusinessFlow by 0.01%. can you shave some time off so we can push in feature B also?
Please add a feature flag so we can do gradual rollout.
What operational levers does this have?
Lgtm - just address those comments
I thought FAT binaries don't work like that - they included multiple instruction sets with a header pointing to the sections (68k, PPC, and x86)
Rosetta to the best of my understanding did something similar - but relied on some custom microcode support that isn't rooted in ARM instructions. Do you have a link that explains a bit more in depth on how they did that?