OpenJDK Comes to Windows 10 on ARM
infoq.com
infoq.com
I guess this opens up the chance JetBrains will point IntelliJ and PyCharm over.
MacOS does? By what measure?
Did I miss a beat and somehow thousands of developers have ported their apps to Windows ARM?
Last I heard Adobe only had a few tools working on the ARM version of Windows and only a few other developers were onboard.
From the sounds of it, when Apple Silicon goes live, there is going to be a pretty big selection of native apps (Plus they have iPad/ iPhone apps). The fact that Windows ARM didn't support emulating 64 bit x86 out the gate didn't help either since a lot of pro tools are 64 bit.
Most likely, everyone who will port their software to Apple ARM will also port to Windows ARM at the same time (same application core).
But of course the real (and perhaps obvious) difference is that Apple is much more strict about its ecosystem, having decided ARM will definitely be a thing and developers need to follow to stay relevant.
The Windows version is "maybe there will be ARM devices one day, maybe". That's not nearly as convincing.
I believe the most convincing thing for developers (besides rewards like promotion and filters in the store, which MS badly sucks at) would be a wave of serious ARM devices coming out in the very near future. The longer it takes the slimmer the chance that Windows on ARM will really catch on.
It is implied. To be accurate, it started being implied when mac os has been brought into discussion.
Uh, what? Java started as a write-once-run-anywhere platform for applications. Java gained popularity as a browser plugin for richer UIs. Significant amounts of enterprise and in-house software are written in Java using AWT/Swing, SWT, etc.
I have been developing on Windows and deploying into whatever OS almost since Java exists, thanks to IT policies regarding desktop computers.
And yes, I also have deployed my share of Java applications running on Windows based JEE containers.
My point here is:
- A huge chunk of Linux software (desktop or server) has been ported to ARM or will soon be.
- A huge chunk of MacOS software will likely be ported within the first few months of launch.
- A very small percentage of Windows software has been ported to ARM. Even the usual Windows strongholds: Games and corporate software have poor support for Windows ARM. Windows x86-64 bit emulation is missing (or at least was at launch) so a significant amount of pro software and games won't run even under emulation.
> The Windows version is "maybe there will be ARM devices one day, maybe". That's not nearly as convincing.
Exactly this. Microsoft has had so many false starts on platform shifts they have a hard job selling this.
Also outside HN bubble right there in the real world, macOS desktops are about 8% across the whole world. It doesn't really matter what CPU they have.
Considering many/ most pro apps like Photoshop are not written in .NET or Java, it is a significant concern. Likewise games—a category of software Microsoft has long dominated—are not generally written in Java/ .NET. Likewise, huge chunks of legacy corporate software is not very portable.
> Also outside HN bubble right there in the real world, macOS desktops are about 8% across the whole world. It doesn't really matter what CPU they have.
I wasn't talking about unit sales, I was talking about how much software the platform supports. Regardless of whether the Mac has 3% or 99%, there is going to be a better selection of software available for Mac on ARM in 6 months than for Windows ARM.
> Likewise games...
Nobody who plays games will want an ARM chips anyway because they’re for low powered mobile systems, not desktops with beefy GPUs.
Yeah, not everything will be available, then again it doesn't matter how much software is available, if only a subset of those 8% of the computing world population is going to get it.
to run legacy software.
I think market evidence points to the contrary. The Raspberry Pi is a fully fledged Linux Desktop, it's running and marketed with full fledged desktop software. Last I checked 25 million units have been sold.
It's use/sales far outstrips Windows RT or Surface Pro X which from what I know are the only current uses for Windows on ARM.
So yes I think Windows is in a clear 3rd place on ARM architectures.
I'm not sure I agree with this, lots of Pis are sold for projects which don't involve use as a desktop. In fact—from what I've seen—only a small percentage of Pis are actually used as day-to-day computing devices.
But in addition to the Pi, there is Pine64 which is exclusively sold as a "Desktop" platform with both laptops and workstations.
But I was talking more about the number of apps available on the platform than the number of units sold.
Software support for Windows ARM is a bit of a crapshoot which makes it hard to estimate what's out there.
The use cases for the Raspberry PI is ridiculously varied which I think reinforces it's application support relative to Windows on ARM.
I have seen it used for openstack development, as a desktop, home theatre pc, pihole, nextcloud instance, emulator etc... I haven't really found software that I can't just install/use.
Can you say the same for any windows on arm deployment? Especially if they are only just coming out with mainstream support for OpenJDK and Electron support.
In fact the alternative uses for the Pi are arguably as interesting/ important to its significance as a platform. A lot of little side projects which the Pi gets used for now used to be low end Windows boxes.
If Windows is in 3rd place for desktops, it's because of sales of ARM based Chromebooks, not Raspberry Pi.
That's a statistical error level compared to the number of PCs in the world.
And even the premise is wrong. The "Raspberry Pi" is not bought as a "fully fledged Linux Desktop" (whether it's marketed as such or not), but used mostly for special utility purposes, from automation and DIY experiments to multimedia servers and such...
Even if you add all Linux desktop machines, it's like 2% or something...
This is a comparison between Linux on ARM and Windows on ARM. Not against Windows vs Linux as a whole. I assume this is in the context of future consumer desktop platforms on ARM hardware. In that context, OEMs who want to release a functional desktop product with ARM chips would find it a lot easier/appealing with ARM than on Windows at present.
In that context, Linux on ARM is vastly ahead of Windows of ARM.
My argument is that the total number of raspberry pis being used a Linux ARM desktop outstrips the amount of Windows ARM desktops (which are composed of surface RT/X tablets).
There is a lot of performance left on the floor by real-time-only DBT when applied to binaries which do not jump into dynamic memory at all. QEMU is also, in my opinion, too general-purpose to be efficient. I think high-performance SBT and DBT is crucial to the adoption of new ISAs, it should maybe be something RISC-V International/The Linux Foundation puts up a bounty for (along with native ports of popular JITs like v8 and HotSpot).
Has someone come up with a smooth way to use them on ARM? (The leading contender is a qemu chroot with the scanner gui and driver installed, but that sounds hard to maintain over time).
I really want to just link the x86 .so into an arm binary, performance-be-damned.
----
You could put it in a container, and connect it with CUPS. CUPS is network-transparent and there should be nothing stopping you from running it in a container. It is not unheard of to use QEMU userspace DBT in containers[0].
[0]: https://www.stereolabs.com/docs/docker/building-arm-containe...
A container is nice because you can also be sure that the scanner container only exposes the saned socket, and has no other network access.
Much (most?) new Windows software these days is written in .NET and might just work out of the box, since that's technically speaking what .NET is supposed to enable.
(With the obvious reservations about platform specific quirks. I've ported my fair share of code to different platforms, and now it's often not that simple)
There is also a lot of legacy 32 bit code and industry specific tools which are getting left behind. Plus a lot (most?) of Pro tools and games use C++ or something a bit lower level.
I know Adobe is dragging their feet supporting Windows ARM and there is very little gaming support for it either. Both Adobe and Unity have announced "Apple Silicon" ports, Adobe has been dragging their feet on Windows ARM support and I don't even think Unity has announced they will migrate to Windows ARM.
Things have changed a lot since then, but to me, seeing Windows being the platform which has the least software support, even in this limited scope, is a sign of how much of a reversal Windows has seen.
What a strange universe you must inhabit. Windows still utterly dominates the software landscape except in web stuff. I have yet to work at an org that didn't have a dependence on many pieces of software that are exclusively Windows.
I think they were talking about ARM.
You do know we are talking about Windows on ARM here right?
I haven't said that every time I've been talking about this, but that's the context, Windows on ARM.
> Windows still utterly dominates the software landscape except in web stuff.
Again, Context. Windows on ARM doesn't dominate anything. That's why I said "even in this limited scope" right after the phrase you quoted. I figured folks would recognize we were still on the same topic.
I have enough ARM based games on my Windows Phone.
There's one Windows software sector that this is not good enough for - games (really care about performance+latency, unlikely to ever port to ARM), but that sector is the least likely to want to switch to ARM in the first place. Gamers will go Windows+AMD anyway.
The bigger problem for Windows-on-ARM is that non-Apple desktop-class ARM processors are right now rather weak, and that affects all applications, even ported apps.
Windows-on-ARM already has 32-bit x86 emulation — and it's slow as molasses. Believe me, people do notice the slowdown.
But Microsoft has everything to gain by upping the performance to match what macOS is doing with Rosetta 2, so it's definitely a space to watch closely.
Oddly, Microsoft has 32 bit x86 apps running on ARM, but 64 bit x86 apps are broken. More or less exactly the opposite of Apple in terms of legacy software. This means there are some pretty notable holes in the Windows ARM Pro software scene -> Adobe being the biggest, most obvious.
The message from Apple is "Everything that runs on Catalina runs on the new Macs", but software which has been ported will run best. The messaging from Microsoft is much more nuanced.
> The bigger problem for Windows-on-ARM is that non-Apple desktop-class ARM processors are right now rather weak, and that affects all applications, even ported apps.
This is why Apple can afford to go all-in on ARM while Microsoft has to tap-dance back and forth between the two platforms.
It has been argued on HN that the reason was x86_64 patents that will very soon expire. Once that happens, Windows-on-ARM is very likely to have x86_64 emulation as well. Besdies, 99% of Windows software is available as 32bit.
The software sectors that don't will either never port old stuff (games) or will port anyway for Mac and have an easy Windows port as a result (e.g. Adobe).
>This is why Apple can afford to go all-in on ARM while Microsoft has to tap-dance back and forth between the two platforms.
Microsoft is mostly a software company, rather than an hardware one. It doesn't matter to them on what processor type you run so long as it's their software. I suspect the biggest reason for focusing on ARM isn't Mac, it's Azure.
Microsoft has to tap-dance because it has a very long-tail of developers that do not accept change lightly.
Game developers have been porting their games to ARM for long time now. Sometimes, like GTA San Andreas, even for windows ARM, but these days the platform is usually iOS, Android, or Nintendo Switch. Historically there were others, PS Vita, Nintendo DS, they all had ARM CPUs.
And is it complete enough that any x86 application running native would also run on ARM emulation?
It's not just about having a suitable CPU though, it also relies on a good software layer. And there are many factors such as whether you're hitting cache or not.
Here's how the Windows x86 translator on a Qualcomm Snapdragon compares to Intel CPUs https://www.techspot.com/review/1599-windows-on-arm-performa...
From what I've seen online so far, the binary translator from Apple, Rosetta 2, seems to have promising technology. But we won't know until we see the new Apple Silicon based Macbooks.
Geekbench results for single-core performance are pretty much identical, though I win out by a wide margin on multi-core and video benchmarks.
But forget about benchmarks, here's a more practical example: fortnight loads in about 15 seconds on the ipad. For me about 45.
It's possible the graphics are lower quality on the ipad, though I can't tell the difference. Or maybe they have to optimize a lot more for iPads. Fortnight updates on the iPad, after downloading, also takes minutes while mine takes about an hour. I look forward to much less expensive arm chips coupled with a dedicate GPU, especially if it drives developers to write more optimized code.
In fact, this fortnight difference might be a case study in just how much can be achieved by optimizing. 3-5 year old phones can run Fortnite.
Edit: My concern was that Apple or MS would have divergent hardware and other support with firmware variations in their “custom” implementations. Kinda like the hardware driver issues Linux has had for years, but now burned into firmware.
Linux has been there entire time
* The underlying code is relying on x86 features or is x86 ASM. In that case ya... this is going to be a bit rough - but is a super minority, especially for use cases where you'd want to use ARM
* The runtime or compiler hasn't been ported to ARM yet. For compilers, I don't think this is a problem - I think both clang and gcc are completely ready to go for armv7 and arm64. Go is good to go too. Runtimes is a bit more dodgy, but all the major (Java, C#, Python, Ruby, Perl, Javascript/Node) languages and runtimes are just fine. Maybe the only one out is rust, which doesn't have ARM as Tier 1 supported (but should just work) yet.
* Hardware support. There may not be good open source drivers for various ARM specific hardware blobs.
What else were you thinking of?
Plenty of things work very well and I'd think most people would rate those working as far more important than small compiler tweaks. NVMe, GPU support etc is vastly more important to me than compiler micro-optimizations, for instance, because those actually make day to day developer usage viable. No amount of compiler optimizations will make SD cards fast. And today, you can boot generic Linux images for whatever distro, using UEFI, on high-speed ARM systems, with fully working desktops -- including working FOSS GPU drivers, full web browsers (with working javascript JITs), and high speed storage. So I think it's shaping up pretty nicely.
I've been using it:
https://github.com/pftf/RPi4 https://rpi4-uefi.dev/
Actually what I've been doing is using my wireless router (openwrt) to serve pxe images. So the rpi sits without an SD card. It's powered via Power over Ethernet (PoE), is advertised a pxe server, gets the initial uefi & ipxe binaries, then I can boot from an image off Github or one served locally. ipxe just adds another layer of indirection for expanded fun.
https://developer.arm.com/architectures/platform-design/serv...
* minus quirks/some deviations from the spec because Qualcomm
It's not necessarily sane to maintain binaries for each and every device flavour, but as long as the code is reasonably portable & each manufacturer keeps their LLVM IR/JVM bytecode backends in order, that might be enough to overcome some of the pain.
I've always found Arch distributions to be more usable on ARM systems than Debian distros simply because they user-friendly ways of building & installing from source. Building from intermediate representation might be the right mix of obfuscation, performance, friendliness, and portability for the consumer space.
The reasons most ARM devices require special "builds" for $YOUR_FAVORITE_OS almost entirely comes down to bootloader/peripheral nonsense. There wasn't (until recently) any standardized way to discover devices attached to your favorite ARM chip, nor any standard boot protocol, like we have in the x86 world. Therefore every device needed its own little description of the attached peripherals and (often) needed a little support in the bootloader -- uboot -- to accompany it. Therefore there are normally device-specific kernel/bootloader packages in your favorite distro, and specific installation instructions, but not every package needs this treatment. Once you install the distro, you can use the same ARM userspace binaries/packages as any other device, more or less.
However, ARM is now settling on ACPI/UEFI like in the x86 world to handle booting and peripheral discovery in a generic manner. You can, for example, use UEFI/TianoCore on the Raspberry Pi 4 today, and boot generic ARMv8 distro images of your choosing, just like you do with x86 systems.
Hello,
Arm is explicitly managed to prevent such a scenario to happen. Where things can and do diverge is the boot mechanism and peripherals, even if it has been getting better with time. (Arm servers and Windows on Arm machines using UEFI + ACPI)
However, for user-mode code, compatibility is mandated and checked by Arm, even for designs not made by them. As such, don't worry about it.
Take your pick. Almost all the stuff listed under SBCs is ARM.
Microsoft instead cornered the laptop/tablet with integrated modem for Windows on Arm (64-bit), which allowed them to ship much earlier.
My dad had a Surface RT a few years ago (I cannot recall how long exactly). But you definitely did realize something was "different" with this thing.
I think Apple has a better chance at achieving this broad acceptance than MS has because they have a lot more control over their ecosystem and hardware. People actually seem to use their frameworks for building apps, for App Store as well as direct downloads. Unlike Microsoft who still has not managed to convince developers to move to UWP apps.
I actually don't hate using the Mac App store on my machine, but I haven't used the Microsoft Store ever since I first tried it. And for lots of more casual users, they probably actually won't realize that there is a difference between the architectures.
Linux has been running on ARM for at least the last 15 years.
Have you heard of Raspberry? Even before it was released there were almost all of Debian packages in ARM, so Raspberry had it easy, they just took something that already worked. And it was years ago.
Right now the only OS ready for ARM is Linux.
But from all reports from people with the dev kit, Mac OS is going to hit the ground running.