Matt Watson

So, I finally switched from Apple to Linux, something I’d been planning to do for a while. I thought it would be of interest to share my reasons for switching and what I think after being on Linux for about the past month.

Reasons for switching

1. On-screen keyboard

I mention this because my love-hate relationship with Apple’s various solutions to this accessibility issue has been somewhat notorious. Long story short: Apple used to have an on-screen keyoard that didn’t work, but they eventually came around. Not only did they fix bugs that made it impossible for a disabled person who can’t use a physical keyboard, they eventually rolled out with a built-in app greatly mimicking AssistiveWare’s outdated but glorious Keystrokes. Now you can get the formerly 300-dollar Keystrokes experience for free, built-in!

That is great, honestly, but I still have been slightly disappointed. At least up to the last Mac OS I used — High Sierra — there were some major freezing and key-repeat bugs going on. The main thing was, it was just slow. That could be blamed on the fact that my Apple computer was slightly aged and running on 4 GB RAM. But still, I was running Linux’s Onboard on-screen keyboard faster on an even older, 1 GB repurposed Acer notebook. I just couldn’t understand why Apple couldn’t make theirs faster. And personally, I wasn’t a big fan of the UI.

Onboard is by far my favorite thing about Linux. Without the need for it, I probably would not have switched to using Linux as my main computer. I can type so much easier and faster on my new computer, it ain’t even funny.

2. Less money

Since I was going to use Linux, I had more of a market of used computers to choose from. Instead of buying a new Mac Mini or trying to find a used one for barely less, I just bought a $500 homemade gaming computer from an IT friend. I already had a monitor and the other accessories I needed. 16 GB RAM and a 1 TB hardrive. Just what I wanted. (I did kinda want a solid-state drive but just couldn’t bring myself to shell out the money for one.)

3. Less money, again

I like the idea of focusing on using open-source/free software that is available gratis. I went into it knowing options and support are limited in the open-source world, but there are advantages that outweigh that, including

• Some truly golden nuggets that are completely free, such as Onboard. Other examples include GIMP, Inkscape, and LibreOffice. These are basic functionalities you have to pay for on other OSes unless it comes with your purchase.
• An independent ethos – The fact that the maintainers of much of the software you are using are essentially volunteers gives a certain democratic, independent-minded aura to using a Linux that’s kinda cool.
• Forces you to go back to basics and not get caught up in purchasing apps. Don’t get me wrong, I love shopping for apps, and there’s nothing wrong with it. At the same time, it can be liberating to go minimalist and just survive off of what you already have.
• Adaptability – While open-source programs are adaptable by definition, I have noticed that even if you don’t/can’t edit source code, the programs tend to provide more custom options for users, options that would turn off a consumer market but that power users appreciate.

4. Privacy

Richard Stallman and the Free Software Foundation seem eccentric and radical sometimes, but I can’t help but sympathize with their arguments about privacy and control of your operating system. To borrow a phrase from a good friend of mine, “they’re not wrong.”

How it’s going

All these reasons are good in theory, but how is it going in reality?

Well, Onboard has certainly proven to be awesome. And the Linux programs I know and love have been working great — LibreOffice, GIMP, etc. VSCode runs super smooth, while my old Mac was not able to run it consistently. So the RAM has done its job, and I believe it has been helped along by the fact that I am running a lightweight distro/desktop environment (Debian 9 with LXDE).

There have been some significant downsides that I can’t deny.

Installation

For starters, it took me 8 hours to get Linux installed properly. My IT buddy had pre-installed Ubuntu for me, but for some reason, I never could get the video resolution to work properly with my monitor. I decided to just reinstall from scratch, and I took that opportunity to install Debian 9 with LXDE, which I had used on a VirtualBox VM and knew it worked well. I am not physically able to handle hardware or type, so getting other people to plug things up, bring up the BIOS/guess which darn F key to press (in the .00000000001 seconds it gives you!), and go through the Debian install dialogue was part of what took forever.

Tablet configuration

