A coworker asked recently about how people use VMs locally for dev work, so I figured I’d take a few minutes to write up a bit about what I do. There are many use cases for local virtual machines in software development and testing. They’re self-contained, meaning you can make a mess of them without impacting your day-to-day computing environment. They can run different distributions, kernels, and even entirely different operating systems from the one you use regularly.

Have you ever wondered what a security probe of a computer sounded like? I’d guess probably not, because on the face of it that doesn’t make a whole lot of sense. But there was a time when I could very clearly discern the sound of a computer being scanned. It sounded like a small mechanical heart beat: Click-click… click-click… click-click… Prior to 2010, I had a computer under my desk with what at the time were not unheard-of properties: Its storage was based on a stack of spinning metal platters (a now-antiquated device known as a “hard drive”), and it had a publicly routable IPv4 address with an unfiltered connection to the Internet.

The Woodland Park Zoo in Seattle has been putting on a winter light display for years. In the past it’s been known as Wild Lights, but this year they rebranded it as Wildlanterns and gave it a major refresh. If you’re near Seattle and able to check it out, I highly recommend going. I went the other night with my family and took a number of pictures, which you can see in the photo album.

In another of my frequent late-night bouts with insomnia, I started thinking about the intersection of a number of different issues facing Debian today, both from a user point of view and a developer point of view. Debian has a reputation for shipping “stale” software. Versions in the stable branch are often significantly behind the latest development upstream. Debian’s policy here has been that this is fine, our goal is to ship something stable, not something bleeding edge.

Am I missing something obvious? When did this get so hard? In the old days, you configured your desktop session on a Linux system by editing the .xsession file in your home directory. The display manager (login screen) would invoke the system-wide xsession script, which would either defer to your personal .xsession script or set up a standard desktop environment. You could put whatever you want in the .xsession script, and it would be executed.

Did you know that the cloud team generates daily images for buster, bullseye, and sid? They’re available for download from cdimage.debian.org and are published to Amazon EC2 and Microsoft Azure. This is done both to exercise our image generation infrastructure, and also to facilitate testing of the actual images and distribution in general. I’ve often found it convenient to have easy access to a clean, up-to-date, disposable virtual machine, and you might too.

When buster was first released back in early July of last year, the cloud team was in the process of setting up some new accounts with AWS to be used for AMI publication. For various reasons, the accounts we used for pre-buster releases were considered unsuitable for use long term, and the buster release was considered to be a good logical point to make the switch. Unfortunately, issues within the bureaucracy of both SPI/Debian and AWS delayed the complete switch to the new accounts.

I’m trying to use this to capture some of my thoughts on the current GR, and to document my approach to this vote. If nothing else, I hope to use this to convince myself that I’ve read and understood the various options in the GR. From my perspective, two of the choices on this ballot are easy to deal with, in that they have very clear meaning and the ramifications are easy to understand.

Further Discussion builds concensus within Debian! Further Discussion gets things done! Further Discussion welcomes diverse perspectives in Debian! We’ll grow the community with Further Discussion! Further Discussion has been with Debian from the very beginning! Don’t you think it’s time we gave Further Discussion its due, after all the things Further Discussion has accomplished for the project? Somewhat more seriously, have we really exhausted the community of people interested in serving as Debian Project Leader?

When reviewing pull requests on GitHub, it’s often useful to have local access to the changes under review. There are a few different documented ways to accomplish this, but none have left me entirely satisfied. So, I came up with something different. Maybe it’ll work for you. The existing methods are: You can add a new git remote referencing the source of the PR, then fetch it and check out the branch containing the proposed changes.