I’m going to Linux Audio Conf ’14

Posted by samtuke on 0

Tomorrow morning I set sail on a sleek omnibus to LAC 14. There’ll be 77 events and 33 concerts, not to mention all sorts of mini talks and lean-tos. Scene celebreties will also be there, including falkTX of the amazing KXStudio, Rui Nuno Capela of the stunning qTractor, and Harry Van Haaren of the electrifying Open AV.  Those guys have been heroes of mine for the last three years, and I can’t wait to meet themIt’s going to take about 20hrs of travelling to get to Karlsruhe, Germany, from Berlin, but I’m hoping my life-long travel sickness won’t make me pay.

Bus

So if you’re going to be there, please give me a shout, and let’s have a drink and compare synths. And in the mean time check out 20 seconds of Sorcer.

Get ArkOS up and running on Ubuntu in a virtual machine

Posted by samtuke on 0

So you’ve heard about the plucky new all-in-one host-it-yourself Linux distribution that’s turning Raspberry Pi’s into Freedom Boxes? ArkOS is a nifty little Arch Linux spin-off with slick marketing and granny-friendly interface. Yes it runs owncloud, dovecot, XMPP, transmission, and many more. Fortunately you don’t need a Raspberry Pi to give it a spin: here’s how to run it on Ubuntu machines.

ArkOS logo

Note: Installing the guest additions package, and including rules for forwarding ports 80 and 443 may not actually be necessary, but hey ho, they can’t hurt either, and may avoid hiccups. And in case you’re wondering, my favourite Fedora laptop is out for repair currently so my KXStudio machine has stepped into the breach. Guides should return to trusty Fedora shortly.

  1. On your host Ubuntu machine, install dependencies:
    sudo apt-get install python-setuptools libxslt1-dev python-dev libevent-dev
  2. install the latest version of Vagrant virtual machine configurator by downloading a .deb package direct from their website (repo versions are too old):
    http://www.vagrantup.com/downloads.html
  3. Download the ArkOS ‘genesis’ image for Vagrant via web browser:
    https://arkos.io/downloads/ (look for "genesis testing and development")
  4. $ cd into the directory containing the fresh image, then run this to generate a config file called ‘Vagrantfile’:
    vagrant init [image filename]
  5. Add these configuration lines to the newly generated Vagrantfile to enable connectivity from within new virtual machines to the wider internet, and to forward necessary ports to your host machine so you can browse ArkOS hosted pages from the comfort of your host machine’s web browser. Paste the entirety of this code before the existing final line containing ‘end’:
    # Allow the client Internet connectivity through the host
    config.vm.provider "virtualbox" do |v|
    v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
    v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
    end
    # Allow virt host to access pages hosted on the client
    config.vm.network :forwarded_port, host: 1080, guest: 80
    config.vm.network :forwarded_port, host: 8000, guest: 8000
    config.vm.network :forwarded_port, host: 1443, guest: 443
  6. Start Vagrant for the first time, watch it try to set up Genesis:
    vagrant up
  7. Watch out for git errors stating “host unreachable”. If there are none, you’re good. If there are, you have a connectivity problem.
  8. If all is good, ssh into your new machine:
    vagrant ssh
  9. Double check for connectivity; if you get pings back, all is good. If not, you have connectivity problems:
    ping google.com
  10. If all is good, proceed to the next step. If you have connectivity problems, $ exit to return to your host machine, fix your Vagrantfile config options, then restart the virtual machine, auto-reconfigure Genesis successfully, and ssh back in:
    vagrant halt
    vagrant up
    vagrant provision
    vagrant ssh
  11. Install virtual box guest additions and lynx command line browser in the virtual machine:
    sudo pacman -S virtualbox-guest-utils virtualbox-guest-modules virtualbox-guest-dkms lynx
  12. Restart the virtual machine:
    exit
    vagrant halt
    vagrant up
    vagrant ssh
  13. Enter the genesis folder and start up Genesis:
    cd genesis
    sudo python2 genesis-panel
  14. Wait for the additional packages to install, and look for the success message indicating that Genesis is running “INFO Starting server”.
  15. Now, on your host machine (Ubuntu), visit the below address and you should see your ArkOS control panel staring back at you, ready for play!:
    localhost:8000
  16. Start configuration via the web interface, add database credentials for Genesis, follow the official instructions.
  17. Let us know how you get on in the comments 🙂

