6 ms·

I don't think I could use a Mac for software development anymore if they switched away from Intel. So much of my work is dependent on running linux executables

I don't think I could use a Mac for software development anymore if they switched away from Intel. So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common. I also need a Windows VM quite frequently for the odd program that only runs in Windows, or if I need to run Visual Studio one day. Windows is also very important for me to keep around so I can test software products in the same environment as other windows users, and there are definitely a handful of windows users out there. Sure there may be alternative options in both areas but I'm not interested in solutions that work 80% of the time. I can't let my development environment get in the way of my work.

webaholic 7y ago
May be by the time Mac has an ARM processor, your deployment server might also be an ARM server. :)
bin0 7y ago
You know one of the great things about VMs? They're cross-platform. I'm guessing once the same amount of optimization is put into arm has has been put into x86, the performance ought to be comparable. I'm also about 99% sure docker can be run on arm (RPIs support it, right?). With that said, I sincerely doubt Apple will kill x86 wholesale overnight. I'm guessing there will be a transitional period of quite some time. Also, windows has been doing a ton of work around getting onto arm. I managed to test on my rpi 3, and it was pretty good. it would probably be very doable.
- ihattendorf 7y ago
  Cross platform sure, but cross architecture will kill performance.
  - rbanffy 7y ago
    Not necessarily. JIT ISA emulation that generates native code for the host ISA has been done for ages now.
    - etaioinshrdlu 7y ago
      My understanding is that you could expect, very roughly, maybe a 50% performance hit using best of breed emulators translating from one ISA to an other ISA nowadays.
microcolonel 7y ago
> So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common. Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Because unless you are, I don't see what the issue would be with multiarch, assuming you don't manually compile the binaries for your containers. Also AArch64 cloud servers are a commodity available from at least Amazon right now, and the hardware is available on the open market. Not to mention, if you're running Docker right now, it's not running natively on macOS anyway. If you're just looking to test basic correctness, then surely you can run your dockers in QEMU or whatever AMD64 DBT/emulator is made available. Apple has a history of shipping good emulators (namely Rosetta and the 68k emulator) for their previous architectures when they change ISA.
- tatersolid 7y ago
  > Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything. You really need to develop and QA on the expected deployment platform
  - microcolonel 7y ago
    > "Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything." Sure, but when it comes to platform enablement, that only really needs to be done once per vertical/native dependency. AArch64 has all of those things you listed. Don't know about .NET (though there's not that much .NET development on Linux, at least not when compared with the amount of Node and Java), but OpenJDK, Node, C/C++/Rust/Go toolchains all have mature support for AArch64, among others. It's obviously less mature than the 40-year-old x86 ecosystem, but it's basically all there. Furthermore, the ease with which new ISAs can be adopted by toolchains and libraries is accelerating, so POWER and RISC-V are also getting there in terms of software availability.
jchw 7y ago
It would be slightly less convenient, but it probably wouldn’t affect your development capabilities so badly. Pretty much any Dockerfile that works on x86 should work on ARM. Linux runs totally fine on ARM. If anything, the worse problems are with Linux desktop and games software that assume ARM == embedded and attempt to use EGL and GLES. There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues. (The latter is straight up a non-issue with a good CD pipeline.) Windows 10 also runs on ARM platforms, with the ability to transparently emulate Intel. I’m sure this is or will be usable inside of VMs even if dual booting is not an option. https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-x86-emulation https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
- StudentStuff 7y ago
  Most linux desktops work fine on ARM chips FYI. GPUs in the ARM world are usually just for OpenGL used by video games. Video decoding/encoding is handled by a VPU (not GPU), HDMI is handled by a separate HDMI PHY, and most of these components have mainline, libre kernel support if you use an Allwinner based single board computer. Microsoft has started branding some Mali GPUs as DirectX 11 capable, though YMMV on using these features.
  - jchw 7y ago
    Sure, but many games and applications are hardcoded to use EGL and GLES (which is not always available for desktop ARM.) For example, I believe Qt4 makes the assumption that ARM = GLES.
- MrBuddyCasino 7y ago
  > There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues. I'm not sure thats true. At the very least its going to suck for the first year as gaps are being filled, but those differences might matter too. I would hate to have to duplicate every single Dockerfile just because of this, as engineering orgs are typically heterogenous (win/lin/mac).
deleted 7y ago
[deleted]
onion2k 7y ago
I don't think I could use a Mac for software development anymore if they switched away from Intel. A clear message that's been coming from Apple over the past few years is that developers are not a market they care very much about. I strongly suspect a lot of us won't be using Macs for development in the future.
- Veen 7y ago
  They certainly care about Mac developers and iOS developers.
  - protomyth 7y ago
    Looking at the state of documentation and their general lack of responsiveness, I really don't understand where the idea they care is coming from.
  - onion2k 7y ago
    Do they? The App store is so full of automatically generated cookie-cutter apps with minor cosmetic differences that no one can really make a successful app any more. It's a lottery of who gets an Editor's Pick. That's not developer friendly.
    - Veen 7y ago
      Really? My iOS devices are full of high-quality applications that I bought on the App Store: Omnifocus, Omnioutliner, IA Writer, Pixelmator, Bear, Devonthink, Carrot Weather, Overcast, and dozens more.
      - onion2k 7y ago
        I'm not suggesting there aren't great apps out there - I'm saying they're effectively impossible to find, and new app developers pretty much can't break in any more. There are 100 terrible apps for every good one, and you'll never find some of the best apps out there using the app store because of that noise. Finding new apps is driven by word of mouth, curation, etc. Apple themselves add practically nothing to the ecosystem, and certainly not enough to justify their 30% cut. The list you added to your post is a good example of this - all those apps are examples of things that had a community outside of the app store before they had iOS versions. They're not good or successful because of Apple, but in spite of Apple.