I use a Wacom Intuos Draw tablet, as well as a thumb trackball mouse, to move the arrow on screen and type on the on-screen keyboard. I rarely actually draw with the tablet, but pointing and clicking to type is much faster on such a tablet, and with Onboard laid out with the Chubon keyboard layout, even faster.

But Wacom does not provide drivers for Linux, so you have to get the open-source driver, which is good but doesn’t work as well. Plus, I couldn’t figure out how to get the GUI to control settings. The GUI comes with Linux Mint and Ubuntu I know for sure. I was eventually able to get my setting right by saving a 71-wacom.conf file to the /etc/X11/xorg.conf.d directory with the following settings, FWIW:

# Some of the below input classes appear 3x times, once for each of
# "tablet", "touchscreen", and "touchpad" to ensure that the Wacom
# driver is not accidentally bound to other types of hardware that
# Wacom has made which are not handled by the wacom driver (e.g the
# Wacom Bluetooth Keyboard)
#
# https://sourceforge.net/p/linuxwacom/bugs/294/

Section "InputClass"
        Identifier "Wacom USB tablet class"
        MatchUSBID "056a:*"
        MatchDevicePath "/dev/input/event*"
        MatchIsTablet "true"
        Driver "wacom"
    Option "Mode" "Relative"
    Option "Button 2" "3"
EndSection


Section "InputClass"
        Identifier "Wacom USB touchscreen class"
        MatchUSBID "056a:*"
        MatchDevicePath "/dev/input/event*"
        MatchIsTouchscreen "true"
        Driver "wacom"
EndSection

Section "InputClass"
        Identifier "Wacom USB touchpad class"
        MatchUSBID "056a:*"
        MatchDevicePath "/dev/input/event*"
        MatchIsTouchpad "true"
        Driver "wacom"
EndSection

Section "InputClass"
    Identifier "Wacom tablet class"
    MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
    MatchDevicePath "/dev/input/event*"
    MatchIsTablet "true"
    Driver "wacom"
EndSection

Section "InputClass"
    Identifier "Wacom touchscreen class"
    MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
    MatchDevicePath "/dev/input/event*"
    MatchIsTouchscreen "true"
    Driver "wacom"
EndSection

Section "InputClass"
    Identifier "Wacom touchpad class"
    MatchProduct "Wacom|WACOM|PTK-540WL|ISD-V4"
    MatchDevicePath "/dev/input/event*"
    MatchIsTouchpad "true"
    Driver "wacom"
EndSection

# Serial Wacom devices should always be one of tablet, touchscreen, or
# touchpad so we can safely get away with just one match section in
# these cases
Section "InputClass"
        Identifier "Wacom PnP device class"
        MatchPnPID "WACf*|WCOM*|WACM*|FUJ02e5|FUJ02e7|FUJ02e9"
        MatchDevicePath "/dev/input/event*"
        Driver "wacom"
EndSection

Section "InputClass"
    Identifier "Wacom serial class"
    MatchProduct "Serial Wacom Tablet"
    Driver "wacom"
EndSection

Section "InputClass"
        Identifier "Wacom serial class identifiers"
        MatchProduct "WACf|FUJ02e5|FUJ02e7|FUJ02e9"
        Driver "wacom"
EndSection

# Hanwang tablets
Section "InputClass"
    Identifier "Hanwang class"
    MatchProduct "Hanwang"
    MatchDevicePath "/dev/input/event*"
    Driver "wacom"
EndSection

# Waltop tablets
Section "InputClass"
    Identifier "Waltop class"
    MatchProduct "WALTOP"
    MatchIsTablet "on"
    MatchDevicePath "/dev/input/event*"
    Driver "wacom"
EndSection

# N-Trig Duosense Electromagnetic Digitizer
Section "InputClass"
    Identifier "Wacom N-Trig class"
    MatchProduct "HID 1b96:0001|N-Trig Pen|N-Trig DuoSense"
    MatchDevicePath "/dev/input/event*"
    Driver "wacom"
    Option "Button2" "3"
EndSection