What Heartbleed means for Free Software

Posted by samtuke on 0

The bug in OpenSSL nicknamed “heartbleed” that was discovered this week has been labelled “catastrophic“, “11 out of 10” for seriousness, and credited with “undoing web encryption“. It reached the height of mainstream press yesterday with dedicated front page articles on The Guardian and and The New York Times. This Free Software bug is now known worldwide and is set to remain infamous for years to come. So what does all this mean for the reputation of Free Software?

Software has bugs

Heartbleed is ostensibly a programming oversight, the result of a “missing bounds check“, which basicaly means the program will allow more data input than it should, because the developers didn’t anticipate or test an appropriate scenario. This sort of bug is extremely common in all kinds of software, and Free Software is not immune. Because Free Software makes its source code available to independent audit and review, such bugs are more likely to be found in important apps like OpenSSL. And because high profile Free Software projects are more apt to use automated code testing tools and bug detecting equipment, such bugs are more likely to be blocked from introduction in the first place.

Heartbleed proves that software has bugs, and that Free Software is no exception.

The fix was fast

The Codenomicon Security researchers who discovered the bug notified the OpenSSL team days before making the vulnerability public. The problem was fixed, with updates available for the most important Gnu/Linux servers, before the news even broke, as is the custom with security critical issues. Therefore the fix was extremely fast. Compare that to track records of leading proprietary software companies. Apple’s infamous “goto fail” bug waited four days after public disclosure for a fix to appear, and when it did, the patch concealed its real purpose, making no mention of the critical flaw that it addressed. Microsoft last year admitted to sharing details of vulnerabilities in their software in secret before they were fixed, leaving their own customers exposed to exploitation.

Heartbleed shows that important Free Software can react quickly to pre-empt exposure to publicly known vulnerabilities.

Access enabled discovery

What prevented this bug from going undetected for another two years? Heartbleed’s discovery took place during review of source code that wouldn’t have been possible had OpenSSL been proprietary. Vulnerabilities can be found with or without source code access, but the chances that they’ll be identified by good guys and reported, and not by bad guys who’ll exploit them, are higher when independent auditing of the code is made possible.

Heartbleed demonstrates that Free Software encourages independent review that gets problems fixed.

Tracing the problem

Was the heartbleed bug introduced by the NSA? Is the problem deliberate, or a mistake? We need not wait for a public statement from OpenSSL to sate our curiosity – the full history of the bug is a matter of public record. We know who introduced them problem, when, who approved the change, and the original explanation as to why. We know exactly who to ask about the problem – their names and email addresses are listed beside their code. We can speculate about hidden agendas behind the work in question, but the history of the problem is fundamentally transparent, meaning investigators both inside and outside of OpenSSL can ask the right questions faster and immediately rule out a slew possibilities that initially suggest themselves in such a case.

Heartbleed shows the value of Free Software transparency and accountability.

Catastrophic success

Despite the understandable consternation surrounding heartbleed’s discovery, its impact is actually very encouraging. The shock resulting from the flaw reflects how widely OpenSSL is relied upon for mission critical security, and how well it serves us the rest of the time. 66% Of all webservers have OpenSSL installed via Apache or Nginx according to Netcraft. The list of top shelf security apps using OpenSSL in the back-end is a long one, including PHP (running on 39%  of all servers). The fact that heartbleed has become front page news is a good thing for raising public awareness of the ubiquity of Free Software crypto across business sectors, and for reminding us how much we take its silent and steady protection for granted.

Heartbleed exposes Free Software’s importance and historical trustworthiness to a global audience.

Impact on Free Software?

