Ask HN: Is an ARM-based laptop a viable development machine for a Backend dev?
As a Macbook Pro user for the past 4 years (previously linux-on-an-xps), I'm concerned that Apple's move to ARM with the next generation will make them non-viable as a daily driver for dev work. What are people's thoughts on their viability once the initial kinks are ironed out? If the answer is no: good 13" Linux-able laptop suggestions?
76 comments
I think for the next year to two years, backend development on ARM Mac will come with some additional pain. There will always be some package with a C extension that doesn't compile on your platform (for example).
As a non-Mac user (and someone who develops for ARM targets of all sizes) I'm really happy about the situation though. Apple is forcing developers to not be able to assume processor architecture any more, just because what they're developing is aimed at desktop. Lots of software is going to become more portable and we'll all benefit. In the meantime though, I'm going to keep developing on x86/64.
As a non-Mac user (and someone who develops for ARM targets of all sizes) I'm really happy about the situation though. Apple is forcing developers to not be able to assume processor architecture any more, just because what they're developing is aimed at desktop. Lots of software is going to become more portable and we'll all benefit. In the meantime though, I'm going to keep developing on x86/64.
I agree with this completely, unfortunately I'm using a Mac. I'm leaning towards keeping my current Mac running as long as possible in the hopes "everything has all blown over" before I refresh
I believe it'll be a shorter time. These are the first generally usable mainstream ARM machines. From now on, it should be quick.
There's always a long tail. The big issues (like the fact that docker doesn't currently work) will be dealt with quickly, but for every relevant package that 99% of people indirectly need to be updated, and then that updated version to be linked to in the thing you're actually using takes time. It will also turn out that there will be a few things that aren't maintained any more and replacements will be needed.
A lot of the work was already done by the "Raspberry Pi" crowd of early adopters.
I've used a ARM chromebook reinstalled with Linux for dev work. I've ran into problems, especially where you depend on a third-party library that's difficult to build from source or isn't very portable, like JavaFX, some popular Python scientific libraries that are optimized with C code, some GUI packages on Julia behaved weird. I'm happy that Apple is moving to ARM, because it will invigorate the consumer ARM space.
I personally would recommend to go with the T440 series, as it's the last generation of Thinkpads where you can replace all hardware parts yourself. But it's core i-based, so it needs some work regarding Intel ME etc.
The Linux support is amazing, the only thing with Thinkpads is the synaptics driver which needs a config file to make it work as you want it to.
The thinkwiki contains a lot of information about all models, including a list of known problems. [1]
Before you install Linux on any laptop, I would recommend to check for BIOS compatibility. Sometimes there were OEM versions out there where the EFI vars could be deleted and then it's bricked unless you flash coreboot or reflash the original BIOS on it with an adapter.
If you want to go full tinfoil and libre, why not switch to a pinebook?
[1] https://www.thinkwiki.org/wiki/Category:Models
The Linux support is amazing, the only thing with Thinkpads is the synaptics driver which needs a config file to make it work as you want it to.
The thinkwiki contains a lot of information about all models, including a list of known problems. [1]
Before you install Linux on any laptop, I would recommend to check for BIOS compatibility. Sometimes there were OEM versions out there where the EFI vars could be deleted and then it's bricked unless you flash coreboot or reflash the original BIOS on it with an adapter.
If you want to go full tinfoil and libre, why not switch to a pinebook?
[1] https://www.thinkwiki.org/wiki/Category:Models
I love my T460p, which is a lot like that T440, but a macbook it is not. There are no good macbook pro level screens to be had on those older thinkpads, the trackpad is abysmal, and the machine as a whole is cumbersome to carry around. Also, those 4th gen cpu’s in the T440p are getting long in the tooth, new machines are a lot more snappy (especially single core). On the plus side you have a nice selection of ports (but no thunderbolt) and the best laptop keyboard in the industry, and of course the repairability factor. I’d say that if you’re optimizing for developer comfort, other and newer laptops are better, but getting an older thinkpad is a bit like getting an older car for day to day usage, it is something for enthusiasts or people on a budget who are handy.
The pinebook is somewhat underpowered, if someone is considering a macbook and looking at linux alternatives then a system76 laptop or dell xps developer edition is more up their alley budget-wise and will be a far better experience to actually use.
I think as a community we sort of have to come to terms with the notion that repairability is dead. All modern laptops are basically mostly unrepairable, and when they break the old one gets recycled to component metals and you have to get a new one. On the plus side, they break less often. Repairable laptops in turn are just not as nice to use, so they will keep losing in the market. I only see this changing through regulation that forces a right to repair, but if that means thin and lights like a macbook air can no longer be sold, is that really better?
The pinebook is somewhat underpowered, if someone is considering a macbook and looking at linux alternatives then a system76 laptop or dell xps developer edition is more up their alley budget-wise and will be a far better experience to actually use.
I think as a community we sort of have to come to terms with the notion that repairability is dead. All modern laptops are basically mostly unrepairable, and when they break the old one gets recycled to component metals and you have to get a new one. On the plus side, they break less often. Repairable laptops in turn are just not as nice to use, so they will keep losing in the market. I only see this changing through regulation that forces a right to repair, but if that means thin and lights like a macbook air can no longer be sold, is that really better?
There are a lot of used notebooks on the market. They are as good as new except display. Just add RAM and SSD, that would be impossible.
Soldered RAM should be at least twice big to stay relevant in five years. I am in search of a new notebook and some premium Dell models have 16GB top. How long people are going to keep them?
Soldered RAM should be at least twice big to stay relevant in five years. I am in search of a new notebook and some premium Dell models have 16GB top. How long people are going to keep them?
I wouldn't recommend any Thinkpad of the xx40 series because of the dreadful trackpad/clickpad. It might not be a dealbreaker for you but it's indeed a downside to consider given how unusable it is. A lot of people actually replace it with a xx50 trackpad.
T440 have obnoxiously bad screens.
You can upgrade them to IPS from T480 series.
Very little will change for most developers.
I suspect you're deploying on Linux, right? You're already building and deploying on different operating systems, how much can a different architecture complicate things? Well...
What if you're using interpreted or VM languages (Python, Java, PHP)? Unless you have native dependencies, very little changes.
If you build native code (C/C++, Go, Rust), then you might need to cross-compile. That might range from super-easy if you're 100% Rust or Go, to challenging if you have C/C++ dependencies.
But you use CI, right? In that case, the problem almost disappears. Test locally (ARM) without cross-compiling, build and deploy on CI (x86) without cross-compiling.
Who builds deployment artefacts locally these days? Hopefully very few. :-)
There are some macOS-on-M1-specific issues you might face if you're using Docker (native ARM or virtualised x86) containers, but those will clear up soon enough.
I'd take the improved CPU and memory performance of the M1, but I don't need a laptop refresh, and the Mac Mini can't drive two DisplayPort displays yet.
I suspect you're deploying on Linux, right? You're already building and deploying on different operating systems, how much can a different architecture complicate things? Well...
What if you're using interpreted or VM languages (Python, Java, PHP)? Unless you have native dependencies, very little changes.
If you build native code (C/C++, Go, Rust), then you might need to cross-compile. That might range from super-easy if you're 100% Rust or Go, to challenging if you have C/C++ dependencies.
But you use CI, right? In that case, the problem almost disappears. Test locally (ARM) without cross-compiling, build and deploy on CI (x86) without cross-compiling.
Who builds deployment artefacts locally these days? Hopefully very few. :-)
There are some macOS-on-M1-specific issues you might face if you're using Docker (native ARM or virtualised x86) containers, but those will clear up soon enough.
I'd take the improved CPU and memory performance of the M1, but I don't need a laptop refresh, and the Mac Mini can't drive two DisplayPort displays yet.
> What if you're using interpreted or VM languages (Python, Java, PHP)? Unless you have native dependencies, very little changes.
Raspberry Pi really did a great job moving this ball forward in regards to Pip. Most packages will readily install, except a few scientific ones (I still can’t install scipy on my pi).
Go, on the other hand, is extremely easy to develop on and port.
Raspberry Pi really did a great job moving this ball forward in regards to Pip. Most packages will readily install, except a few scientific ones (I still can’t install scipy on my pi).
Go, on the other hand, is extremely easy to develop on and port.
My recollection of the PowerPC Mac era is that compiling anything open-source was fraught with challenges. My system would typically end up with acres of cruft and one-off hacks just to get things to build.
Life's different in 2020: there's Docker and, if you can tolerate the attitude, Homebrew. It should be easier this time around. But I'd be wary of moving to ARM quite yet for anything that requires manual compilation. I'm certainly not going to make the leap until I've seen that other people have successfully built some of the more esoteric parts of the toolchain I use.
Life's different in 2020: there's Docker and, if you can tolerate the attitude, Homebrew. It should be easier this time around. But I'd be wary of moving to ARM quite yet for anything that requires manual compilation. I'm certainly not going to make the leap until I've seen that other people have successfully built some of the more esoteric parts of the toolchain I use.
> if you can tolerate the attitude
Maintainer here. Not sure if you’re referring to the way Homebrew is technically implemented, or the maintainers’ attitude.
Either way, what would you prefer us to do better/differently?
Maintainer here. Not sure if you’re referring to the way Homebrew is technically implemented, or the maintainers’ attitude.
Either way, what would you prefer us to do better/differently?
The tone taken in Github issues can be really, really hostile. The very first thing a user sees in the issue template is a shouty headline about being blocked. There are many comments which come across to me as passive-aggressive such as https://github.com/Homebrew/brew/issues/5675#issuecomment-46... or the last para at https://github.com/Homebrew/brew/issues/5654#issuecomment-46... .
I appreciate that you have a near-impossible mission in helping diagnose people's installation issues. I don't envy you, and I appreciate the technical work you do. Few open source projects are immune from the challenges of burnout caused by ingrate users and Homebrew probably gets it worse than most. As a maintainer, I 100% get it. But as a user, it puts me off using the software. I now use Homebrew much less than I used to as a result.
I appreciate that you have a near-impossible mission in helping diagnose people's installation issues. I don't envy you, and I appreciate the technical work you do. Few open source projects are immune from the challenges of burnout caused by ingrate users and Homebrew probably gets it worse than most. As a maintainer, I 100% get it. But as a user, it puts me off using the software. I now use Homebrew much less than I used to as a result.
I see. Thank you for taking the time to explain and even provide examples. Much appreciated and insightful.
I’ve been thinking a lot about how to make the issue template friendlier while keeping the rate of poorly written reports at an acceptable level. We definitely need to change our approach. Setting a hostile frame in an issue template isn’t helping anyone.
Thanks again for taking your time to explain. We still have a lot to learn and improve.
I’ve been thinking a lot about how to make the issue template friendlier while keeping the rate of poorly written reports at an acceptable level. We definitely need to change our approach. Setting a hostile frame in an issue template isn’t helping anyone.
Thanks again for taking your time to explain. We still have a lot to learn and improve.
Wow, really good handling on your part here. Always nice to see how people are able to discuss these things in a productive manner. Thanks for homebrew, made the switch from linux possible for me :) great work.
applauds
For myself, it’s the attitude to system permissions. It really shouldn’t expect a specific user to own anything in particular. MacPorts get this bit right.
> if you can tolerate the attitude, Homebrew.
If you can't, there's MacPorts. It's rock solid, even if not at the bleeding edge of everything.
If you can't, there's MacPorts. It's rock solid, even if not at the bleeding edge of everything.
Yeah, well, Docker doesn't currently work so smoothly on Apple Silicon: https://github.com/docker/for-mac/issues/4733
Which is a bit surprising. Weren't they using HyperKit for virtualization?
The chips that were in the special Developer Transition Kit hardware that developers got over the summer did not support hardware virtualization, so there was no way for the Docker team to test. The M1 chip in the Macs shipping this week has that support, so the Docker team should be able to get things running soon.
Makes a lot of sense. There is no reason HyperKit would fallback to software virtualization when hardware support is not available because it's always been available for supported x86 Macs.
What kind of backend dev work?
I do backend with Python, Julia and PHP.
They all have ARM builds and I’m not expecting issues. I’ve worked with them on ARM and have a few pi’s around running with projects on them.
But it depends on the type of backend work. If you’re using C and assembly and need to target x86, then I can see issues.
Regarding the move, I expect these first ones to be targeted more to regular users and to projects testing their projects on them.
IMO the main reason why things aren’t working on them right now is due to there not being availability and projects not having to move to it yet. But there’s no technical reason why things won’t be ported for them. The ecosystem just needs to grow.
I do backend with Python, Julia and PHP.
They all have ARM builds and I’m not expecting issues. I’ve worked with them on ARM and have a few pi’s around running with projects on them.
But it depends on the type of backend work. If you’re using C and assembly and need to target x86, then I can see issues.
Regarding the move, I expect these first ones to be targeted more to regular users and to projects testing their projects on them.
IMO the main reason why things aren’t working on them right now is due to there not being availability and projects not having to move to it yet. But there’s no technical reason why things won’t be ported for them. The ecosystem just needs to grow.
Mostly Python & JS in containers + the infra-supporting work. I guess my main concerns are OS packages (e.g. image processing libs) and docker/k8s.
And RE ecosystem: yeah I hope you're right (and think you are), I guess I'm just wondering what the odds are, and how feasible a switch back to Linux is without losing out on he niceness of mac-land.
And RE ecosystem: yeah I hope you're right (and think you are), I guess I'm just wondering what the odds are, and how feasible a switch back to Linux is without losing out on he niceness of mac-land.
There's currently an issue with Docker and they weren't able to fix it because the dev machines they where sending out didn't have virtualization enabled so they couldn't work on it.
This issue is regarding to starting docker.
Once that's up, there will be an issue with prebuilt images if they don't provide an ARM build. As more machines get out there, this should start to fix itself. For Python and JS, I don't foresee an issue with the projects that would prevent this. It's then an issue of who manages the project and if they want to do it or someone else forking it and providing arm builds. Not a big issue IMO. It's a fairly easy thing to do.
Anecdote, switching back to Linux, I've toyed with it recently and... it's not as frictionless (which sucks).
I run a bit of Linux infrastructure and I'm on servers all the time. But on laptops, I don't know why, I kept having issues. I went in knowing I won't have the integration and whatnot, but I still had some issues.
I ran it on extra, older, Apple hardware I have. Not sure if that might be why and newer or more compatible hardware would work better.
This issue is regarding to starting docker.
Once that's up, there will be an issue with prebuilt images if they don't provide an ARM build. As more machines get out there, this should start to fix itself. For Python and JS, I don't foresee an issue with the projects that would prevent this. It's then an issue of who manages the project and if they want to do it or someone else forking it and providing arm builds. Not a big issue IMO. It's a fairly easy thing to do.
Anecdote, switching back to Linux, I've toyed with it recently and... it's not as frictionless (which sucks).
I run a bit of Linux infrastructure and I'm on servers all the time. But on laptops, I don't know why, I kept having issues. I went in knowing I won't have the integration and whatnot, but I still had some issues.
I ran it on extra, older, Apple hardware I have. Not sure if that might be why and newer or more compatible hardware would work better.
RE docker: yeah I saw that, I've no doubt that they'll get a working build - I kind of suspect that how long it takes might be a good idea of how hard it is to get working :D
RE docker images: yeah thankfully the big hitters (alpine etc) will be fine so should be ok here. I have less confidence in supporting libs though.
RE linux: Argh, sounds like we're of similar backgrounds and this is my fear to be honest. I've heard good things about dell/lenovo hardware so I'd probs have to swing that way for the next refresh, but yeah i suspect it won't be as painful as I'd like.
RE docker images: yeah thankfully the big hitters (alpine etc) will be fine so should be ok here. I have less confidence in supporting libs though.
RE linux: Argh, sounds like we're of similar backgrounds and this is my fear to be honest. I've heard good things about dell/lenovo hardware so I'd probs have to swing that way for the next refresh, but yeah i suspect it won't be as painful as I'd like.
I'd be impressed if they could get a docker on the Mac working with not absolutely crappy volume mount performance.
> Once that's up, there will be an issue with prebuilt images if they don't provide an ARM build.
Does docker run on macos (amd64) now? I thought it ran in a Linux vm? If they get the vm to run, all images should work exactly the same as before (modulus any hit for amd64-on-arm vs amd64-on-amd64)?
Does docker run on macos (amd64) now? I thought it ran in a Linux vm? If they get the vm to run, all images should work exactly the same as before (modulus any hit for amd64-on-arm vs amd64-on-amd64)?
They do.
It uses a Linux environment for it.
The issue is anything compiled or baked into the image using x86, won’t be able to run without yet another translation layer.
Could end up being
Mac arm > qemu emulating amd64 cpu > docker vm (Linux amd64) > whatever application
Could be done, just adds another layer to translate things and overhead.
It uses a Linux environment for it.
The issue is anything compiled or baked into the image using x86, won’t be able to run without yet another translation layer.
Could end up being
Mac arm > qemu emulating amd64 cpu > docker vm (Linux amd64) > whatever application
Could be done, just adds another layer to translate things and overhead.
I don't think a blanket answer will apply to everyone here: which specific tools that YOU use won't support ARM (and until when exactly)? If some tools won't support it for a while, can you live without them? Do you need to run all these backend tools on your own machine?
I think many people are trying to figure these questions for them out right now, as there is very little information yet on ARM support from many tools.
I think many people are trying to figure these questions for them out right now, as there is very little information yet on ARM support from many tools.
Yeah, totally agree - ironically I think it's rad that apple are kind of forcing this adoption of ARM. Could lead to cheaper/more energy efficient servers as adoption increases. I guess it just isn't the kind of thing I'm keen to be an early adopter for (admittedly selfishly).
Yea personally I'm the same boat. But going out and buying a macbook with an intel processor also doesn't seem a great idea as that's definitely not the focus going forward.
> I do backend with Python, Julia and PHP.
> They all have ARM builds and I’m not expecting issues.
I expect Julia to have an advantage here, as so much of Julia libs are pure Julia.
Id be surprised if php and python does not run in to problems with extensions, like database drivers, various libraries (eg: ssl/crypto, math, image processing etc).
Same for server side Javascript.
Will be interesting to see if Apple does a 180 and roll out servers again.
Ed: i expect database drivers might be an issue for Julia too.
> They all have ARM builds and I’m not expecting issues.
I expect Julia to have an advantage here, as so much of Julia libs are pure Julia.
Id be surprised if php and python does not run in to problems with extensions, like database drivers, various libraries (eg: ssl/crypto, math, image processing etc).
Same for server side Javascript.
Will be interesting to see if Apple does a 180 and roll out servers again.
Ed: i expect database drivers might be an issue for Julia too.
Sure, but the nice thing about them is that they can all be recompiled at worst and then keep working.
BLAS libraries on ARM are much more varied in quality than on x_86
If you do decide to go with Linux:
- Dell XPS (mac-like comes with Linux)
- Lenovo Thinkpad (excellent Linux support, as it is used by a lot of Linux devs)
- Any of the Linux CTO laptop builders (Librem, Tuxedo, ...) will have excellent support, but will not look as good as the Dell
- Anything else: YMMV, check the reviews.
- Dell XPS (mac-like comes with Linux)
- Lenovo Thinkpad (excellent Linux support, as it is used by a lot of Linux devs)
- Any of the Linux CTO laptop builders (Librem, Tuxedo, ...) will have excellent support, but will not look as good as the Dell
- Anything else: YMMV, check the reviews.
THe support is good on the XPS. Everything works out of the box (apart from the standard linux trackpad multi touch issues.)
a word of caution, the 2019 13" has a stupid[1] keyboard layout. They cram the pageup/down keys above the left right keys. This caused huge amounts of issues for me, making it unusable. If this were to be fixed, it would be a very compelling machine.
[1]subjective
a word of caution, the 2019 13" has a stupid[1] keyboard layout. They cram the pageup/down keys above the left right keys. This caused huge amounts of issues for me, making it unusable. If this were to be fixed, it would be a very compelling machine.
[1]subjective
If you get an XPS with windows. It’s a pain to install linux because of some weird Intel thing needing to be disabled first. Caused me a lot of headache. Runs great once you get past that tho.
Lenovo on the other hand. Just works.
Lenovo on the other hand. Just works.
Personally I'm on my 3rd XPS running Linux, and the install has mostly been smooth sailing.
The BIOS is configured for RAID rather than AHCI/SATA by default. Bumped into that with mine. It was fairly easy to modify Windows to not use the RAID version so I could boot into Linux on one drive and boot into Windows on the other. Suspect I could get Centos to go the RAID route, but did not want to mess with it.
I had one of the first XPSs, and it was a 'mare for the first few months - I'm kinda surprised it's still that much of an issue to be honest.
I love my Lenovo T4xx. Linux was a breeze to install.
I just wish the Fn and Ctrl keys were swapped. Although you can change it in the bios.
I just wish the Fn and Ctrl keys were swapped. Although you can change it in the bios.
I did this and it was smooth sailing. All I had to do was set the hard drives from RAID to ACHI in the BIOS.
I should have mentioned I was trying to dual boot too. And Windows doesn’t like the flat out change. You need to change the settings in windows before changing the bios. Something I didn’t need to do on my Lenovo.
My XPS with Linux (installed by dell, no customization except for user space packages) will freeze/stall about twice a day and needs to be rebooted with the power button, losing all unsaved work.
Dell does not offer any support for this computer's software so there's not really a remedy except keeping drivers up to date and hoping it gets fixed someday.
Would not recommend it for anything but personal work right now.
Dell does not offer any support for this computer's software so there's not really a remedy except keeping drivers up to date and hoping it gets fixed someday.
Would not recommend it for anything but personal work right now.
Or stump up for the Precision 5540 if you have the cash. That running arch and i3 and you are cooking with gas!
I recently got a 'Build Your Own' Precision 7750. After-market RAM and SSDs were far cheaper than Dell's offering.
I'm a bit gutted though, no Ryzen CPUs were offered and considering how much I spent I won't be buying another laptop for at least 10 years.
I'm a bit gutted though, no Ryzen CPUs were offered and considering how much I spent I won't be buying another laptop for at least 10 years.
The RAM limit is a bit concerning in the long term. Apart from that, there are some pains right now with some tools (Docker doesn't work yet) that will be resolved soon. It still runs macOS software for x86 too, so that'll help with the transition. When available, I'll get a maxed out 32 or 64GB one myself.
On the Linux side, my advice is to avoid the "fancy" ones that don't explicitly support Linux. Avoid dGPUs if you can and stick to Intel graphics. Beware some machines are coming out with soldered RAM, mostly in the ultrathin category.
On the Linux side, my advice is to avoid the "fancy" ones that don't explicitly support Linux. Avoid dGPUs if you can and stick to Intel graphics. Beware some machines are coming out with soldered RAM, mostly in the ultrathin category.
> If the answer is no: good 13" Linux-able laptop suggestions?
https://puri.sm/products/librem-14/
https://puri.sm/products/librem-14/
This is just a personal preference, but I like to do all of my development work remotely.
I use visual studio code and just have ssh connections set up. When I open a project, the terminal auto connects to my dev server.
I can open and edit any file, push to git, deploy, and not need anything on my local machine.
It keeps the need for resource usage low, and all of your code is in one place so you can switch machines easily.
Throw a sim card in the laptop and you can literally just open it up and program from anywhere without a hassle.
I use visual studio code and just have ssh connections set up. When I open a project, the terminal auto connects to my dev server.
I can open and edit any file, push to git, deploy, and not need anything on my local machine.
It keeps the need for resource usage low, and all of your code is in one place so you can switch machines easily.
Throw a sim card in the laptop and you can literally just open it up and program from anywhere without a hassle.
It depends a lot on the tools you use and what your target system is. Docker and all (edit: some!) of the GNU tools won't work for a while on the Macbook.
What I would suggest, if your target is Linux and your tooling allows, is to develop directly on the cloud. It is completely seamless with Visual Studio Code. You can run edit your files, build your code, run it and debug it on a cloud VM just like you would do it locally. It also means that it doesn't really matter how fast (and expensive) your Notebook is, since all the real work takes place in the cloud. Not sure how well other development environments support it though.
Another issue you may run into is that none of the ARM Macbooks support two external screens. You can only use a single screen, plus the built-in screen. I don't mind, since I prefer to use a single widescreen, but I know a lot of people who work with 2 monitor setups.
What I would suggest, if your target is Linux and your tooling allows, is to develop directly on the cloud. It is completely seamless with Visual Studio Code. You can run edit your files, build your code, run it and debug it on a cloud VM just like you would do it locally. It also means that it doesn't really matter how fast (and expensive) your Notebook is, since all the real work takes place in the cloud. Not sure how well other development environments support it though.
Another issue you may run into is that none of the ARM Macbooks support two external screens. You can only use a single screen, plus the built-in screen. I don't mind, since I prefer to use a single widescreen, but I know a lot of people who work with 2 monitor setups.
The GNU tools in general work just fine.
It seems like at least parts of gcc, including GFortran, and tools that depends on it, like R, do not support the new ARM ABI: https://developer.r-project.org/Blog/public/2020/11/02/will-...
Pardon my ignorance, but wasn't Docker supposed to fix this? (disparity of environments). I have read the other recently post as well about "Docker doesn't work on the new ARM based Macs", but I don't understand why. I mean, Docker has this in their website (https://www.docker.com/use-cases):
> It works on my machine! As a developer you know that one of the trickiest problems in software development is having to deal with environment disparity across different machines and platforms. Docker allows you to run containers locally, eliminating disparity between your development and production environments, and everything in between. [...] (Docker) is the ultimate answer to your portability concerns as containers can easily move across machines.
Is that not true?
> It works on my machine! As a developer you know that one of the trickiest problems in software development is having to deal with environment disparity across different machines and platforms. Docker allows you to run containers locally, eliminating disparity between your development and production environments, and everything in between. [...] (Docker) is the ultimate answer to your portability concerns as containers can easily move across machines.
Is that not true?
Docker images package the entire environment that an application needs to run, but to do that they contain precompiled software for a specific CPU architecture, so they can't help you jump across architectures. Not even a full VM allows that by itself, for running software for a different architecture you need emulation.
https://github.com/docker/for-mac/issues/4733 "Docker fails to launch on Apple Silicon #4733"
Even though, yes, in theory. Each new platform and arch requires work.
Even though, yes, in theory. Each new platform and arch requires work.
Anything webdev related should have good support because so many web developers are using macs.
Curiously, since most web traffic come from mobile devices, you have the situation where web developers on x86 machines are writing JavaScript code that run on ARM devices. Doesn't seem to be an issue so far.
True, taking this further, even react-native JS is running fine on arm devices right. I suspect it's more the "untested" waters of backend-land that'll suffer more here
Mmmm, I think you're right eventually, but how long it'll take, and how much of the more complex stuff will work is more my concern.
I needed 2 days to support aarch64 for SIMD heavy and assembler optimized code for smhasher, a collection of all useful hash functions. Extremely low level stuff. Even without using any SIMD abstractions library.
I don't expect any problems for all my higher level work. aarch64 is much nicer than power, s390, mips or sparc (oh the horror)
It's extremely nice to offload heavy computations to all your phones in parallel btw. They are faster than my Macbook Air. I have now a little phone cloud via GNU parallel and ssh. Comes more handy than the heavy x86 machines.
It's extremely nice to offload heavy computations to all your phones in parallel btw. They are faster than my Macbook Air. I have now a little phone cloud via GNU parallel and ssh. Comes more handy than the heavy x86 machines.
Why not fire up an ARM vm instance of linux on your machine using qemu and see if the packages you want are viable? Make sure to enable acceleration and nested virtualization if you want to test containers.
What's the likelihood that running a non MacOS in emulation would still be a reasonable dev environment compared to native on some other hardware?
Well, the only honest answer would be "we don't know yet". Stick to your current hardware and keep watching what's going on.
Yes.
> I'm concerned that Apple's move to ARM with the next generation will make them non-viable as a daily driver for dev work.
Nothing will change, you’ll have still possibility to work as a developer, with each year even more and more. Adding to that Apple will not ditch intel any time soon, at least until they can satisfied needs for most customers pro and not.
People are always afraid of changes on big scale, but they are good to move industry forward. Embrace it and don’t panic too soon. :)
EDIT: Yes, of course downvotes. To anyone doing this, you can still use your favorite C64 but don’t slow down the rest of the world.
Nothing will change, you’ll have still possibility to work as a developer, with each year even more and more. Adding to that Apple will not ditch intel any time soon, at least until they can satisfied needs for most customers pro and not.
People are always afraid of changes on big scale, but they are good to move industry forward. Embrace it and don’t panic too soon. :)
EDIT: Yes, of course downvotes. To anyone doing this, you can still use your favorite C64 but don’t slow down the rest of the world.
I don't think it's helpful to be so nonchalant about Apple's breaking changes. It would come at significant cost to my organisation if Apple made changes to MacOS that meant Nix would no longer function. That almost happened. Luckily, the Nix developers found a workaround for Catalina, though it's awkward and it's more to maintain.
Changing the arch is also costly and has far-reaching implications, and the work that goes into mitigating this is not insignificant.
https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html
Changing the arch is also costly and has far-reaching implications, and the work that goes into mitigating this is not insignificant.
https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html
Like everything in life changes cost one way or another, it doesn’t mean it’s bad. ;)
I think that's easy to say if you're not the guy paying the bills.
Yes, of course, have a great day and everything.