Wednesday, July 20, 2011

ONOTE and OTONE - A musical project

I'm starting a new musical project, which I'm calling OTONE and/or ONOTE.  Actually, I've been working on this project for several years without realizing what I wanted to do with it.  It coalesced in my mind when I thought of the acronyms above.  Here's what they stand for:

  1. The One Tune One Night Experiment (OTONE)
  2. The One Night One Tune Experiment (ONOTE)
I'm not yet sure what the difference between the two are yet (though see below), but here's the idea behind the project.

If you're like me, you can easily sweat over a song and its recording for ever, tweaking the mix, or hearing another melody, or (worst of all) agonizing over every word of a lyric that was like pulling teeth in the first place.  Sometimes you think if you just do one more take of the guitar, you can get it perfect, or oh! it just needs a little bit of tamborine right there.  Sometimes the arrangement just doesn't sit quite right, or you know in your gut that lurking out there somewhere there's a better way to get from the bridge to the last chorus.

Well, I'm kind of frustrated with that because it can lead to never actually finishing a song and getting it out there for folks to hear.  At some point you reach diminishing returns, where the little tweaks don't really improve the song enough.  Probably most importantly, the whole thing can put the brakes on the creative process.  I liken it to software maintenance vs. creating a new project from scratch.

Software maintenance is important, useful, and can be fun, but the juices really get flowing when you're starting a new project.  You get this rush of an idea and your fingers can't type fast enough to translate them into code.  It's this latter feeling that I want to better capture with music.

A brilliant friend and awesome drummer once said, "you have to get the crappy songs out in order to get to the good ones."  A similar thought is "let 1000 flowers bloom."  The more you write the easier it gets, and the more likely that out will come some cool songs.  Thus OTONE/ONOTE.

The idea is to produce one song in one evening, and not sweat the details (too much).  I have a small backlog of tunes that I've written using this approach (without realizing it) and plan on posting them to my website and social media over the next few weeks.  Going forward, I'm going to set aside one night a week or fortnight, and see what happens.  I'll post those too.  I'll very likely put them under a non-commercial Creative Commons license, but I haven't yet decided whether to allow derivative works or not (I'm leaning toward "yes").

I encourage my other artistic friends to take a similar approach with their music, writing, art, etc.  Feel free to use the #onote or #otone tags, but if you could link back to this article as your original impetus, I'd really appreciate it.

I should mention that some of the songs were not written in one night, but all were produced in one night.  I'm trying to keep it under check, but sometimes I just can't help but twiddle the chorus now and then. :)  Maybe that's the distinction though.  OTONE can mean a song I wrote in one night, while ONOTE can be one evening devoted to producing just one song.

A couple of other things to keep in mind:

  • The songs will be rough.  The whole point is not to cut and paste that one early bass note into the right place because that just slows you down.  Unless it doesn't and you can still finish in one night. :)
  • Part of the reason for doing this is to better learn other software.  I'm fairly proficient at Cubase 4 (but despise the dongle), and GarageBand is easy to get started (but much more difficult to do advanced stuff like arrange), Logic 9 is cool but I don't know it that well, and there are lots of free and alternative DAWs to experiment with.  Doing quick one-night projects gives me some time to explore these.
  • Give me feedback and maybe I'll flesh out the good ones.  There's no rule against coming back around to the ones you like and obsessing over the details later.
  • Remember: just because the sun's come up doesn't mean the night's over.

Now, go out and create!

Wednesday, July 13, 2011

Ignore at your own peril

On Monday, I lost my home directory on my primary development machine.  I'd had this machine for a couple of years but it was still beefy enough to be an excellent development box.  I've upgraded it several times with each new Ubuntu release, and it was running Natty.  I had decent sbuild and pbuilder environments, and a bunch of virtual machines for many different flavors of OS.

I'd also encrypted my home directory when I did the initial install.  Under Ubuntu, this creates an ecryptfs and does some mount magic after you successfully log in.  It's as close to FileVault as you can get on Ubuntu, and I think it does a pretty good job without incurring much noticeable overhead.  Plus, with today's Ubuntu desktop installers, enabling an encrypted home directory is just a trivial checkbox away.

