I gave a presentation today on the methods and reasons of blogging for Delphix Engineering.
One of my points was that presentations make for simple blog posts–practice what you preach!
While doing this work, I noticed a very surprising thing. When a host has both IPv6 and IPv4 addresses associated with a name (such as localhost), Go prefers to resolve to the IPv4 version of the name, unless one has asked specifically for v6 names.
Those of you who follow me may have heard about this project I've created called mangos.
There is a very nice write up of mangos by Tyler Treat, which might help explain some things.
This is a follow on from last last blog entry "Oracle Solaris 11 Derived Manifest with Automated Installation", where I mentioned that I could not examine the disk partitions of the new system since the aiuser does not have permission to run fdisk.
Recently, Randy Bias of EMC (formerly of CloudScaling) wrote an excellent piece on Why “Vanilla OpenStack” doesn’t exist and never will. If you haven’t read it and you are anywhere near a private cloud effort, you should consider it a must-read: Randy debunks the myth of a vanilla OpenStack in great detail. And it apparently does need debunking; as Randy outlines, those who are deploying an on-premises cloud expect:
I’ve been working out a minor idea involving the control of some household actions based on local time, but relative to sunrise and sunset rather than a naive time of day. Simon Kennedy’s Astral is a Python module that can compute these times, but its examples focus on retrieval of locations from major cities. Most places aren’t major cities in the module’s list, so I spent a little time to read the source to determine what other entry points were enabled.
Fifteen years ago, I initiated a time-honored tradition among my colleagues in kernel development at Sun: shortly after the first of every year, we would get together at our favorite local restaurant to form predictions for the coming year. We made one-year, three-year and six-year predictions for both our technologies and more broadly for the industry.
When looking back on 2014 from an infrastructure perspective, it’s hard not to have one word on the lips: Docker.
We built DTrace to solve problems; at the start, the problems we understood best were our own. In the Solaris Kernel Group we started by instrumenting the kernel and system calls, the user/kernel boundary. Early use required detailed knowledge of kernel internals. As DTrace use grew—within the team, in Sun and then beyond—we extended DTrace to turn every function and every instruction in user programs into probes. We added stable points of instrumentation both in the kernel and in user-land so that no deep knowledge of program or kernel internals would be required.