planet g33k aotearoa

I didn't like the knobs on my Akai LPD8; they were too short & shiny. I wanted to use the same knobs that I put on my Polymorph, but (a) the LPD8 pot shafts were too short, and (b) the knobs were meant for knurled shafts and the LPD8 pots had "D" shafts.

Fortunately I was able to make some "adapters" by gluing some thick "cigar" matches together, cutting them down and then gluing them to the pot shafts with UHU glue. I added a bit of heatshrink to help hold them on.

The knobs fit over the end of the glued matchsticks, and it all worked quite well. As long as I don't clout the knobs too hard...

Well, 2010 has been and gone, but we're still here, tired but happy. Hopefully 2011 won't be quite so relentless, particularly once I've finally wrapped up the TRaCS 3 project (soon!).

This year I'll finally be exploring my synth collection and making some music (and this time I really mean it). I'll also be cataloguing it all on this site.

So what has happened in the last fifteen months?

• We went on a lovely family holiday to France and EuroDisney.
• I went back to NZ for 16 weeks to try and finish the Railways project (I failed).
• I have moved my "office" out of the small wooden shed into a nice new "log cabin", still at the bottom of the garden. It's lovely. Thanks, Bernard!
• Theo has started pre-school. And the changing of that final pooey nappy is inching ever closer...

Nginx setup (in /etc/nginx/sites-available/blog.johnp.net):

server {
    listen      80;
    server_name blog.johnp.net;
    access_log  /home/www/blog.johnp.net/log/access.log;
    error_log   /home/www/blog.johnp.net/log/error.log;

    # Common include & image files.
    location ^~ /i/ {
        alias   /home/www/i/;
    }
    location ^~ /images/ {
        alias   /home/www/images/;
    }
    # There are only two non-blog URIs to worry about.
    location = /favicon.ico {
        alias   /home/www/blog.johnp.net/htdocs/favicon.ico;
    }
    location = /robots.txt {
        alias   /home/www/blog.johnp.net/htdocs/robots.txt;
    }
    # Pass all other URLs to PyBlosxom running under Paste.
    location ~ / {
        fastcgi_pass    localhost:4999;
        fastcgi_param   PATH_INFO $request_uri;
        include         fastcgi_params;
    }
}

My little server is running Ubuntu, which has /etc/nginx/fastcgi_params for all the "standard" CGI variables. But PyBlosxom wanted PATH_INFO as well.

Python Paste setup (in /home/john/blog/etc/blog.ini):

#!/usr/bin/env paster
[default]
debug = false

[exe]
command = serve
daemon = true
reload = true
reload-interval = 120
monitor-restart = true
pid-file = /home/john/blog/etc/paster.pid
log-file = /home/john/blog/log/paster.log

[server:main]
use = egg:Flup#fcgi_thread
host = 127.0.0.1
port = 4999

[app:main]
paste.app_factory = Pyblosxom.pyblosxom:pyblosxom_app_factory
configpydir = /etc/pyblosxom

Unfortunately the "executable shell script" stuff mentioned in the docs doesn't work too well for me (which it does warn you about), so I've wrapped the paste serve invocation into a short script:

#!/bin/bash
# serve-blog.sh - Run Python Paste to serve my PyBlosxom blog.
# File Created: 14 October 2009
# Author: John Pallister (mailto:john@synchromesh.com)

CONFIG_FILE=/home/john/blog/etc/blog.ini

/usr/bin/paster serve --daemon \
    --reload \
    --reload-interval=120 \
    --monitor-restart \
    --pid-file=/home/john/blog/etc/paster.pid \
    --log-file=/home/john/blog/log/paster.log \
    $CONFIG_FILE \
    $*

# End of serve-blog.sh

I have added this script to my rc.local to run at boot time.

Relevant bits of my PyBlosxom setup (in /etc/pyblosxom/config.py):

# 2 Oct 09 JDP Note: I have modified /usr/share/python-support/pyblosxom/Pyblosxom/pyblosxom.py
# to read '.blog' files instead of '.txt' files.
#
# Unused variables:
#   renderer
#   default_flavour
#

py["datadir"] = "/home/john/blog/entries"

py["logdir"] = "/home/john/blog/log" # This doesn't seem to be used...
py["log_file"] = "/home/john/blog/log/pyblosxom.log"

py["log_level"] = "warning"
# The next two lines were good when debugging my archives plugin.
#py["log_level"] = "debug"
#py["renderer"] = "debug"

py["base_url"] = "http://blog.johnp.net"

