How will it work out in Apple land?

For developers who work only on iOS apps, the transition also won’t mean much. Maybe a faster, more accurate Simulator. They’ll need to buy an ARM Mac sooner or later (within the next 5 years), because Apple requires them to use the latest Xcode version for App Store submissions, and Xcode supports at best the previous version of macOS. But that has been Apple’s policy forever, and the Intel Macs will probably be within the usual deprecation range when that happens.

The requirements for macOS-only developers are pretty obvious, they will need to buy an ARM Mac on day one, so they can test their apps on the new platform. They will also need to work on ARM compatibility — although updating your app for the new OS is a yearly ritual in Apple land, so that’s also mostly business-as-usual (unless you do a lot of unportable low-level stuff in your code). There are some pro apps that tend to lag behind new Apple decrees (some might have been hit by Catalina), and users of those apps might prefer to stay with Intel for a little bit longer.

But then, we get to the requirements of developers who use Macs, but don’t work exclusively with the Apple platforms. This is a fairly large group, since many developers like Macs for the good hardware, Unix-based software, and the integration of both. And for some part, non-developers are affected too.

Who needs non-Apple operating systems?

The first group are people tied to Windows, somehow. Some of them might be using Boot Camp to play games. Others might be using Boot Camp or virtualization software (Parallels Desktop, VMware Fusion, Oracle VM VirtualBox) to run Windows and Windows-specific apps — perhaps they need the Windows version of Office, or various Windows-onlypro apps, or they need Windows to file their taxes, because their government does not care about non-Windows OSes. Or perhaps they’re web developers, and they need to test compatibility with the Windows versions of browsers, or the old Microsoft browsers (IE and pre-Chromium Edge).

The second group is software developers who need Linux. While macOS provides a very competent development environment, and many things can be run directly on macOS, some use-cases may require a Linux VM. Perhaps the most notable case is Docker.

Docker is a solution for lightweight app containers, that can offer separation between apps, and that can simplify and standardize deployment. Docker itself is not a virtualization solution (at least in the traditional sense). Docker must run on top of Linux (there’s also Docker-on-Windows, but that’s another story). The Docker Desktop for Mac app runs a lightweight Linux VM, and runs containers in that VM. The virtualization solution Docker for Mac uses is Hypervisor.framework, which is part of macOS itself.

Who else needs virtualization? Android developers. The Android Emulator is also a virtual machine that runs the Android operating system. Android can run on different architectures, and so, a x86 system image is typically used for the Emulator.

Is virtualization possible on ARM?

Yes, definitely. Apple has been testing it much earlier, since the aforementioned Hypervisor.framework was found on iOS in April. And Apple announced virtualization support for ARM Macs during the keynote, and showed an example of a Linux VM. That VM was, of course, running an ARM64 distribution of Linux.

But what can we use this for? Turns out, it’s complicated. The easiest thing from the few use-cases mentioned before is Android. Google just needs to get the Emulator working on ARM Macs and ship that to the devs.

What about Linux in general? Many mainstream distributions support ARM64, so that’s not a problem in general. The support for a particular distro or software might be worse than on x86_64, but it’s generally not a problem for users.

But for Docker, there’s a problem. One of the many advantages of Docker is dev-prod parity. If you deploy your app with Docker to an x86_64 Linux server, you can also install Docker on an x86_64 Linux developer machine (or a Linux VM on an Intel Mac/Windows PC). Both the server and the dev machine can run the same image, the same code, the same configuration. That won’t happen if they are a different architecture. This means that you can end up with bugs happening because of different environments, and it’s also possible that some images you depend on are not available for both architectures.

And then we get to Windows. Windows also has an ARM version, but it’s currently available only with a new ARM device (you can’t buy it standalone). If Microsoft were to sell this, we’d have an issue with the software. Windows 10 on ARM supports 32/64-bit ARM software, and can run 32-bit Intel (x86) software using emulation. It cannot, however, emulate apps that require 64-bit Intel processors (x86_64). This makes the software situation on that platform a bit better. While many developers don’t care about ARM and might not have builds for ARM available, most Windows software is available in both x86 and x86_64 versions, or is exclusively 32-bit. But certain pro apps are x86_64 only, so if there is no ARM build of it, an ARM Windows PC currently cannot run it. (Update: Microsoft announced x86_64 emulation on ARM, which means more software will work.)

And note that Microsoft knows about the transition, but we haven’t heard anything about Windows during the keynote…

