Installing MPLAB X IDE 5.25 on 64-bit Ubuntu 19.04

Josip Medved Leave a comment

While I love seeing companies provide Linux version of their software, it still annoys me when they do it as lazily as possible. For example Microchip not only doesn’t provide repository for their software, making you download and install every version separately, but they also don’t provide up-to-date instructions. Their section describing Ubuntu 14.04 and above simply doesn’t work.

To install MPLAB X on newer Ubuntu one must first explicitly add architecture:

$ sudo dpkg --add-architecture i386
$ sudo apt-get update
$ sudo apt install libc6:i386 libx11-6:i386 libxext6:i386 libstdc++6:i386 libexpat1:i386

Only once those are up you can proceed installing MPLAB IDE X itself:

$ tar -xvf MPLABX-v*-linux-installer.tar
$ chmod +x /tmp/mplabx/MPLABX-v*-linux-installer.sh
$ sudo ./MPLABX-v*-linux-installer.sh

Of course, installing compiler follows (XC8 in this case):

$ chmod u+x xc8-v*-full-install-linux-installer.run
$ sudo ./xc8-v*-full-install-linux-installer.run

And now MPLAB X IDE is installed.

PS: I won’t even go into the need for 32-bit compatibility libraries in 2019…

ZFS Pool for Virtual Machines

Josip Medved Leave a comment

Running VirtualBox on ZFS pool intended for general use is not exactly the smoothest experience. Due to it’s disk access pattern, what works for all your data will not work for virtual machine disk access. Yes, you can play with record size and adding SLOG device but you can also go slightly different route. Add disk specifically for VirtualBox.

My testing has found that simple SSD with the following settings does wonders:

$ zpool create -o autoexpand=on -m /VirtualBox \
      -O compression=off -O recordsize=4K -O atime=off \
      -O utf8only=on -O normalization=formD -O casesensitivity=sensitive \
      VirtualBox /dev/diskid/DISK.eli

First of all, you don’t want compression. Not because data is not compressible but because compression can lead you to believe you have more space than you actually do. Even when you use fixed disk, you can run out of disk space just because some uncompressible data got written within VM. Due to copy-on-write architecture, you can still get into the trouble but exposure is greatly limited.

Ideally record size should match your expected load. In case of VirtualBox that’s 512 bytes. However, tracking 512 byte records takes so much metadata that 4K records are actually both more space efficient and perform better. Depending on your exact hardware you might find that going to 8K or even higher might hit the sweet spot. Testing is the only way to know for sure but 4K is a reasonable starting point.

All other options are just plumbing – of course you want UTF-8 and no access time tracking.

Now you can run VirtualBox without complicating your main data pool.

PS: This assumes that you have disks enumerated by diskid and fully encrypted.

PPS: I usually just spin up temporary virtual machines for testing and thus I don’t care much about them long term. If you plan to kick something up long-term, do consider mirrored ZFS.

Samba and Sync Writes

Josip Medved Leave a comment

Looking up information about ZFS SLOG, I always see the same advice: “SMB uses async writes and thus ZIL provices no benefits.” It’s sane advice as ZIL brings no benefit to asynchronous writes. Sane, but no longer true.

Samba 4.7.0 changed default value for strict sync parameter from no to yes. Practical consequence of this change is that ZIL SLOG will be useful even for CIFS shares and adding it will bring you some benefits.

Should you add ZIL SLOG is still question highly dependent on your actual clients and how your pool is structured. But answer is definitely not a straight “no.”

Farewell Mercurial

Josip Medved Leave a comment

My first love when it comes to distributed source control systems was Mercurial. It was powerful, simple, and it had excellent Windows client. Compared to Source Safe and CVS I was using before, it was a heaven.

While I first dabbled with local repositories, it wasn’t too long until I found BitBucket. As it was free for up to five users it seemed like a perfect home for many of my projects – both public and private. Yes, Git was getting popular at the same time but I preferred Mercurial. However, as more and more people started using Git, I switched.

Even when I switched to Git, I still continued keeping some projects on BitBucket – especially those where I collaborated with other users. It was simply much easier to get them used to TortoiseHg than to Git. For inexperienced user there was a real benefit in all restrictions Mercurial had by default.

Unfortunately, less than a year from now BitBucket will kill off Mercurial support.

I fully understand them. There was simply not enough Mercurial users out there to make it work. Even when I look at my own repositories, Mercurial is only a small fraction of my commits. However, I am still sad to see an old friend gone.

My guess I’ll convert most of my remaining repositories to Git. Considering how integrated Git got over the years with other tools, I am sure quite a few of shared repositories will go Git route too. For rest, I guess I’ll need to find another home.