py["flavourdir"] = "/home/john/blog/flavours"

py["plugin_dirs"] = ["/etc/pyblosxom/plugins", "/home/john/blog/plugins"]
py["load_plugins"] = ["disqus", "myarchives"]

py["cacheDriver"] = "entrypickle"
py["cacheConfig"] = "/var/run/pyblosxom-cache"

This is not the complete setup, but it has the interesting stuff. I copied the default HTML flavour files (content_type.html, date_head.html, foot.html, head.html, and story.html) into /home/john/blog/flavours/html.flav/ for tweaking.

Hopefully someone will find this useful.

Emboldened by my success in writing an archives plugin, I'd now like to do one for my blog categories and another to suck down my recent Delicious link posts.

I'd also like to re-do the layout so it doesn't look so primitive. I was reading a post on Peter Seibel's blog the other day, and his layout & HTML source looked pretty good, so I might do something based on that.

But none of these things are particularly urgent, so I think I'll move on to trying to get ABCL running on the Google App Engine (after having spent a fair bit of time getting JDEE and its dependencies set up in Emacs). But I do intend to do a post on my Nginx/Paste/PyBlosxom setup.

And now, having finished this post, it's time to go to bed.

Well, I've finally got around to moving this blog to PyBlosxom. I've written my own plugin to generate the archives at the top of the page; I'm also now running on Nginx as a web server, which talks to Python Paste via FastCGI. So the blog is now dynamically generated. The next thing is to try and integrate the Disqus comments plugin.

The other thing I need to do is move the rest of my personal site(s) to this server.

I have lots of things I'd like to blog about; it's great to finally have this sorted out.

And yes, it's been another very busy year. Since my last post my third child was born (Hi Theo!), my oldest has started school (Hi Bethany!) and we've moved half-way around the world for a while... so stay tuned for more news (OK, maybe "news" is the wrong word).

Via Tim Prebble's blog, some nice video podcasts by Christopher Willits from XLR8R TV. The story so far:

1. Part 1 (Ep. 42), the basics.
2. Part 2 (Ep. 46), using Ableton Live.
3. Part 3 (Ep. 52), a MIDI pickup and a GR-20.
4. Part 4 (Ep. 74), recording at SnowGhost.
5. Part 5 (Ep. 82), automation clips.

You can download nice 640-by-360 H.264-encoded QuickTime movies of each episode (approx. 100MB per video), and I thought it'd be nice to watch them on my Nokia 6234 phone. (These seem to be very popular here in New Zealand; at least, after I bought mine the next four people I met with a 3G phone also had a 6234.)

After reading a useful Nokia article on creating mobile videos, I fired up QuickTime 7 Pro and started exporting the movies with different settings. This is what I came up with for the best results (and about 28MB per video):

Audio export settings.

The nice thing about doing this myself is that I could keep the audio bandwidth high (so it sounded pleasant) while scrunching the video (so the phone could play it cleanly). The audio bitstream accounts for half the file size.

I would love to have time to actually try this stuff myself. I have a GK-2a pickup and an old GM-70 I picked up on Trade Me; one day I'll manage to get it all set up and have a play. (Perhaps by then I'll have a Graphtech Ghost setup and an Axon AX100 instead.)

I have managed to get trac-wiki.el and TRAMP set up under Emacs 23.0 on Windows. This means that I can now edit Trac wiki pages via XML-RPC and edit these blog posts via SSH. Sweet!

References:

• trac-wiki.el by Shun-ichi Goto.
• xml-rpc.el
• The Trac XML-RPC Plugin

.emacs configuration:

