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.

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.

Lwn, Slashdot, and many others have marked the recent announcement of Linux Journal’s demise. I’ll take this opportunity to share some of my thoughts, and to thank the publication and its many contributors for their work over the years. I think it’s probably hard for younger people to imagine what the Linux world was like 20 years ago. Today, it’s really not an exaggeration to say that the Internet as we know it wouldn’t exist at all without Linux.

Following up on a previous post announcing the availability of a first round of AWS AMIs for stretch, I’m happy to announce the availability of a second round of images. These images address all the feedback we’ve received about the first round. The notable changes include: Don’t install a local MTA. Don’t install busybox. Ensure that /etc/machine-id is recreated at launch. Fix the security.debian.org sources.list entry. Enable Enhanced Networking and ENA support.

At this past November’s Debian cloud sprint, we classified our image users into three broad buckets in order to help guide our discussions and ensure that we were covering the common use cases. Our users fit generally into one of the following groups: People who directly launch our image and treat it like a classic VPS. These users most likely will be logging into their instances via ssh and configuring it interactively, though they may also install and use a configuration management system at some point.

Following up on Steve McIntyre’s writeup of the Debian Cloud Sprint that took place in Seattle this past November, I’m pleased to announce the availability of preliminary Debian stretch AMIs for Amazon EC2. Pre-generated images are available in all public AWS regions, or you can use FAI with the fai-cloud-images configuration tree to generate your own images. The pre-generated AMIs were created on 25 January, shortly after Linux 4.9 entered stretch, and their details follow:

Join Microsoft to celebrate Debian 8 at LinuxFest Northwest

I’ve run OpenWRT on my home router for a long time, and these days I maintain a couple of packages for the project. In order to make most efficient use of the hardware resources on my router, I run a custom build of the OpenWRT firmware with some default features removed and others added. For example, I install bind and ipsec-tools, while I disable the web UI in order to save space.

If you’re running Spamassassin on Debian or Ubuntu, have you enabled automatic rule updates? If not, why not? If possible, you should enable this feature. It should be as simple as setting "CRON=1" in /etc/default/spamassassin. If you choose not to enable this feature, I’d really like to hear why. In particular, I’m thinking about changing the default behavior of the Spamassassin packages such that automatic rule updates are enabled, and I’d like to know if (and why) anybody opposes this.

Today is the first time I’ve taken an interstate train trip in something like 15 years. A few things about the trip were pleasantly surprising. Most of these will come as no surprise: Less time wasted in security theater at the station prior to departure. On-time departure More comfortable seats than a plane or bus. Quiet. Permissive free wifi Wifi was the biggest surprise. Not that it existed, since we’re living in the future and wifi is expected everywhere.

I’ve aborted several attempts recently to get something of interest posted. For whatever reason, none of that stuck. So here’s something with fewer expectation attached to it: A collection of random updates. Debian packaging Spamassassin The Spamassassin project released version 3.4.0, a major update over the 3.3.2 branch, after nearly two-and-a-half years in development. 3.4.0-1 is currently in unstable and testing, and seems to be working reasonably well for me.

“Netiquette” is an ancient term, dating back to the earliest days on the internet. These days, one might argue that it’s no longer relevant, or that there are so many different definitions that it’s been rendered meaningless. However, one particular aspect of it endures: “Don’t feed the trolls!” A recent thread on the debian-security mailing list provided an amazingly effective demonstration of the effectiveness of this approach. A certain pseudonymous individual made multiple posts in this thread that exhibited classic troll behavior (no meaningful contribution to the discussion, inflamatory comments, etc).

It’s been a little too long since I kept the Debian Choqok packages as up to date as I’d like. This has lead to some issues, since bug #591100 really should have been fixed in time for squeeze. Then, when upstream stopped pushing their svn changes to gitorious and moved their actual development to kde.org’s local git hosting, all my branches got screwed up, leading to further delays. I think this is fully resolved at this point.