ubuntu 20.10 on a raspberry pi 4 8gb

Summary

Canonical finally released a reasonably tuned version of Ubuntu 20.10 for the Raspberry Pi 4, 4GB and 8GB versions. I installed it on my 8GB board and gave it a small whirl as it were. Based on my initial experiences, while Ubuntu for Raspberry Pi is much polished over any other released version, it won’t replace Raspbian/Raspberry Pi OS, 64 bit.

Installation and Startup

This version of Ubuntu was installed on a SanDisk 128GB µSDXC card (V30, XC I, U3, A2). It was well more than enough room, and it was certainly inexpensive enough. On first boot, Ubuntu automatically resized the file system to use all the available space, which is to be expected these days

Ubuntu 20.10 fully recognized my LG display. Settings | Displays shows it as an LG Electronics 29″ monitor with 2560 x 1080 (21:9) resolution. This beats Raspbian in a way, as you have to make a minor tweak to Raspbian after first boot to remove outer black bands and fill the entire display. Every other version of Ubuntu for Raspberry Pi would not properly work with my LG monitor, and as a consequence it was always blacked out after first boot.

Initial Usage

One of my long-running peeves with all Linux distributions is the inclusion of bloat in the form of unneeded applications, especially games. I used to be able to go in before installation and deselect a lot of that, but with Ubuntu for Raspberry Pi, you get it all, whether you want it or not. Raspbian by comparison is tight in that you get only what you need. You can install more later on if you wish, but you don’t have to go hunt down the superfluous bits and delete them. Since this was meant to be a quick peek at Ubuntu, I skipped this phase and moved on.

I was surprised that the GCC tools weren’t installed. Performing apt install build-essential got me what I needed. I also had to install git and curl (for installing Rust). I have yet to understand why these are not installed with the base, as we’re not asking for much, either in tools or disk space..

I also installed Visual Studio Code, which is now fully available as a package for AArch64/ARM64 from Microsoft. Go to the download page ( https://code.visualstudio.com/download ), look in the middle for Linux, and select ARM 64 for the .deb packaging. I am no longer attempting to build VSCode on any of my ARM64 systems any more. And when it is fully installed, it identifies itself as Visual Studio Code, not some janky weird name.


With VSCode in my arsenal of development tools, I no longer have a need for either Vim or Emacs. I can install the extensions I care about and move on with my life.

All of this is applicable to Raspbian OS as it is to Ubuntu for Raspberry Pi.

Operations and Final Thoughts

There’s no getting around that Ubuntu for Raspberry Pi is a formidable distribution when it comes to working in a powerful development environment. All the tools are up-to-date, at least as far as the release date for Ubuntu 20.10. These tools are far more up-to-date than what is stock on Raspberry Pi OS. So there’s that.

But when it comes to day-to-day usage, Ubuntu for Raspberry Pi has an aggravating slowness to how it operates. Startup of any application is noticeably laggy, enough to be annoying after a time. Moving windows around on the desktop is choppy at best. Raspbian, by comparison, is every bit as snappy as Ubuntu on regular x86-64 hardware. Everything starts quickly and the desktop is smooth. Raspbian is fast enough to be transparent in use and to just get out of my way. Ubuntu for Raspberry Pi, not so much.

And this Ubuntu, similar to Ubuntu releases on on other ARM64 boards (such as nVidia’s Nano and Xavier boards) has a much larger memory footprint than Raspbian. Memory is fixed on all these boards, such that I pay attention to how much I have to give to the OS before I even get started with my application usage.

Ubuntu 20.10 for Raspberry Pi is a compelling offering, especially if you’re an Ubuntu power user on other hardware and want to maintain the same working environment across all your different machines. While it won’t currently replace Raspbian 64-bit on my Raspberry Pi, it’s so very close to being able to do so. If the next release can pick up performance and reduce resource usage, then it will stand as a true alternative to Raspbian. And that’s when I’ll make the move over Ubuntu on my Raspberry Pi 4 devices.

using parallels desktop for mac 1.6.0 with current linux distributions

Fedora 33 Beta, in all its glory

An update to Parallels Desktop for Mac installed on my MacBook today. Version 1.6.0 is currently running on my system, supporting five Linux virtual machines:

  • Ubuntu 20.04 LTS
  • Ubuntu 20.10
  • PopOS 20.04
  • CentOS 8.2.2004
  • Fedora 33 Beta

When I first installed Parallels about a month ago, I installed two of the five Linux VMs (both Ubuntu LTS and PopOS), including Parallels Tools, without any issues. I use Parallels Tools to allow VMs to natively access a certain folder on my MacBook’s file system so that I can share files between all the virtual machines as well as the MacBook itself. I do that with VirtualBox, and it’s a feature I really depend upon. Unfortunately hen I installed the other three and attempted to install Parallels Tools on those VMs, Tools failed to build and install.

This is a problem I’ve run into in the past with VirtualBox. The tools required to better integrate the VMs into macOS are dependent on the Linux kernel headers. If they change, as they are wont to do between various kernel releases, then the tools build will fail. There’s not much you can do about it except wait for a new Parallels or VirtualBox release to arrive that works with the latest kernel headers.

Normally I’d rail against the makers of Parallels or VirtualBox about that issue, but the real culprits are the Linux kernel developers who decide to make changes all for the sake of whatever they feel is justified. There’s very little I can do about it, except to run with an operating system as the host to my Linux VMs that shows better maturity and class — macOS.

I run the VMs because I need the tools they carry, especially the most advanced versions, such as Python, GCC, Clang/LLVM, Git, and CMake. I’ve got “legacy” applications I keep bring forward with me, adapting to the latest tools, while updating source modules to take advantage of the latest language standards. I run the VMs because there are customers who run with Linux on utility hardware, to do backend duty. So I fire up an instance and develop inside of that, then deploy my work on their systems when they’re happy with the results.

I’m very happy with Parallels and Linux on macOS, especially with the 16″ MacBook Pro as the host. 64 GB and 4TB of SSD makes for a sublime experience all around.