linux

A few months ago, I replaced my Core i9 MacBook Pro with a Raspberry Pi 4 model B with 8GB of RAM for a day, and I made a video and a blog post about the experience.

Obviously there's a vast difference between a new Core i9 laptop with 32 GB of RAM, a dedicated GPU, and a 2 terabytes of fast storage and a tiny Raspberry Pi running ARM. So it wasn't a fair fight, but I could do a lot of things well enough, and every generation of Pi has gotten better.

A few weeks ago, someone from Mindshare Management asked me if I'd like to do the same test, but this time with an almost one-for-one replacement laptop: the new Kubuntu Focus M2.

Review video: Check out the video that goes along with this review:

After doing a video testing different external GPUs on a Raspberry Pi last week, I realized two things:

1. Compiling the Linux kernel on a Raspberry Pi is slow. It took 54 minutes, and I ended up doing it 7 times during the course of testing for that video.
2. If you ever want to figure out a better way to do something, write a blog post or create a video showing the less optimal way of doing it.

To the second point, about every fifth comment was telling me to cross-compile Linux on a faster machine instead of doing it on the Pi itself. For example:

And on the Pi Forums, it seems like nobody worth their salt compiles the kernel on the Pi either, so I figured—since I'm probably going to have to do it again another thousand times in my life—I might as well put together a guide for how to do it on a Mac.

Earlier this week, as part of my work doing a more complete review of the Raspberry Pi 4 (coming soon!), I decided I'd go all-in and spend one entire day working entirely (or at least as much as possible) from a Raspberry Pi.

And not just doing some remote coding sessions or writing a blog post—that's easy to do on a Chromebook, a tablet, or any cheap old laptop—but trying to do all the things I do in a given day, like:

• Browse Twitter using a dedicated app
• Use Slack (you laugh, but Slack uses more memory than most of the other apps I'm running at any given time—combined!)
• Record and edit clips of audio and video
• Work on some infrastructure automation with Docker, Ansible, and Kubernetes

So as with any project of this scope, I created a GitHub repository, pi-dev-playbook, to track my work—and, to be able to immediately replicate my development environment on a new Pi, should the need arise.

For many of my Ansible playbooks and roles, I have CI tests which run over various distributions, including CentOS, Ubuntu, Debian, and Fedora. Many of my Docker Hub images for Ansible testing include systemd so I can test services that are installed inside. For the most part, systemd-related issues are rare, but it seems with Fedora and DNF, I often encounter random test failures which invariably have an error message like:

No such file or directory: '/var/lib/dnf/rpmdb_lock.pid'

The full Ansible traceback is:

I wanted to document this process on my blog, since it's the second time I've had to do it, and it always takes me way longer to figure it out than it should... basically, here's how you can take a laptop with a hard disk that's running an older version of Fedora (in my case, Fedora 23), use the Fedora install media to re-partition the drive, then install a newer version of Fedora (in my case, Fedora 26):

Note: If you want to install and use PHP 7 and Composer within Windows 10 natively, I wrote a guide for that, too!

.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

Since Windows 10 introduced the Windows Subsystem for Linux (WSL), it has become far easier to work on Linux-centric software, like most PHP projects, within Windows.

To get the WSL, and in our case, Ubuntu, running in Windows 10, follow the directions in Microsoft's documentation: Install the Windows Subsystem for Linux on Windows 10, and download and launch the Ubuntu installer from the Windows Store.

When building certain roles or playbooks, I often need to add a new directory to the global system-wide $PATH so automation tools, users, or scripts will be able to find other scripts or binaries they need to run. Just today I did this yet again for my geerlingguy.ruby Ansible role, and I thought I should document how I do it here—mostly so I have an easy searchable reference for it the next time I have to do this and want a copy-paste example!

In this case, my_custom_path_var would refer to the path you want added to the system-wide $PATH. Now, on next login, you should see your custom path when you echo $PATH!

Generally speaking, I'm against performing major OS upgrades on my Linux servers; there are often little things that get broken, or configurations gone awry, when you attempt an upgrade... and part of the point of automation (or striving towards a 12-factor app) is that you don't 'upgrade'—you destroy and rebuild with a newer version.

But, there are still cases where you have legacy servers running one little task that you haven't yet automated entirely, or that have data on them that is not yet stored in a way where you can tear down the server and build a new replacement. In these cases, assuming you've already done a canary upgrade on a similar but disposable server (to make sure there are no major gotchas), it may be the lesser of two evils to use something like Ubuntu's do-release-upgrade.

When Microsoft announced the Windows Subsystem for Linux, now seemingly rebranded as Bash on ubuntu on Windows, I was excited at the possibility of having Drupal VM (and other similarly command-line-friendly open source projects) work better in a Windows environment. But unfortunately, the Anniversary update's version of WSL/Ubuntu Bash was half-baked, and there were a lot of little issues trying to get anything cohesive done between the Windows and Ubuntu Bash environments (even with cbwin).

Then, a year or so later, Microsoft finally announced that tons of improvements (including upgrading Ubuntu in the WSL from 14.04 to 16.04!) would be included in the 'Creators Update' to Windows 10, dropping tomorrow, April 11.

Ever since I heard about the new 'Beta' Windows Subsystem for Linux, which basically installs an Ubuntu LTS release inside of Windows 10 (currently 14.04), I've been meaning to give it a spin, and see if it can be a worthy replacement for Cygwin, Git shell, Cmder, etc. And what I was most interested in was whether I could finally point people to a more stable and friendly way of using Ansible on a Windows workstation.

In the past, there was the option of running Ansible inside Cygwin (and this is still the best way to try getting Ansible working in an older Windows environment), but this always felt kludgy to me, and I hated having to recommend either that or forcing Windows users to do a full Linux VM installation just to run Ansible commands. I finally updated my PC laptop to the latest Windows 10 Anniversary Update, and installed the Windows Subsystem for Linux, and lo and behold, Ansible works!