Snap

Yesterday while surfing the ASCII highways of IRC (yes, IRC) a URL linking to a MacOS application scrolled by my screen. Unclack is a small MacOS utility which silences the microphone of the user when they’re typing. The purpose is to prevent the noise of typing being passed through to other participants when on a Zoom / Skype / Jitsi call. Neat.

They don’t make a Linux version, and I couldn’t see anything similar, so I did what I usually do in this instance, throw the idea towards my friendly local coder, Stuart Langridge. He was, as ever, initially bemused and then dismissive.

As you may or may not be aware, I work for Canonical on Snapcraft and Ubuntu. I use Ubuntu as my daily driver, and spend a lot of time maintaining snap packages, and listening to developers and users talk about software packaging, publishing, delivery and use.

Over time I’ve collected a bunch of virtual notes in my head. Much of it has been turned into documentation, but often the information is rather spread out. I wanted to “brain dump” a bunch of notes, for common things people ask me about snap, snapd and snapcraft. Here’s the first set, about snap / snapd. A later post will focus on snapcraft.

I recently ordered a Raspberry Pi 400, I couldn’t resist. I’ve bought a few Raspberry Pi’s over the years, with a couple installed around the house. The Pi 400 struck me as quite the game-changer though, with a built in keyboard-enclosure and accessible connectors. The fact it reminded me of my youth with memories of the Sinclair Spectrum where everything is housed inside the keyboard helped a bit.

One omission which struck me as odd was the lack of audio jack. I’m sure there’s sensible cost or logical, technical reasons for it, but it’s a bit of a pain for me. Neither of the displays my Pi 400 is connected to have any kind of speaker or audio jacks. I don’t often need the audio output, but sometimes I’m testing applications which require an audio device.

It’s now super easy to build Linux software packages on your Windows laptop. No VM required, no need for remote Linux hosts.

I spend a lot of my day talking to developers about their Linux software packaging woes. Many of them are using Linux desktops as their primary development platform. Some aren’t, and that’s their (or their employers) choice. For those developers who run Windows and want to target Linux for their applications, things just got a bit easier.

OpenSpades is a super-fun “Open-Source Voxel First Person Shooter”. I’ve been playing it for a while both on my GameOS desktop and under WINE on Linux. For whatever reason the upstream OpenSpades on github project had no Linux builds available for download, and I was lazy so I used WINE, which worked just fine.

This weekend though I decided to fix that. So I made a snap of it and pushed it to the store. If you’re on a Linux distro which supports snaps you can install it with one command:-

Continuing Snapcraft Docs Days

In March we had our first Snapcraft Docs Day on the last Friday of the month. It was fun and successful so we’re doing it again this Friday, 28th April 2017. Join us in #snapcraft on Rocket Chat and on the snapcraft forums

Flavour of the month

This month’s theme is ‘Flavours’, specifically Ubuntu Flavours. We’ve worked hard to make the experience of using snapcraft to build snaps as easy as possible. Part of that work was to ensure it works as expected on all supported Ubuntu flavours. Many of us run stock Ubuntu and despite our best efforts, may not have caught certain edge cases only apparent on flavours.

Announcing Snapcraft Docs Day

Snap is a simple archive format for big things.

Snapcraft is a delightful tool for automatically building and publishing software for any Linux system or device. Our documentation and tutorials are great for getting started with snapcraft. We can always improve these though, so this Friday, will be our first Snapcraft Docs Day.

• When: Friday, 31st March 2017, all day
• Where: #snapcraft on Rocket Chat
• Who: Developers & documentation experts of all levels

Why we’re doing this

The goal is to ensure our documentation and tutorials are useful and accurate. We’re keen to get people testing our documentation, to make sure it’s clear, understandable and comprehensive. If we’re missing anything, or there are mistakes then file those issues, or better yet, fix them yourself.