And you need to be sure to name it 71-wacom.conf, or one above whatever’s in your /usr/share/X11/xorg.conf.d directory, which already had a 70-wacom.conf file in my case, because those conf files will apparently run on startup in sequential order according to how they are named.

Anyway, I’m getting way more into the weeds than I meant to, but all this to say, it was hard to set up. In hindsight, I probably should have gone with a more user-friendly distro.

No compositor

This is again related to the fact that I chose LXDE, which increasingly seems like a mistake. There are things I love about it, such as PCManFM, the task bar, and the fact that it ships with unopinionated defaults. And I even liked the fact at first that it had no compositor, because for most of my first month, I didn’t need one and figured no need to slow the computer even more, even if unnoticeably. However, one need that a compositor fills is those times when you need transparency, such as when grabbing an area of the screen in Kazam. I installed Compton, but it doesn’t seem to be working right. It gets the job done, but there are some weird glitches, such as the rounded corners of the Onboard keyboard not handly transparency consistently. And I had to add Compton to start-up applications, which was confusing, and I’m not sure if I did it right.

No iPhone tethering

I had highly depended on my Mac as the gateway to my phone, which I cannot physically use anymore due to good ol’ SMA. I do plan on switching to Android soon, which I hear offers even more control via desktop, but until then, I tend to ignore all my calls unless an able-bodied person is around to answer for me :-|.

Conclusion

But all in all, I think it was worth it. The fine-grain control I have over my system, the greatness of Onboard, the money saved, and getting to be on my moral high horse as a free software user :-), outweigh the downsides. I will post some more Linux tricks possibly in the future. Stay tuned!

UPDATE: A reader points out:

“‘Some truly golden nuggets that are completely free, such as Onboard. Other examples include GIMP, Inkscape, and LibreOffice. These are basic functionalities you have to pay for on other OSes unless it comes with your purchase.’

“1. All of these are available for Mac I believe. Don’t conflate open source apps with open source OSes. [Of course. I didn’t mean to say you can’t run those programs and other free programs on Mac or Windows, but you have to pay for alternatives to them, such as Word. Also they do not run as well and can be harder to install on Mac, in my experience. — MW]

“2. Apple’s office suite is free. [Fair point. I didn’t realize they changed that. I had to pay for mine. — MW]

“A bunch of your speed issues were RAM-related, not Mac-specific necessarily. [All except the fact that Onboard runs faster on a 1GB RAM Acer notebook w/ Linux than Apple’s accessibility keyboard on a 4GB RAM Mac Mini. — MW]

“I’ll give you credit for sections 1, 2, and 4, but 3 is just celebrating open source in general, which doesn’t require a switch to Linux to enjoy. [Agreed. — MW]

I discovered the technique of using functionality plugins several months ago and was reluctant at first. When building a site with WordPress using my own theme, I usually just dump any custom functionality I want into the functions.php file. But the idea with functionality plugins is that you put non-theme-specific code into a plugin instead. This prevents your code from being overridden when changing themes.

Addressing objections

At first, this might seem like a bunch of hassle for little payoff. You might be thinking:

“I don’t know much about making plugins.”

But a functionality plugin is not a big plugin like you would normally think of. It is simply one file (you can optionally put it into a folder) that works just like your functions.php file, only you must put a special header at the top. For instance, this website uses a plugin I made called “Matt Watson Functionality” that is simply one file I placed in my wp-content/plugins folder and named mattwatson-functionality.php. It starts like this:

<?php
/**
   * Plugin Name:       Matt Watson Functionality
   * Plugin URI:        https://www.mattwatson.org/
   * Description:       Matt Watson functionality plugin
   * Version:           1.0.0
   * Author:            Matt Watson
   * Author URI:        https://www.mattwatson.org/
   * License:           GPL-2.0+
   * License URI:       http://www.gnu.org/licenses/gpl-2.0.txt
   * Text Domain:       mattwatson-functionality
 */

From there on, I put whatever PHP code I want, just like I would in the regular functions file.

