Bit Cannon

Two Years on Linux

This is the sixth post in my series on finding an alternative to Mac OS X. The previous post in the series recapped my first year away from Mac OS and my move to FreeBSD on my desktop computer.

The search for the ideal desktop continues and my preferences evolve as I gain more experience. In this post I summarise where I'm at two years after switching away from Mac OS. This includes leaving FreeBSD on the desktop and switching from GNOME to Awesome. I'll cover the motivation, benefits, and drawbacks to giving up a complete desktop environment for a, "build your own", desktop.

Embracing Awesome

If I were to identify a general trend in my time away from Mac OS it would be one of gradual migration. Initially I was looking to replicate my Mac OS experience. I landed on elementary OS as it shared many of the same values of Mac OS. Over time, I moved to vanilla GNOME and gradually dropped some of the tools I initially felt were essential, like Albert, and Enpass. Instead, I opted for built in functionality or command line tools.

These gateway tools allowed me remain not too far outside my computing comfort zone. As time goes on though, I'm adopting more platform native options, like using the built in GNOME search instead of having a dedicated app for that like Albert.

GNOME was working pretty well for me and even got updated from 3.18 to 3.28 on FreeBSD (although it's remained there and the current version is now 3.32). Despite this, high resource usage, some conversations, blog posts and shift in workflow led me to reevaluate tiling window managers.

I was using the terminal more than ever before. I've been comfortable in the terminal for a long time but I realised that I was using the tiling features of Tilix and Neovim a lot. I was also using the tiling feature of GNOME to show two apps side-by-side.

The memory usage and log spamming of gnome-shell was bothering me too. The former overflowed into a snarky tweet that led to a conversation that more or less convinced me that the use of JavaScript in gnome-shell was not the ultimate cause of the memory issues but the fact that such an issue went unfixed for years made me evaluate other options. Note: As of GNOME 3.30 the leak should be largely fixed.

I had a good conversation with a friend and long time Linux proponent about his use of i3, and he commented that he felt I'd probably like a tiling window manager. I've tried i3 before but didn't really like it's semi-manual management of layouts. This did prompt me to start looking around though.

I read some interesting blog posts:

It was a comment on the post above, the really piqued my curiosity. It mentioned spectrwm (previously known as scrotwm) as a possible candidate. I installed it and was really taken by its primary/secondary tiling model and the sensible defaults approach. I tweaked and ran spectrwm on my XPS 15 for a while but eventually ran into some limitations of its configuration and integrated bar. At this point I was mostly enjoying a tiling window manager for the first time. I spent some time poring over the Arch Linux Wiki, Comparison of tiling window managers page. I reviewed most of the options on that page. Looking for ones that supported the primary/secondary model from spectrwm, were well maintained, configurable, came with a usable base configuration, and did not have many dependencies.

Eventually I landed on Awesome. It's a well established project and uses Lua for configuration, which is a simple, easy to learn language that allows almost any configuration to be created. I've been happily using it on all my systems for about four months now.

Awesome Window Manger - Using the 'centerwork' layout while working on my linux.conf.au badge

It's not all roses though, the thing with switching from a desktop environment to just a window manager is that it makes you really realise all the things that you get for free from the desktop environment. After settling into Awesome I needed to build/find replacements for the following features that I took for granted in GNOME:

  • Brightness control with keyboard buttons
  • Volume control with keyboard buttons
  • Setting the DPI correctly for a HiDPI display
  • Display adjustment when adding/removing an external display
  • Automatically unlocking the keyring upon login so that I didn't need to enter the password for SSH and GPG keys.
  • Displaying the battery and volume level in the top bar
  • Trackpad/mouse configuration:
    • Trackpad acceleration
    • Natural scrolling
    • Enable Clickfingers behaviour
  • Double buffering of windows to prevent tearing, black fills where shadows should be present.
  • Notifications

I did solve all these challenges. Check out my xprofile and rc.lua if you're curious.

Moving on From FreeBSD

From Oct 2017 to Jan 2019 I ran FreeBSD as the primary OS on my desktop computer. Similarly, I hosted this website and others on a FreeBSD server for more than two years. I recently rebuilt my personal server infrastructure on Docker, hosted by Alpine Linux and went back to Arch Linux on my desktop computer.

It wasn't any one thing in isolation that led to this switch. It was lots of little things that culminated in a broken system one day that pushed me over the edge. I will just list some issues that come to mind in no particular. This post would be very long if I went into detail for each item. I'm aware that there are solutions and workarounds to some of these, like running Linux in bhyve but it was the sum of the whole, not any individual items that made me switch:

  • ZFS on Linux being ported to FreeBSD:
    • One of the reasons I used FreeBSD was for ZFS. I did so on the assumption that the FreeBSD implementation was more stable and "more canonical" than ZFS on Linux (ZoL). However, the announcement that ZoL is being ported to FreeBSD to get its bug fixes, improvements, and wider developer base suggested that was wrong.
  • I wanted/needed to use Docker more.
  • The portion of the community that likes to point out jails existed before Docker and are somehow better.
    • In my experience the jails user experience is terrible compared to Docker and lacks a lot of the features that Docker automatically takes care of, such as networking, file system layers/caching, distribution of images.
  • Attending linux.conf.au:
  • The general fear and loathing of all change that some of the community exhibit.
    • They decry everything that doesn't keep things that way it was in 1970 as a violation of the "UNIX philosophy", as though everything done by the UNIX grandfathers was perfect and unchangeable.
  • Working on my Rust powered linux.conf.au e-Paper badge, a project that targeted Raspbian, which was easier to test with a Linux host.
  • More advanced virtualisation:
    • Such as built in graphics support, no need for VNC workarounds.
  • Losing hours to slow networking in virtualised environments, something that just works on Linux.
  • The reaction to the improved FreeBSD Code of Conduct last year by some of the community deeply troubled me.
  • Graphics support:
    • The recent drm-kmod work that brings modern graphics support to FreeBSD is a great improvement but it's a port of Linux code. If I'm running a bunch of Linux code anyway maybe it's better to just go to the source.
  • The onerous process required to contribute patches to update a port and find someone to review and merge them.
  • Bugs with patches supplied that sit unmerged for months unless you know the right people to nudge.
  • Continued use of tools that are unfamiliar to the vast majority of developers these days (Subversion, patch based workflow).
    • I can and did deal with this but I think it's a huge barrier to entry for new contributors.
  • A Electron port that no one seems to be able to get over the line.
    • I'm no electron fan but if the choice is no app or an electron app I'd at least like the option to run it.
    • There's a US$850 bounty on this issue, $50 I added myself.

Apologies, I know the above list is a bit ranty. For something a bit less ranty read this a great post by Alexander Leidinger that outlines some things he thinks the project needs to do to stay relevant.

I called out some community behaviour, and reactions above but want to point out that these folks don't represent the whole community. Lots of the BSD community are lovely and are doing the best they can with the comparatively small resources they have available. I thank them for their efforts.

The clincher was a failed upgrade in January 2019. I think I followed the handbook but something happened to the ZFS pool that prevented the system from booting from it. I was able to boot off an install flash drive and mount the pool fine but it refused to boot by itself. I spent several hours trying to fix it but in the end it was the final straw. I carefully backed everything up and then did a clean Arch Linux + ZFS install.

With the knowledge that ZoL was a lot more mature than I had originally thought I decided to install Arch onto the NVMe drive and then have /home live on a zpool comprised of the 3 SSDs.

One drawback to using ZFS for /home is that Dropbox stops working due to their brain-dead requirement that you must use ext4. There are hacks to work around it but I didn't have proper Dropbox support on FreeBSD so not having it on this install was no different. My use of Dropbox is in maintenance mode anyway so it's only rarely that I actually need it.

Finally, I may not be using FreeBSD day-to-day anymore but that doesn't mean I've completely left. I continue to make monthly donations to the FreeBSD and OpenBSD projects and will continue to ensure that BSD systems are well-supported by any software I build. I'll also advocate for avoiding unnecessarily Linux specific code where possible.

The Journey Continues

After more two years my journey continues and I expect it to keep doing so. I enjoy exploring what's out there and my preferences shift over time. In the future I expect to periodically try out Wayland based systems, like I did on the new desktop Arch install (issues with copy and paste between Firefox and Alacrity led me to put that on hold).

On the operating system front NixOS and Guix are pioneering new ways of constructing reliable systems. As a Rust developer I'm also watching Redox OS, an OS written from scratch in Rust. What comes of Google's Fuschia project will also be interesting to see unfold. The world of operating systems may not be as diverse as it once was but there's still lots to come.

Comments