Windows 10 is catching up with all the other operating systems by offering better support for ARM processors, but this means third-party developers will also need to work on making their apps faster in the new ecosystem. Google now seems to have begun work on Google Chrome for Windows 10 on ARM, with a little help from an unexpected ally.
I am a proponent of ARM laptops, simply because of their long battery life and fanless operation. While I personally do not use Chrome, there are many applications that rely on it, such as Discord, which I do use every single day to hang out with friends and play games. Slack, which I personally don’t use but is a hugely popular application, also uses Chrome.
Most programs are coded for x86. Since most things in Linux land are open source, they can just be recompiled for ARM.
Though I would love an ARM laptop, for what I use my laptop for, it’d have to be beefier than your flagship phones are…
The ultimate would be if there were such a device that could be my phone, or if I plugged it into a dock, I could still use my dual-4k monitor setup with mechanical keyboard
https://www.zdnet.com/article/asus-novago-arm-powered-windows-10-lap…
Leech mentioned more powerful than his current smartphone.
The Asus NovaGo uses a SD835 and is therefore less powerful than his current smartphone. (Probably running a SD845 or an Apple A11/12).
There is no ARM powered Windows phone which can plug into a dock and turn into a workstation but there is a more powerful than a phone ARM powered Windows Laptop on the market.
It’s a Lenovo
https://www.lenovo.com/gb/en/laptops/yoga/yoga-c-series/Yoga-C630-13…
Looks good, but fearing the price. Also leech gave no spec to base my assumptions onto.
https://www.digitaltrends.com/laptop-reviews/hp-envy-x2-qualcomm-sna…
https://www.tomshardware.com/reviews/samsung-galaxy-book-2,5859.html
https://www.windowslatest.com/2018/10/24/weibu-announces-a-windows-1…
Or you can go that (preferred) paths :
https://www.crowdsupply.com/eoma68/micro-desktop
https://www.crowdsupply.com/sutajio-kosagi/novena
But ok, not (yet) powerful enough.
Well, I was talking even current flagship phones, which aren’t going to be powerful enough for say virtualization, opening 30+ ssh sessions, etc. You know, things I do on a daily basis
For what it’s worth, I currently have a Note 8 (SD835 I believe).
Well, your needs aren’t compatible with current smartphones. But most people have.
https://www.samsung.com/us/explore/dex/
https://www.sentio.com/
https://nexdock.com/
https://miraxess.com/
https://www.razer.com/projectlinda
Just looking are the specs is not going to be a like for like comparision now is it.
In a laptop with lots more space and better cooling than a phone a chip will provide more power to the user.
A desktop would go even further.
Hey a non neddlesly thin phone could do better! Some phones (prtty much) throttle all the time (under load), making the powerful cpu in them pointless.
Take the cooler off your dekstop and see what sort of speed you get!
I really wish people would quit with this nonsense. Any nontrivial program requires effort to port to a completely different CPU architecture regardless of it being the same operating system.
Every architecture has its own features, quirks, bugs, endianess (ARM is bi-endian for one while x86 is strictly little endian), differences in word and page sizes, etc. An incredibly complex program such as a web browser, open source or not, is NOT trivial to port to any new architecture even on the same operating system and it will take thousands of man hours to port it, test it, work out the kinks, then maintain it for the projected lifetime. I defy you to take Firefox and “just recompile it” to get it to run on some new POWER CPU without going through the effort of porting it and patching the code. It won’t work! Likewise “just recompiling” Chrome/Chromium for ARM ain’t gonna work either whether it’s on Linux or Windows.
https://archlinuxarm.org/packages/armv7h/firefox
Uh… seems people have already done the work. You literally can take Firefox and just recompile it for ARM because it’s already been done.
So no, it’s not nonsense, because, being open source, people have taken nontrivial programs and done the work of porting. They didn’t just start thinking about porting to ARM now just because you haven’t until now.
Ha, yeah not sure how that’s nonsense. I mean I could feasibly run Firefox on Debian for m68k. Granted would need enough memory for that.
It’s called having a proper tool chain for multiple CPU architectures. Since people don’t have the source to most proprietary applications for Windows, it’d require the companies to take all their software and port it to ARM, do you or Microsoft think that’ll ever happen? Especially for software where the company has gone out of business.
There are always those that are very tied to the hardware that’d be difficult to port, even with open source. Like emulators. Some of them don’t even work correctly with x86_64, and you have to install 32bit libraries to use then (some NES / Genesis emulators come to mind).
Most (in Windows at least) are *compiled* for x86. As with most programs in *nix only a tiny minority contain architecture specific code.
I’m still bitter about SmartBooks not making it to market in 2009. We could have had a decade of ARM laptops already; Microsoft don’t deserve praise for getting Windows to half work on ARM.
What do you mean “half work”?
There’s a long way yet until Windows on ARM has equal functionality to Windows on x86. It doesn’t emulate x64 binaries. Hyper-V is not supported, so no virtualisation there. IMEs, Shell Extensions. No OpenGL > 1.1(!). More limitations will turn up.
It’ll get there in the end, I’m okay with that, but let’s not throw away the past and praise Microsoft for changing the market to ARM — they *actively* worked against that when Netbooks arrived, or are we already forgetting OLPC?
Nothing you mentioned is “equal functionality”
Not even looking for “equal functionality” but I have one of these : https://www.amazon.com/Mini-Netbook-Laptop-Notebook-WindowsCE/dp/B00…
Windows CE 6, Windows XP themed, works perfectly, if only the CPU was a bit stronger (300 MHz vs. 800 MHz for the Android version) and have more memory.
I done several Embedded Visual 4.0 development on it
Remembering ActiveSync and Gapi things…
http://www.poodwaddle.com/netbook/
Edited 2018-11-22 13:09 UTC
IME, and Shell Extensions are supported, just not x86 versions. That doens’t mean Windows “half works,” that just means it needs software.
Windows for x86 doesn’t support OpenGL beyond 1.1, either. It’s graphics vendors that support it. Windows itself is just as complete.
The only actual thing missing from Windows, that is a part of Windows, that you mentioned is Hyper-V. I’m not surprised it isn’t included, since so much of it is x86 specific, it’ll take time to port.
Like Drumhellar says, The situation with OpenGL is basically the same as on x86 Windows… And doesn’t Hyper-V depend on some hardware features that aren’t present in current ARM chips? (and there are other solutions for virtualisation which could work, though perhaps not as performant)
Also, the first two versions of OLPC were x86 without any intervention from MS…
Hi everyone. I think its a good idea because a lot of people use Chrome and it can be better for users.
Edited 2018-11-22 09:21 UTC
Microsoft has a long history of spending millions on these kinds of things and abandoning them. (Surface RT being the most relevant example). Even if it makes it to the market, I can’t recommend buying any until they’ve stayed on the market for at least 2 years.
Tons of desktop programs rely on CEF (Chromium Embedded Frame based on full Chromium but always custom compiled for the specific program to don^aEURTMt use unnecessary code), to name a big one, Spotify. Carbonite Backup and many many more are really webapps that with CEF progressing really needs only very few direct native OS calls without going through web code. Well known programs on Windows like CCleaner and Malwarebytes for Windows and macOS too seem to have such custom UIs that they probably use a lot of CEF but these of course need some OS specific code to do their stuff, but porting the main components should be easy. And of course web apps bundled in Android apps with some native like the settings screen, like Feedly.
I don^aEURTMt use Windows a lot so can^aEURTMt mention a lot of programs but I see a ton bundling CEF or WebKit (which Chromium is built from, but just the rendering engine, not JS engine, which was why they created Chrome in the first place, a faster browser based on WebKit for many years so Google contributed a LOT to WebKit which again made Safari better, but well they have moved away from cloning the WebKit code now, since Apple devs had control they could choose to not accept a commit etc. Blocked things like Pointer Events from MS stupids…
Still Google Project Zero, with the goal of finding holes in not just websites but also OS^aEURTM not Google-owned, is the biggest contributor to several patches to WebKit and Safari and also macOS and iOS, the last two proprietary but at least they find security holes all the time and report them to Apple. One just have to look at Safari/macOS/iOS changelogs when updates are out, clicking on the link for more details, as they usually only list new features and bug fixes to usability, and a last point ^aEURoesecurity fixes^aEUR, where they list credit… I assume Apple pay those who find security holes depending on the severity just like Facebook and Google and MS. Not sure how much Apple contributes, if any, to any company.
WebKit is a fork from KHTML again which is the reason it is one of Apple^aEURTMs still only FOSS projects which allows apps to use WebKit, (after Apple stopped using CUPS for printing on macOS it is now maintained by others) usually in a framework like Qt or GTK. CEF is more a complete framework with everything you need if you build the UI in HTML5 and access to a ton of OS APIs when necessary).
Say you want to browse for local files in Spotify, well it just opens a standard file picker that is easy from web code and get back the path. Volume control and playback etc, writing profile info, cache and downloaded playlists erc is easy using CEFs APIs to the local app^aEURTMs data folder.
Some bridging is necessary though, for example on Linux Spotify implements the MPRIS D-Bus standard to appear in the OS^aEURTM native volume controller, probably on Windows too. macOS does not have per program in its native volume control in the status bar.
On Windows they may have to use some native code if you choose to slaunch Spotify links from the web in the Spotify program. But I really doubt it. Start on login doesn^aEURTMt require RegEdit, just a link in the Startup folder, like on Linux in .config/autostart. Spotify runs as the user logged in so. Main processe does this I suppose, rest sandboxed. CEF works great to utilize all CPU cores just as if having various tabs open in Chrome, that is way so many complain(ed) about the amount of processes in the main program tree called ^A<>. Basically one for playback, one for downloading/caching etc. If not they would block the UI thread, making it unresponsive, like a mobile app doing heavy lifting without using a service, thread, async tasks etc.
So many I had to explain regarding suddenly many Spotify processes since v0.9 AFAIK to in the Spotify Community forum, and they were like ^A<>, and the total RAM usage actually went down when just playing, as Helpers are created and destroyed when necessary. Before all 3 supported desktop OS^aEURTM had basically totally different code bases. The Linux version was just maintained by employees that used Linux (work and home) and wanted Spotify on their PCs, as their official statement said on the download page before, it was an own one for Linux, and we never knew if we would get the new version. A lot were skipped. And then the main dev that had complete oversight and understanding of the code left Spotify, but we got the latest 0.9 version, the one before 1.0 which was a total rewrite and using CEF no problem supporting 32-bit as well, which was discontinued in v0.x at v0.9.4 AFAIK still using the old grey UI, just adding web renderer, as they never bothered to add CEF to 32-bit, just fixing distro problems. It was like v0.6 really which is still my favorite regarding cleanliness. This before even US launch I think, no Browse or Library or web API, but MPRIS yes! So easy it has been to write just BASH scripts to control playback. Or whatever language.
After seeing the benefits of the web player, but for a while Flash was needed since there was no W3 standard for DRM, and so much resistance against it. Bad IMO. A lot of apps would only be for one OS if it wasn^aEURTMt for web DRM, especiallt apps from individual developers, small teams and FOSS applications. Like with the Spotify Web Player, they had to use Flash, otherwise all files played using HTML5 audio would be super easy to download in batches using scripts.
Spotify was like that before like v0.6 and before, when it was all native, and later they started to show web content in the content window in v0.8 (0.7 never was released AFAIK), but the rest like the window management, side menu and the the program menu and the Files, Edit, Help etc were all native widgets, and the UI would block a lot when certain things were done.
But v0.8 was a disaster:
1) I think they bundled it with Apple^aEURTMs WebKit from different native implementations of it, like QtWebKit on Linux and IDK but like WinWebKit on Windows etc. Actually AFAIK they used GTK WebKit on Linux for some reason looking at terminal output and other GTK calls, it was a mess, and all libs bundled instead of using the preinstalled Qt and GTK shared libs on all LTS versions of Ubuntu, which they write specifically that LTS Ubuntu is the only supported platform after 12.04 was released, but really got full support from v14.04 with Spotify v1.0
From 14.04 Spotify v0.9 works fine until 17.04 with just one package from the 14.04 (security, recommended) repo installed which does not overwrite any files. v0.9 is still good, they got rid of the white background and the horrible single threaded web engine which caused for example super lag on scrolling long lists and sorting, blocked the whole UI while it was doing anything in the web code.
2) It was slow and keeping the dark theme for the native UI and white for the content part like they had changed the CSS bg color and text color for just that, as all other components were styled the same as in the web app.
3) They did not use CEF optimized for their use case and such could not use it the web part cross platform.
In v0.9.7 was when they switched to CEF AFAIK, and the ^aEURoeoutrage^aEUR over all the helper processes came, while at the same time praising the performance and dark theme back for the entire app.
They could also have used Qt for native widgets on all OS^aEURTM, but they used Win32 on Windows at least, don^aEURTMt know on macOS as I didn^aEURTMt have a macOS PC at the time but probably Cocoa.
With v1.0 it was a total rewrite after the DRM issue was solved and CEF built for their use case. I have tried to inject JS and use Chromium flags to change stuff but they seem to have done things right. Not possible to change DOM or fetch content from it, not changing web files in cache directory etc while the program runs either.
Edited 2018-11-23 21:05 UTC
Hm, IIRC the author of uTorrent works at Spotify …too bad he didn’t manage to make it even 10% as light as uT (for me, music player is something that constantly runs in the background, so it better be light on resources / to not take them from what I’m doing)