Many commentators on the heartbleed bug believe it demonstrates weaknesses and flaws in Free Software as a concept and method. But I see the contrary: heartbleed demonstrates how well Free Software is working to deliver security we need, to identify problems with it, and to fix them when they’re found. As a crypto lover and developer it only remains for me to thank the OpenSSL Team for their dedication, and the stirling Free Software they provide to us all.

Create new revisions by default for products in Drupal Commerce

Posted by samtuke on 0

People make mistakes. That’s why anyone worth their salt is using version control systems like Git for their code these days. The closest we can currently come to version control for Drupal products, is use of the revisioning system. And if you’re here, I’ll assume that you know what that is, and what it does.

“Products” however are not like other content types – they’re not nodes. Fortunately they can still be configured to save revisions by default on each new edit, just like other content types. That means you can let loose your team of editors and translators on your website, including your products, with significantly reduced risk of data loss and regressions.

To enable revisions by default:

  • Visit yourdomain.com /admin/structure/types/manage/product-display
  • Click on the “publishing options” tab
  • Under “default options” tick “create new revision”

Fix missing maps on Drupal 7 with Open Layers and SSL

Posted by samtuke on 0

Open Layers are great, Drupal are great, and the OpenLayers and associated Drupal modules that combine the two are especially great. Unless, like most modern security-conscious websites, you’re using encrypted connections to your server with SSL. In that case, maps are unfortunately invisible wherever they’re used, both on public pages, and in administrative and content editing pages.

This is because web browsers try to protect users by ensyring that if a page is accessed securely over HTTPS, all parts of that page are also loaded securely, including scripts and images. By default, your maps on Drupal are loaded remotely via unsecure connections. So while we trust the maps will be safe and correct, we cannot (and should not) convince our web browser to do the same.

Here’s the solution.

Change the URL used for retrieving Open Streetmap tiles
Paste this on the end of your Drupal website URL:
/admin/structure/openlayers/layers/list/osm_mapnik/edit
e.g. http://documentfreedom.org/admin/structure/openlayers/layers/list/osm_mapnik/edit
Scroll to the ‘Base URL (template)’ textfield, which should state “https://tile.openstreetmap.org/${z}/${x}/${y}.png”, and swap “http” for “https” in the URL.
Change the URL used for retrieving the OpenLayers JavaScript library
Unlike the tiles URL that you just changed, the JavaScript library URL is only available via HTTP, not HTTPS, so we can’t just add that all important ‘s’ and expect it to work. Instead, you’ll need to download the Javascript library in question to a secure server, and then link to it. Either that or find somewhere it’s already hosted securely (if you do, please let me know).
I recommend putting it on your own webserver and linking to it there. You can do that like this:
cd /path/to/your/webserver/root/
wget http://openlayers.org/api/2.12/OpenLayers.js
mv OpenLayers.js sites/files/OpenLayers-2.12-manual-download.js
Next change the URL used by Drupal to retrieve the JS library; paste this on the end of your Drupal website URL:
/admin/structure/openlayers
Scroll to the ‘OpenLayers external source’ field, and replace ‘http://openlayers.org/api/2.12/OpenLayers.js’ with https://YOUR-WEBSITE.com/sites/files/OpenLayers-2.12-manual-download.js. e.g. https://documentfreedom.org/sites/files/OpenLayers-2.12-manual-download.js. Don’t forget the ‘s’ in HTTPS!

That’s it. Try viewing your maps, hopefully they’ll now appear!

Thoughts on marketing the ‘Improv’ board

Posted by samtuke on 0

At the end of last month KDE announced a new Open Hardware project to create a Raspberry Pi-like computer called “Improv“, produced by “Make Play Live” of Coherent Theory LLC. This is an important development that I’m delighted to see, and I plan to pre-order and get mine in March.

Marketing Free Software and Open Hardware based products, and specifically marketing to Free Software communities, is a fascinating and complex challenge. Let’s see if we can learn something from observing the journey of Make Play Live’s new product.
Improv board