To protect your home directory, ecryptfs creates a random hex passphrase that is used to decrypt the contents of your home directory.  To protect this passphrase, it encrypts it with your login password.  ecryptfs stores this "wrapped" passphrase on disk in the ~/.ecryptfs/wrapped-passphrase file.

When you log in, ecryptfs uses your login password to decrypt wrapped-passphrase, and then uses the crazy long hex number inside it to decrypt your real home directory.  Usually, this works seamlessly and you never really see the guts of what's going on.  The problem of course is that if you ever lose your wrapped-passphrase file, you're screwed because without that long hex number, your home directory cannot be decrypted.  Yay for security, boo for robustness!

When you do your initial installation and choose to encrypt your home directory, you will be prompted to write down the long hex number, i.e. your unwrapped passphrase.  Here's the moral of the story.  1) You should do this; 2) You should remember where you put that magic piece of paper!

I did #1 but failed to do #2.

I'm not exactly sure how my ~/.ecryptfs directory got corrupted, but somehow the wrapped-passphrase file got deleted.  I'm fairly certain that I didn't do it accidentally, but you never know.  I suspect that there was some bad interaction with sbuild because the only thing I'd done right before the corruption, was to update my sbuild environment, and build a package in it.  Note that if you follow the Ubuntu Security Team's instructions for setting up your sbuild (which I highly recommend), your unencrypted home directory will be exposed to sbuild's chroots.  This is very convenient for normal work-a-day package building.  However, it's possible that some bug in sbuild caused my ~/.ecryptfs directory to get corrupted.  That's only a wild guess though; I'm now rebuilding my dev box on a fresh 1.5T drive starting with Oneiric alpha 2, so we'll see if this bug bites me again.

This time, I'm prepared.  I stumbled upon a clever and secure way to never lose that piece of paper again.  This technique should also allow you to store and share other securely encrypted data across any of your Ubuntu machines.

The first step is to set up Ubuntu One.  You get 2GB of data free, so why not use it!?  I have U1 set up on all my Ubuntu desktops, and it's a great place to stash things you might need everywhere.  I've been considering storing things like my Firefox, Chromium, and Claws-Mail configs in U1 because I always want to keep them in sync.  I already store my Timelog Tracker data there, so I can enter my time and accomplishments from any desktop.

(I generally do not keep most of my configuration files in U1 since I keep them under Bazaar.)

Now, it would be a very simple matter of just creating a subdirectory under ~/Ubuntu One for each machine that has an encrypted home directory, and then just copy the contents of ~/.ecyptfs to that.  You need a separate subdirectory per machine because even if your login password is the same everywhere, that random hex number will be different.

You can do this today, but it may not be secure as you'd like, since the hex number that unlocks your encrypted home directory is "only" protected by your login password.  Crack the password, and if there's ever a security hole in U1 (or some other legal or illegal machinations) that manages to expose your wrapped-passphrase file, then your entire home directory is vulnerable.  For a little extra security, we can use encfs and fuse to create an unencrypted front-end to an encrypted directory inside U1.  You would then copy your ~/.ecryptfs files to the unencrypted mount, and it would get stored with an additional level of encryption (and obfuscation) to U1.  Now someone would have to crack two passphrases to get to your home directory.

The instructions on how to do this couldn't be simpler, and are outlined in this wiki article, and this one.  For the lazy (like myself), here are the steps:

$ sudo apt-get install encfs fuse-utils
$ sudo modprobe fuse
$ sudo adduser <your-login> fuse
$ sudo sh -c "echo fuse >> /etc/modules"
$ mkdir ~/safe  # or whatever, contents are plaintext
$ mkdir "~/Ubuntu One/safe" # or whatever, contents are encrypted
$ encfs "~/Ubuntu One/safe" ~/safe
# You will be prompted for a new encfs passphrase, this is your extra security
$ mkdir ~/safe/<your-machine>
$ cp -a ~/.ecryptfs/* ~/safe/<your-machine>

And now just let U1 do its synchronization magic.