One of the tasks I use the MBP for is running Linux virtual machines. For that purpose, there are two well-known tools; Oracle’s VirtualBox, which is open source and free, and Parallels Desktop, which is commercial. Both are capable of running most Linux distributions I care about, and Parallels is known for running Windows, and rather seamlessly, on the macOS desktop. The only problem is I have no need to run Windows as a VM, as the critical application Office is available as a native macOS application.

One major difference between VirtualBox and Parallels is that VirtualBox appears to need a kernel extension installed for its VMs to operate. VirtualBox ran just fine until I updated macOS to 11.6. It ran without issue on every release before that. When I stepped up to Big Sur 11.6, VirtualBox VMs would no longer boot.

Every time I would attempt to start a VirtualBox VM, I would get something like the following:

along with this:

Very annoying to say the least. I finally solved the problem thusly:

• Boot the MBP into macOS recovery mode following these directions: https://support.apple.com/en-za/HT201314
• When in recovery mode, open a terminal (Utilities > Terminal), using the menus on the upper left.
• In the terminal execute csrutil enable --without kext
• In the terminal execute spctl kext-consent disable

Then reboot out of recovery mode and back into macOS. The next time you attempt to start a VirtualBox VM, you will succeed.

I ran into another issue when I upgraded from VirtualBox 6.1.26 to 6.1.28. Under 6.1.28 I ran into the same VM boot issue, even though the documented changes were still in place. When I downgraded back to 6.1.26 it all started to work again.

If you’re wondering why I just don’t run everything under Parallels, it’s because Fedora and some of the other distributions I need to run don’t work very well with Parallels. The only distribution that works without issue under Parallels, regardless of version, is Ubuntu or Ubuntu derived distributions. Most of the time I’m quite OK with Ubuntu, but every now and then I need to I need to dip into Fedora.

My final thoughts on all of this: I spent six grand on this MBP. It’s my MBP, and as far as I’m concerned it will do what I want it to do, not what someone else feels it should be doing. Installing and running a kernel extension on macOS should not be a problem, and blocking it from installing is laziness on someone’s part who’ve decided perhaps it’s too much trouble to make sure that capability continues to work from release to release. I’m sure that trying to get a kernel extension running on top of Apple Silicon probably doesn’t work at all, which is why I’m not rushing out to get a new machine using it. I’m not interested in finding out that I can no longer dive into the internals and do what I want it to do.

I downloaded the latest desktop release of Fedora from https://getfedora.org/en/workstation/download/ the other night and installed it in a VirtualBox VM. It installed without any hassles whatsoever, almost as if it was based on Ubuntu.

When it booted into the desktop the first time after installation I was able to pretty much get right to work, checking out its various features and capabilities. Out-of-the-box so to speak it was able to mount the shared macOS folder defined in its VirtualBox VM definition. When I added my Fedora account to the vboxsf group, I was able to see all the files in the shared folder. This was achieved without having to install the VirtualBox guest additions. It looks like the kernel work with VirtualBox shared folders really works, which is amazing after all this time.

The only reason I might want to install the VirtualBox guest additions is to gain the ability to have the Fedora desktop resize when I resize the VM window. Right now it won’t do that. I have it configured for 1680 x 1050 scaled to 150% (this is a MacBook Pro with a 15″ Retina Display). The Fedora desktop fits the MacBook screen quite well, and the mouse cursor moves seamless between the MacBook desktop and the Fedora stock Gnome desktop. I can’t think of a really good reason to install the guest additions so I’ll just leave it as is for the time being.

The Fedora desktop is also running with the Wayland manager/compositor, and I discovered it runs much smoother than either other desktop manager (classic Gnome and Gnome with X.org).

I’m also quite pleasantly surprised by the version of the tools that comes with this distribution. GCC/G++ are both at version 10, as is Clang/LLVM. Python and Git are also right at the top, release-wise. I managed to install Visual Studio Code right from the Fedora repositories without having to add any other repos to def. That also included htop. I have yet to not be able to install anything I might need. I even went looking to see what versions of Java I might be able to install, and I found Java 8, 11, and 14. All of these are OpenJDK, not Oracle, which makes me quite happy. I’ve not installed them yet, but I know I can if I need them.

