I'd like to advocate for remote development environments. Most of my day is spent typing into a tmux session on a cloud-hosted box. (I picked up a Magic Keyboard for my 11" iPad Pro, and thanks to Blink it's a great glass terminal. It's not going to work if you're debugging let's say a React app, but I've been very happy on it the last several days churning out Golang.) Running stuff on your laptop makes it run slow,…
ARM Mac: Why I'm Worried About Virtualization
201–210 of 313 posts
Re: ARM Mac: Why I'm Worried About Virtualization
#202Re: ARM Mac: Why I'm Worried About Virtualization
#203Earlier quoted context omitted.
To give a different perspective: I find Apple's move to ARM the most exciting thing to happen in desktop computers in many years. I'm typing this from a PC running Win10. Current plan is: as soon as ARM desktop Macs become available (and assuming they don't screw it up in some weird way), I'd like to switch.
If it's ARM that excites you, Surface Pro X (Windows) and Pinebook (Linux) exist today. If it's macOS, you could switch now. What about the combo of macOS + ARM do you find compelling?
Re: ARM Mac: Why I'm Worried About Virtualization
#204On the flip side, I guess ARM Macs will now allow the use of hypervisors for Android simulators, instead of a full hardware virtualization. ... thus making Android development better on Macs?
Re: ARM Mac: Why I'm Worried About Virtualization
#205On the flip side, I guess ARM Macs will now allow the use of hypervisors for Android simulators, instead of a full hardware virtualization. ... thus making Android development better on Macs?
It won't be a trivial task (hoping for pre-existing code to port over maybe?) but we have the other pieces like using Hypervisor.framework for x86 already, and being able to cross compile the other code for arm64, so that would be the only major task left.
On the subj. of better GPU support, it depends on what it's actually like using the drivers, but from previous experience with the GPUs and drivers shipped with macOS, there shouldn't be any special kind of trouble at least. We may have to use Metal if Apple also gets rid of opengl support on those new machines, but there are also existing translators for gles and vk to metal. The graphics hw itself, is actually the least of our worries due to how consistent the hardware is likely to be---we'd have to deal with a much fewer set of hw/driver quirks versus other host OS platforms.
Re: ARM Mac: Why I'm Worried About Virtualization
#206Are there any excited embedded developers in the crowd? I have done a little embedded work and cross compiling has always been a huge pain in the ass to setup. I know some people have even gone as far as purchasing expensive niche workstations with ARM CPUs specifically to avoid this problem. I feel like having a mainstream ARM platform like the MBP will make compiling software for ARM-based single board computers a…
32 bit on the phones, a real pain in the ass to cross compile, but it's a fun learning experience (I'm just a noob to any programming). I'd love to get paid for this tbh :D
Re: ARM Mac: Why I'm Worried About Virtualization
#207Are there any excited embedded developers in the crowd? I have done a little embedded work and cross compiling has always been a huge pain in the ass to setup. I know some people have even gone as far as purchasing expensive niche workstations with ARM CPUs specifically to avoid this problem. I feel like having a mainstream ARM platform like the MBP will make compiling software for ARM-based single board computers a…
Most tools are adopting Linux remote build + remote debug, wherein you ssh in and hook into the compiler and debugger all from the comfort of CLion/VS2019/VSCode.
If they don't have remote build, there is often building locally, with a copy of the root filesystem, using a cross-compiler, then remote deploy + debug. The most annoying part of this process is fixing all the symlinks not supported on NTFS.
Expensiver niche workstation = $500 dev kit directly representative of your target, but with everything exposed.
The interesting thing is now we need ARM -> x86 remote build or cross-compilation tools, of which I know of none.
Re: ARM Mac: Why I'm Worried About Virtualization
#208I would expect about a 5x slowdown running Docker images. Docker on a Mac utilizes a hypervisor. Hypervisors rely on running the same architecture on the host as the guest, and are about about 1x - 2x as slow as running natively. Since you're running ARM Mac, these hypervisors can only run ARM Linux. They can't run x86_64 Linux. What will happen instead? These tools will fall back on emulators. Most of the software I…
Re: ARM Mac: Why I'm Worried About Virtualization
#209I use virtualization continuously, but not for anything that needs to be as fast as possible.
I won’t hesitate to get an ARM Mac once I can run x64 Windows VMs on it. (Presumably VMWare Fusion or Parallels, and for once I won’t feel ripped off by the upgrade pricing.)
Docker on Mac doesn’t work that well today, so I don’t have any workflows that depend on it.
Re: ARM Mac: Why I'm Worried About Virtualization
#210Earlier quoted context omitted.
I'd much rather have a more powerful x86 workstation for the same money than an ARM laptop. Never really had problems with cross-compile. And without support for running Linux natively, it doesn't get me much for even for the parts of testing that don't need the specific target (well, VMs maybe).
To be clear, we don't know if the ARM MacBook will be able to run Linux natively. We only know that Apple won't continue support for Boot Camp and therefor Windows anymore. Linux was never supported.
EDIT: fixed link