“I’m using my own theme that I’m never going to change, so what’s the point?”

This is certainly a common use case scenario — where a developer is coding their own or a client’s website and is only using WordPress’s theming feature because that’s what you must do in order to use the CMS. This kind of “theme” is not meant to be used by anyone else, is not going to be distributed in anyway, and is not meant to be switched out. In essence, the theme is the website.

While it is true that such a website is not designed in the first place to allow the user to switch themes, there are still other scenarios where having your functionality code separate from the theme is useful. For instance, in 3-5 years when the website frontend design plans get overhauled, you might want to develop the frontend code from scratch again using a new custom theme. Essentially, you are rebuilding the website… but if you’ve used a custom functionality plugin, you have saved yourself some time. You don’t need to migrate non-frontend-related code to the new theme, because your plugins will just carry over.

Using a functionality plugin with other themes

Most chatter I’ve read on using functionality plugins are directed toward developers who are coding their own theme. But what if you’re a lazy developer like me who is just using a standard theme from the WordPress.org repo? It is rather common, in fact, for developers to have ugly personal websites or use other people’s themes, because they just don’t have time to work on it. When you use a third-party theme, though, you pretty much lose the ability to write anything to the functions.php file, because your changes will be deleted on a theme update. This is annoying if all you need to do is add a few lines of code to, say, the head of your pages, or inject a few style rules for whatever reason. This often results in just downloading a plugin from WordPress.org. A lot of these plugins do super basic things and are largely meant for non-developers.

But if you’re a developer and used to touching the code, you can just add a functionality plugin to do basic things instead of using other people’s plugins, which are usually large and designed to do a lot of things you might not even need.

For instance, I decided to use the Twenty Fifteen theme for this site, and I wanted to track my site’s traffic using my self-hosted Matomo installation. While I could have downloaded a plugin from WordPress.org that would inject Matomo’s JavaScript snippet into my page head, I can just do it myself in my own functionality plugin. And hey, while I’m at it, I’ll go ahead and add anything else I need to the wp_head hook, such as my favicon links.

<?php

// [... Plugin header]

add_action('wp_head', 'mw_wp_head');
function mw_wp_head() {
	?>
	<!-- MW Custom Plugin -->
	<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
	<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
	<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
	<link rel="manifest" href="/site.webmanifest">
	<link rel="mask-icon" href="/safari-pinned-tab.svg" color="#5bbad5">
	<meta name="msapplication-TileColor" content="#da532c">
	<meta name="theme-color" content="#ffffff">

	<?php if( !is_user_logged_in() ): ?>
		<!-- Matomo -->
		<script type="text/javascript">
		  var _paq = _paq || [];
		  /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
		  _paq.push(['trackPageView']);
		  _paq.push(['enableLinkTracking']);
		  (function() {
		    var u="//piwik.mattwatson.org/";
		    _paq.push(['setTrackerUrl', u+'piwik.php']);
		    _paq.push(['setSiteId', '1']);
		    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
		    g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
		  })();
		</script>
		<!-- End Matomo Code -->
	<?php endif; ?>
	<!-- /MW Custom Plugin -->
	<?php
}

When you need to push code but can’t FTP

Usually, to update your custom theme’s functions.php file, you would just FTP it (or use a deployment service that does the equivalent). But there might be times where you need to update someone’s website but don’t have access to FTP. For example, the website might have an IP address whitelist, and you’re working remotely today. Or maybe your FTP program is not working for some reason. Not an ideal situation to be in, but it happens.

The more functionality code you have extracted out to plugins, the easier it will be for you to make updates in a pinch. You can just change the plugin and re-upload it in the WordPress admin area. Of course, you could do the same for the theme, but that involves re-uploading all theme files from a zip. Easier just to upload your-plugin-name.php on the plugins screen.

Final thoughts

Going from dumping all your functions in the theme to dumping them in a functionality plugin might not magically make your code that much more organized. You can always be more organized by doing things like applying object-oriented programming with classes to using namespaces, etc., but this is at least a good start with concrete payoffs.