Problem Statement:

Create an openSUSE Leap 42.3 VM on GCP:

1. Login to your GCP console and your project (default or otherwise).
2. From Menu (top-left),  Compute Engine -> VM instances
3. Note that openSUSE is not listed as an Operating System image when you try to create a new VM.  This is well documented at the Images section of the Compute Engine topic.
   
4. Launch the Cloud Shell within the console, on the top-right.
   
5. Find the available community supported openSUSE Leap image with the following command input to the Cloud Shell. 
• gcloud compute images list --project opensuse-cloud --no-standard-images 
6. Create a VM with the openSUSE Leap 42.3 image in the Singapore datacenter (or any Zones that is closest to you)


•  gcloud compute instances create osleap423 --image-family opensuse-leap --image-project opensuse-cloud --zone asia-southeast1-a
• For Reference, the available parameters for gcloud compute instances create at this link - https://cloud.google.com/sdk/gcloud/reference/compute/instances/create
• Verify that the VM has been created in the console 
  
7. SSH into your newly created openSUSE Leap 42.3 VM to download and apply the latest updates/patches.  Click the SSH button (see screenshot above).
• Once you SSH into your VM,  zypper up.
  
  
8. Reboot the VM to test all updates are working.
• Reboot:  sudo reboot.  You will lose SSH connection, naturally.
• Sign back in via SSH button... it may take a few tries as the VM is rebooting.
• Sign out of SSH:  exit
9. Shutdown the VM.  Select the VM (checkbox) from the Console and Click STOP.

Create a custom image in your GCP Project for Re-use later:

1. From the GCP console, navigate to Compute Engine -> Images
2. Click [+] CREATE IMAGE 
   
3. Put in the name of your new image (eg. my-opensuse-leap-423) and select Source as Disk and Source disk as the boot disk from the right VM (eg. osleap423).
   
• (Optional) You can click the command line link at the bottom to note the equivalent Cloud Shell command.  This is useful if you want to script actions for future re-use and not use the web-console.
4. Once your custom image is created, you will be able to select it for the next VM you wish to create.

Here’s something I didn’t know: The DEC VT100 turns 40 in August. This factlet comes courtesy of Wikipedia, as I’m not quite old and wise enough to have made its acquaintance outside of a museum. None the less, the VT100 and its extended family of hard-working office furniture has always been with me in terms of the ECMA-48 standard, better known as ANSI X3.64 or simply (and these days, probably as accurately as any formal descriptor) “ANSI codes“, which it helped pioneer.

This pinnacle of 1970s UX is somehow still going strong, and recent developments like lots and lots of colors, ubiquitous Unicode support, good monospace fonts, etc. have opened up some interesting possibilities for creative abuse in a rich tradition that dates all the way back to manual typewriters, if not further. Previous entrants in this category are the venerable aalib and libcaca, and more recently there’s timg and others that use the U+2580 half-block symbol.

I wrote a small tool to further improve on this. It combines a range of Unicode symbols in an attempt to minimize the squared error of the output, and has plenty of bells and whistles besides. Check it out.

After all the fun we had in part 1 of our FreeIPA + DNS series, we now come to a new chapter.

During the move of openSUSE to Let’s Encrypt we used the excellent tool from ssllabs to verify each server after we changed the certificate. One of our coworkers noted “Hey, why don’t you have a CAA record. It would give you an even better score”. CAA records allow the domain owner to specify which certificate authorities are allowed to create certificates for this domain. Which seems to be a nice benefit for little work. For a longer explanation see this blog post from Qualys.

The last code I wrote during the hackfest was the start of code generation for GObject interfaces. This is so that you can do

gobject_gen! {
    interface Foo {
        virtual fn frob(&self);
    }
}

and it will generate the appropriate FooIface like one would expect with the C versions of interfaces.

It turns out that this can share a lot of code from the existing code generator for classes: both classes and interfaces are "just virtual method tables", plus signals and properties, and classes can actually have per-instance fields and such. I started refactoring the code generator to allow this.

I also took a second look at how to present good error messages when the syn crate encounters a parse error. I need to sit down at home and experiment with this carefully.

Back home

I'm back home now, jetlagged but very happy that gnome-class is in a much more advanced a state than it was before the hackfest. I'm very thankful that practically everyone worked on it!

Also, thanks to Alberto and Natalia for hosting me at their apartment and showing me around Madrid, all while wrangling their adorable baby Mario. We had a lovely time on Saturday, and ate excellent food downtown.