For testing purposes, I recently installed Kubernetes on an Ubuntu Server VM, running on my XEN Server, through the use of the Microk8s package:

https://microk8s.io/

Installation was a breeze, and I quickly got Kubernetes up and running and was able to interact with it using microk8s.kubectl. Microk8s.kubectl is a version of kubectl having it’s own configuration pointing to the locally installed Kubernetes. This avoid conflicting with the standard kubectl which would have had its configuration overwritten by the microk8s package.

On my Windows developer PC, I wanted the ability to access the cluster using kubectl without having to run microk8s.kubectl through an SSH session.

To do this, one first have to find the kubectl config yaml file. This resides in the %userprofile%\.kube directory. If the file is not there, create it.

Configuration of the file to match that of microk8s.kubectl can be done copy paste the configuration of microk8s.kubectl and replace localhost with the external IP of the cluster. This can be done through SSH using the config view command.

$ microk8s.kubectl config view

apiVersion: v1
clusters:
- cluster:
    server: https://<externalip>:<externalport>
  name: microk8s-cluster
contexts:
- context:
    cluster: microk8s-cluster
    user: admin
  name: microk8s
current-context: microk8s
kind: Config
preferences: {}
users:
- name: admin
  user:
    password: <password>
    username: admin

Now, copy paste to the config file on Windows, and replace localhost with the external IP of the cluster.

In addition, if the SSL certificate is untrusted on the cluster (which it typically is), make sure to add insecure-skip-tls-verify: true under the cluster part.

The final config file should look like this:

apiVersion: v1
clusters:
- cluster:
    insecure-skip-tls-verify: true
    server: https://<externalip>:<externalport>
  name: microk8s-cluster
contexts:
- context:
    cluster: microk8s-cluster
    user: admin
  name: microk8s
current-context: microk8s
kind: Config
preferences: {}
users:
- name: admin
  user:
    password: <password>
    username: admin

If everything is well, executing kubectl get services on Windows should return at-least the Kubernetes service.

I have a Lenovo ThinkCentre M720q that I use for entertainment purposes mounted besides the flat-screen TV at home. This works wonders, except that I could not get the darn HDMI audio to work.

As workaround, I used a mini-jack cable to connect the PC and the TV. This is OK, but the noise from the mechanical fan is transmitted over the wire to the TV and thus amplifying the noise a bit.

Annoying to say the least!! especially considering the fact that the PC should indeed support Audio over Display-port / HDMI.

In the weekend, I decided that I would experiment in getting the audio to work. And I succeeded!

Firstly, I identified the embedded graphics adapter of the PC to be an Intel UHD Graphics 630. For an integrated graphics adapter, OK high end.

Next, I updated the driver of the graphics adapter from the standard driver delivered by Lenovo. Not directly possible it would seem since installing the official Intel driver was blocked by the installer with a message “Contact the PC manufacturer for support”.

I was not able to locate any newer driver on Lenovos website. Instead, I unpacked the Intel driver and forcefully updated the graphics driver using Windows Device Manager (and braced myself for a blue-screen of death). Steps:

• Enter Device Manager
• Find the Display adapter under Display Adaptors
• Right click and click Update Driver
• Then Click “Browse my computer for driver software”
• Then Click “Let me pick from a list…”
• Then Click “Have Disk” and find the folder where the Intel driver was unpacked.
• You should then be able to select the new driver.

If everything goes according to plan, the screen should flicker and Windows might restart. Then you should be able to select HDMI Audio out in the Task Bar under the Speaker icon (refereed to as ‘Select Playback Devices’).

I quickly learned that removing the HDMI while powering down the PC and re-powered it without HDMI being attached HDMI Audio would stop HDMI audio from working. I could no longer select the playback device under Select Playback Devices.

Getting HDMI Audio to work after this required that I downgraded the driver and upgrading the driver once again.

Such a hassle! But at-least I avoid the noisy fan in my speakers :-)

I recently acquired an Android tablet intended to be used for work related purposes. The tablet is connected to the Internet, but not the company wide Intranet, making it a bit hard to synchronize documents, etc.

A Company VPN is provided, running ontop Windows 2012. This VPN allowing Intranet access when connected. Only two protocols are supported by the setup: IKEv2 PEAP and SSTP.

Internet Key Exchange version 2.0 (IKEv2) is a protocol used to setup a secure connection between two entities using the Internet Protocol Security (IPSec) protocol suite. IPSec is on the Network layer, alongside IPv4 and IPv6.

