Below are the five most recent posts in my weblog. You can also see a chronological list of all posts, dating back to 2003.
Now I'm back to Linux on the Desktop for my dayjob, I was slightly nervous about checking out the state of the art for Linux music players; an area I've never felt the Linux desktop was very strong on.
However for the time being I've largely side-stepped the issue by listening to BBC 6 Music for most of the day. For better or worse, I scrobble, and somebody has written a neat web app for scrobbling along to radio stations. When I want to listen to something different for a change, I've been trying out a trial of Google Play Music, for which somebody has written a Chrome extension to scrobble. On the rare occasions I listen to local music, I'm using VLC.
Google Play Music seems pretty good, but I'm not getting a lot from my trial because 6 Music is generally fantastic.
Scrobbling 6 Music has revealed a bit of a disconnect for how I use last.fm, and how website thinks you should use it. Within a day or two, my "music compability" with 6 Music was (predictably) "SUPER". Looking at my "Top artists", right near the top are 6 Music's current playlist favourites Courtney Barnett and Nadine Shah, who I can (at least) recall the songs that have been played; just below them are Young Fathers, who I cannot. A little lower are Hot Chip and Slaves: both artists who have current singles out which I enjoyed for a while, but the relentless BBC playlist policy is overdoing them and I'm inclined to switch over when they come on now. If I listen to a whole album in a given week, then the artist will likely (and rightly) be sat at the top of "last 7 days"; if I don't, then it could be something I can't even remember listening to.
It looks like his last novel will be The Long Utopia, the fourth book in the Long Earth series, co-written with Stephen Baxter.
Someone recently pointed out that an upload I had made is now inaccessible.
In it's place is a short message:
this item is unavailable due to issues
with its content. What issues are not made clear.
I've never been contacted by
archive.org about this, not even to be
admonished, should they have felt that to be necessary. I've tried contacting
them to find out what the issues are but have heard nothing back.
It's worth remembering: Just because it's available now, even on
doesn't mean it will be Tomorrow!
I've been playing around with Debian and Docker a little bit. I found Joey Hess' post about Docker trust interesting reading, in particular this advice:
I'd recommend only trusting docker images you build yourself. I have some docker images published somewhere that are built with 100% straight debootstrap with no modifications (...) But I'm not going to link to them, because again, you should only trust docker images you built yourself.
On that advice, I did exactly that. I've pushed the basic scripts I used to build my images to github:jmtd/debian-docker. Suggestions welcome!
However, I am planning to share the images I build, at least for my own convenience, on the Docker repository. I'm hoping to publish some PGP-signed sums somewhere so you could verify the binary images on the Docker registry if you so wish.
The three images I'm currently maintaining are:
jmtd/debian:buildd: a sid image, variant
buildd, to use as the base for package builds
jmtd/debian:wheezy: a minbase wheezy
jmtd/debian:wheezy-i386: a minbase wheezy, i386
(note: I haven't pushed them all yet.)
With docker 1.5.x at least, the i386 image works fine on amd64 hosts. I've used it as the basis for running wine and Windows binaries. I might push a wine image if I generalise it enough to be more useful.
The Docker folks recommend using Debian as a base image because it's a small size (approx. 163M for my base image, 85.01M for the semi-official one: See Joey's blog for some of the differences) but with a good set of tools. I wondered whether I could leverage the efforts of the Emdebian project to get an even smaller base image.
Unfortunately, the Emdebian project discontinued their 'Grip' project midway through last year. A basic Emdebian grip install is a fair bit smaller than the equivalent wheezy image, but once you've applied security updates most of the difference is lost. I suspect that some of Emdebian's minimisation techniques would be useful and applicable for shrinking Docker base images.
A few months ago I decided it would be good to re-rip my CD collection, retaining a lossless digital copy, and set about planning the project. I then realised I hadn't the time to take the project on for the time being and parked it, but not before figuring a few bits and pieces out.
Starting at the beginning, with ripping the CDs. The most widely used CD ripping software on Linux systems is still cdparanoia, which is pretty good, but it's still possible to get bad CD rips, and I've had several in a very small sample size. On Windows systems, the recommended ripper is Exact Audio Copy, or EAC for short. EAC calculates checksums of ripped CDs or tracks and compares them against an online database of rips called AccurateRip. It also calibrates your CD drive against the same database and uses the calculated offset during the rip.
I wasn't aware of any AccurateRip-supporting rippers until recently when Mark Brown introduced me to morituri. I've done some tentative experiments and it appears to be produce identical rips to EAC for some sample CDs (with different CD reading hardware too).
Fundamentally, AccurateRip is a proprietary database, and so I think the longer term goal in the F/OSS community should be to create an alternative, open database of rip checksums and drive offsets. The audio community has already been burned by the CDDB database going proprietary, but at least we now have the—far superior—MusicBrainz.
Older posts are available on the all posts page.