Qualcomm hasn't made a single Qualcomm core since Apple released their first aarch64 SoC. Qualcomm had zero competition and decided to not really work on anything. Apple blindsided it with its very competitive aarch64 cores, Qualcomm had nothing to show, so they switched to ARM's core design.
Customers kept paying Qualcomm for their SoC with ARM designed cores, so once again, Qualcomm had no reason to actually do anything but sit on their patents.
Intel had a similar story, since Sandy Bridge "x86_64" part of CPU barely changed, most of the performance gain was somewhere from better process, more custom instructions (avx2, etc.), higher TDP (since ryzen).
It's not ARM vs x86, it's Apple ARM cores vs everyone elses cores.
> I dunno here, is Rails a server application library because I can progressively integrate the different components of its total API, e.g. first use ActiveRecord, then adopt rails-api for the frontend, then adopt ActiveView and Turbolinks for the end-user frontend? Or is there different idea of framework at work here?
I think you misunderstood parent comment. Progressively integrate here means: you have a web page (facebook.com), you want to replace a part of it with react (chat function), you rewrite just that portion of the webpage in react.
You can't get a Sinatra application and replace just one route with rails. Well, you can use ActiveController, which is just an opinionated wrapper around Rack with a lot of sugar, but that wouldn't be rails and you won't get any rails benefits of doing that.
Let's see. They don't approve for other platform because "they want dartvm to be cross-platform and not hold too much platform dependent code"
Then they proceed adding platform dependent code for their vanity projects like Fuchsia along side their other platform dependent code for not vanity projects like ChromeOS and Android.
IMO Dart is only alive because of Flutter, outside of it, it's dead.
That's not the case for a long time. I have rEFInd that started life in windows 7 esp with freebsd dual booting, now the same hard-drive booting windows 10 (upgraded from 7, not fresh installation) and nixos, all with the same rEFInd from the same.
The correct way to do so, is to have separate hard-drives for different OS. Then there is zero chance of them stepping on each other.
> Process per connection is pretty easy to accidentally run into, even at small scale. So now you need to manage another piece of infrastructure to deal with it.
Most places I saw this as an issue, are where developers think that by tweaking the number of connections will give them a linear boost in performance. Those are the same people that think adding more writers in RWLock will improve writing performance.
I agree that it's easy to run into and pretty silly concurrency pattern for today's time. At the same time, it's just a thing you need to be aware of when using PostgreSQL and design your service with that in mind.
Customers kept paying Qualcomm for their SoC with ARM designed cores, so once again, Qualcomm had no reason to actually do anything but sit on their patents.
Intel had a similar story, since Sandy Bridge "x86_64" part of CPU barely changed, most of the performance gain was somewhere from better process, more custom instructions (avx2, etc.), higher TDP (since ryzen).
It's not ARM vs x86, it's Apple ARM cores vs everyone elses cores.