Can we emulate x86(_64) and run x86(_64) Windows 10?

Theoretically? Yes. Practically? No.

The issue with emulation is speed. There are a few x86 emulators available, and those emulators can be run on an ARM device just fine. You can find videos on YouTube (not a very reliable source of information, I know) in which people try to benchmark those, or try to run Windows using an emulator like that. And even with an ancient Windows version, the emulation is painfully slow. Windows 10 would be basically unusable if you tried to emulate all of it.

How does the x86 emulation on Windows 10 for ARM work? You can watch the Channel 9 video about Windows 10 on ARM (around 6:00) for more details. The trick is that system DLLs are using a hybrid x86/ARM64 library format, which means x86 code can call those DLLs at native speeds. This means that many apps run at near-native speed (depending on the ratio of custom code to system DLL calls). This technique cannot work for emulating the entire operating system. If Windows 10 on ARM was made available for ARM Macs, running x86 Windows apps would become feasible.

Rosetta probably uses similar technique. Most apps will be translated at install time, not at run time. But you can’t do that with an entire OS.

What’s next for people who rely on both macOS and Windows?

For a few more years, Intel Macs will still be supported by Apple (with new macOS versions) and by software vendors. But after that? Well, you’re stuck with two machines, at least until Windows on ARM becomes viable and runnable on Macs. Or you can start exploring alternatives to macOS software. If you’re one of the macOS-as-UNIX-with-great-UX developers (hello!), perhaps you’ll have to switch to Linux — or perhaps Windows with Windows Subsystem for Linux? (The latter is becoming more usable with every Windows release, so keep an eye on that… I wrote this post in NeoVim in WSL2, with Windows Terminal supporting many advanced terminal features, and the transparent filesystem integration letting me access Windows files directly).

Post-M1 announcement update (2020-11-14)

Parallels have confirmed support for M1 Macs and are offering a Technical Preview of their M1 virtualization product. This announcement’s mention of Windows 10 ARM supporting x86_64 apps has caused some tech writers to assume Parallels will support Windows 10 ARM on M1 Macs. This is not what the post says. Parallels is not, and cannot announce support for that OS, because Windows 10 ARM is (still) available to ARM OEMs only to install on their devices — making an official announcement about this feature today would be admitting to doing something illegal/not allowed by the EULA. I’m pretty sure they are not working on support for Windows 10 ARM now and in the foreseeable future, until Microsoft opens up Windows 10 ARM to the public — their own legal issues aside, who would they sell the Windows support to?

In other news, Docker is not ready yet.

Making install media with El Capitan (with access only to Recovery)

The best, safest, least error-prone way to do an install is with a USB stick. Unfortunately, making a USB stick with the macOS installer on it is a nuisance. The expected way to produce macOS install media is to download the installer from App Store/Software Update, and run the createinstallmedia command-line program included with that installer app. All is well, as long as macOS works. If it doesn’t, and Recovery can’t install it for you, that can be difficult to solve.

Apple does not make macOS images publicly available. That’s probably to make Hackintoshing this little bit harder, but this also affects legitimate users. The only thing you can easily download from Apple is El Capitan. Apple offers InstallMacOSX.dmg on their website.

There are also some other downloads available:

• there’s a Sierra download, with a broken link, although it can be fixed by changing updates-http to updates: get Sierra installer.

• if you need something older than El Capitan, downloads are available as far back as Lion, although these might not have the createinstallmedia tool required for this procedure.

This post assumes you’re working with El Capitan; a quick look though that file suggests the instructions in this post should work with Sierra as well.

If you take a look at the instructions, you will see that this is not a bootable OS X image. This image has a .pkg package. This package is expected to install /Applications/Install OS X El Capitan.app. Well, we’re in recovery, we can’t install stuff. So, let’s do this the manual way.

Manually installing .pkg files

Turns out the .pkg format is just an archives all the way down, with all archives being different formats (at least three).

The first archive is the .pkg file itself. Those files are in XAR format, which was invented by the OpenDarwin community. You can either extract it with pkgutil --expand foo.pkg foo_files (the last argument is the destination directory, can be anything, will be created by pkgutil) if you have access to that command (it’s available in Recovery OS), or you can try the xar utility as xar -xf foo.pkg. The structure produced by both tools is a bit different, but we can work with both.