All joking aside this looks to be one of the best Fedora releases I’ve touched in years. I haven’t been this satisfied with Fedora since 2013, when I installed Fedora versions 16, 17, and 18 starting late 2011 on a bog standard Dell laptop where I was working at the time. When I took a look at Fedora again, it was 2014, and it was an attempt to install on a VirtualBox VM. From that point things were touchy and I just stayed with Ubuntu. But now I have to admit its pretty (shockingly) good. This particular Fedora VM is a keeper — so far.

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.

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.

Oracle released VirtualBox 5.1 last week, and today I downloaded the latest bits and updated my VB installation on my MBP. Right now the MBP is running with OS X Version 10.11.5 (I’ve resisted the urge to install the Sierra beta). I also updated the extensions package as well as the guest additions ISO.

Once VB 5.1 installed, I updated all my existing VM’s guest additions without incident. So far I have Mint 18 (seen above), Fedora 24, CentOS 6, Ubuntu 16.04, and Kali. Kali doesn’t have the guest additions as I want as pristine an environment as possible with those tools.

But this version of VB isn’t without problems.

1. I can’t seen to install the guest additions in CentOS 7 (based on RHEL 7). I don’t know why but the tools can’t find the kernel headers, even though I installed the full gcc and kernel-devel packages. I suppose I could have dug around and found out why it can’t find the kernel headers, but I have four other working Linux distributions with additions, and I just didn’t feel like putting in the effort. Lazy, I guess.
2. I tried to install PC-BSD. Initial live media boot and installation went swimmingly. Trying to run after the install (with the MATE, the KDE, desktops) resulted in a panic. After two attempts I gave up. If I need a BSD-like OS I have Mac OS X. And if I want Unix-like, well, I have all these systems around the house, including Arch running on three Raspberry Pi 3s. I have no shortage of OS playgrounds.

Other Software

I decided to try out Microsoft’s Visual Studio Code editor in the Mint VM. I’ve played with it a bit on Windows 10, Ubuntu 16, and my MBP, all directly on hardware and all without incident. But trying to install and run it on my Mint 18 VM didn’t work out so well.

I would have loved to have worked with the editor in the Mint 18 VM, but it looks like it’s not to be. I don’t know why the editor has a corrupted interface, but it’s totally unusable in this particular setting. I still have vi and gedit as a consolation.

Upshot

One of the big claims with VM 5.1 is performance improvements. I use it now on my Windows 10 notebook in place of VMware, and on my MBP, and I’ve never thought it was slow. VMs seem to boot rather quickly, and the VMs operate efficiently once up and running. I’m quite happy with the way everything works.

After what I wrote about abandoning Oracle’s Java, and why, you might think my use of VB is a bit hypocritical, and you’d be right; it is. Unfortunately, I’ve found nothing that works as well, especially VMware. And I need a virtualization tool that works on my multiple notebooks, with as many different Linux distributions, as possible. VMware keeps getting worse and worse in that regard. I certainly don’t mind paying for a good software package, and I almost broke down and bought a commercial copy of VMware, but the free player has been so plagued with issues that it’s turned me off buying a license (or licenses, one for Mac and one for Windows). I’ve better things to do with my time than trying to get everything initially working.

I would have liked for PC-BSD to have worked (finally). But it didn’t and I refuse to go forum diving for old and/or cryptic information. Considering the definition of insanity, some might consider my continued attempts at getting FreeBSD/PC-BSD up and running in a VM (which I will do before committing hardware). Fortunately, I wasted no more than about 15 minutes before calling off the latest PC-BSD installation experiment.

I’ve installed a VM of Linux Mint 18 on my MBP using VirtualBox 5.0.24 on Mac OS X 10.11.5. No muss, no fuss. It just installed. I did it primarily just to see what would happen.

Some points of interest about the setup.

