Macbook Air M1 Vmware Fusion

Posted onby admin

It's not mentioned which MacBook Pro is being used, but it's a safe bet that the CPU is capable of VT-x but it may be disabled. I've checked a 2012 iMac, a 2017 MacBook Pro and a 2014 Mac mini and all had VT-x supported and enabled. Check if supported: To check if your Mac supports VT-X, issue the following command. Last month, VMware announced the next major version of its virtualization software for Mac, Fusion 12, and as of today, the update is now available. As we noted last month, Fusion 12 includes a.

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.

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.

Vmware

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.

Vmware On M1

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

Macbook Air M1 Vmware Fusion Manual

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!

Vmware

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:

  • 18h battery life (more like 10+ with regular compile jobs, but still great)
  • Greatly improved screen compared to my 2012 laptop
  • I finally bought a QUERTY one.
  • 8GB is more than 4GB.
  • 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!

Were Charles Darwin here today, once he’d finished screaming at us for tinkering with necromancy and demanding to know what the heck a Lexus was, I think he’d want to see the new MacBook Air. Apple’s M1-powered notebook is one of a trio of Apple Silicon showcases and, as the “Father of Evolution” was well aware, some generations take a leap forward, not just a step.

Though at $999 the M1 MacBook Air isn’t the cheapest model to use Apple’s homegrown chipset – the new Mac mini starts at $699, albeit before you budget for a display and peripherals – it’s arguably the purist example of Cupertino’s strategy. Fanless and self-contained, it promises a beguiling combination of flexible performance and battery life, wrapped up in a familiar design.

The aesthetic explains how Apple could bring its first Apple Silicon models to market so rapidly, since it didn’t need to retool for new laptop or desktop chassis. In fact you’ll need to slap an “M1 Inside” sticker on the lid if you want people to know you’re at the cutting-edge. Some of the function key labels are tweaked versus the Intel-powered Air, but otherwise this is the same ultraportable we’ve known for a few years now.

That means a 13.3-inch 2560 x 1600 Retina display, a full-sized Magic Keyboard, Touch ID built into the power button, a sizable trackpad, and a 720p FaceTime HD camera above the screen. The port selection remains as controversial as ever, with two Thunderbolt 3 on the left side (that also work as USB 4 Type-C), and a 3.5mm headphone jack on the right. While I agree that two ports on a MacBook Pro seems miserly, I think the selection is just about acceptable on the slimmer MacBook Air.

Inside, 8GB or 16GB of memory, between 256GB and 2TB of SSD storage, and both WiFi 6 802.11ax and Bluetooth 5.0 wireless can be found. Star of the show is the Apple M1, of course, though the specifications differ very slightly depending on which MacBook Air configuration you buy.

The entry-level $999 machine with 8GB of memory – the one I’m reviewing – uses an M1 variant with an 8-core CPU, a 7-core GPU, and a 16-core Neural Engine. The $1,249 version of the Air, however, has an M1 variant with an 8-core GPU. Both, though, are capable of driving up to a single 6K 60Hz external display (at least, officially).

As anybody following the Apple Silicon story likely already knows, the headline here is Apple using for its Macs the same chip tech that powers its iPhone and iPad models. That combination of Arm-based hardware – versus Intel’s x86 processors – and software like macOS Big Sur allows for the same sort of optimizations on Mac that have long made iOS and iPadOS such powerhouse platforms. It also helps narrow the gap between those three ecosystems, computer and tablet and phone, by supporting native iOS/iPadOS apps on macOS for the first time.

The flip side to that is compatibility with the apps Mac owners have already been using. It’s a problem that has stymied attempts by Microsoft and Qualcomm to coax Windows on Arm into making any sort of splash: getting all the pieces of apps, operating system, laptop, and the core chipset to line up properly has turned out to be akin to herding cats. Apple’s solution – in somewhat typical Cupertino fashion – is a mixture of stick and carrot.

On the one hand, the transition is inevitable. Apple may still have Intel-powered Macs coexisting alongside their Apple Silicon counterparts for a while to come, but the writing is undoubtedly on the wall for them. Developers are under no misconception about the future of the platform.

To make it less arduous a change are things like Rosetta 2. In short, while native software written for Apple Silicon is best, Rosetta 2 allows apps written for Intel-based Macs to run on the new M1 and future Apple-designed chipsets. In theory, it means the same programs you’re used to running on your old Mac should work on your new MacBook Air. Indeed, Apple says you could even notice an uptick in speed.

I suspect most software the typical MacBook Air user requires will run just fine. Apple’s own apps are, you’ll be unsurprised to hear, ready for the M1: if you use Pages, Numbers, and Keynote for your productivity; Mail for your email; iMovie for your videos; and Safari for your browsing, you’re good to go out of the box. Even more complex apps, like Final Cut Pro, along with some third-party heavyweights like Microsoft Office 365 and Google Chrome, now have Apple Silicon versions, at least in public beta.

Vmware on m1 mac

It’s not a clean sweep, though, despite what Apple suggests. The closer to edge-cases you get, the more likely you are to run into issues with compatibility. Parallels users, for example, won’t be able to use that software to run Windows; if you’re a VMWare Fusion user, you’ll find it doesn’t play properly with Rosetta 2 virtualization either.

Manual

Much as with the port selection, I feel like the majority of MacBook Air owners won’t run into these sort of problems. There are handy third-party sites keeping check of what apps are running smoothly and which are not, so it’s worth checking if there’s a must-have title you can’t live without. The reality, though, is that software developers want access to Mac users, and that’s going to fuel the transition whether they’re happy about it or not.

