That's .NET Native, which is a completely different beast unfortunately. .NET Core is set to add support for ARM64 in .NET 5. Furthermore many .NET apps for Windows were built using WPF, which won't support ARM64 until .NET 5.
I was a bit surprised the article didn't mention Windows on ARM at all. Following the Apple announcement, I managed to snag a Windows laptop that uses the Qualcomm Snapdragon 850 ARM SoC for dramatically less than MSRP on eBay. (To be fair, they were selling it for parts since they couldn't figure out how to remove the password. Wiping the drive and reinstalling Windows was easy enough.) For the most part, it feels just like Windows. Every app I've downloaded has _just worked_. That being said, there's definitely at least one app that won't (Wireguard since it requires an ARM64 driver to work). I've actually been tracking which software provides an ARM64 version[1]. Sadly, it looks like virtually every toolchain still needs to update to support ARM64 on Windows. I'm tracking a handful of GitHub issues, and support is definitely in the pipeline, but it's slow going. For example, .NET _still_ doesn't support Windows on ARM, despite the fact it's the flagship way to build apps on Windows, and ARM64 Windows devices have been available for almost two years.
This is largely due to a limitation of Android itself. If your app wants to do any sort of background task that's not tied to Google Cloud Messaging, it needs to setup those background tasks. When your phone reboots, those tasks are cleared. Many apps use the "run at startup" permission to receive a notification from the system when startup has completed. It doesn't actually mean the app is running in the background.
Just a heads up that the WebKit team hasn't weighed in, and Mozilla does not intend to look at this specification at all in the near future. So this looks like another Chromium-only feature for the time being.
Android device manufacturers make their money when you buy a new device. Apple, on the other hand, makes money when you buy apps (in addition to making money on device sales I'm sure). They have an incentive to make sure that the latest OS runs on as many devices as possible, so that developers can release their apps to a wider audience, and so that Apple can make more money. Google wants apps to run on as many devices as possible, so that's why they bend over backwards to support older devices with their SDK. Samsung doesn't have any incentive to update the Galaxy S6 since that won't bring them any additional revenue.
> outside of the bay area bubble, android phones are used by the majority of people
It really depends on your market. If you're a parking garage in the US, about 60% of your customers are using iPhones (assuming your customer base is a perfect sample of the US at large, which is also not true). I can only think of a handful of instances in which a business type in the US would have a majority of Android users.
I'm a huge fan of using Lambda to perform hundreds of thousands of discrete tasks in a fraction of the time it'd take to perform those same tasks locally. A while back I used Lambda and SQS to cross check 168,000 addresses with my ISP's gigabit availability tool.[1] If I recall correctly each check took about three seconds, but running all 168,000 checks on Lambda only took a handful of minutes. I believe the scraper was written in Python, so I shudder to think about how long it would have taken to run on a single machine.
My main gripe with the cast iron is that it generates so much smoke (even with fancier oils like grapeseed) that I get a pretty bad headache. I guess my ventilation is just not up to par. I've been eyeing a portable induction cooktop to use outside, but my boyfriend just wants me to get a grill.
Have you done your steaks in the broiler? I usually use a torch since I find that in order to get the sear I want, I have to leave them in the broiler too long. I usually cook the steaks to 129 F, but I guess I could drop down to 122 F or something.
I search and copy text from GitHub at least a dozen times a day, so I'm not sure what you mean when you say search has been broken since November. As for the code copying, could you provide a bit more info on what's actually preventing you from selecting the text?
I really wish Microsoft would release a version of Windows 10 (the full version, not IoT) for the Pi 4 so developers could easily test their apps on an actual ARM device. Being able ship a Raspberry Pi 4 preloaded with Windows 10 to developers could bring a huge boost in the number of apps that support Windows on ARM.
I've tried to find a decent modern-looking Windows diff client, and have just settled for VS Code. It's certainly not perfect, but with a few extensions (mainly Compare Folders[1]) it's a workable solution for my needs.
Not to be snarky, but my initial response to this was "Large project that uses language known for memory safety issues discovers that most of their security bugs stem from memory safety issues". In a more serious note, I hope this motivates the Chromium team to invest more in Rust. While the other options sound like good "in the meantime" solutions, switching to a language that, at its core, is designed to prevent these sorts of issues would be a huge benefit to society as a whole considering that Chromium is the most popular browser engine in the world.
WebView2 isn't a replacement for Electron; it's a replacement for the Internet Explorer powered WebView component that's been a part of Windows 10 since the beginning. WebView2 doesn't have the same level of platform APIs that Electron provides. While you totally could build a similar app using WebView2 as you could with Electron, you're going to have to build all the non-web bits yourself.
> Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. [...] It is very hard to get 100% right, which is why no browser does.
This is not correct. In instances where CSS doesn't affect the styling of the control, the browser can use native controls. As far as I know, every browser _except_ Firefox does this. For example, <select> elements in Chrome and Safari are native elements (albeit Win32 versions in the former on Windows).
> The underlying problem is Windows suggesting Windows 98 styled buttons
I'm almost positive that Firefox doesn't use OS-native controls; they've specifically styled their controls to look the way they do, so yes, this is a Firefox problem, not a Windows problem.
I'm fairly sure that if you install Python using the official installer and select the "Add to PATH" option that the actual executable will be used. I'll check later in a clean VM to confirm and update this comment.
I'm super excited for this! I do wish that they'd ressurect their JavaScript projection for the runtime though. Especially with their focus on React Native, it'd be awesome not to need a "native" module to call Windows APIs. That being said, I also hope Rust/WinRT becomes a valid native module format for React Native (though I suspect it won't since that would likely require React Native developers to have the Rust toolchain setup to compile the module).
It looks like this is currently in a private alpha, but the code is all open source. [1]
When Apple introduced something similar, I really wished that someone else would provide something similar. I'm glad to see Mozilla is gearing up to offer this. My main worry, though, is longevity. What happens when you sign up using a generated email address, and then Mozilla decides to shutter the service? You'd likely lose access to that email, and wouldn't be able to log into your accounts anymore. Thankfully Mozilla respects users enough that they'd probably offer ample notice so that you could change your email address.
This is a prime example of where I think GitHub's acquisition of Dependabot and npm could really pay off. Imagine being able to publish a prerelease version of your library and run the CI tests of your consumers, all from within the GitHub interface. Dependabot already tracks compatibility between versions, so this would be a natural extension of that.
I'm not holding my breath, but I really hope Apple works with Microsoft to ensure that Boot Camp still continues to work. Windows on ARM on a MacBook with a powerful A14 sounds like a delight.