Finding an Alternative to Mac OS X — Part 2
Adventures with Linux
This is the second in my series on finding an alternative to Mac OS X. Part 1 was about evaluating 13 alternative operating systems and then choosing one to use full time. The selected OS was elementary OS. The motivation for this change is to get access to better hardware since Apple is neglecting the Mac lineup.
If video is more your style I gave a short (10 min) talk at work on my adventures with Linux that covers the core content of this post.
It's been nearly a month since the first post, which garnered a lot more attention than I expected. There's quite a lot of unrest amongst Apple users at the moment about the current state of the Mac. A lot of the responses were along these lines:
- I've been considering the same thing, interested to see how it goes.
- What about Windows? Or, Windows 10 is better than previous versions and has the Windows Subsystem for Linux (WSL) now.
- You should try Linux distribution X.
- Did you try KDE?
Based on this feedback I did go back and reevaluate Solus OS as well as try out a KDE based distribution, KaOS, and install Plasma on my Arch install. This didn't change my mind on the best candidate for me to try: elementary OS.
Regarding Windows, I should say that I am strongly biased towards *nix style operating systems and find it unlikely that I'd be happy using Windows full time. However, in the interests of keeping an open mind I will give it a try in the next few months. I have backed the Eve V campaign. The Eve V is a 2-in-1 laptop tablet that will come with Windows 10. For now Windows is off the table.
I closed the first post with:
I plan to resize the Arch partition on my work PC and install elementary alongside. I'll aim to do all my work duties on just that machine.
I installed elementary 0.4, "Loki", which is derived from Ubuntu 16.04 LTS. Installation was straightforward. I was pleased that the live environment included tools like GParted that let me resize and add partitions to allow dual booting with the existing Arch installation. A secondary benefit of dual booting was that I could mount the Arch partition in elementary and copy over code and config to get set up quickly.
My priority after installation was getting my development environment set up:
- Password manager
- Text editor
- ruby environment
In preparation for this move I set up Enpass on my Mac and iPhone with syncing via Dropbox. I imported all my passwords from 1Password. Enpass lacks some of the finesse of 1Password but overall it works well and includes reliable browser integration.
It was pointed out to me that I should be using an open source password manager, which is a valid point. However I didn't have a problem with 1Password being closed source and I'm not aware of any open source options that are: cross platform (at least Linux, and iOS), have browser integration, and can remain synced across devices. Unless I've missed such a product, it's closed source for now.
Downloading Enpass for Linux yields a Debian package (
Installing this required using
dpkg -i on the command line. I think
installing third-party software is something the system needs to handle
gracefully. The elementary folks could make installing it a lot simpler.
Setting up Enpass syncing was easy since it uses the Dropbox API so I didn't even need to install Dropbox.
The default elementary browser is a tweaked version of Epiphany. It feels quite similar to my Mac browser of choice, Safari (and is also WebKit based). However in my brief usage I found it to be unstable. I encountered WebKit crashes and stalls loading pages for no particular reason. The deal breaker though is that it does not support extensions (for Enpass password filling).
Setting up my work Google Apps email in the default Email app was simple, not much to say here.
Things did not go as smoothly with Slack. Again they supply a
on their download page so I resorted to
dpkg -i again to install it. However
it complained about missing dependencies. Attempting to add said dependencies
with Slack in it's half installed state resulted in more errors about missing
dependencies. In the end the solution turned out to be remove Slack, install
the dependencies, then install Slack.
Clearly there is some user error at fault here and there must be a better way to install downloaded packages like this. One option looks to be Gdebi. This feels like something that is harder than it needs to be in elementary. Especially since it is a simple double click on a stock Ubuntu installation.
Installing my text editor of choice, Neovim, also proved annoying. The installation instructions suggest using either Linuxbrew (a port of Homebrew to Linux) or Personal Package Archive (PPA). Having had good experiences with Homebrew on my Mac I decided to give Linuxbrew a try. However it turns out Linuxbrew manages it's own version of all the packages it tracks (makes sense I guess). This end up duplicating many of the packages available or already installed by the system package manager. This works on macOS since there is no system package repository but did not sit well with me on a Linux system.
The other other listed option, the ppa, was a daily, "unstable", build. My text editor is one of the most important tools for getting my job done. I'm not about to install an unstable version of it, so that left building from source. I'm not averse to this but it means the onus is now on me to keep track of, and build new releases. It also means that you lose the easy uninstallation and clean upgrades of system packages. To address these drawbacks this I resorted to a handy tool I've used before: GNU stow.
Update: As I was writing this post Neovim announced a stable ppa.
The experience up to this point had soured my feelings towards elementary somewhat and I wondered if I'd just be better off sticking with Arch. After all, most parts of the elementary desktop environment (pantheon) are in the Arch User Repository (AUR).
I set about building and installing all of the AUR packages for a full pantheon environment. The end result was a pale imitation of the real thing. Light DM, the display manager elementary uses was crashing so I had to swap it for gdm just to be able to log in. Once logged in, it did not look right since it was running on GTK+ 3.22 and the elementary theme only works properly on GTK+ up to 3.18.
I'll omit all the details, but at this point I tried both GNOME 3 and KDE Plasma 5 on Arch but both left me wanting the well designed, uncluttered, and integrated elementary environment. I rebooted back into elementary and just accepted I'd have to work around the limitations of its Ubuntu base.
Making Myself at Home
Over the course of the next few days I brought more of my tools and
customisations over. Some like
tig were easy, others like
required building and installing from source. I expected installing my
preferred monospace font, Pragmata Pro, to be a real chore but it was super
easy: Just download, click the font file, then click "Install" in the font
Getting the terminal to use Pragmata Pro required installing GNOME Tweak Tool, which let me change the system monospace font. This had a side effect that brings me joy anytime it happens: Any application that renders monospace text using the system default font, does so in Pragmata Pro. I especially like seeing it in email.
The elementary desktop environment is pleasant to use. It has a familiar dock, (Plank) and generally does what you expect. There are customisable keyboard shortcuts for many common actions.
Interestingly elementary almost completely removes menus. As a heavy keyboard shortcut user this makes discovering shortcuts difficult. I ended up resorting to searching the elementary Stack Exchange and reading the, "Learning The Basics", guide to discover some of them. This removal of menus is something largely inherited from GNOME. In GNOME 3.20 (the version after elementary is built upon) GNOME introduced shortcut windows to address the discoverability problem. It would be great to see elementary support these too.
One of the things I was concerned I would miss from macOS was the consistency of the UI. I think my fears in this area were unfounded. So far I have found the built-in applications as well as most others built using GTK+ 3 to be well designed, consistent and pleasant to use.
The first few days went well enough that I also installed elementary on a Mac mini at home (more on that in another post). In the subsequent weeks I've hardly used macOS.
One of the benefits of desktop hardware is the ability to upgrade. This is an aspect of computing that is sadly missing in the Apple lineup these days. I've been wanting to get a high-resolution display for a while now but my MacBook Pro was incapable of driving one at 60Hz. Now that I'm using Linux on my PC this is no longer a problem — just install a better graphics card! I bought the following:
- Gigabyte GeForce GTX 1050 Windforce OC, 2GB graphics card — AU$199
- Dell P2415Q 23.8inch 4K (3840 × 2160) display — AU$665
Keep in mind these are Australia dollars which are worth less than those fancy American dollars and are no doubt also inflated by the, "Australia Tax".
I chose an NVIDIA GPU because they publish (proprietary) drivers for Linux and FreeBSD, making their hardware well supported. At first I installed the drivers in the Ubuntu apt repos but the graphical environment failed to start — the drivers were too old and did not support the GTX 1050 chipset. So off I went to NVIDIA and installed the latest version manually.
With the right drivers installed I was back in action and was able to use the full resolution of the display @ 60Hz. Retina aka HiDPI is reasonably well supported on Linux but requires some manual steps to enable it. In the GTK+ based elementary OS this boils down to:
gsettings set org.gnome.desktop.interface scaling-factor 2
The end result is stunning. Pragmata Pro looks especially great. So good that I splurged on buying the whole font family (bold + italic). Previously I'd only purchased the regular variant.
Most things work but I did run into some rough edges:
- "Whole Screen" shots have an extra black area in HiDPI
- The screen is placed in the upper quadrant, the rest of the image is black.
- Notifications are half the width they should be.
- When switching apps Plank shrinks more than it should.
Cracks Start to Show
My point of comparison for software installation is: the Mac App Store, Homebrew and Arch Linux. With each of these it's a simple matter to install the latest version of a tool or application. On elementary I ran into a number of cases where software I wished to install did not exist in the Ubuntu repos or were outdated enough to be a problem:
- Neovim (Homebrew and main Arch repos)
- fzf (Homebrew and main Arch repos)
- ripgrep (Homebrew and main Arch repos)
- Nvidia graphics drivers (version 367 in Ubuntu, 375 in Arch)
This is obviously something that can be worked around but it adds friction that I did not have on macOS.
Furthermore, whilst I was generally enjoying the elementary desktop and apps, as time went on I started running into more bugs. Bugs are bound to happen and it was excellent to be able to search a public bug tracker to see the status of an issue or create a ticket if it was new. However this didn't change the fact that they were affecting me on a daily basis. Here are some of the more frustrating ones I ran into:
- dbus bug that prevents the desktop from appearing after log in.
- Fixed upstream in Jul 2016.
- Ctrl-C doesn't work in Mail.
- Fix committed Dec 2016 but yet not released. Milestone is set to next elementary release, Juno.
- Plank uses high CPU while idle after running for more than a day or so.
- Unfixed but basically means you have to kill the
plankprocess every day you remain logged in.
- Unfixed but basically means you have to kill the
- Unable to open new applications because the X server has reached the maximum
number of connections. See Ask Ubuntu question
- Note: As I was writing this post I encountered this issue on Arch as well. It appears that Enpass is the cause.
- Events shown in the calendar are off by a day.
- Bug has been open for over a year and remains unfixed. Seems kind of important for a calendar app to show stuff on the right day.
- gnome-keyring bug that prevents the ssh agent functionality working,
resulting in prompts for ssh key passphrases when interracting with remote
servers and git repos, which I do a lot for work.
- Fixed upstream in v3.20, Nov 2015 (Note: Despite the bug title, it wasn't limited to just Wayland sessions)
The accumulation of this friction finally came to a head with the last bug above. I tried to start writing this very follow up post (on the Mac mini at home) by cloning the git repo that stores this blog and I was prompted for the password to my ssh key. This is not supposed to happen. Previously the system had shown a nice graphical dialog prompting for this password and an offer to store it for future use. Some more digging revealed I'd run into a gnome-keyring bug that was fixed in Nov 2015 :-(
At this point the system was actively harming my productivity so I did what any rational person would do: blew it away and installed Arch Linux. I then compounded my lost productivity by constructing a GNOME environment I was happy with:
It still didn't feel quite right so I burnt more time and swapped out the GNOME Shell for the Budgie Desktop from Solus OS, which I've been using since:
After I was happy with the set up at home I rebooted into Arch on the work PC and replicated the environment there, which fortunately was much quicker.
Text Input and Keyboard Customisation
As the days rolled on I addressed a few more of the things I was missing from macOS: Using GNOME Tweak Tool I remapped Caps Lock to Control and swapped Super (⌘) and Alt so the keyboard layout was more familar.
At some point I had occasion to type an em dash (—). A Linux using colleague
Ctrl-Shift-u then the hexidecimal Unicode code
point as one way to do this. Whilst this does work, there was no
way I was going to attempt to remember the code points for all the symbols I
wanted to type — especially since this is simply
Option-Shift-dash on a Mac.
My search for a better method yielded the Compose Key. When enabled via GNOME
Tweak Tool this allows many non-ASCII characters to be typed by tapping the
compose key then typing two or more other keys. I assigned it
Right Super. Often the keys are obvious, such as:
? for ‽,
m for ™, or
c for ©. I think these are actually better than
Option combinations as they're more guessable. Incidentally em dash
Compose then three dashes.
Replacements For macOS Apps
I prefer a native mail client to web mail. After switching to Arch I've been using Geary, which elementary Mail is based on. It's quite good for reading mail, rendering all messages I've encountered correctly, even rich HTML newsletters. It has a three pane UI that groups related emails together into conversations like Mail.app on mac OS.
It is less competent for composing email as the editor is quite limited:
- There is no way to insert images inline (they can only be attached).
- Dragging and dropping an image or file onto the editor just pastes the path into the text instead of attaching the file.
- There is no way to insert a bulleted or numbered list.
On macOS Firefox has always felt a little off to me. There's leaky abstractions that reveal it's doing its own thing, and that it isn't a Mac first app like Safari. Some have been fixed like the scrolling physics not quite matching system scrolling. Others remain, like not using the system spelling service or missing standard contextual menu items on text fields such as Services and Transformations.
On Linux Firefox feels at home. It adapts to the GTK+ theme in use and generally feels like a Linux app should. I've been liking Firefox Sync, which syncs my history, open tabs etc. between home, work and Firefox Mobile on my iPhone. The iPhone app also provides a neat share action accessible from the share sheet of any application, "Send Tab", that allows you to open the page on any other synced Firefox.
"Files" aka Nautilus has handled all my file management needs well so far. These include:
- Double clinking a file to open it in an application.
- Moving and copying files with drag and drop.
- Double clicking an archive to have it extract automatically, without prompts or
- Files on elementary used File Roller to extract files. This added unnecessary dialogs and decisions when what I want 99% of the time is extract everything, into a directory inside the the same directory as the archive.
- Pressing Space with a file selected to show a preview, like Quick Look in Finder.
- "Mounting" my MacBook over ssh to browse, view and copy files from it.
- Opening the current directory in the terminal with
- Dragging and dropping a file onto a terminal to paste the path.
There is something nice about being about to completely close Files unlike Finder, which is always running and present in your Dock.
Still To Do
The main thing that I'm missing from Karabiner is simultaneous keys. These
d to access the arrow keys on the
hjkl keys (I.e.
access arrow keys without leaving the home row). I haven't looked into whether
this is possible to replicate because I've ordered a programmable replacement
controller for my Filco mechanical keyboard. I plan to
build home row arrows into it so they work on any computer. This will also
allow me to move the Caps Lock, Super and Alt config from earlier into the
My three most common uses for Alfred are:
- App launching
- Clipboard history
For app launching I used slingshot, built into elementary and later the
Alt-F2) built into Budgie. I've remapped that to
convenience. I've not looked into a replacement for clipboard history yet but I
am aware of some options. For snippets the only comparable tool appears to be
AutoKey-Py3. I tried it but it was unreliable. It doesn't appear to work at
all in Firefox, was unreliable in the terminal and worked ok in gEdit. I'm
kicking around the idea of building my own (in Rust of course).
I'm going to continue using Arch at work and home. I'll also keep an eye on, and continue to support elementary. I think the elementary team is definitely on the right track but they probably need to give some thought to the base it's built upon. A Long Term Support (LTS) release makes sense for servers but for a desktop I think it's the wrong choice.
The next frontier is Linux on my MacBook. I think that will be more of a test, particularly with hardware support (especially WiFi and trackpad).
This experiment has consumed days of my time at this point and the result is not in any way as polished as macOS. For the type of work I do and how I like to do it, it is still a productive environment though. Plus there is the added benefit of access to much more up-to-date, varied hardware than Apple is offering at the moment.
I may still have the shine of novelty attached to my experience so far. Time will tell if that fades and it becomes frustrating or remains a productive environment. I'll continue to attempt to shift my computing needs to Arch. As always I'll be posting as I go. Subscribe to the feed or follow me on Twitter for updates. If you enjoyed this post consider supporting me on GitHub Sponsors.
This is part 2 in a series. Read Part 3