Macbook Air M1 Vmware Fusion Specs

The other big concern some have voiced is memory. None of Apple’s M1-based Macs can be configured with more than 16GB of RAM at the moment, which on paper is a compromise versus the 32GB+ that some Intel models can be equipped with. Thing is, it just isn’t quite an apples to apples comparison.

This new MacBook Air uses what Apple refers to as “unified memory” and, at its most fundamental, it means the memory is physically integrated into the M1 chipset itself. Intel-based Macs – even those with permanently soldered RAM chips – have separate slots. It allows all parts of the M1, whether processor, graphics, or Neural Engine, to tap into that same shared memory pool.

It adds flexibility, but it also pays dividends on speed. Rather than having to copy something from CPU memory to GPU memory, when the graphics chip wants to work on something the processor was handling, all of the M1’s cores can address the same data in that shared memory.

Now, even with those advantages, that’s not to say you can’t run out of memory (at which point macOS Big Sur offloads to the slower SSD, as usual). What has proved a huge surprise, though, is just how difficult that is to do in day to day use.

I’m not a conservative memory-user. In fact you could argue I’m positively profligate: in a typical day I run Safari and Chrome simultaneously, each with at least a couple of windows open, and with 6+ tabs loaded in each of those windows. Then there’s Apple Mail, and the messaging app the SlashGear team uses, and Affinity Photo for image editing, and usually a dozen or so TextEdit windows along with iMessage. Periodically I’ll load up Final Cut Pro X, too.

My everyday machine is a 16-inch MacBook Pro with 32GB of memory and a Core i9 processor, and sometimes it’s just not a happy bunny. Chrome is a notorious memory-hog, sure, but at some point there’s only so much grunt to go around.

The degree to which the M1 MacBook Air has handled my uncompromising day-to-day use has been, frankly, astonishing. Things were made a little easier because most of my go-to apps are M1 optimized – if I was, say, an Adobe Lightroom user than I’d be reliant on Rosetta 2 emulation, which would be less efficient – but I could still run everything my usual MacBook Pro deals with and not encounter issues on the M1 MacBook Air. If benchmark numbers are your thing, we have those too.

Weirdly, the biggest disappointment has been iOS apps. Yes, they run – each in a separate window – but most are built for touch. You can use keyboard and trackpad to interact with them, but it’s definitely a sub-par experience; it’s hard to imagine Apple not bringing out a touchscreen Apple Silicon Mac somewhere down the line.

Vmware Fusion M1

All the same, while it might not be perfect, there are times when an iOS app hits the spot. My colleague Vincent, for example, has been using an M1 MacBook Pro, and can now load the iOS-only app for his 360-degree camera on his laptop. My connected smoker doesn’t offer a Mac app, but since I can now run the iPhone app in Big Sur, I can monitor my pork butt and tweak temperatures without having to pull out my phone.

Macbook Air M1 Vmware Fusion

The other advantage is battery life. Apple quotes up to 15 hours of wireless web-browsing from the M1 MacBook Air’s 49.9 Wh battery, but I’ve been (metaphorically) burned so often by over-promising laptop estimates that I immediately dismissed that. Turns out, I shouldn’t have been so pessimistic: by the end of a nine hour work day, macOS was typically telling me I still had around 40-percent battery left.

Again, your go-to apps will make a difference there: the more heavy-lifting Rosetta 2 has to do, the bigger the hit on battery life. The MacBook Air is fanless, too, which has its own pros and cons. I love the silent running, but beefy tasks inevitably involve more heat, and after a while the M1 will throttle back for reasons of self-preservation. Although I’ve been impressed with Final Cut Pro performance, for instance, those looking to Apple Silicon with video editing at the top of their to-do list should probably go for the M1 versions of the MacBook Pro or Mac mini, which have fans and thus can sustain their peak performance longer.

I called the new MacBook Air an example of tech evolution at its clearest, and sometimes that’s not so much a standout feature as it is a general feeling when you live with a machine. It’s about how rapidly the notebook wakes when you lift the lid – so quick, I had a moment of “is the light in the fridge on when you close the door?” style skepticism, and wondered if the MacBook Air simply wasn’t sleeping at all – and how silky-smooth the animations are. At times it feels more like an iPad Pro that way, responsive and elegant.

Not perfect, though. The webcam may tap the Neural Engine to try to coax better quality out of its 720p sensor, but there’s only so much you can do with software and it’s underwhelming overall. It’s frustrating that, while you can get an iPad with built-in cellular connectivity, you still can’t get a MacBook Air with 4G or 5G onboard. And we’ll have to wait to see what new form-factors – or even just a touchscreen – Apple has in mind.

Macbook Air M1 Vmware Fusion

Nonetheless, it’s dramatic just how good this first-generation outing for Apple Silicon is. I usually wouldn’t recommend being an early-adopter when it comes to big, evolutionary changes in platform like this switch away from Intel is, and yet Apple seems to have avoided not only the obvious pitfalls but the nuances as well. That I could move from an old Mac to this new MacBook Air and have the biggest takeaway be just how much nicer the experience was speaks volumes.

“The forms which stand in closest competition with those undergoing modification and improvement will naturally suffer most,” Darwin wrote in The Origin of Species and, while I suspect he wasn’t talking about PC versus Mac, the sentiment is no less true today. We may only be at the beginning of the Apple Silicon transition, but even this base-spec M1 MacBook Air proves that Windows notebooks must recognize that natural selection here isn’t balanced in their favor.

Vmware Fusion M1 Support

Story Timeline