Running i3 with URxvt as my terminal emulator and Compton for compositing. I had the URxvt background set to a semi-transparent color derived from my wallpaper by pywal. I also had a rule increasing the transparency of unfocused windows.

When I switched the focus of terminals, the focused terminal would be the right color but the unfocused terminal would turn semi-transparent black. I was expecting the opacity to decrease, but the color to stay the same. It turns out that URxvt has its own default setting to fade the terminal when it loses focus. It appears this involves a black or grey overlay (the source of the color change). You can disable this with the --fade switch at runtime or with the following line in your Xresources:

URxvt.fading: 0

Note that the switch is “fade” while the config option is “fading”. The value is the amount by which to fade (so 0 is off, 100 is complete). Disabling this also made the text on my unfocused terminals more legible.

My Matebook X Pro has a 13″ 3000×2000 display at 259ppi. It’s pretty sharp. Gnome (via Ubuntu 18.04) worked out of the box. I hear Plasma also works well out of the box but I haven’t tried it.

Getting HiDPI support with i3

Unlike Gnome, i3 has no built-in support for HiDPI displays. However, with a few tweaks, it works just fine. I’ll go over a few of the options I’ve experimented with. If you want the short answer, skip to the section on Xft. Quite a lot of this is covered at the Arch Wiki. I’ll be using my own DPI settings as an example so modify as needed.

The hard way: modifying xorg.conf

Xorg is the obvious place to start since it controls your display. There are a few ways to affect DPI in the short term. One method (useful for the Manjaro i3 install CD) is to type xrandr --output eDP1 --scale 2x2. You’ll get a usable but slightly fuzzy display. You can also set the DPI directly with xrandr --dpi 259 although your mileage may vary (it doesn’t seem to work if you’ve set the DPI by any other method).

To persist the settings you could put a call to xrandr in your .profile, but saving the values in xorg.conf is probably the way to go. You’ll need to either edit /etc/X11/xorg.conf or add a config file to /etc/X11/xorg.conf.d/. You can use one of two methods to tell xorg your DPI:

Section "Monitor"
    Identifier "<default monitor>"
    # To tell it your definitions and let X figure out the DPI
    DisplaySize 294 196
    # To just tell it the DPI
    Option "DPI" "259 x 259"
    # Only use one of the two above options
EndSection

This method will scale i3 and any plain X applications like URxvt. However, if you use some GTK applications like Libre Office or Chrome, those will be unaffected. You’ll need to tell GTK about your resolution.

Scaling GTK applications

There are a few ways to scale GDK applications. Ignore any advice about using gsettings to alter the text-scaling-factor. It has no noticeable effect on programs rendered outside of the Gnome DE. Testing it under Gnome suggests it affects the window decorations in Gnome but, since you’re using another window manager, it doesn’t do anything here.

There are two environment variables that you can use to scale GTK applications. GDK_SCALE (yes, that’s a “D”) will allow you to multiply the size of GTK applications by any integer value. GDK_DPI_SCALE will allow you to multiply the size by any fractional value. Why do both exist? According to the Gnome documentation, GDK_SCALE appears to be intended for your usual display scaling and GDK_DPI_SCALE exists as a workaround for people using non-HiDPI aware applications: it allows the user to double the system font size to make those applications readable and then halve the text size of GTK apps to bring them back to size.

You can use GDK_SCALEon it’s own to double or triple the size of GTK apps, but that’s probably not what you want. You can use GDK_DPI_SCALE on it’s own to set any fractional value. It works, but it’s not perfect. My guess is that the latter method increases the font-size and the UI scales to compensate. This leads to text that is slightly too large for the UI. Instead, what you can do is scale up with GDK_SCALE and then scale down the text with GDK_DPI_SCALE. Notice in the following photo how the UI is cramped when using GDK_DPI_SCALE on it’s own:

Scaling Google Chrome

Google Chrome isn’t affected by the GDK environment variables. However, it has a runtime parameter to force scaling: google-chrome-stable --high-dpi-support=1 --force-device-scale-factor=2

The easy way: Xresources and Xft

Forget everything above. Add the following line to the file ~/.Xresources: Xft.dpi: 180

Restart X and you’re done.

This will scale i3, GTK apps, and Chrome. You’ll have to manually increase font sizes in a few applications that don’t obey this setting like URxvt. You should definitely add GDK_SCALE=2 to your .profile and cancel it out with GDK_DPI_SCALE=0.5. This will fix the spacing issues seen in the screenshot above.

What I learned

I think DPI is solving the wrong problem. This value should be accurately reported but it shouldn’t be determining the size of UI elements and content except in very limited circumstances where absolute size is critical (e.g., word processing). Outside of those use cases, what people care about is apparent size. And that is heavily affected by how close you sit to your screen. I don’t want a website to appear the same absolute size on my laptop and my 24″ 96 DPI screen. I want it to be a little bit smaller but for it to appear a similar size after I move closer to the screen.

In the end, this means setting an inaccurate (too low) DPI on the HiDPI screen. This tricks the system into drawing elements slightly smaller and preserves the apparent size across systems. It simplifies the sharing of configuration files because even though a 12pt font will be different sizes on each computer, it should appear to be the same size. And that’s all that matters.

As the title suggests, I have installed Majaro-i3. I’ll post more about that later. First, I wanted to record the solution to my first big problem. I don’t know to what extent it is unique to my setup.

My laptop is a Matebook X Pro. I couldn’t get the Calamares installer to work with LUKS so I used Architect (thank you i3 Community Team for including both) to install the i3 edition. I don’t know if that results in a different setup than the graphical installer. I also automatically installed the free drivers. (Edit: this also happens if you manually install the video-linux package which has both the i915 and nouveau driver).

After the install, everything was working well except that when I tried to exit i3, reboot, or shutdown, the computer would freeze and the CPU fan would kick on. The logs were unhelpful although it was clear that the computer was indeed shutting down. journalctl showed that the X session was ending and all the expected shutdown/reboot events were firing.

There were three notable errors:

1. The Intel graphics driver (i915) was printing “Atomic update failure on Pipe A”
2. The Nvidia graphics driver (nouveau) was printing a whole series of errors intermittently
3. There was a kernel error: “watchdog: BUG: soft lockup – CPU# stuck for 22s!”

Researching the third error turned up a bunch of posts about nouveau. So 2/3 pointed that way. I created a file called /etc/modprobe.d/nvidia-blacklist.conf with the following contents:

blacklist nouveau
blacklist rivafb
blacklist nvidiafb
blacklist rivatv
blacklist nv
blacklist uvcvideo

Rebooted and things work fine.

Blacklisting is a bit of an extreme solution since I might want to get the hybrid graphics working at some point. On the other hand, the i915 is more than capable of handling my normal workload.

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).