The second archive-in-archive is the Payload. It’s a gzipped cpio archive that contains the files installed by this package. If you have BSD tar (default on macOS, easily installable on Linux), you can just do tar -xvf Payload. Otherwise, you can use gunzip -c Payload | cpio -i (or gzcat). That will extract all the files the package has.

Another nested archive is the Scripts archive, although note that pkgutil will extract it automatically. If it’s not extracted, it’s actually .cpio.gz again, with the same way to extract it.

(PS. If you have 7z around (on Windows/Linux as well), you can just point it at all the compressed files mentioned in this paragraph.)

Making install media out of partial macOS installers (“not a valid OS installer application”)

$ (mount the DMG in Disk Utility)
$ cp /Volumes/Install\ OS\ X/InstallMacOSX.pkg /Volumes/Macintosh\ HD/
     (Or copy it to some other volume you can write to; NOT the USB stick)
$ cd /Volumes/Macintosh\ HD/
$ pkgutil --expand InstallMacOSX.pkg elcapitan
$ ls -F elcapitan
Distribution*       InstallMacOSX.pkg/ Resources/
$ cd elcapitan/InstallMacOSX.pkg/
$ tar -xvf Payload
x .
x ./Install OS X El Capitan.app
x ./Install OS X El Capitan.app/Contents
…

# "Install OS X El Capitan.app/Contents/Resources/createinstallmedia" --volume /Volumes/MyBlankUSBDrive --applicationpath "Install OS X El Capitan.app"
Install OS X El Capitan.app does not appear to be a valid OS installer application.

$ mkdir "Install OS X El Capitan.app/Contents/SharedSupport"
$ mv InstallESD.dmg "Install OS X El Capitan.app/Contents/SharedSupport"
# "Install OS X El Capitan.app/Contents/Resources/createinstallmedia" --volume /Volumes/MyBlankUSBDrive --applicationpath "Install OS X El Capitan.app"
Ready to start.
To continue we need to erase the disk at /Volumes/MyBlankUSBDrive.
If you wish to continue type (Y) then press return:

Install macOS Catalina.app does not appear to be a valid OS installer application.

El Capitan installer can’t be verified

If you get this error, it might be because Apple’s signing keys expired, or because of other date/time weirdness. Regardless, you can force an install if you are sure the installer is not damaged with this command (source):

# installer -pkg  /Volumes/Mac\ OS\ X\ Install\ DVD/Packages/OSInstall.mpkg -target /Volumes/"XXX"

Bonus tidbit 1: how the download works

While messing with all the installer stuff, I found out a few interesting/worrying things about the download process.

The first one is that the macOS installer uses plain HTTP without encryption to download files. That opens you to all the standard issues — an attacker can replace files you download, and the protocol doesn’t do anything to detect errors (the installer will verify files, but where do the checksums come from?).

The second one is how the download happens. You might have noticed it to be a bit slower than usual traffic. The download happens in 10 MB chunks, using the Range HTTP header. The installer asks for 10 MB, gets it, saves, asks for another chunk. Repeat that over 800 times, and the overhead of the entire HTTP dance becomes noticeable. (I haven’t checked, but I hope the installer at least uses Keep-Alive. I wouldn’t be particularly surprised if it didn’t, though.)

But this raises another question. The servers clearly support partial downloads. And yet, if your network disconnects during the download, your download progress for that file is reset, and in Catalina, you can go from 8 GB back to 500 MB if you’re particularly unlucky. The question is, why? This infrastructure should make it trivial to continue the download, perhaps discarding the most recent chunk if you’re concerned about that download of it being unsuccessful.

Bonus tidbit 2: using Terminal from Setup Assistant

The first time you boot a Mac after a clean install, it starts the Setup Assistant. This app asks for basic OS settings (locale, date/time, user accounts), and also lets you restore user data from backups.

Sometimes, you might want to access the Terminal or Console from that screen. You can do that with Ctrl + Opt + Cmd + T and Ctrl + Opt + Cmd + C respectively (source).

How could that come in handy? For example, if you want to check if the backup drive still worked and if the process isn’t stuck (I wrote a test file and also checked top).

Bonus tidbit 3: creating an image of the install media might not work

A few months later, in December, I upgraded to Big Sur and then installed Windows 10 alongside it in Boot Camp. I then did some more hacks, which led to two unbootable OSes.

