Has anyone seen a detailed writeup on how they are performing the x86->ARM64 recompilation? I would imagine it works something like a software hypervisor once the individual instructions are translated?
I'll wager that there is still some of the old FX!32 technology in there, that was used back in the day to translate between x86 and AXP.
Remember NT was always designed to be cross platform - it shipped on x86, PPC, MIPS and Alpha originally. I ran SQL Server on Alpha for a while. Good times.
No, Compaq bought Digital, then, when HP bought Compaq, they killed Alpha in favor of the instruction set of the future, Itanium, and, adding insult to injury, sold the Alpha IP to Intel to ensure it’d never see the light of day again.
The Sunway line of processors developed by the Chinese military are rumored to use a modernized version of the Alpha instruction set (unauthorized obviously): https://en.wikipedia.org/wiki/Sunway
In this case I would say the lack of details is a good thing. It must work so well that they can keep it a secret from major vendors. If it wasn't near native speed or had bad x86/x64 ISA support they would be giving a heads up to the bigger software shops.
From the 68K to PPC migration at Apple, I remember software spent much more time running system code than application code (listening for events, redrawing stuff, and so on). It's true PPC was much faster than 68K and that made the move easier, but, still, just not having to emulate anything beyond the system library calls is great.
I still use a Surface RT 2, with Windows RT on ARM, as my main couch-surfing tablet. The battery is not as good as it used to be, and Ad-heavy sites load slowly because I can't install an adblocker. But it still works quite well for browsing. The fact there are no apps means it hasn't gotten slower: it's still fast enough, although an iPad pro is now much faster.
I very much wonder how this new generation of Windows on ARM will work out. On a faster ARM processor Windows will run very well, no doubt. Edge will be a good improvement over IE, the RT version of which was quite good i.m.o. But how will Chrome and iTunes run? Will they be ported to ARM, or will they run under x86 emulation? Will Microsoft finally convince more developers to bring apps to the Windows Store?
Unsubstantiated claim. On one hand I'm not convinced that ARM chips outperform Intel. On the other hand we could easily see many apps going through an x86 emulator, which incurs a performance hit against native. At the end of the day you get a performance hit, without a reason that can easily be explained to a user. Intel tablets can be procured cheaply, and most people would pay an extra $10 for something that runs twice as fast.
>> On one hand I'm not convinced that ARM chips outperform Intel.
What does "Intel" even mean? Intel offers such a wide array of chips, from bad to great.
If we're talking about the low end of laptops on sale today, then we're probably talking about the Atom Z, Celeron/Pentium N, and maybe CoreM. And those chips are "meh" at best, and are a pretty low performance bar to meet.
>> At the end of the day you get a performance hit, without a reason that can easily be explained to a user.
Why does it need to be explained to a user? Is the average user even going to understand or care that there's a performance hit? They're just going to know that their computer is slow or fast. And that performance expectation is usually mapped to the price of the machine they bought.
This is nowhere near the end of Intel, performance desktops and servers will still be running Intel processors for many years to come, ARM simply cannot match the performance - despite how impressive that demo video might look.
Intel was already dead in the water for mobile so I doubt they're too bothered.
Microsoft has plans on moving some of its Azure services to run on ARM, among other things for Windows Server on ARM.[0]
> "We feel ARM servers represent a real opportunity and some Microsoft cloud services already have future deployment plans on ARM servers," he wrote ahead of the conference.
> "We have been running evaluations side by side with our production workloads and what we see is quite compelling.
> "The high Instruction Per Cycle (IPC) counts, high core and thread counts, the connectivity options and the integration that we see across the ARM ecosystem are very exciting and continues to improve."
Again, the ARM benchmarks/demos recently are very impressive but there is no way they'll be able to match the higher end Xeon's, if for no other reason than you have to do x86 emulation.
I think they'll definitely be able to take some market share from Intel at the lower-end, but they won't be going anywhere any time soon.
AMD K12 is still slated for release in 2017 somehow - they didn't discontinue it. It'll have Zen levels of performance if it's released. For the time being, only Apple cores are remotely near competitive in single-core performance.
>> The iPad Pro is already neck and neck with the MacBook Pro
A nitpick with the use of "the" with Macbook Pro.
I think you need to qualify that as the 13" Macbook Pro. The 13" models use ultrabook class processors, while the 15" models use much faster quad core i7 processors. IMO, the 13" and 15" are very different beasts because of that.
You must be confusing the 13" MacBook Pro (i5-7267U, i5-7287U, i7-7567U) with the 13" MacBook Air (i5-5350U) or 12" MacBook. Only the latter has a true "ultrabook class" processor.
Call me a snob, but I consider anything suffixed with a U to be an ultrabook class processor, and anything with an M to be something worse. On the Windows side, those high end U CPUs are typically put in laptops that the manufacturers themselves call "ultrabooks".
Either way, a U processor doesn't really compare to the MQ/HQ suffixed CPUs in terms of perforamnce.
Yup, I'm going to call you a snob. ;) Purely because you're distinguishing based on a naming convention, rather than actual performance. But of course you're entitled to your opinion!
Checking the Geekbench comparisons, performance of the 13" and 15" MacBook Pros are mixed in together.
But, thinking about servers, for years now the default has been to build software systems that scale horizontally (by adding more computing cores) rather than vertically (by using faster cores).
In such systems, you may find, e.g., that 20 slower cores performs about as well as 10 faster ones.
In that case, you start looking at other factors. A big one is power efficiency. You have to pay to pull electricity into your servers and pay to get the heat away from them. This might be ARM's big advantage.
Now, in general systems, a single core has to be able to achieve a certain level of performance to be considered at all. It has to have enough power that people are confident that it will support a wide range of potential applications before servers using them will be widely deployed. But it's arguable that we're already there now, or almost there.
I think the way this is going to go down is AWS (and/or their competitors) will add an ARM option for EC2 and other compute services. It will be cheaper than the Intel option. People will try it and find it works fine for a wide range of uses. Then the dam will break and things will transition quickly.
Now, I'm kind of assuming here that ARM will continue to improve but will hit limits and will settle in to a place where it offers performance in the ballpark of Intel yet maintain significantly better power efficiency. If ARM somehow finds a way to surpass Intel then things will move more quickly and if it stagnates only a partial transition will occur.
So far ARM in servers has proven to be a disaster performance per watt-wise. Intel's Xeon D CPUs are not even the latest microarchitecture and yet they are wiping the floor with any other chip trying to get the performance per watt crown. Look up some Xeon D-1587 benchmarks (16 Broadwell cores at 1.7 GHz in a 65W envelope).
And since then Intel has picked up another 30% at least in performance/watt by going from Broadwell to Kaby Lake and soon Coffee Lake and so they can answer any challenger if they so want.
The reason there's no Skylake Xeon D is that Intel doesn't need it yet.
Intel must have been seeing this coming for quite a while. Even to a casual viewer from the outside it's been pretty clear for years.
I wonder what their response has been and if it has a chance of succeeding.
I am assuming we haven't seen their response yet. If we have, then they are in a bad place.
If you want to be an optimist in Intel's favor, perhaps recent chip delays and stagnation is due to them pulling resources away from incremental improvements to dead-end architectures and putting them on to The Next Big Thing in CPUs, which we'll all find out about soon... ha, ha.
And switched into the netbooks and hybrid laptops market, where Android has been a disaster, specially since developers only target phone screen sizes.
At most retail stores on my German city, the amount of Windows tablets/netbooks clearly outnumbers the few Android ones on display.
Even the Samsung models on display are all W10 ones.
My biggest concern is how locked these machines will be. Judging from previous history, the Surface RT, it's a shame it won't be possible to install Linux on these machines.
Such a move could be the end of the general purpose computer.
Not so much an "end" but more a bifurcation. Most people aren't hindered by a locked down machine. There will still be a market for computers like people on HN use, but we will be the minority.
> There will still be a market for computers like people on HN use, but we will be the minority.
I think we will eventually be squeezed into a bin where we can no longer access economies of scale, so you're effectively paying for the general purpose computing.
After decades of signed bootloaders being the norm, legislation may just come along and sign the death knell. Exemptions will be provided for industrial uses, but everyone else gets CFAA indictments.
But who is going to develop apps for these locked down platform? It is not in the interest of the OS maker to make it impossible for developpers to do their job. They need to have access to some open platform to attach debuggers, intercept and observe http traffic, develop and debug drivers, etc. Are windows, android and iOS apps all going to be developped on linux?
I wonder if there will still be a small yet thriving enthusiast community around building, restoring, modding, etc. of "real computers" --- somewhat like what happened for old cars. Much like antique vehicles are not as safe (in all senses of the word) or efficient as new ones, and often cost more to maintain, but at the same time they are also simpler, more easily understood, and relatively free of outside (regulatory or otherwise) influence while providing mroe freedom and control to their owners; just like comparing an older, more open PC to the latest locked-down consumption-oriented gadget.
After decades of signed bootloaders being the norm, legislation may just come along and sign the death knell. Exemptions will be provided for industrial uses, but everyone else gets CFAA indictments.
This is definitely a major concern. I'm sure that it will be ameliorated as more high-performance ARM chips hit the market and some provide open bootloaders or have them written by a community. I want an ARM laptop like nobody's business, and I love my chromebook for its ability to run arbitrary linux executables.
The trend of portable ARM workstations looks super promising, but if these entries are hardlocked to Windows, then they are complete non-starters.
Nice image, but reinstalling Windows from signed media is fairly easy on the ARM Surface tablets [1][2]. All modern ARM devices, including Android and iOS ones, have a recovery mode of some sort you can trivially access. I can't imagine Microsoft would release any new ones without a similar system.
> Now imagine your machine hit by ransomware and you being unable to boot it from a known clean OS...
... and then you buy a new one?
The last time I got ransomware was 2008 – while visiting a warez site. For me, and I imagine for most people, the frequency at which you will replace your computer is greater than the frequency that you will get ransomware. Best to throw the thing out and start fresh, making sure your photos and docs are backed up elsewhere.
Unless you mean their foray into ARM chips, their x86 parts have just as much an untrustable control coprocessor that nobody can audit or disable in their PSP, and are unlikely to support open firmware like coreboot either.
> It's a full desktop experience which, ironically noted by Liliputing, is less locked-down than Windows 10 S, because the Win 10 on ARM can run non-Windows Store applications.
> It is, as Pulapaka says. “a full desktop experience” – not just Windows Store apps, “your existing x86 apps will run completely fine on this device.”
I speculate that "Windows RT" / Surface RT was a warning-shot to Intel, and that the Windows Store restriction was intentional as not to spook Intel too much - I don't believe anyone in the executive levels of OSG at Microsoft ever believed that Surface RT would take-off - or that the inability to run Win32 programs (provided they were recompiled for ARM) would ever fly with consumers while the device still ostensibly came with an otherwise full Windows explorer.exe desktop experience - restricted only to a modified version of Office 2013.
Where's my windows x86 buildroot? How can I read through the equivalent of the IP-xfrm source? (something I had to do the other week to realize that the user-space program I was using was, in fact, behaving correctly)
There is fully unlocked as in you can install any userspace applications you want on there and fully unlocked as in you can unlock the bootloader and install 3rd party OSes. I read OP's comment as the latter and I'd be really surprised if it still wasn't locked down in that way.
Possibly true, although some of the surface widgets have been linux capable in the past.
I wouldn't worry, chromebooks are increasingly getting the ability to run android apps, and arm compatibility is a big win for android running apps. I expect nice chromebooks are in the pipeline with the snapdragon 835.
Every chromebook (and chromebox for that matter) can be installed with Linux. I believe that agreement that allows suppliers to call it a chromebook require the ability of the user to install their own OS. Additionally google's been pretty good at upstreaming various patches for touchpads, battery management, and related.
The general trend since the early 2000s has been to use any change in architecture, technology, or form factor to push customer-hostile changes: total device lock-down, deep integration of surveillance, de-prioritization of creation use cases in favor of consumption use cases, use of DRM and DMCA-type restrictions to prohibit repair and customer modification, etc.
I'm not optimistic here either. If recent history is any guide any architectural shift will bring lock-down.
Edit: seems to resonate in with the general political trend. Since around 2001 or so the global trend has been toward various forms of authoritarianism. Tech trends reflect social trends.
...and to think that only 18 years ago, Intel was persuaded into removing the machine-readable serial numbers from their processors, something that seems almost innocuous today but was met with extreme resistance when it was first announced: https://news.ycombinator.com/item?id=10106870
One only needs to look at the number of datasheets that Intel, AMD, and the other x86 manufacturers publicly provide(d) and compare with what Qualcomm, Broadcom, and the other ARM SoC manufacturers have to see the stark contrast.
Admittedly the x86/PC is not completely open and documented either (especially in the recent years), but the IBM PC in 1981 with its extensive set of documentation including schematics and BIOS source code(!) started a trend of strong backwards compatibility that still persists to some extent in PCs today and contributed to a solid, well-documented platform on which countless applications could be built and continue working despite many upgrades and improvements over the years.
From that perspective, I think --- contrary to most popular opinion --- that the presence of "legacy" features is a good thing particularly as it relates to the PC architecture: it's what enables retaining that aspect of openness and stability, something which can hardly be said of the various ARM platforms today. Every one is different, barely documented (at least publicly), and changes frequently. And even the Raspberry Pi, a well-known ARM platform specifically for "tinkering", has remained pitifully underdocumented and closed --- with newer versions of the Pi changing dramatically again.
Of course, there is still an opportunity for Qualcomm/Microsoft to release everything and make this platform a de-facto standard like IBM did 36 years ago, but sadly I don't think that's very likely...
The general purpose computer is already dead for several years, after the OEMs realized they couldn't reduce their margins any further down and the components market is a very tiny portion of their profits.
The PC model was a singularity caused by a cascade of IBM mistakes.
The future, regardless how we like it or not, is of appliance computers in shape of laptops or iMac-like desktops.
They might even ship GNU/Linux or *BSD with them, but you will get Dell Linux, HP Linux, Lenovo BSD and so on.
I am not that pessimistic. A couple of years back it was all "The PC is dead, everyone uses tablets now", but when I look around at work, about 50% of the computers are still regular PCs, the other half being laptops.
The market for open PCs where you can plug arbitrary extension cards into a PCIe slot will most likely shrink, which may drive prices up, but it won't go away for quite a while (IMHO).
Well, if you are on the road a lot, you need a mobile computer, obviously. Most of the engineers (probably all of them) at my employer have laptops, too. They need them, because they are on the move a lot of the time, visiting customers, construction sites and so forth.
But all of the office workers have regular PCs, so do the CAD people. No, wait - strike that. Some of the CAD people have laptops, too.
But there is a market for open PCs that can run any OS and software you like, that can be extended through extension cards, where you can upgrade CPU, RAM, graphics card independently of each other and so forth. It is not what it used to be, and it will continue to shrink, but I don't think it's going away completely.
As a curious aside, if you bought an x86 powered smartphone or tablets running Android, it features ARM binary translation given that many apps with native elements included ARM native code but no x86. I did my own tests with it to find it achieving close to 100% performance. It's turtles all the way down.
I thought that was achieved by having applications in Java bytecode with a Java virtual machine doing just in time compilation. In fact I thought that was the whole point of the Android ecosystem.
The Android NDK is heavily used - so you end up using native code apps anyway...
libhoudini was Intel's dynamic translator for running ARM libs on x86 Android devices.
No, they make use of DEX bytecodes and depending on the specific Android version they are only pure interpreters, JIT, AOT compilers or a mix of everything with PGO.
So basically they're not JVMs and Java bytecode but rather JVM and bytecode analogues that serve roughly the same purpose (post-Dalvik AOT ART notwithstanding).
ART is register based hybrid JIT/AOT runtime that was designed for memory constrained embedded devices. You cannot run Java applications on an Android device because ART is not compatible with the JVM and vice versa. Additionally, ART processes DEX bytecode and not Java bytecode.
Benchmarks of emulated x86 code and native ARMv64 code please? Any natively compiled windows apps one can benchmark to get a feel of its speed? Any 3D benchmarks of native code of any type?
While I hope for a great experience I am always scared of scarificing a lot of performance.
Keeping in mind that android uses the linux kernel. So whatever android driver exists for the 835 LTE is by definition a linux driver. It's possible there's some userspace part that could be android specific, but there's a decent chance of it working under linux.
Google and ARM have for all practical purposes closed off the open source Linux ecosystem as far as mobile phones are concerned. You can't run any off the shelf Linux on your phone without drivers.
I wonder what Microsoft will accomplish with ARM on the desktop? Are we going to regress decades to tightly closed drivers and systems? And the spectacle of open source devs struggling with ARM SOCs for years while the ball is kicked from vendor to ARM to Microsoft and back.
In effect lose the ability to run our own OS on our desktops and the incentive for people like Linus to develop an OS and the rich ecosystem it has spawned.
I don't believe Linus has ever developed Linux to be a consumer kernel. For the first ~15 years it took over servers, and still rules servers supreme. The mainline kernel still sees all its investment, all its participation, coming from predominantly the server sector.
Intel and AMD will keep making server CPUs, and those CPUs must support booting Linux kernels. That won't change as long as x86 is the performance king, and it would take a contender a sizable advantage to justify the opportunity cost to switch.
This is the second article I've read that has hinted that x86 emulation will be 32 bit only[1]. Does anyone know if this is the case or is there 64 bit app support as well on A53 cores?
[1] From the article: (via the inbuilt x86 emulator for 32-bit apps)
103 comments
[ 3.1 ms ] story [ 163 ms ] threadRemember NT was always designed to be cross platform - it shipped on x86, PPC, MIPS and Alpha originally. I ran SQL Server on Alpha for a while. Good times.
The Sunway line of processors developed by the Chinese military are rumored to use a modernized version of the Alpha instruction set (unauthorized obviously): https://en.wikipedia.org/wiki/Sunway
It those went to Intel... Well... It'll be fun to watch the fireworks.
I wonder if WoW64 had to be modified to support having two architectures.
Though they maybe planned ahead: it's "Program Files (x86)", not "Program Files (32-bit)" :)
It was somewhat outlined in this channel 9 video: https://channel9.msdn.com/Events/Build/2017/P4171
MMX/SSE/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/POPCNT/AESNI/CTMUL
I very much wonder how this new generation of Windows on ARM will work out. On a faster ARM processor Windows will run very well, no doubt. Edge will be a good improvement over IE, the RT version of which was quite good i.m.o. But how will Chrome and iTunes run? Will they be ported to ARM, or will they run under x86 emulation? Will Microsoft finally convince more developers to bring apps to the Windows Store?
Unsubstantiated claim. On one hand I'm not convinced that ARM chips outperform Intel. On the other hand we could easily see many apps going through an x86 emulator, which incurs a performance hit against native. At the end of the day you get a performance hit, without a reason that can easily be explained to a user. Intel tablets can be procured cheaply, and most people would pay an extra $10 for something that runs twice as fast.
What does "Intel" even mean? Intel offers such a wide array of chips, from bad to great.
If we're talking about the low end of laptops on sale today, then we're probably talking about the Atom Z, Celeron/Pentium N, and maybe CoreM. And those chips are "meh" at best, and are a pretty low performance bar to meet.
>> At the end of the day you get a performance hit, without a reason that can easily be explained to a user.
Why does it need to be explained to a user? Is the average user even going to understand or care that there's a performance hit? They're just going to know that their computer is slow or fast. And that performance expectation is usually mapped to the price of the machine they bought.
Intel was already dead in the water for mobile so I doubt they're too bothered.
https://arstechnica.com/information-technology/2017/06/intel...
> "We feel ARM servers represent a real opportunity and some Microsoft cloud services already have future deployment plans on ARM servers," he wrote ahead of the conference.
> "We have been running evaluations side by side with our production workloads and what we see is quite compelling.
> "The high Instruction Per Cycle (IPC) counts, high core and thread counts, the connectivity options and the integration that we see across the ARM ecosystem are very exciting and continues to improve."
[0] http://www.techrepublic.com/article/windows-server-on-arm-mi...
I think they'll definitely be able to take some market share from Intel at the lower-end, but they won't be going anywhere any time soon.
Again it doesn't make any sense to put ARM on server. There just aren't any advantage yet. And the forseeable future.
A nitpick with the use of "the" with Macbook Pro.
I think you need to qualify that as the 13" Macbook Pro. The 13" models use ultrabook class processors, while the 15" models use much faster quad core i7 processors. IMO, the 13" and 15" are very different beasts because of that.
Either way, a U processor doesn't really compare to the MQ/HQ suffixed CPUs in terms of perforamnce.
Checking the Geekbench comparisons, performance of the 13" and 15" MacBook Pros are mixed in together.
MacBook Pro (13-inch Mid 2017) Intel Core i5-7360U @ 2.3 GHz (2 cores): 4330 MacBook Pro (15-inch Mid 2017) Intel Core i7-7700HQ @ 2.8 GHz (4 cores): 4339
That's a negligible difference.
Of course multi-core changes the picture dramatically due to 2 vs 4 cores and the different TDPs, etc...
[1]: https://browser.primatelabs.com/mac-benchmarks
But, thinking about servers, for years now the default has been to build software systems that scale horizontally (by adding more computing cores) rather than vertically (by using faster cores).
In such systems, you may find, e.g., that 20 slower cores performs about as well as 10 faster ones.
In that case, you start looking at other factors. A big one is power efficiency. You have to pay to pull electricity into your servers and pay to get the heat away from them. This might be ARM's big advantage.
Now, in general systems, a single core has to be able to achieve a certain level of performance to be considered at all. It has to have enough power that people are confident that it will support a wide range of potential applications before servers using them will be widely deployed. But it's arguable that we're already there now, or almost there.
I think the way this is going to go down is AWS (and/or their competitors) will add an ARM option for EC2 and other compute services. It will be cheaper than the Intel option. People will try it and find it works fine for a wide range of uses. Then the dam will break and things will transition quickly.
Now, I'm kind of assuming here that ARM will continue to improve but will hit limits and will settle in to a place where it offers performance in the ballpark of Intel yet maintain significantly better power efficiency. If ARM somehow finds a way to surpass Intel then things will move more quickly and if it stagnates only a partial transition will occur.
And since then Intel has picked up another 30% at least in performance/watt by going from Broadwell to Kaby Lake and soon Coffee Lake and so they can answer any challenger if they so want.
The reason there's no Skylake Xeon D is that Intel doesn't need it yet.
Intel must have been seeing this coming for quite a while. Even to a casual viewer from the outside it's been pretty clear for years.
I wonder what their response has been and if it has a chance of succeeding.
I am assuming we haven't seen their response yet. If we have, then they are in a bad place.
If you want to be an optimist in Intel's favor, perhaps recent chip delays and stagnation is due to them pulling resources away from incremental improvements to dead-end architectures and putting them on to The Next Big Thing in CPUs, which we'll all find out about soon... ha, ha.
[1] "Intel fires warning shots at Microsoft, claims x86 emulation is a patent minefield" [ https://arstechnica.com/information-technology/2017/06/intel... ]
They've just pivoted out of the mobile market by giving up on Windows phone.
At most retail stores on my German city, the amount of Windows tablets/netbooks clearly outnumbers the few Android ones on display.
Even the Samsung models on display are all W10 ones.
Such a move could be the end of the general purpose computer.
I think we will eventually be squeezed into a bin where we can no longer access economies of scale, so you're effectively paying for the general purpose computing.
After decades of signed bootloaders being the norm, legislation may just come along and sign the death knell. Exemptions will be provided for industrial uses, but everyone else gets CFAA indictments.
History went the other way eventually, but I think manufacturers still have a huge incentive to lock things down if they can get away with it.
After decades of signed bootloaders being the norm, legislation may just come along and sign the death knell. Exemptions will be provided for industrial uses, but everyone else gets CFAA indictments.
Stallman's story is relevant as ever: https://www.gnu.org/philosophy/right-to-read.en.html
The trend of portable ARM workstations looks super promising, but if these entries are hardlocked to Windows, then they are complete non-starters.
Now imagine your machine hit by ransomware and you being unable to boot it from a known clean OS...
[1]: https://www.microsoft.com/surface/en-gb/support/warranty-ser... [2]: https://www.microsoft.com/surface/en-us/support/warranty-ser...
... and then you buy a new one?
The last time I got ransomware was 2008 – while visiting a warez site. For me, and I imagine for most people, the frequency at which you will replace your computer is greater than the frequency that you will get ransomware. Best to throw the thing out and start fresh, making sure your photos and docs are backed up elsewhere.
The last time a hundred companies were hit with ransomware, disabling tens of thousands of desktops was... Yesterday.
Because that is what will happen, as netbooks and Android have already shown.
https://www.theregister.co.uk/2017/05/12/microsofts_windows_...
> It's a full desktop experience which, ironically noted by Liliputing, is less locked-down than Windows 10 S, because the Win 10 on ARM can run non-Windows Store applications.
> It is, as Pulapaka says. “a full desktop experience” – not just Windows Store apps, “your existing x86 apps will run completely fine on this device.”
I speculate that "Windows RT" / Surface RT was a warning-shot to Intel, and that the Windows Store restriction was intentional as not to spook Intel too much - I don't believe anyone in the executive levels of OSG at Microsoft ever believed that Surface RT would take-off - or that the inability to run Win32 programs (provided they were recompiled for ARM) would ever fly with consumers while the device still ostensibly came with an otherwise full Windows explorer.exe desktop experience - restricted only to a modified version of Office 2013.
Where's my windows x86 buildroot? How can I read through the equivalent of the IP-xfrm source? (something I had to do the other week to realize that the user-space program I was using was, in fact, behaving correctly)
I wouldn't worry, chromebooks are increasingly getting the ability to run android apps, and arm compatibility is a big win for android running apps. I expect nice chromebooks are in the pipeline with the snapdragon 835.
Every chromebook (and chromebox for that matter) can be installed with Linux. I believe that agreement that allows suppliers to call it a chromebook require the ability of the user to install their own OS. Additionally google's been pretty good at upstreaming various patches for touchpads, battery management, and related.
I'm not optimistic here either. If recent history is any guide any architectural shift will bring lock-down.
Edit: seems to resonate in with the general political trend. Since around 2001 or so the global trend has been toward various forms of authoritarianism. Tech trends reflect social trends.
Admittedly the x86/PC is not completely open and documented either (especially in the recent years), but the IBM PC in 1981 with its extensive set of documentation including schematics and BIOS source code(!) started a trend of strong backwards compatibility that still persists to some extent in PCs today and contributed to a solid, well-documented platform on which countless applications could be built and continue working despite many upgrades and improvements over the years.
From that perspective, I think --- contrary to most popular opinion --- that the presence of "legacy" features is a good thing particularly as it relates to the PC architecture: it's what enables retaining that aspect of openness and stability, something which can hardly be said of the various ARM platforms today. Every one is different, barely documented (at least publicly), and changes frequently. And even the Raspberry Pi, a well-known ARM platform specifically for "tinkering", has remained pitifully underdocumented and closed --- with newer versions of the Pi changing dramatically again.
Of course, there is still an opportunity for Qualcomm/Microsoft to release everything and make this platform a de-facto standard like IBM did 36 years ago, but sadly I don't think that's very likely...
The PC model was a singularity caused by a cascade of IBM mistakes.
The future, regardless how we like it or not, is of appliance computers in shape of laptops or iMac-like desktops.
They might even ship GNU/Linux or *BSD with them, but you will get Dell Linux, HP Linux, Lenovo BSD and so on.
The market for open PCs where you can plug arbitrary extension cards into a PCIe slot will most likely shrink, which may drive prices up, but it won't go away for quite a while (IMHO).
This one is a W541.
But all of the office workers have regular PCs, so do the CAD people. No, wait - strike that. Some of the CAD people have laptops, too.
But there is a market for open PCs that can run any OS and software you like, that can be extended through extension cards, where you can upgrade CPU, RAM, graphics card independently of each other and so forth. It is not what it used to be, and it will continue to shrink, but I don't think it's going away completely.
But we don't know anyway.
https://www.apkmirror.com/apk/facebook-2/messenger/messenger...
Note that there is one for ARM and one for x86.
https://source.android.com/devices/tech/dalvik/
https://source.android.com/devices/tech/dalvik/jit-compiler
So basically they're not JVMs and Java bytecode but rather JVM and bytecode analogues that serve roughly the same purpose (post-Dalvik AOT ART notwithstanding).
While I hope for a great experience I am always scared of scarificing a lot of performance.
Why would you choose one of these devices over any other pre-existing laptop that can run Linux?
Is it the LTE modem? Is there even good Linux support for something like the Qualcomm 835 LTE modem right now?
Isn't that a bit like taking a kernel driver for 3.4 and hoping it works on 4.10?
Or, more likely in Android's case - a heavily modified 3.0 and hoping it works on 4.10.
Yes, I know about libhybris (and wish someone had a good tutorial for using it).
I wonder what Microsoft will accomplish with ARM on the desktop? Are we going to regress decades to tightly closed drivers and systems? And the spectacle of open source devs struggling with ARM SOCs for years while the ball is kicked from vendor to ARM to Microsoft and back.
In effect lose the ability to run our own OS on our desktops and the incentive for people like Linus to develop an OS and the rich ecosystem it has spawned.
Intel and AMD will keep making server CPUs, and those CPUs must support booting Linux kernels. That won't change as long as x86 is the performance king, and it would take a contender a sizable advantage to justify the opportunity cost to switch.
[1] From the article: (via the inbuilt x86 emulator for 32-bit apps)
There's must be something very difficult about accomplishing this. There are a lot of mentions of x86 on ARM64, however.
edit: closest is this - https://manpages.debian.org/jessie/qemu-system-x86/qemu-syst...
I suppose one could compile that to run on ARM64.