Good examples

  • In the days preceding launch, teaser shots of the board were posted on Twitter, including a tantalising heavily-blurred image showing dimensions but no detail
  • The Make Play Live homepage is very clear about it’s focus on Open Hardware and the Improv board, with clear links to buy.
  • Two interesting, well edited videos were released for the product announcement and published on YouTube. One a personal introduction by Project Lead Aaron Seigo, connecting viewers to the team and expertise, the other a 30 second product expo style hardware closeup. The two juxtapose well and introduce viewers to both the human and corporate sides of the project. Familiarity with both is important for inspiring trust in buyers.
  • KDE’s piece on the its own history with Open Hardware is valuable in it’s own right, and puts the Improv board in context, connecting it firmly with KDE itself and its values.
  • Make Play Live hosts it’s own forum for community members, running on the excellent Discourse forum app. The forum remains active months after the latest company announcement, providing a place for questions and ideas, equating to good value community marketing.
Make Play Live logo

Ideas for improvement

  • The official Twitter account (@makeplaylive) posted it’s first ever tweet only 10 days before product launch, and has only tweeted 19 times total to date. Building up followers before launch, and keeping the account alive with occasional posts and rewteets afterwards could have resulted in much greater impact then and for future news.
  • @makeplaylive tweeted only announcements. Tweeting messages to users with lots of followers and getting their attention would have been a great way to engage receptive community members.
  • Just one shared hashtag was used in tweets: #merweek. That was a good tag to use, but a fraction as popular as tags like #OpenHardware, #KDE, or #RaspberryPi
  • The first news about Improv appeared on kde.org two months after the original announcement. Improv is made by KDE people using KDE software and KDE design principles. This seems like a missed opportunity to get the most potentially receptive community on board with the project early, and enrolling amplifiers (thought leaders, twitterati, etc.) and early adopters.
  • When news about Improv finally did hit kde.org late last month, the links were buried in a long retrospective piece about open hardware in general. While excellently written, the piece included no pictures of the board and no links to buy, instead linking to the historical blog announcement, and a donate form on an unfamiliar 3rd party website. A simpler path to getting the board would be more encouraging.
  • Visitors to Make Play Live wishing to purchase a board are navigated to vaultechnology.com. Consumer trust in the ethics and community behind Open Hardware products is critical, and the relationship between Vault and Make Play Live could be clearer.
  • To purchase, visitors must traverse three pages (“Purchase an Improv” -> “Buy an Improv” -> “add to cart” -> “Checkout”). Taking buyers direct to the checkout page after their very first click (“Purchase an Improv”) would provide a better experience and likely elevated conversion rates.
  • Vault / Make Play Live are hoping to raise $125.000 in donations to get Improv off the ground. Considering they have such an interesting and desirable product, this looks like an ideal opportunity for crowdfunding. Using a platform like Kickstarter or Goteo could have provided many added benefits for marketing, and public and community relations.

By looking at projects like Improv we can develop an understanding of promoting ethical software products. Considering how few specialists there are in this field, and considering how central marketing is to the viability and growth of Free Software and Open Hardware, these are important skills to highlight.

The marvellelous magical mysterious Git

Posted by samtuke on 0

For I ❤ Free Software, I’m taking time to tell you about some Free Software that I love. And as everybody knows, I love Git.

I sing it’s praises, often literally, everywhere I work. Git provides the plumbing of my design, development, and decision making. No, it’s more like the golden contacts along which colleagues creative energies zip. It provides the neural pathways by which our collective brain may think. It is always there, the stalwart friend by my side, adapting to my needs, taking ever new and more serpentine challenges in its stride. I love Git.

Musical scores, vector illustrations, spreadsheets, to-do lists, databases, the lot – Git takes my files and with but two commands provides an invitation for the world to help, contribute, flatter and extend:

git init
git add .

When was that invoice last updated? Why did I delete pictures of Gwen? Where did this cat poem come from? Git knows the answers.

As my career has progressed, Git scaled up. When six months of work diverged my new crypto code ownCloud’s core code-base, who merged 2.000 commits back into the rest? Well me, of course, but not without Git.

