Ever since I read Kay Singh’s Apple Silicon M1: Black. Magic. Fuckery article, I couldn’t stop wanting one. My 2012 MacBook Air was in need of a replacement, and although still very serviceable for a 8+year old laptop, not upgrading OSX and a shortened battery lifespan were getting irritating. So, Santa (well, you know) bought me a M1 2020 MacBook Air. At first, I wanted to hold off for a while, after many of the developer tools I use were officially supporting ARM64. But hey, what the heck.
Read the full review: MacBook Pro 13-inch (M1, 2020) See more like this: The best Macs and Macbooks 2018 The Acer ConceptD 7 is a formidable laptop capable of handling complex and demanding tasks. GIMP for Windows. Updated on 2021-04-07: GIMP 2.10.24 installer revision 3 Backported GLib fix for very slow file dialogs (issue #913) and custom GTK2 fix for non-functional Wacom Airbrush finger wheel (issue #6394). With UTM open on your M1 Mac, click the Create a New Virtual Machine button. I gave the VM the name “Windows 10”, added a note that this is “Windows 10 on Apple Silicon”, and added an optional operating system icon (see image below). Naming the UTM Virtual Machine Next, click the System tab. In this video we will install Gimp on a Mac Air M1 with Big Sur and make sure it works with Rosetta 2.
As there’s not a lot of information out there on the M1 from a developers perspective, except a fewother blogs here and there, I wanted to chime in and share my initial findings. Bear in mind that this will very likely change in the near future, as many developers are starting to support the new architecture. An interesting site to check whether your software works is isapplesiliconready.com and doesitarm.com - although these are not always up to date and sometimes provides false information! Be sure to go after the source yourself.
Whatever you do, be sure to upgrade Big Sur to 11.1 first - that will take a while (and eat up more HDD space). I went with the 512GB Air version with eight cores. I don’t care about CPU throttling - even with the 25% performance hit, it still outperforms heavyweight Intel MacBook Pros!
Productivity tools
Before getting to the programming part, let’s take a look at the basic tools I couldn’t live without. First, install iTerm 2. It’s already M1-ready, and Big Sur moved from Bash to Zsh, another good shell I still know from my Gentoo days. Check out technofob.com’s oh-my-zsh config for colors and such, and maybe add extras in your ~.zsh.
Now that you have a shell, we need cmdline stuff. The master branch of Homebrew is ARM64-complaint and you can install two homebrews for the bottles that are still lagging behind - or compile them from source using brew install --build-from-source. I’ve successfully built these from source: sqlite, openssh, python3.9, imagemagick. I set up the M1 homebrew version in /opt/homebrew - and so far, every installation didn’t need a Rosetta alternative - yet. (Heads up: unrar is gone! See link for alternate formula.)
A few other critical pieces of software:
Already running native:
- The Brave nightly build. Most Chromium-based browsers work.
- Rectangle, the upgraded Spectacle one.
- Alfred - of course! I became a convert after fiddling with it, replacing Spotlight and Clipy (see below).
Still on Rosetta - but development on the way:
- Clipy clipboard utility, the upgraded ClipMenu one.
- Hopefully Opera someday soon.
- Sublime Text 3. Preview builds of Visual Studio code are already released.
- Evernote. It runs on Electron, a known-to-be CPU hungry JS shell. The Rosetta one works, but is a bit sluggish and uses a significant amount of battery.
- Update jan. 2021: The latest GIMP 2.10 is finally released for OSX, but there are known Big Sur issues. I didn’t run into a single one.
Update 12 jan. 2021: Sublime Build Systems still use /bin/bash to execute the exec_cmd or cmd commands. This means that your $PATH will be screwed up. There are a couple of options to mitigate this. Fiddling with the internal exec.py file did not work for me. In the end, I simply re-created a .bash_profile file in my home dir to set the path for Sublime Text 3 builds. Using Terminus does not help.
Spotify is a mess, according to some, while others claim that Rosetta is “good enough”. I’d like to run as much stuff as possible native, I guess we’ll have to wait. For now, “it just works”, but as Evernote, is far from optimized.
Java development
The Azul community released ARM64 Java builds that are blazingly fast. There are other solutions, but the Zulu builds I tested so far are great. They even ported the JDK13/JDK11/JDK8 older ones. I settled for v15, since Gradle does not like Java 16 yet, according to the compatibility matrix. Gradle 6.7 builds fine with the ARM64 development kit.
The biggest hurdle for me was JavaFX, the UI libraries we use to teach students the Model-View-Controller principle. It reportedly works under Rosetta, but I wanted to try it native anyway, and got a nice no toolkit found exception, not unlike this one. Funnily enough, it builds fine, but it does not execute: JavaFX looks for a native UI renderer and cannot find one.
Installing JDKs with different architectures turned out not to be problematic, and I can quickly switch between both using an alias:
Paths shouldn’t be hardcoded, but /usr/libexec/java_home -a didn’t work for me. Building this sample FXML project using ./gradlew clean build took about a second natively:
- ARM64:
1378ms - x86_64 Rosetta2:
9646ms! (second time:2459ms, still almost double) - x86_64 MacBook Air 2012:
14590ms (second time:3200ms)
As you can see, combining Rosetta with another “Virtual” Machine is not a particularly great idea. Remember that the 2012 MacBook Air only has 4GB of memory, with eight year old tech.
NetBeans IDE
NetBeans: 12.2 includes Big Sur/Rosetta2 support, but is not running natively. It auto-detects the JDK ARM64 build, which is even more annoying, as setting the default Java Platform is a pain. The “best” way is to manually override netbeans_jdkhome in netbeans.conf. Compared to IntelliJ, NetBeans truly is a piece of shit. Of course, the x86_64 setting also slows down NetBeans itself, not only the project you wish to compile/run.
IntelliJ IDE
IntelliJ: 2020.3 ARM64 test builds are available. It seems that the Rust debugger is not hitting the breakpoints. There’s also a preview PHPStorm build, although I haven’t tried it yet. After opening a Gradle 6.3 project, IntelliJ complains about an invalid Gradle configuration, claiming that JDK15 isn’t compatible with this version of Gradle, although it builds fine on cmdline. Fixing the distribution URL in gradle-wrapper.properties to 6.7.1 does the trick:
After that, the Azul JDK combined with the IntelliJ preview build is a snappy experience and pleasant to work with. Debugging works fine, just as a few third-party libraries I tried - as long as you stay away from JavaFX.
.NET Development
I still need to try this with Rider and Mono. Khalid Abuhakmeh wrote about his experience in a jetbrains blogpost, concluding that it was pleasant to work with .NET on the M1. Bear in mind that he’s talking about Rosetta.
C/C++/Cross-compiling
First, get Xcode from the App Store. Yoink, 12GB!
Next, the CLion IDE: the debugger cannot be launched, official ARM support is currently not there yet, but they’re working on it (last update: 25th of December). One of the perks of being an early adopter, I guess… I don’t want to try this in Rosetta as I only need CLion every odd semester for my teaching activities, and hopefully, by then it’ll be okay.
Until then, I’ll compile and debug cmdline. CMake works flawlessly, using the master version of brew: > Pouring cmake-3.19.2.arm64_big_sur.bottle.tar.gz. Using it to compile the 1.10 release of Google Test gives C++11 errors so you’ll have to add a -DCMAKE_CXX_STANDARD=17 flag to CMake as per this ticket. Compiling itself was extremely quick, compared to what I’m used to on my 2012 MacBook Air.
Game Boy Advance
Cross-compiling GBA stuff using pacman worked flawlessly, obviously in Rosetta mode. I doubt it will ever be released natively. Cross-compiling the whole gba-sprite-library, including four demo projects, took 15343ms. I was surprised that this worked without any problems, and a Rosetta-enabled mGBA happily plays my binaries! On the 2012 laptop, it takes more than twice that long: 32950ms.
Arduino
After finding not so promising Reddit posts, I had to try it out myself. A Github issue tells us Rosetta is supported and “somewhere in the future” native support should be coming - Linux ARM64 builds are already available.
After installing the Arduino IDE (which runs on a JRE, by the way), right-clicking and pressing “Get Info” reveals Kind: Application (Intel). It boots up fairly slowly, but compiling and uploading work without problems. Performance is a non-issue here, you won’t be compiling megabytes of C code anyway.
JavaScript
Node 15.5.0 and its package manager have native bottles uploaded in the master Homebrew repository. Everything works flawlessly after a brew install npm. Do yourself a favor and install a Chromium-based browser to check out Lighthouse.
Go
It’s been a while since I programmed in Go, but Dids created a gist entitled “Compile Go for Apple Silicon (M1)', where he explains how to compile Go natively. I have yet to try it out.
Python
Although python 3.8 comes included with Big Sur, python 3.9 compiled without any issues from source using Homebrew. However, since OSX always seems to come with an annoyingly old 2.7 version, you have to create a symlink in /usr/local/bin to set the default version to 3.9. You may also need to re-link Python:
Writing
Hugo extended works like a charm on ARM64. Pfew!
As for my needed LaTeX tools: the MacTeX about ARM page tells me that full native support will arrive in spring 2021. Until then, Rosetta to the rescue (it also requires 6.7GB…). I do hope that switching will not be problematic, as I can’t wait until then.
As for pandoc that converts my Markdown to LaTeX, compiling from source downloads the x86_64 version of the GHC Haskell compiler. As expected, compilation crashed:
So, I reverted to the x86 installer pkg, which seems to work fine. After the necessary installations, I re-compiled a recently accepted ICSE paper (involving make, pandoc, panflute, pdflatex, bibtex, yaddayadda), and it took 7700ms on the 2012 Air, while the Rosetta x86_64 version took 4447ms. Consider me happy! It will be very interesting to see this number further reduced in spring 2021.
Virtualization
The universal memory structure of the M1 architecture has its advantages, but these obviously fade when dual booting. Furthermore, using something like VirtualBox gets you into further trouble by evenly splitting RAM. It looks like VirtualBox support will never be coming as it requires a x86 CPU.
Alternative options are Parallels, which has a technical preview already published, and VMWare Fusion, which announced on Twitter that they’re working on it.
As of now, there is no possibility for me to run my virtual image of Linux for the Operating Systems course I’m teaching. I guess I’ll be using a Dell laptop for this purpose… I don’t mind, my 2012 MacBook Air didn’t have the required memory to comfortably work with it anyway, so I already resorted to another machine.
Edit 25 jan. 20121: Eleanor pointed me towards a gist to get qemu running on M1. This means it is possible to run Windows 10 and Ubuntu Server on your ARM Mac! On performance: A simple factorial program in ghci is noticeably faster on Ubuntu (ARM64) via qemu than on MacOS via Rosetta. Follow Sevarg’s recent guide to get Ubuntu running under QEmu!
So… Is it worth it?
It depends. If you’re like me, and you have been waiting for a long time to upgrade, now is the best possible time to take the plunge. However, if you already own a more recent MacBook (I hope it’s with a decent keyboard: this one types lovely, compared to my wife’s 2017 butterfly keyboard on the MacBook Pro - what a train-wreck), it might be a better idea to wait half a year.
Currently, with the software I daily use, about 50% of them are running under Rosetta. It is impressive nonetheless: it is seamless and still very fast - except if you’re a Java developer and somehow have to support JavaFX. Don’t forget that the M1 chip comes with other awesome perks:
18hbattery life (more like 10+ with regular compile jobs, but still great)- Greatly improved screen compared to my 2012 laptop
- I finally bought a
QUERTYone. 8GBis more than4GB.- We used the 2020 Air to video-call (using browser-based Jitsi) over Christmas, while we used the 2012 Air during Christmas Eve - the fan went on and it crashed once.
- The instant-on effect is amazing, compared to waiting up to ten seconds.
- I can finally play Baldur’s Gate III!
Like Kay said: Black. Magic. Fuckery!
© Provided by CNET Andrew Hoyle/CNETAs a professional photographer, I was intrigued when Apple ditched Intel's chips and instead started using its own M1 silicon in the MacBook lineup. The performance boosts Apple promised were appealing -- as was the supposed battery life improvement -- but I was nervous about having to run my professional software on a platform that wasn't yet properly supported by some of the tools I use every day.
© Andrew Hoyle/CNETI've spent some time now with the 13-inch M1-based MacBook Pro (with 16GB RAM) and have run it through a variety of tests to see how well I can work on it. Is it a safe upgrade for photographers or other creative professionals? Or should you wait for promised software updates?
Apple using its own chips might seem like a small change that you'll never need to think about, but it has a big impact on how software will run. To get the best performance, the programs you use will need to be rewritten to properly take advantage of the new hardware.
That's potentially a problem, as it requires software developers to support two versions of their products; an Intel version and an Apple M1 version. At the time of writing, Adobe has released an M1 version of Lightroom, but not Lightroom Classic (the version that I, along with most photography pros, still use). The industry-standard Photoshop only supports M1 when you download the beta version, and Adobe hasn't officially given any kind of timeline for when all its Creative Cloud suite of apps will fully support Apple M1.
© Provided by CNET Andrew Hoyle/CNETSo it's useless for photographers?
Not at all. While these apps aren't optimized, they will still run, thanks to Apple's Rosetta 2 software, which allows Intel versions of software to run as normal. That means any app you'd normally want to use on your MacBook will still be able to run on the new model without any difference in how it operates, and you likely won't see much in the way of performance degradation, although that can vary app by app.
In my hands-on testing, I found the M1 versions of Adobe's apps to run extremely swiftly. Lightroom ran lightning fast, and allowed for extremely swift editing and exporting. Even Lightroom Classic (the Intel version) still ran well when used via Rosetta 2.
The improvements are noticeable when using M1-optimized versions. I tested how long it took Photoshop (both in Intel and M1 beta versions) to align 19 full-resolution raw images and then to merge them into a focus-stacked image. It's a technique I use regularly in my product photography, so it's important for me to have good efficiency here.
© Provided by CNET Andrew Hoyle/CNETGimp Macbook M10
Intel-based Photoshop, via Rosetta 2, took 50.3 seconds to align the layers and 1 minute, 37 seconds to merge them. I compared that to an exceptionally powerful Windows desktop PC that was built with an AMD Ryzen 9 3950 X CPU, Nvidia RTX Titan graphics and 128GB RAM, specifically to be a beast with editing photos and 8K video. The PC took 20 seconds to align the layers and 53 seconds to merge them -- a clear victory for the PC.
I then ran the same tests on the beta version of Photoshop that supports Apple M1. It took 22 seconds to align the layers and 46.6 seconds to merge them -- a faster overall time than my immensely powerful editing rig was able to achieve.
In the M1-supported version of Lightroom, it took the MacBook 6.4 seconds to import 100 raw images, edging out the PC's time of 7.1 seconds to complete the same task.
The story was similar when it came to exporting video in Premiere. The Intel-based version of Premiere took 6 minutes, 25 seconds to export on the M1 MacBook, but the optimized M1 beta version took about half the time, at 3 minutes, 24 seconds. For reference, my desktop did the same export in 1:20.
Other software that isn't optimized still runs as normal, and you'd never know that you're running 'emulated' versions of software, as the machine's overall performance is still excellent. It took 51 seconds to import 100 raw images into pro image-editing software Capture One, and the desktop wasn't much in front at 48 seconds. Capture One has said an M1-optimized version is coming in an update, but we don't know exactly when this will be.
Pro video software DaVinci Resolve Studio is also available in beta for M1, and I found it was extremely quick to use, with no issues previewing 4K files in a timeline.
Download Gimp 2020 Mac
© Provided by CNET Andrew Hoyle/CNETOverall I'm impressed. Even when running unoptimized versions of apps, the M1 MacBook Pro still puts up a hell of a fight against a superpowered editing PC, and the fact that it's able to outperform the PC on some tests when using M1-optimized beta apps is astonishing. I'm certainly excited about what performance improvements we'll see as more developers fully optimize their software for Apple's silicon.
Gimp Photo Editor Mac
If you're a photographer and considering upgrading, I'd absolutely say the M1 MacBook is a safe bet. At the very least you'll still be able to use all your current software as normal via Rosetta 2, and in time when official M1 versions are released, those performance boosts -- and likely the battery life savings as well -- will be extremely welcome.
Gimp 2 Download Mac
Read more:MacBook Air M1 review: Big changes from Apple silicon and Big Sur