As part of the upgrade, I had prepared install media and used it to install (so it wouldn’t fail, as it did last time), and made a .dmg of it with Disk Utility. (Also, Apple won’t tell you this, but you need to give Disk Utility Full Disk Access for disk imaging to work. Otherwise, you get a cryptic error.) I erased the USB drive after installing, but hey, I could get it back. I booted into Internet Recovery and restored my image. Big Sur failed to boot and showed a 🚫 sign. I tried restoring my Catalina image from the previous reinstall, and that didn’t work due to a size mismatch. I used a different USB drive than these months ago (I didn’t have that one with me at the moment), and apparently the one I used had a different size (both are marketed as 16 GB). The images could be mounted fine, and createinstallmedia should have worked, likely producing a bootable drive.

Bonus tidbit 4: don’t bother restoring a Time Machine backup

Time Machine is Apple’s magical backup solution. Time Machine saves snapshots of your entire disk. It’s supposed to help restore files that were deleted or changed in an unwanted way, or help you restore a full macOS install.

Time Machine is great at file recovery, but none of my 3 system restore attempts were successful. Attempt #1 was a full Time Machine System Restore, from Recovery, back in June. It failed partway through, it couldn’t read everything from the disk. There might have been underlying hardware issues with that failure, so I had another attempt.

Attempt #2 was a Migration Assistant restore, as part of the initial setup. This one succeeded, and things worked… except for one fairly important app. This app requires online activation with the vendor, and it wouldn’t reactivate after the install. Whatever the third-party vendor is doing didn’t like the reinstall. I tried to nuke all the things in ~/Library related to their software, and ran their nuke-everything uninstaller, but that didn’t work. I reinstalled from scratch and copied over my files, settings and apps from the Time Machine drive.

Attempt #3 involved the System Restore again, this time for the December reinstall. The hardware issues were all fixed in the meantime, so I went for a Time Machine System Restore.

Issue #1: Internet Recovery booted into Catalina. There was an issue on Apple’s side, Big Sur was unavailable in Internet Recovery in December. TM Recovery will not restore a backup created with a newer version of macOS than you’re booted into, so I was forced to restore a slightly older Catalina backup. (I spent most of my time in Windows during that weekend, so other than the need to upgrade macOS to Big Sur again, I didn’t really lose any data due to this.)

Issue #2: It wasted time computing an inaccurate size estimate. Before restoring a backup, macOS first checks if it will fit on your drive. When it does that, an indeterminate progress bar is shown. macOS won’t tell you the result of that computation, but you can read the final value from the full Installer Log (Cmd + L). On my Mac, the value was 96.2 GB. I was at the Mac when it was getting close to that value. 94, 95, 96, 96.1, 96.2, 96.3… hold on a second, 96.3 GB? Hopefully that’s just a bunch of extra things that are installed from the system image directly, or something like that, right? Of course, since the progress bar is based on the pre-computed size, it became indeterminate and I couldn’t tell when it would end. 98, 100, 110, 120, 121.2 GB is where it ultimately ended. So, not only did it waste 20+ minutes computing a size, it was off by 25 GB.

Issue #3: The restore didn’t work. The System Restore finished and claimed to have succeeded, but macOS wouldn’t boot. It showed an Unrecoverable error, SecurityAgent was unable to create requested mechanism. Most people who had a similar error had it caused by a botched TeamViewer uninstall; I didn’t have that installed, and it was referring to a different component. So, wipe and fresh reinstall it is.

I copied my stuff from the TM drive, and it was acting weird. Some apps failed to load their settings copied into Library, others started with a “Move to /Applications?” prompt (even though they were in that directory). For some reason, those files had some hidden attribute set on it. I worked around it by putting files in a .zip archive with Keka, and then unzipping them; xattr might also help. (The attribute was likely com.apple.quarantine.)

After I got the Mac to work, I reinstalled Windows and set up rEFInd, and it now works fine. (I only use rEFInd because I want virtualization in Windows, and that doesn’t work unless you’re warm-rebooting from macOS. I don’t need anything more advanced than the Option key boot menu, but Apple made me use a third-party bootloader.)

We now go back to the original post from June.

An Open Letter to Progress Bar Designers

Dear Progress Bar Designers: can you please make your progress bars functional? The macOS progress bar might look sleek at just 7 px (non-Retina)/6 pt = 12 px (Retina) high, but at the same time, you’re looking at individual pixels if you need to know if it works or if it’s stuck. I have had to point my mouse cursor at the end of the filled-in part just to know if it’s working or not. Or sometimes, put a piece of paper in front of my screen, because there is no mouse cursor when macOS installs on the black screen. How to make that progress bar easier to use and more informative? Just add numbers on top of it. For long-running processes, I wouldn’t mind progress bars that said “12.34%”. That specific Setup/Migration Assistant window should be changed (it only has a remaining time estimate and transfer speed, it should also show moved data/total size), but wouldn’t more things benefit from a clear indication of the progress? Yes, perhaps it looks less sleek, perhaps it requires more space for the bar.

