I have been a Linux user for just about twenty years. In the early days I played with distributions like Redhat and Mandrake from CDs included with Linux magazines. I switched to Slackware full-time in the early 2000s when I finally had proper internet access. Since 2006, I’ve been on Ubuntu. I’ve worked in the command line full time, with various lightweight window managers (especially iceWM and fluxbox), and in KDE and Gnome. For the past decade, I’ve followed the whims of Mark Shuttleworth from Gnome 2 to Unity to Gnome 3.

I recently bought a new laptop (a Huawei Matebook X Pro) with decent Linux support and decided I would try to catch up on what I’ve missed.

Why leave Ubuntu?

Ubuntu is a great distribution. It started as an offshoot of Debian Linux in 2004 and is now one of the most popular distributions.

Ubuntu has a predictable release cycle in which new versions come out every six months (timed to follow the Gnome desktop’s six-month release cycle by about a month). Releases are generally supported for nine months. However, every two years, there is a long term support (LTS) release that is supported for several years (currently up to ten years). With a few exceptions, software versions are locked in at the time of release and users will only receive minor updates for bug fixes and security issues during that support period. For example, Ubuntu 18.04 comes with Gnome 3.28 and will likely always come with Gnome 3.28 for the next decade even as 20 new versions of Gnome are expected to be released.

The release-based model is a strength and a weakness. The reliability of an Ubuntu system starts high and generally increases over time as bug fixes are applied and feature updates are left out. However, the slow pace means that you may not see new features for months or even years. You may not even have the latest software at the time of release. The most striking example in my experience has been Node.js. Ubuntu 14.04 LTS is still “supported” and comes with Node 0.11.4 (which was already out-of-date in April 2014). In 2014 and 2015, a group of developers forked Node and forced progress to leap forward. The current version is 11.5.0. However, if you have Ubuntu 14.04, the only thing you will officially get is that pre-1.0 release. Even Ubuntu 19.04 (which isn’t due until next year) only has 8.11.4 in its software repository.

The weakness can be overcome. More recent versions of software can be installed from a PPA. Node.js has the Node Version Manager. And, this being Linux, nothing prevents you from compiling the most recent software from source. In fact, I think this extreme stability is desirable in some applications. I will continue to run Ubuntu on the server. Major version upgrades break things and if it doesn’t need fixing why break it? On the server, you want stability, security updates, and bug fixes. So leave all of those applications in a known reliable state and look outside for the very few applications where you need the bleeding edge. The same could be said of a workstation. But it’s a little boring on a personal computer. I want to play with Gnome 3.30. OK, that’s not true, but I want to see for myself if it’s really more performant.

The other major feature of Ubuntu is that it makes many choices for you. Ubuntu is very opinionated. Even with the abandonment of Unity, Ubuntu doesn’t give you a vanilla Gnome Shell (though it is available). I trust and agree with a lot of Ubuntu’s decisions. It puts together a very reliable system that works flawlessly on every computer I’ve tried it with. Again, this is what I want on my server. It might even turn out to be what I want on my personal computer. But I think that I want to come to these decisions on my own. If nothing else, I want to understand them better than I do.

It’s primarily for this last reason that I’m abandoning Ubuntu on my personal computer. I want to make the computer mine. I might decide it’s not worth it and return to Ubuntu but at least I’ll come back with a better understanding of the state of Linux.

What distribution is for me?

Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. – Richard Stallman (apocryphal)

At the end of the day, I think there are more similarities than differences between distributions. They all run the Linux kernel, an init system (probably systemd), a command prompt (probably bash), a window manager or desktop environment, and a selection from the same collection of applications (LibreOffice, Firefox or Chromium, etc). You can achieve the same results with more or less work in any distribution.

Fixed release vs. rolling release

As described above, Ubuntu is a fixed release distribution. New versions are released on a schedule and major upgrades are often limited to that schedule. The more customised distributions tend to be fixed release because those modifications need to be applied to the underlying components.

Rolling release distributions update constantly with new software. However, this means that they don’t receive the level of testing that a fixed release gets. Features in an Ubuntu release are frozen months before the release date. The remaining time is spent on testing and bug fixes. This is on top of whatever testing the individual pieces of software received. So the trade-off is generally between newer software and stability.

Some distributions offer a mixture of the fixed and rolling release formats. Debian (the upstream source of Ubuntu) is available in an unstable version, a slightly more stable testing version, and a fixed release stable version with packages being promoted through the various streams.

Level of customisation

The primary separation between distributions from one another are the customisations made by the packagers. Many distributions favour a particular desktop environment and tweak that environment according to their own philosophy. Ubuntu, for example, features the Gnome desktop environment and makes modifications to make Gnome Shell look like it’s former Unity shell. Some, like Elementary OS, feature entirely custom desktop environments. The more customised distributions often also shift with tools for managing the operating system that depend on particular choices made by the packagers.