As pressures increased, sites with a great many visits, who undid all those bugs in the blink of an eye? Yes it was Git. The next day at leisure I browsed through the blameworthy changes, edited, committed, and pushed, knowing nothing was lost, and safety maintained. Thank heavens for Git.

A poem

Git governs software
Git keeps the score
Git knows when who worked, and on what, and why for

Now extra Git tools
Let us tip, and show blame
Click to merge, paint a diff
Run test tools, Fork by name

Git is marvellous, magical, and sometimes mysterious
So if you love FS  you should take Git more serious

Fix Fedora 20: “Warning could not boot”

Posted by samtuke on 0

So you’re in front of your shiny new laptop / netbook/ ultrabook / toaster, you’ve put Fedora 20 on a USB stick, filled up the progress guitar pick, only to be dropped to an emergency shell with errors like:

dracut-initqueue[398]: Warning: Could not boot.
dracut-initqueue[398]: Warning: /dev/disk/by-label/Fedora-Live-Desktop-x86_64-20-1 does not exist
Starting Dracut Emergency Shell...
Warning: /dev/disk/by-label/Fedora-Live-Desktop-x86_64-20-1 does not exist
Warning: /dev/mapper/live-rw does not exist

This dispiriting problem was solved in our case by simply typing the following at the dracut prompt:

exit

Give it a try, and if that fails, try using the direct write (dd) method of live USB creation.

Wacom intuos3 button layout for Gnome 3

Posted by samtuke on 0

If you’re using a Wacom intuos 3 graphics tablet with Gnome 3, then this little button layout illustration should be useful. Gnome’s built in Wacom configuration tool is great, but the numbers it assigns to the tablet buttons are not intuitive. Use this diagram to avoid a trial and error approach to function assignment.

How to fix Fedora 19 “unlockable lockscreen” bug

Posted by samtuke on 0

The problem

So you’re using Fedora 19, you update yum one day, and a few days later you find some strange lockscreen behaviour. The look of your lockscreen has changed – a different background colour, clock size, and password box positioning. So far so good. But wait, why does a second lockscreen appear after you shoo away the first? Why can’t you type your password to the input field? Why can’t you get back to your desktop and unsaved work?

The explanation

This bug affects people who have the Cinnamon desktop installed in a session using Gnome. Maybe you’ve installed Cinnamon desktop environment to try it out in the past, maybe other users on your machine are using it for their sessions, or maybe you’re using an app that relies on Cinnamon and has previously installed it as a dependency. My reason for having it is Nemo – the fork of Nautilus file manager, which is the default way to browser folders on Gnome 3, and which dropped a bucket load of functionality with a recent update, causing me and many others to move to the Cinnamon-oriented aquatically-named fork.

Cinnamon has it’s own lockscreen and this conflicts with Gnome 3’s own. Basically the “unlockable lockscreen” issue is caused by these two screensaver apps competing for your attention and your password, and between them they manage to prevent you from unlocking either one or both of them at all. Although this bug has apparently been fixed for Fedora 20, we Fedora 19 users are still suffering. Indeed yesterday I lost a whole page of notes to this bug, when I had to use ctrl+alt+backspace to force a session logout (you can enable this shortcut using Gnome Tweak Tools GUI; instructions reside in the Fedora Forums).

The workaround

These instructions should save you when the bug has taken effect and you need to unlock your screen. A fix to stop the problem occurring in the first place is underneath.
Open a new virtual terminal using Ctrl+Alt+F2, login using your usual username and password, and execute:
killall cinnamon-screensaver
Make sure it worked by ensuring that this command doesn’t find the process we just killed is still running:
sudo ps -e | grep cinnamon-screensaver
And now go back to your original X-based session using Ctrl+Alt+F1

The solution

Remove Cinnamon’s screensaver. Unfortunately this will remove the Cinnamon desktop entirely, including any Cinnamon-based apps you have installed, like Nemo. Well Nemo, so long and farewell. I look forward to your smarter file sorting and expanded file-handling extension set in Fedora 20. As root:
yum remove cinnamon-screensaver
Then log out and in again (Cinnamon’s screensaver should no longer auto start with the session).
Good luck!