Secure Socket Tunneling Protocol (SSTP) is also a protocol used to setup a secure connection between two entities. This protocol is an application level protocol, building ontop of SSL/TLS. Since the protocol builds on-top of TCP, it is more prone to performance problems due to the throttling nature of TCP, which is not the case with IPSec since the tunnel is maintained using Network level datagrams. SSTP is however a very ‘friendly’ protocol in the sense that it can punch through nearly all firewalls, due to it using a single TCP port: 443 which also the case for normal HTTPS.

While IKEv2 is natively supported by Android (at least on my Galaxy tablet), SSTP is not. Getting IKEv2 to work against the company VPN server has however shown to be near to impossible due to certificate issues with the current setup. What I can tell, the setup at the company uses self-signed certificates that do not 100% comply with IKEv2.

I tried SwanVPN, an app which implements IKEv2. Here I actually got through some of the certificate issues, by fiddling with the connection settings and adding the self signed certificate and self signed root certificate to my trusted certificates on Android. But, VPN could not be established due an error code of NO IDENTITY was thrown back in my face - this I never solved. The error is apparently related to a missing attribute in the certificate: Subject Alternative Names which I am to this day still a bit puzzled about…

Then I looked into using SSTP, which is also supported by our company VPN server. However, SSTP is not natively supported by Android nor by SwanVPN. Googling around, I found VPN Client Pro: https://play.google.com/store/apps/details?id=it.colucciweb.vpnclientpro

After installing this on my Android tablet, the configuration of the VPN was straight forward and more or less equivalent to setting up the VPN on Windows 10.

Best of all, this worked like a charm!!!

My most recent productivity application, Shortcutty, requires the ability to hook into Windows to capture keydown events. The purpose is to show (or hide) the application whenever the user pressed CTRL+~.

I easily got this to work using the Win32 API + PInvoke in my .NET application. But, on some applications such as my Visual Studio instance, the hook failed by unknown reasons.

After a bit of debugging and digging through online archives on the matter, I quickly realized that the issue was as simple as my application not having administrator rights. The latter is required if I want my application to interact with other applications having higher privileges.

Visual Studio, as it happens, was running with admin-rights - thus my application was unable to hook into it, obviously for security reasons. Generally: a non-administrator process cannot interact with a process having administrator rights. You cannot even drag and drop between applications.

.NET Core is yet another .NET framework implementation implementing .NET Standard 1 (production) and .NET Standard 2 (beta) while also extending the standard with .NET core specific API’s such as Console and Thread (which are not part of the .NET Standard).

The cool thing with .NET Core is that it is: 100% open-source, 100% cross-platform and very modular. This stands in contrast to .NET and Mono since these are very monolithic implementations and huge in size. The source is available under MIT on GitHub: https://github.com/dotnet/core

Since .NET Core is very crossplatform, one can write .NET applications for x86/ARM Windows and x86/ARM Linux - and since it is very modular, the framework does not occupy much space compared to the desktop implementations.

API’s are generally not available in the framework but needs to be downloaded from NuGet, e.g. EntityFramework, ASP.NET, and even some Reflection support are an “add-on”.

I measured the raw framework installation on my Win 10 x64 box to about 70MB, while the .NET 4.6 framework is roughly 2000MB in size, that is, 28 times larger! Deployment wise, .NET Core SDK supports deploying application + framework meaning that the target does not have to have the specific framework installed.

The SDK will automatically pull all the dependencies into the publish package, which includes all NuGet dlls + native assemblies where applicable (e.g. if using sqlite .NET core wrapper). One can also publish to a specific target, such as Linux-x86 or Linux-arm, which will produce a platform specific package with an elf executable that can be executed.

Referencing .NET assemblies which does not target .NET Standard or .NET Core is not possible in .NET Core 1.1 since the APIs are incompatible. .NET Core 2.0 will include a compatibility layer making it possible to reference assemblies targeting other frameworks - although this sounds awesome, I have not experimented with this feature yet.

.NET Core is without a doubt the future of .NET!

Microsoft introduced the Virtual Desktop concept with the introduction of Windows 10. This is similar/direct clone of how many Linux distributions support multiple desktops, allowing multiple desktop instances to house separate windows.

Simply put, this feature is awesome when working on multiple projects at once, since one can layout the windows in the order that make sense for one particular project without sacrificing the layout of another project on another desktop.

For work, I typically have a desktop for my Outlook + misc documents while a second desktop houses my Visual Studio + other dev related stuff. I typically have a third desktop for music playback / other media.

This setup is especially powerfull when working on server/client projects at the same time.

One desktop can hold the Server related development, while another desktop can hold the client related development. Switching between desktop is as easy as using WIN + CTRL + left/right arrow keys.

If something comes up, e.g. a support case during work, one can simply create a total new desktop to take care of this using WIN + CTRL + D. This allows one to easily resume work on an existing project when the case has been resolved.