(arm64)
Jamey Saldana
TeamViewer crashes often on my Surface Pro X which runs Windows 10 on ARM (arm64). This device can run 32-bit apps through emulation when no native arm64 is available, which is the case for TeamViewer. So TeamViewer runs in 32-bit on this device.
When a crash occurs (e.g. when remotely controlling a customer's device), a log is visible in the Windows Event Viewer.
Would be great if TeamViewer was available natively on Windows on ARM though, instead of running as an emulated 32-bit application. CPU usage is quite high currently, and the battery life would definitely benefit from a native ARM version.
I'm planing to purchase a Microsoft surface pro x device, but I'm hesitated because as you've mentioned most of the windows applications runs on the Surface uses the 32-emulator, the most important application I need is teamviewer & without confirming it runs on the Surface without any problems there is no point of purchasing it except wasting my money.
I gotta say that the 32-bit version of TeamViewer has been working fine on my Pro X - I had issues with hardware acceleration in the beginning, but those have been resolved in the meantime (I believe through a display driver update on Microsoft's side).
Tried the 64-bit version two weeks ago on Windows 11 (which supports 64-bit emulation) but it crashed when I tried to connect to another computer. The 64-bit emulation in Windows 11 is slightly buggy still, so I expect that to improve over time.
I think it's just a matter of time for TeamViewer to come up with a native ARM64 version of Windows. As a developer I know that a lot of toolchains/dependencies have been updated to support ARM64 lately (which I've been contributing to myself as well), so it should become easier and easier for TeamViewer to port things to ARM64 ??
We do have arm64 binaries on our list of requested binary distributions, but it's not currently on our short term roadmap. Since we provide comprehensive binary support for the entirety of CRAN, not just on the latest version of R but also for the past four R releases, every distribution / platform variant we support adds over 100,000 binaries that have to be built and maintained. While we'd love to provide binaries for every requested environment, we do need to prioritize our limited resources where most needed.
Requests like this are appreciated and encouraged, as it does help us recognize the demand and prioritize accordingly. In that vein, can you give us a little more detail about how you use these binaries, and what arm64 Linux distribution(s) are most important to you?
I work between an Apple Silicon Mac (arm64), and an Intel-powered remote cluster. I would like to be able to develop multi-platform Docker containers containing a synchronised development environment, so I can test my pipelines locally before running on the remote cluster. Currently, creating the arm64 container requires compiling packages from source - this is slow, and times out if I run the build on e.g. Github Actions.
We are still exploring including full CRAN binaries for arm64 on selected platforms via Posit Package Manager. Hearing both of you interested in Ubuntu is a helpful data point. No timeline for availability yet, but still hoping to get it on the roadmap soon. Thanks as always for your interest!
Hi jpvelez, just so it's clear we do have arm64 binaries for Mac. If you use p3m.dev on your Mac, you should see a binary in most cases. It is the case though that we still haven't added in Linux binaries, which would cause the issues with a Docker build using Linux on the Mac.
93ddb68554