• Linux Mint 18 came with the VirtualBox Guest Additions pre-installed. That shared folder showed up after installation and first boot. I added the local login to the vboxsf group in order to see the contents of the folder.
• Linux Mint runs quite well. It should, being based on Ubuntu 16.04 LTS.
• VirtualBox 5.0.24 is an excellent VM for various contemporary Linux distributions. I don’t run any other operating systems with it, so I can’t speak to them.

I like the dark theme of this version quite a bit. I’m also avoiding installing Java on this VM, choosing instead to install Google’s Go Language. My other language of choice on this VM is C++. I’m going back through my other VMs and removing Java and Java tools (particularly IDEs). I’ve got VIM and gedit for the work I need. And other tools to make sure my code is as robust as possible.

This is probably one of the lamest posts I’ve ever written. I leave it here as example of how far into the weeds I tend to get. If you want to use macOS (as it’s now known) to support Raspberry Pi development, and in particular to program Linux images onto micro SDHC cards, then download balena Etcher from https://www.balena.io/etcher/ and install it. Etcher is extremely easy to use, walking you through the three steps necessary to create a bootable image on a card. Don’t do what I did below; that’s just an absolute waste of time.

Original Post

You’re viewing CentOS 7 running in VirtualBox 5.0.16, with a micro SDHC card mounted and in turn viewing the Arch Linux ARM ext4 native Linux filesystem I created for my RP3. When I originally created the RP3 micro SDHC card I used my Ubuntu 15.10 notebook as the workbench. But I’ve been wanting to do similar work using my MBP as the primary tool bench, with an eye towards retiring the native Ubuntu notebook with the MBP due to the Ubuntu notebook’s age, rather than attempting to replace the Ubuntu notebook as I’ve written I originally wanted to do. The biggest hurdle to using the MBP was just reading the native ext4 file system on the MBP, as Max OS X has no native provisions to read Linux file systems. This post is about getting to that point. As time goes along I’ll be doing more than just reading the microSDHC, but reading (and then writing) is the foundational requirement, else this is all a waste of time and resources.

Before I go much farther let me properly attribute this from another post, “Mount SD card in VirtualBox from Mac OS X Host,” written by Brady Holt on 21 July 2014. Please note this was done nearly two years ago. This is an update to his post using contemporary software and with my observations.

Software and hardware I’ll be using:

• OS X El Capitan, version 10.11.3 running on a MacBook Pro (Retina, 15-inch, Mid 2015)
• VirtualBox 5.0.16 with Oracle_VM_VirtualBox_Extension_Pack-5.0.16
• CentOS 7 with all updates as of the date of this post with VBoxGuestAdditions_5.0.16 running as a VM

I’m going to create a Linux VM with VirtualBox and use that to mount and at least read the micro SDHC card with the Arch Linux ARM ext4 file system. I had originally looked for a Mac OS X utility to do this, but eventually gave up as the utilities that claimed they could do that had allegedly stopped working with the release of El Capitan because of System Integrity Protection, or rootless, mode. Far be it from me to disable in El Capitan what is supposed to add additional security to OS X. I’m somewhat surprised that I could get this to work, but I suppose that if, at some point in the future, Apple releases a Mac OS X update that breaks what I’ve built here that I’ll be back to using a separate Linux machine.

The first step is to install VirtualBox and then to install CentOS 7 within a VirtualBox VM. I won’t cover that here, as there are plenty of existing how-tos for that. Just make sure that the Virtual Box Extension Pack is installed and that you’ve downloaded and installed the VBoxGuesAdditions and have built it within the VM. That gets everything prepared both on the OS X host side as well as within the VM.

The next step is to get the overall system prepared to mount the RP3 micro SDHC card within the CentOS 7 VM.

1. Plug in the microSDHC card into the MBP using the microSDHC adapter. I’m using a Samsung 32GB Evo Plus device. Note that it’s named “NO NAME” on the desktop. This is the MSDOS 100MB boot partition on the microSDHC card.
2. Go to Launchpad and search for diskutil. Launch diskutil. Select “NO NAME.”

3. Click the Info button at the top right. Note the device associated with “NO NAME.” It’s the third line down from the top, called “BSD device node.” In my case it’s disk2s1. The device associated with this partition is /dev/disk2. We’ll use this later.