At the other end, of course, are distributions that make almost no attempt at customisation. Arch Linux and Gentoo provide nearly unmodified versions of their software packages.

Package management

Linux software can generally be compiled from the source code but this is time consuming. Most distributions distribute software in archives called packages which are installed by a package manager. Package managers include apt (.deb, Debian), yum (.rpm, Redhat), and pacman (.pkg, Arch). The type of package used by a distribution divides distributions into families that are often compatible and can share software. For example, software packaged for Debian as a .deb can generally be installed on Ubuntu. Most significantly, package managers handle the installation of dependencies (other software required by the program to run).

I’ve left out one notable package manager. Most package managers install pre-compiled binary packages. Gentoo’s portage system actually downloads and compiles source code on the user’s machine. This system is based off the BSD port system. In theory, this results in code optimised for a particular computer and allows the user to specify particular compiler flags (options that may enable or disable features in the software). This would contrast to binary packages which must be built with the broadest audience in mind.

What am I going to do?

In a move that makes me re-consider the sanity of blogging again, I started this post before Christmas and then set it aside for a while. At the time, I was sure that I wanted to install Arch on my laptop. However, I highly value being able to actually use my laptop for work. I have decided to publish this as part one and use part two to consider a variety of options for experimentation.

It has been just over five years since my last post. It barely counted as a post. My last post of any substance was six and half years ago in April 2012. As a 33 year-old who has been practicing law for five years, the description in the sidebar of my current theme still says I’m a 25 year-old law student. So where have the years gone?

In 2011 and 2012, when I was last regularly updating, I was between law school and articling and actively developing my other website LawOfCanada.net. That project was put on hold while I was articling with the Crown Law Office. While I was articling, I got a call asking me to remove the CanLII integration from LawOfCanada.net (Lexum soon after released Lexbox with similar functionality to what I was providing).

The defunct Divorces.ca is the cause of my only two posts in 2013 as I was learning Angular and developing the website for my semi-automated family law business.

For the last five years, I have been working as an assistant crown attorney in various jurisdictions around Ontario. Programming (the usual topic for this website) has been not quite on the back burner but certainly rear of the middle. I have rewritten LawOfCanada.net without CanLII integration from scratch in Node.js and React (replacing Symfony and Dojo). I have privately been working on a wiki that will eventually serve as the source for an annotated Criminal Code. However, the day-to-day of prosecution and the frequent moves for work have kept me quiet on the blogging front.

I’ve been blogging since it was called blogging. My first website was a Goosebumps fan page in the mid-1990s followed by a Star Wars fansite which was in operation from 1997 until around 2001 when Geocities deleted it without warning. My first blog ran from 2003 until 2008 when I decided to build up my web presence under my own name and started this site. With this little recap, I’m hoping to kickstart a return to the Internet proper. I will focus on technology and dabble in the law.

My first project will be a re-introduction to Linux. I’ve been a Linux user slightly longer than I’ve been blogging. However, I made the move from Slackware to Ubuntu in 2005 and to Ubuntu LTS in 2014. But when I tried to install Ubuntu 18.04 on my new laptop, I had a challenge for the first time in a while: the laptop would not boot into my encrypted system. The answer to my problem turned out to be simple (mkinitcpio) and reminded me that I used to know things like that. It is time to dive back in.

I have a long, multi-part Angular form on my <a href=”http://www.divorces.ca/” title=”Toronto Uncontested Divorces – Lawyer Prepared”>new website</a>. At a certain point, I began to find it difficult to review the source to ensure that the model being produced lined up with the output I wanted, so I wrote a bookmarklet that displays the ngModel attribute above each form control.

The current version unfortunately requires jQuery to be used on the page.

Source code

javascript:$('.debugAngular').remove();$("[ng-model]").each(function(i, el){ var pos = $(el).offset(); varNewEl = $("body").append('<div style="position:absolute;z-index:9999;top:'+(pos.top-15)+'px;left:'+pos.left+'px;background:#000;color:#fff" class="debugAngular">'+$(el).attr("ng-model")+'</div>') });

I’ve been playing around with node.js and I decided to try setting up a web socket connection. I’m using socket.io on the server side and Dojo Toolkit on the client side. Things on the server-side were straightforward. However, I decided to give dojox/socket a shot and got the following error:

-debug- destroying non-socket.io upgrade

As it turns out, dojox/socket is a fairly plain wrapper over the browser’s built-in Websocket object (with long-polling support added). Socket.io does rather a bit more and (rightly or wrongly) seems to prefer talking to itself. Luckily, if you’re not too picky, you can easily include the official (AMD-compatible) socket.io client:

Source code

require([
	'../socket.io/socket.io.js'
], function(io) {
	var socket = io.connect('ws://localhost:8000');
	socket.send("Hiya server!");
});

Note that the proper relative path to the socket.io.js file has to be specified (the proper version of this file is automatically served by socket.io through node.js).