(add-to-list 'load-path "D:/src/other-lisp/emacs-lisp")
(require 'trac-wiki)

(trac-wiki-define-project "tracs3" "http://tracs3.synchromesh.com/trac/" t)

(let ((auth (base64-encode-string (format "%s:%s" "<my username>" "<my password>"))))
  (set (symbol-value 'url-basic-auth-storage)
       `(("tracs3.synchromesh.com:80" ("Restricted Access" . ,auth)))))

(autoload 'trac-wiki "trac-wiki" "Trac wiki editing entry-point." t)

My .emacs configuration for TRAMP is:

(require 'tramp)

(setq tramp-default-method "pscp"
      tramp-default-host   "synchromesh.com")

(add-to-list 'tramp-default-user-alist
	     '("pscp" ".*\\.synchromesh\\.com\\'" "<my username>"))

Hopefully this means I'll update both the TRaCS 3 wiki and this blog a bit more frequently...

I've started some notes on the future of Ngake. The idea is that I develop Ngake as a site all about Ngake sites. Simple, really.

I have recompiled mod_lisp2.c against Apache 2.2.8 for Windows using Visual C++ Express 2008. mod_lisp itself only needs the include files and libraries that are an optional part of the Apache binary installation, but I downloaded the Apache source (that includes Visual Studio 6 project files) so that I could check the compiler and linker settings.

My slightly modified mod_lisp2.c, the Visual C++ 9 project file and the Release build of the module are available in a .zip file. Please note the title of this blog when considering whether to use any of it.

The diff looks like this:

*** ../../download/programming/Other Lisp stuff/mod_lisp2 - svn.c Tue Apr  8 23:33:07 2008
--- mod_lisp2.c Mon Jun  2 18:15:31 2008
***************
*** 443,451 ****
  {
    char crlf[2] =  {0xd, 0xa};
    char length[16];
!   snprintf(length, 16, "%x", n_bytes);
    
!   apr_status_t status = write_lisp_data (socket, length, strlen(length));
    if ( status == APR_SUCCESS)
      {
        status = write_lisp_data (socket, crlf, 2);
--- 443,453 ----
  {
    char crlf[2] =  {0xd, 0xa};
    char length[16];
!   apr_status_t status;
! 
!   apr_snprintf(length, 16, "%x", n_bytes);    // 2 Jun 08 JDP
    
!   status = write_lisp_data (socket, length, strlen(length));
    if ( status == APR_SUCCESS)
      {
        status = write_lisp_data (socket, crlf, 2);

Doesn't get much simpler than this IFES screen on a Vietnam Airlines between Hanoi and Saigon. Well, there's the small matter of not having anything resembling a keyboard with which to input any information, but anyway.

garden mint

Vietnam is unfortunately covered in cheap plastic like most parts of the world, an environmental mistake of huge proportions that will come back and bite us, hard.

They do however have alternative packaging materials that are more nature friendly. Banana and other leaves are used a great deal, and how about this:

That's ten fresh eggs, in a simply woven straw basket. There's further straw inside the basket to stop the eggs from doing the Humpty Dumpty thing to one another.

The basket is pretty sturdy, and seems to protect the eggs well. I like it.

On 2 May, I presented the NZOSS' viewpoint on cloud computing privacy issues at the Privacy Forum 2012 (PDF programme) in Wellington - the official name for the day was "Think Big? Privacy in the age of big data". The questions we were asked, and my answers (or at least the notes on which my answers were based) are below.

The other two panelists on the panel discussion (led by InternetNZ CEO Vikram Kumar) were Ben Kepes (Director, Diversity) and Waldo Kuipers (Legal Counsel, Microsoft NZ).

The presentations were videoed, so I expect that they will be made available online sometime soon - I'll update this post to include links. The evening of the 2nd, Radio NZ's Checkpoint had a brief segment featuring Bruce Schneier, also included a brief excerpt from me.

Question One

There are many real privacy risks in relation to cloud services. There also many misconceptions. What do you think is the single greatest risk and the single biggest misconception?

Response One

Modern computing tools and the economies of scale and the economics of abundance that "cloud" technologies afford businesses today, both large and small, hold great allure and promise for many of us. Most of us willingly trade our privacy for the ability to take part in global networks like Facebook, Twitter, and LinkedIn, although I suspect most people spend little time considering the privacy implications of using these networks, and assume a certain benevolence from cloud providers based on a "safety in numbers" herd instinct (which may or may not have some legitimate basis).

Of course we may also use cloud services more indirectly, and less willingly. Compliance-related activities like submitting tax details, immigration details, vehicle registrations and other personal data like insurance and personal medical records, credit ratings, and other personal data might well - now or in future - be held by cloud services.

The real misconception is that some corporate vendors are "trustworthy" - that they won't sell or use our data in ways we don't want them to... Or, if they do sell our details, our your personal information won't be used for nefarious purposes or against us in some way.

Unfortunately, I think it is fair to say that the personal privacy horse has already bolted for anyone using the cloud, having provided legitimate personal details when requested. Those of us who do so entrust our interest to entities who, for the most part, have few if any incentives to respect our interests.

At present, we have no real choice but to either remain anonymous and avoid using the modern computing resources available to us, or to trust that eventually our legal systems will mature sufficiently to provide the average person recourse in the event that their details are misused or personal freedom abused. Unfortunately, in some cases, we cannot function in society (e.g. in the case of some of the compliance requirements above, like paying taxes, registering to vote, etc.) without potentially "using" cloud services because our government has chosen to adopt those services from private sector - which often means overseas owned corporations. The current state of corporate influence on our and other governments around the world and their legislative priorities, however, makes the idea of holding cloud providers to account in any useful way seem very unlikely.

Question Two

Keeping in mind the real privacy risks in relation to cloud services, what steps do you think a person or organisation can take to mitigate the risks?

Response Two

Short of "staying off the grid" or otherwise remaining anonymous, and who knows how much longer that will even be legal or possible, there is no way to completely mitigate privacy risks unless you can actually identify a cloud provider whose incentives are compatible with a trustworthy relationship with their customers.

The only organisations I can see who might offer that set of incentives are user and community driven or cooperative organisations. Of course, a model already exists for these communities and it is thriving on the Internet, and largely because of it: the free and open source software community, and related communities like the open data and creative commons communities.

The "Cloud Computing Code of Practice," produced by the good folks at the NZ Computer Society,  is a great effort at defining a set of guiding principles - including a thoughtful privacy policy - which cloud services providers should take on board, but only time will tell how many cloud providers volunteer to adhere to its tenets (and whether any outside of NZ will do so).

Even with trusted digital communities, as with physical communities, privacy is only possible with sufficient vigilance and individuals accepting responsibility for their own well-being. At the very least, it would be prudent for any privacy-conscious individuals and organisations to adopt a policy of strongly encrypting all cloud-based network transactions as well as encrypting cloud-stored data, although this is sometimes unacceptably cumbersome, and may require an unrealistically high level of technical capability from people. Analogous to those on the low side of the digital divide, these people will, sadly, become part of the "exposed" class in the future.

Some Uncomfortable Realities of "The Cloud"

• Corporations, the primary providers of large scale cloud services, are  legally bound, as their only priority, to maximise shareholder value. They must do so by whatever means possible, and some seem quite happy to compromise ethics as long as the benefits are deemed to out weight the risks. The rate of change in the digital technology world ensures that any legal framework to regulate such players remains hopelessly far behind the status quo.

• On a more personal level, consider the exhaustive End User License Agreements on which most people trustingly - or with a sense of learned helplessness - click "I Accept"... When you do so, you are almost certainly signing away any opportunity you might have for recourse against misuse of your personal data. Your only protection is to read and comprehend those terms and conditions and/or find someone who has and whom you feel you can trust.

• Whatever you think of Kim Dotcom, the abhorrent treatment of Megaupload, and its customers' data, the willingness of foreign governments, most recently the US working with the aid of our own governments to overreach their jurisdictions and to blur the lines of legality regarding alleged copyright infringement, is chilling, and should be forcing anyone using cloud services to take stock.

  Not only has Megaupload's business been destroyed prior to any evidence of wrong doing, but its uninvolved customers have been, in some cases, irreparably damaged due to what appears to be law enforcement hubris and corporate lobbying. This is a dangerous precedent.

• Given that most cloud-services companies are US owned corporations, it's relevant to point out the repressive implications of much of the US' "war on terror"-induced legislation, particularly the Patriot Act. It creates a corrosive environment for all sorts of reasons, but, in my opinion, makes the US an unacceptable jurisdiction for information services - the country no longer champions liberty in any practical way.

• "Free" (of cost) cloud services, if successful, will eventually run out of start up capital or be purchased by a corporation and will invariably either eventually start forcing you to pay to continue accessing your data, or will do nasty things with your data to "monetise" you. Usually they will do both. Every incentive points that way. In short: if you're not paying for a cloud service's product, you are the product.

In Summary

If you want to use the cloud, but retain any modicum of privacy, then:

• find trustworthy non-corporate community-based cloud service providers who are not in the US jurisdictions and, ideally, those who voluntarily adhere to the Cloud Computing Code of Practice
• trust, but verify (you can distribute that verification burden across a trusted community)
• encrypt all content and transactions
• don't agree to any terms and conditions unless you understand their implications

Otherwise, accept that privacy is a quaint anachronism.

Useful Links

New threats to privacy...

• http://www.politico.com/news/stories/1111/69366.html
• http://www.wired.com/threatlevel/2012/04/house-passes-cispa/

Implications of cloud services based in the US (or other repressive regimes):

• http://www.wired.com/cloudline/2011/12/us-cloud/
• https://cyberspying.eff.org/
• http://uprisingradio.org/home/2012/04/25/how-tech-companies-work-with-re...