4. At the top of the utility click the ‘Unmount’ button with your mouse. The button text will then change to ‘Mount.’ Please note you don’t want to eject the device, just unmount.

5. Now we need to create a VirtualBox VMDK file to point to this device. That’s how we’ll get it to mount inside the Linux VM. Open a terminal and type sudo VBoxManage internalcommands createrawvmdk -filename sd-card.vmdk -rawdisk /dev/disk2 at the prompt. The file will be created where ever you run it, so my advice is to change directory to a location where you want this (or preface the file name with a full path) to create the file. Just remember where you left it.
6. Change permissions on the microSDHC device and the VMDK file to 777. At the prompt type chmod 777 sd-card.vmdk /dev/disk2. This opens up permissions for the file and card to be used later by the VM
7. Add sd-card.vmdk to the VM’s storage devices. In VirtualBox, under the CentOS VM, select the Storage dialog, and in the Storage Tree under Controller: SATA click the add device button. You will be prompted to either create a new device or add an existing device. Choose to add existing and add sd-card.vmdk.
8. Check diskutil one more time and make sure that the microSDHC card is still unmounted. OS X has automount and can silently remount the drive. If it does then you will fail to start the Linux VM.
9. Once the VM is started bring up Nautilus and note two new ejectable entries for the card, a 103MB entry and a 32GB entry. Click on the 32GB volume. You’ll be prompted by Nautilus to enter root’s password for that VM to view that volume. Once that’s done Nautilus opens into the 32GB volume. You can drag and drop files into and out of the midroSDHC’s 32GB volume. I do this to add content as well as pull log files while developing.

One caveat. If you shut down the VM and then want to bring it back up, you’ll need to unmount the microSDHC card like before and execute chmod 777 /dev/disk# again, or the VM will fail to start due to lack of permissions on the raw device.

The screen capture above is from my still-somewhat-new MBP. In order to create the screen shot I moved the mouse away from the VM and chord pressed [Command][Shift][4] and then pressed the space bar to bring up the camera mouse pointer. I then moved the camera back over the VM and clicked the trackpad to take capture.

In this basic example I’ve configured CentOS 7.2 with VBoxGuestAdditions 5.0.12, which you can download here: http://download.virtualbox.org/virtualbox You can download the VirtualBox installation package for your OS as well as the extension pack and guest additions. Note that the guest additions is an ISO that needs to be mounted in the VM before it can be installed inside the VM. You’ll need to install the guest additions if you want seamless mouse movement and sharing of host OS (Mac OS X in this instance) folders for transfer of data between guest and host.

My only big complaint with VirtualBox is networking. If you install with just NAT then the VM can reach outside of the host OS to the outside world and download updates when needed. Unfortunately the VM is unreachable from Mac OS. Any other type of networking attempting to combine both outside connectivity as well as internal is problematic. In particular, if I want to do development requiring network connectivity between my Mac and the guest OS then I can set up networking to do that, but at that point the VM can’t reach the outside world. The only example of what I’m trying to do was a howto for Windows 10 and VirtualBox, but that doesn’t work on my Mac.

The screenshot above shows the shared folders on the host OS. Make sure that the Linux account you’ve created on the VM has vboxsf as one of its groups or you won’t have permissions to see into the shared folders.

When you’re done with the VM just shut it down. If you opt to save the machine state, when you come back up the next time the mouse cursor will disappear when it moves over the VM desktop. Since my MBP has a SSD it’s just as fast for me to restart the VM as it is to save the state and restore, so to keep things as uncomplicated as possible I just turn the VM off when I’m done with a session. That way, the next time it’s powered up I know what the overall state is.

Update 17 January

I wrote about CentOS 7 back in September 2014, back when it was first released. Note that this is well over a year ago. I’d installed it on my notebook for a short period to compare it with Ubuntu and I discovered that it wasn’t quite up to my liking back then. But time and updates march on, and circumstances most definitely change. The changes to CentOS/RHEL as well as changing needs and requirements make that older review a bit OBE (overcome by events). I’m still no fan of the desktop look-and-feel but it’s not a deal-breaking issue, no more than it was over a year ago.