In my past few blog posts, I have been talking about the current state of affairs concerning ARM VPS hosting. To put my money where my mouth is, I have now migrated my blog to the ARM instances Oracle has to offer, as an actual production use of their cloud. You might find this surprising, given the last post, but Oracle reached out and explained why their system terminated my original account and we found a solution for that problem.

Update: Oracle have made this right, and I am in fact, now running production services on their cloud. Thanks to Ross and the other Oracle engineers who reached out offering assistance. The rest of the blog post is retained for historical purposes. In my previous blog, I said that Oracle was the best option for cheap ARM hosting.

ARM is everywhere these days – from phones to hyperscale server deployments. There is even an ARM workstation available that has decent specs at an acceptable price. Amazon and Oracle tout white paper after white paper about how their customers have switched to ARM, gotten performance wins and saved money. Sounds like everything is on the right track, yes?

A few years ago, I worked as the CTO of an advertising startup. At first, we used Skype for messaging amongst the employees, and then later, we switched to Slack. The main reason for switching to Slack was because they had an IRC gateway – you could connect to a Slack workspace with an IRC client, which allowed for the people who wanted to use IRC to do so, while providing a polished experience for those who were unfamiliar with IRC.

As usual, I have been hard at work on various security initiatives in Alpine the past month. Here is what I have been up to: Alpine 3.14 release and remediation efforts in general Alpine 3.14.0 was released on June 15, with the lowest unpatched vulnerability count of any release in the past several years.

From time to time, somebody reports a bug to some project about their program crashing on Alpine. Usually, one of two things happens: the developer doesn’t care and doesn’t fix the issue, because it works under GNU/Linux, or the developer fixes their program to behave correctly only for the Alpine case, and it remains silently broken on other platforms.

My first experience with IRC was in 1999. I was in middle school, and a friend of mine ordered a Slackware CD from Walnut Creek CDROM. This was Slackware 3.4, and contained the GNOME 1.x desktop environment on the disc, which came with the BitchX IRC client. At first, I didn’t really know what BitchX was, I just thought it was a cool program that displayed random ascii art, and then tried to connect to various servers.

Anybody who has the responsibility of maintaining a cluster of systems knows about the vulnerability remediation lifecycle: vulnerabilities are discovered, disclosed to vendors, mitigated by vendors and then consumers deploy the mitigations as they update their systems. In the proprietary software world, the deployment phase is colloquially known as Patch Tuesday, because many vendors release patches on the second and fourth Tuesday of each month.

A side effect of the whole freenode kerfluffle is that I’ve been looking at IRCD again. IRC, is of course a very weird and interesting place, and the smaller community of people who run IRCDs are largely weirder and even more interesting. However, in that community of IRCD administrators there happens to be a few incorrect systems programming opinions that have been cargo culted around for years.

A few weeks ago, I announced the creation of a security response team for Alpine, of which I am presently the chair. Since then, the team has been fully chartered by both the previous Alpine core team, and the new Alpine council, and we have gotten a few members on board working on security issues in Alpine.