There are times when an email based workflow gets really difficult. One of those times is when discussing projects related to spam and malware detection. noahm@debian.org host stravinsky.debian.org [2001:41b8:202:deb::311:108] SMTP error from remote mail server after end of data: 550-malware detected: Sanesecurity.Phishing.Fake.30934.1.UNOFFICIAL: 550 message rejected submit@bugs.debian.org host stravinsky.debian.org [2001:41b8:202:deb::311:108] SMTP error from remote mail server after end of data: 550-malware detected: Sanesecurity.Phishing.Fake.30934.1.UNOFFICIAL: 550 message rejected This was, in fact, a false positive.

When a Debian cloud VM boots, it typically runs cloud-init at various points in the boot process. Each invocation can perform certain operations based on the host’s static configuration passed by the user, typically either through a well known link-local network service or an attached iso9660 drive image. Some of the cloud-init steps execute before the network comes up, and others at a couple of different points after the network is up.

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.