Category: VirtualBox

initial ubuntu 20.04 musings

whbeebe
Ubuntu 20.04 in dark mode

tl;dr — I installed Ubuntu 20.04 inside VirtualBox 6.1.6 r137129 and kicked the digital tires. I may have stubbed my virtual toes.

Environment Setup

The VM configuration on macOS. Unless noted below all other settings were the default.

  • 4 GiB memory
  • 40 GiB disk
  • Floppy disk taken out of the boot order
  • 128GiB video memory buffer
  • Two processor cores
  • Graphics controller VMSVGA with 3D Acceleration enabled
  • Networking is bridged adapter with vertio-net adapter
  • Shared folder with ~/Shared

Base OS Installation

Ubuntu was installed as a minimal desktop with Firefox browser using the ZFS filesystem. The basic build environment, which includes gcc and the kernel headers, is installed after first boot. I installed with the ZFS file system because I was curious and wanted to try it out for a bit.

If you want to install gcc and all the build tools and libraries, then do a single ‘apt install dkms’ and everything will be pulled in. You need to do this if you are going to build and install the VirtualBox Guest Additions. You’ll need to build them if you want:

  • a seamless desktop experience between the Ubuntu virtual desktop and the macOS desktop, and
  • to use the shared macOS folder within the Ubuntu VM.

And before you can actually see the shared folder inside Ubuntu without sudo, you need to add the regular user login to the vboxsf group as defined in /etc/group.

Additional Tool Installation

I also installed Google Go, Clang, Git, Vim, CMake, htop, and Visual Studio Code. Which brings me to my first criticism of Ubuntu. Go and VSCode aren’t regular apt installable, but are only available through the snap tools. That would be fine, except the versions are not up to date (Go is one major release back at 1.13, whereas Go is currently at 1.14.2). Snap is a great idea as long as its tools are up-to-date, but I’ve not yet found a snap package that wasn’t behind in some way. In the case of Go, it can be pulled from go-lang.org as a tarball and unpacked under /usr/local. VSCode can be pulled from its Github distribution area as a deb file and installed locally. And that deb file brings up another issue: the default when you click a deb file is to unpack it, not install it. Now you have to right click and then select from the context menu to install it. I’m assuming this is considered a security feature, but if it is, it’s dubious at best.

My First Impressions

Overall I believe the distribution is OK. Nothing to rave about. Almost boring. But believe me when I say that boring is good, especially with operating systems. Absolutely no installation drama whatsoever.

This is the first LTS distribution I’ve installed with the full Gnome desktop. I still have Ubuntu 18.04.04 installed on my ancient Samsung R580, and it’s running just fine, thank-you-very-much. For the time being I won’t be trying to upgrade the R580 to 20.04, and I may never do it. And not because I don’t believe a 10-year-old notebook can’t handle it.

While I certainly appreciate its boring stability during installation and setup, I’m not all that impressed with this latest and greatest. If you’re careful and paying attention it does have the latest tool releases (which is what I’m always interested in). But there are little things (minor things to the general user community, I’m sure) that bug me a bit. The biggest annoyance is that the desktop, using Xorg (not Wayland) is not fluid when working with it, such as window manipulation on the Ubuntu desktop. It has these little hesitations as you move a window around or resize it. I have Ubuntu 19.10 installed as a VM as well, and that release runs a notably smoother as a VM in the same VirtualBox release. The Ubuntu 20.04 desktop is also a bit more of a memory hog than I’m used to with older versions of Ubuntu.

I’ll hang onto this installation, using it for functional testing and to try out the latest gcc and clang releases. Overall I think it’s a great release. Personally I believe that a bad install/day with Ubuntu is always better than a good install/day with just about any other distribution, so there’s that. If you’ve got the hardware horsepower I’m sure it will run a lot smoother than what I’ve experienced so far, which makes me tend to believe I need yet another new computer, something I really don’t want to spend money on. After all, I’m supposed to be retired, with a fixed income that can’t support multiple-thousand-dollar computers. My MacBook Pro is a mid-2015 machine, while the Samsung R560 with Ubuntu 18.04.04 was released over a decade ago. Situated in the middle of those two is my mid-2012 Mac Mini Server, purchased refurbed in 2014.

Ubuntu 20.04 is more than functional for my modest needs. I guess I was expecting a bit more pizazz than what I found. As long as 20.04 is stable and reliable, then I’ll trade that for pizazz and move on with my life.

red hat enterprise linux (rhel) 8.0

whbeebe

Here’s my personal review of Red Hat’s latest, RHEL 8. It’s not much, so if you’re looking for something far more in depth, then you won’t find it here. Instead I look at it from the perspective of an end user who’s used older versions, and try to determine if I should use this latest version.

RHEL 8 was formally released 7 May 2019, a little less than a month ago from the date of this post. It’d been out in beta form before that, as I noted by a number of comments in various fora around the end of 2018. But I stayed away from checking this latest RHEL release, due in no small part to my less than happy experiences using RHEL 7 and its unpaid version CentOS 7.