webaholic 7y ago

May be by the time Mac has an ARM processor, your deployment server might also be an ARM server. :)

bin0 7y ago

You know one of the great things about VMs? They're cross-platform. I'm guessing once the same amount of optimization is put into arm has has been put into x86, the performance ought to be comparable. I'm also about 99% sure docker can be run on arm (RPIs support it, right?). With that said, I sincerely doubt Apple will kill x86 wholesale overnight. I'm guessing there will be a transitional period of quite some time. Also, windows has been doing a ton of work around getting onto arm. I managed to test on my rpi 3, and it was pretty good. it would probably be very doable.

ihattendorf 7y ago
Cross platform sure, but cross architecture will kill performance.
- rbanffy 7y ago
  Not necessarily. JIT ISA emulation that generates native code for the host ISA has been done for ages now.
  - etaioinshrdlu 7y ago
    My understanding is that you could expect, very roughly, maybe a 50% performance hit using best of breed emulators translating from one ISA to an other ISA nowadays.

microcolonel 7y ago

> So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common. Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Because unless you are, I don't see what the issue would be with multiarch, assuming you don't manually compile the binaries for your containers. Also AArch64 cloud servers are a commodity available from at least Amazon right now, and the hardware is available on the open market. Not to mention, if you're running Docker right now, it's not running natively on macOS anyway. If you're just looking to test basic correctness, then surely you can run your dockers in QEMU or whatever AMD64 DBT/emulator is made available. Apple has a history of shipping good emulators (namely Rosetta and the 68k emulator) for their previous architectures when they change ISA.

tatersolid 7y ago
> Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything. You really need to develop and QA on the expected deployment platform
- microcolonel 7y ago
  > "Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything." Sure, but when it comes to platform enablement, that only really needs to be done once per vertical/native dependency. AArch64 has all of those things you listed. Don't know about .NET (though there's not that much .NET development on Linux, at least not when compared with the amount of Node and Java), but OpenJDK, Node, C/C++/Rust/Go toolchains all have mature support for AArch64, among others. It's obviously less mature than the 40-year-old x86 ecosystem, but it's basically all there. Furthermore, the ease with which new ISAs can be adopted by toolchains and libraries is accelerating, so POWER and RISC-V are also getting there in terms of software availability.

jchw 7y ago

It would be slightly less convenient, but it probably wouldn’t affect your development capabilities so badly. Pretty much any Dockerfile that works on x86 should work on ARM. Linux runs totally fine on ARM. If anything, the worse problems are with Linux desktop and games software that assume ARM == embedded and attempt to use EGL and GLES. There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues. (The latter is straight up a non-issue with a good CD pipeline.) Windows 10 also runs on ARM platforms, with the ability to transparently emulate Intel. I’m sure this is or will be usable inside of VMs even if dual booting is not an option. https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-x86-emulation https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...

StudentStuff 7y ago
Most linux desktops work fine on ARM chips FYI. GPUs in the ARM world are usually just for OpenGL used by video games. Video decoding/encoding is handled by a VPU (not GPU), HDMI is handled by a separate HDMI PHY, and most of these components have mainline, libre kernel support if you use an Allwinner based single board computer. Microsoft has started branding some Mali GPUs as DirectX 11 capable, though YMMV on using these features.
- jchw 7y ago
  Sure, but many games and applications are hardcoded to use EGL and GLES (which is not always available for desktop ARM.) For example, I believe Qt4 makes the assumption that ARM = GLES.
MrBuddyCasino 7y ago
> There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues. I'm not sure thats true. At the very least its going to suck for the first year as gaps are being filled, but those differences might matter too. I would hate to have to duplicate every single Dockerfile just because of this, as engineering orgs are typically heterogenous (win/lin/mac).

deleted 7y ago

[deleted]

onion2k 7y ago

I don't think I could use a Mac for software development anymore if they switched away from Intel. A clear message that's been coming from Apple over the past few years is that developers are not a market they care very much about. I strongly suspect a lot of us won't be using Macs for development in the future.

Veen 7y ago
They certainly care about Mac developers and iOS developers.
- protomyth 7y ago
  Looking at the state of documentation and their general lack of responsiveness, I really don't understand where the idea they care is coming from.
- onion2k 7y ago
  Do they? The App store is so full of automatically generated cookie-cutter apps with minor cosmetic differences that no one can really make a successful app any more. It's a lottery of who gets an Editor's Pick. That's not developer friendly.
  - Veen 7y ago
    Really? My iOS devices are full of high-quality applications that I bought on the App Store: Omnifocus, Omnioutliner, IA Writer, Pixelmator, Bear, Devonthink, Carrot Weather, Overcast, and dozens more.
    - onion2k 7y ago
      I'm not suggesting there aren't great apps out there - I'm saying they're effectively impossible to find, and new app developers pretty much can't break in any more. There are 100 terrible apps for every good one, and you'll never find some of the best apps out there using the app store because of that noise. Finding new apps is driven by word of mouth, curation, etc. Apple themselves add practically nothing to the ecosystem, and certainly not enough to justify their 30% cut. The list you added to your post is a good example of this - all those apps are examples of things that had a community outside of the app store before they had iOS versions. They're not good or successful because of Apple, but in spite of Apple.