Just compare: which is easier to parse? Which is more informative?

I’d honestly be happy enough with option 2, at least it can be read easily and you can remember the number instead of a vague position.

In the end…

After all this, I managed to get macOS Catalina installed. After various failures in built-in El Capitan recovery and Catalina Internet Recovery, I first installed El Capitan with this hack, then jumped to Mojave because I thought the new Software Update would help (it didn’t, same installer, same failed-to-extract-package issue), then made a Catalina USB stick, and it finally clean-installed, but I was worried about the backup disk’s operation, and I used a proxy on my local network to try and speed up Catalina downloads without much improvement… but hey, at least it works. Apple should really make it easier to install their OS and to make boot media even when stuff doesn’t work, even from Windows. The Hackintosh folks can just find someone with a working Mac and ask them to download from App Store and make install media, or find less legitimate sources, they probably don’t care as much. But if my own system crashes, I’d probably want to get working install media immediately, myself, and from Apple. Without all this mess.

Mac as a UNIX® machine: nothing beats a terminal

What are the first things you should set up on a Mac, as a programmer? Homebrew (and Homebrew Cask). That’s a package manager that can install all software necessary to create an useful command-line environment, including Python, ffmpeg and sox for media needs, git, GCC (clang is wonderful, but I need plain old GCC sometimes), zsh, and a handful of other programs. And, of course, Vim.

And what Homebrew Cask can do for you? Install many GUI programs, without needing to mess with .dmg installers or stuff. Including web browsers, music players, or iTerm2.

Did I mention UNIX®, with the registered trademark sign (belongs to The Open Group; used for informational purposes only)? macOS has a fancy certificate to prove it’s compliant with the relevant specifications. It runs the FreeBSD userland, which is what you expect from a typical *nix system. (Linux converts might get slightly annoyed at behavioral differences, for example rm directory -rf will work on Linux with GNU coreutils, but won’t on macOS/FreeBSD)

The GUI: beautiful, fluid, friendly

macOS is famous for its user interface. The macOS GUI is well thought out, even though there are some idiosyncrasies a long-time Linux/Windows user might consider weird. For example, sorting folders before files is something natural for Windows, but on macOS, it’s a brand new option — added in macOS Sierra, which came out in September 2016.

That aside, the macOS user interface makes one coherent product. You can expect consistent behavior between apps, and that often extends to third-party software. Apple has a document, called Human Interface Guidelines, which describes how a macOS app should behave. While there are some documents like this one for Windows, you can see many apps ignoring what it says — including eg. built-in software, which cannot even decide on which font to use (bitmap MS Sans Serif vs vectorized Microsoft Sans Serif vs Segoe UI — what is going on?!)

While the interface is friendly and coherent, it can get a little worse when foreign apps are involved — for example, Qt or wxWidgets apps can sometimes differ in behavior, but that’s not noticeable. X11 apps are another story, but most of their developers are not aware that someone is running them on macOS. (Excluding the Inkscape developers, which have a Mac “app” that basically runs it in X11 and they do not even care…)

Programming: old habits die hard

Did I mention Vim? Well, I’m still using Vim and a terminal emulator to get a lot of coding work done. Why? Because they are still the best ways to be productive. I tried many gooey solutions for coding, from the heavyweights (PyCharm, Visual Studio) to the laughable Atom editor (famous for being slow, and effectively a web browser) — and none of them was able to replace Vim and a Terminal. They are far too addictive.

That said, I sometimes use GitHub for Desktop, or other helper tools. Sometimes, they work well — key word here is sometimes. Unlike Vim (or NeoVim, or a GUI: MacVim/VimR), which boosts my productivity by a lot.

Honorable mention goes to Automator and AppleScript. They are a superb solution for automating common tasks in the GUI, something other OSes do not provide. With Automator, everyone can create a workflow to perform repetitive tasks faster. With AppleScript, you can get even more stuff done.

The trackpad: addictive