From what I’ve seen so far it appears that RHEL 8 may actually deserve its primary version increase. The upgrades across the board are substantial enough. If I wanted a RHEL-like distribution with up-to-date tools, why not use Fedora? Because I DO NOT want to deal with Fedora’s peculiarities and periodic ‘bleeding edge’ breaking changes within Fedora releases just to keep up with the latest packages. All I ask of my Linux distributions is that they are reasonably up to date in the core tools and will work without special handling in just about any environment. There are a lot of distros that can do this, but Fedora isn’t one of them. I haven’t used Fedora since its late teen releases, and I don’t expect I ever will again. But it would appear that RHEL 8 now falls within that categorization of easily up-to-date and easy-to-install. Thank you Red Hat.

It looks like there might be just a tinge of desperation at Red Hat Central. I say this in large part noting how RHEL 8 is being launched. In the past, when I went to download and install a developer version of RHEL 7, I jumped through a fair number of hoops to get an ISO. After installation I was reminded periodically that my ability to install updates was time limited. RHEL 8 on the other hand is noticeably different. Everywhere I look and read there are articles about RHEL 8 as a development platform. When I went and logged recently into Red Hat  Developer, I was immediately led to the download section where I easily found and downloaded my ISO copy. After installation as a VM in Oracle’s VirtualBox (6.0.8 as of this writing) on macOS 10.14.5, and after registering with my developer credentials to keep my installation up-to-date, I was not greeted with any kind of time limitation warning. It still annoys me I have to register to get the updates, which is one big reason I prefer CentOS; CentOS updates are just a simple yum away.

I think that desperation might be rooted in the observation that Red Hat might not be relevant to a lot of developers these days. Red Hat’s biggest competitor I believe to be Ubuntu. I’ve read a number of stories where developers, especially AI developers, are now buying machines with Ubuntu desktop pre-installed. And I’ve watched Ubuntu pushing out not just into the server side but into cloud containers as well IoT images. Yes, I know all about Red Hat’s push with Kubernetes. But that’s countered in part that Red Hat is now owned by IBM, and I can assure you that I at least am not happy about IBM in the mix. That’s another reason I’ll get my images from CentOS and go elsewhere for my cloud needs.

RHEL 8 is actually using a fairly recent Linux kernel, 4.18, as apposed to RHEL 7 and RHEL 6, which stuck with a version 3 kernel, heavily patched. And the tools supplied in RHEL 8 are also fairly up-to-date; gcc is at version 8.2.1, git is at 2.18.1, and Python (or python3) is at version 3.6.8 (python2 isn’t even installed). So the quality of the tools in RHEL 8 is, in my not-so-humble-opinion, a big step up over RHEL 7, and about time. All of this is out-of-the-box.

There were some additions and tweaks. For example I added gnome-tweaks to get the Tweak Tool and enable dark mode via Adwaita-dark. I also enabled all the control buttons on the right corner of each window and enabled having the application’s control menu on the application’s left side. That last “feature” really bothers me. This is yet another attempt to copy an Apple macOS feature. That feature looks great on macOS, but it’s always looked bad on the Linux desktop. Seriously, if you want that look and feel then buy a Mac. And finally, for running RHEL 8 as a VM in VirtualBox 6.0.8 on macOS Mojave 10.14.5, you need to select running the VM’s desktop as a standard Xorg X windows system, rather than using Wayland. Wayland does not play well with VirtualBox and it hasn’t since Wayland was first officially released with RHEL, going back to VirtualBox 5.x. You pick that at the login screen (see the little gear on the lower right beneath where you type in your password). If you don’t do that you’ll see nothing but constant tearing and flashing of the virtual display.

My installation was bare-bones, just enough for the tools (compiler tool chain primarily) without any games or social media or office software. As pure as possible to just a desktop and basic developer tools. To that I added htop, Amazon’s Corretto Linux release (Java 8 212), Microsoft’s Visual Studio Code editor and IDE, and Microsoft’s PowerShell Core 7 Preview 1. The following three show htop, Visual Studio Code, and PowerShell respectively.

There’s a reason for these specific applications. The same applications run on macOS and Windows 10. That means that given the same languages (Python and Java, for example) or advanced C++ compilers that support the latest C++ standards (gcc 8.2 and Microsoft’s Visual Studio, for example) as well as the same CM tool (Git), then there is no longer any reason to remain committed to a single platform. Commit all your work up on Github, and then move from platform to platform as the need may be to get your job done. And I very much like the idea of PowerShell being common across all the platforms.

I believe RHEL 8 is going to be a very solid release, the best in a few years. The only issue is with other distributions, the biggest competitor being Ubuntu. I run a mod of Ubuntu from System 76 called Pop!_OS. It too has Corretto Linux, Visual Studio Code and PowerShell. I like Pop!_OS primarily because of its very excellent looking desktop out-of-the-box. For all practical purposes RHEL 8 has achieved parity with the latest Ubuntu release and derivatives.

Update January 2020

I deleted the Pop!_OS VM some number of months back because it seemed to have corrupted itself. I’ve only had one other Linux distribution do that, and it was Arch Linux.

On RHEL 8 I’ve replaced Amazon’s Corretto Java with AdoptOpenJDK (https://adoptopenjdk.net). PowerShell 7 is now up to Release Candidate 1.