14 ms·

Ask HN: Is an ARM-based laptop a viable development machine for a Backend dev?

• d3nj4l 6y ago
  I think you mean ARM, not AMD. There's absolutely no problem with using an AMD device for backend work.
  • kinix 6y ago
    sigh yes, yes i did. I've built PCs with AMD before and am a big fan, but clearly going full tech-malapropism
• rovr138 6y ago
  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.
  • kinix 6y ago
    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.
    • rovr138 6y ago
      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.
      • kinix 6y ago
        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.
        • wiredfool 6y ago
          I'd be impressed if they could get a docker on the Mac working with not absolutely crappy volume mount performance.
      • e12e 6y ago
        > 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)?
  • nl 6y ago
    BLAS libraries on ARM are much more varied in quality than on x_86
  • e12e 6y ago
    > 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.
    • rovr138 6y ago
      Sure, but the nice thing about them is that they can all be recompiled at worst and then keep working.
• dmos62 6y ago
  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.
• nicoburns 6y ago
  Anything webdev related should have good support because so many web developers are using macs.
  • kinix 6y ago
    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.
  • yen223 6y ago
    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.
    • kinix 6y ago
      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
• quarantine 6y ago
  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.
  • philliphaydon 6y ago
    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.
    • robert_foss 6y ago
      Personally I'm on my 3rd XPS running Linux, and the install has mostly been smooth sailing.
    • kinix 6y ago
      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.
    • blackrock 6y ago
      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.
    • SweetestRug 6y ago
      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.
      • philliphaydon 6y ago
        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.
• monkin 6y ago
  > 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.
  • yakshaving_jgt 6y ago
    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 https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html
    • monkin 6y ago
      Like everything in life changes cost one way or another, it doesn’t mean it’s bad. ;)
      • yakshaving_jgt 6y ago
        I think that's easy to say if you're not the guy paying the bills.
        • monkin 6y ago
          Yes, of course, have a great day and everything.
• cookiengineer 6y ago
  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 https://www.thinkwiki.org/wiki/Category:Models
  • sam_lowry_ 6y ago
    T440 have obnoxiously bad screens.
    • cookiengineer 6y ago
      You can upgrade them to IPS from T480 series.
  • turlando 6y ago
    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.
  • Joeri 6y ago
    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?
• rkangel 6y ago
  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.
  • kinix 6y ago
    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
  • rbanffy 6y ago
    I believe it'll be a shorter time. These are the first generally usable mainstream ARM machines. From now on, it should be quick.
    • rkangel 6y ago
      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.
      • rbanffy 6y ago
        A lot of the work was already done by the "Raspberry Pi" crowd of early adopters.
• fsflover 6y ago
  > If the answer is no: good 13" Linux-able laptop suggestions? https://puri.sm/products/librem-14/ https://puri.sm/products/librem-14/
• jdub 6y ago
  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.
  • ed25519FUUU 6y ago
    > 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.
• tjansen 6y ago
  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.
  • saagarjha 6y ago
    The GNU tools in general work just fine.
    • tjansen 6y ago
      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-r-work-on-apple-silicon/index.html https://developer.r-project.org/Blog/public/2020/11/02/will-...
• Doctor_Fegg 6y ago
  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.
  • cptwunderlich 6y ago
    Yeah, well, Docker doesn't currently work so smoothly on Apple Silicon: https://github.com/docker/for-mac/issues/4733 https://github.com/docker/for-mac/issues/4733
    • rbanffy 6y ago
      Which is a bit surprising. Weren't they using HyperKit for virtualization?
      • ncw96 6y ago
        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.
        • rbanffy 6y ago
          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.
  • rbanffy 6y ago
    > 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.
• nottorp 6y ago
  Well, the only honest answer would be "we don't know yet". Stick to your current hardware and keep watching what's going on.
• rbanffy 6y ago
  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.
• rwdim 6y ago
  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.
• xnx 6y ago
  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?
• kjaftaedi 6y ago
  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.
• ingvul 6y ago
  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 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?
  • lfischer 6y ago
    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.
  • valbaca 6y ago
    https://github.com/docker/for-mac/issues/4733 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.
• johnklos 6y ago
  Yes.
• rurban 6y ago
  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.