Apple is famous for their trackpads. Their newest generation of these devices does not really move when you click it, it uses the Taptic Engine and [insert smart-sounding words here] to simulate a click. It also supports Force Touch, for pressing down harder on something (eg. a word to reveal dictionary definitions), and haptic feedback for certain operations (in Soviet Russia, trackpad clicks you!)

Those trackpads also provide intuitive gestures. Working with full-screen windows or multiple desktops? Just swipe left/right to switch between them. Need to see all your windows? Swipe up with three fingers. Smooth zoom, scrolling and rotating can also be done with just the trackpad.

And recently I had to do some stuff on someone else’s Windows notebook. That notebook features a touchpad that does not click — it has two buttons on the bottom, and tap to click is enabled. I had to drag and drop some files between two windows. I tried doing it the way I got used on the MBP trackpad, which is basically the way you’d do it with a mouse: hover cursor above file, click the trackpad, move mouse to other windows, and release. That doesn’t work on those non-clicky touchpads. A software developer failing at drag-and-drop must be a funny thing to see. That’s just how addictive the trackpad is. (Of course, Windows notebooks with clicky trackpads exist, but are not as popular as the tappy ones.)

Walled garden: how can you NOT love our products?

Of course, there are some issues with living in an Apple walled garden. The main issue is: if you want to use something that is not an Apple product, good luck with that. Sure, you can use an Android phone, but you won’t get some of the nice Handoff features, and if you want to transfer files, have fun using a forgotten barely-working app from 2012. That phone also won’t be able to access your iCloud stuff, so put your data somewhere else.

Do you want to use an external hard drive, or a USB stick? With other operating systems? Well, you might have an issue with the file system. You can choose between ExFAT, which is not popular but kinda does the job; FAT32, which has a 4GB file size limit (virtual disk images are often larger than that), or NTFS, but for that you will need to pay a third-party company — and trust them not to do anything nefarious. Or use experimental built-in support, or an open-source project, both of which aren’t something one would normally trust with important data.

Speaking of external hard drives, here’s a hint: if you want to use a drive for Time Machine (a wonderful, foolproof, one-click backup solution), and you want it encrypted, make sure it uses GPT and not MBR. I had to reformat my drive twice, and that’s not well documented (you need to click the help button, then go through 3 pages to find a mention of this).

Do you want to play some games? Well, there is basically no support for gamepads, only some community beta drivers for the official PS3/Xbox 360 pads. Apple does not care.

And then we get to mouse issues. You see, even though the trackpad is awesome, I also want to use a regular mouse. So I started with my old PC mouse, as a temporary solution. The mouse was a Logitech M560, which uses the wireless Unifying USB connector. It turns out the middle mouse button is supposed to be a Windows button on one click and left mouse button on another, but Linux drivers seem to change that behavior. To fix that, I’d need drivers for macOS. Logitech believes this mouse is not worthy of a Mac, and so the mouse is not detected by their driver suite. I got rid of that mouse and replaced it with a Microsoft Sculpt Comfort Mouse. The mouse has a real middle button, which is activated by clicking the scroll wheel, and a Windows button on the side (generally useless on macOS).

Sadly, macOS insists on scrolling in a weird accelerated way, where the number of pixels scrolled grows over time — which means scrolling by one step means scrolling by 5 pixels, but the longer you scroll, the larger the scroll becomes.

The future: I’m worried

I made the decision to buy the MacBook Pro in the middle of rumor season, after WWDC which left a lot of people disappointed. I decided that, if all the rumors about removed ports and touchy-feely screens were true, I would not want that device on my desk.

And boy did Apple deliver! The new MacBook Pro has only USB-C ports (and a headphone jack!), a gimmicky Touch Bar that only helps with emoji (the rest can be done with standard keyboard shortcuts, or on-screen toolbars — I thought that was a Pro machine, not a toy?), and a fingerprint reader (which I don’t care about). And then there’s the cheaper model, with two USB-C ports and no touch interfaces. My MBP, mainly a desktop replacement, is on AC power all the time, and runs an external HDMI display. With the cheaper model (worse CPU than 2015; same price as 2015 with the same 256GB drive), I would have zero ports for any other external devices. And I often have some thing plugged in, in which case the only unoccupied ports are the Thunderbolt ports (which I don’t have any devices for).

So, I hope this 2015 model will live on for years, and hopefully when it fails, Apple will have a more sensible machine out there. For now, I’ll keep my MacBook Pro (Retina, 13-inch, Early 2015) and will be pretty happy with it.

With just only one exception: two kernel panics in nearly 5 months. A bit unstable, eh?