does that make me a pi baker?

I discovered an awesome tool for cloning micro-SD cards like those used in the Raspberry Pi 3 computers for the project I’m working on.  It’s called ApplePi-Baker and it’s doing a fantastic job of speeding up that process.  Too bad it doesn’t work on operating systems other than OS X.

I’m guessing that it’s using the underlying/poorly-documented drive devices on the Apple like /dev/rdisk1 rather than /dev/disk1 (subtle, I know), but it’s blazingly fast by comparison and it seems to work.  And when I say “work” I mean:  you don’t have to go research all the many ways of using the dd command, for example.

Note that you’ll want a few available gigabytes on the destination drive you’re backing up to.  But the program has several compression options.  For example, backing up a 16GB image to a ZIP file only needed about 3.5GB when finished so it’s good when your space is limited.

It’s a little scary at first since it boldly asks for your Admin password as it gets started, as combined with the fact that it isn’t digitally-signed with an authorized Apple Developer key.  That said, you should be able to trust it since it does what it says it does and nothing else.  Note that after you download it, you can’t immediately run it.  You’ll need to open Finder, go to Downloads and then Ctrl-click it and choose Open the first time, then click the Open button.  Having done this once, you may then drag it to your Applications folder and then run it normally after that.

open-source minion supercomputer

It seems like every villian these days has their own plan for world domination. So I thought I’d better get started on my own by developing an open-sourced supercomputer design using the affordable Raspberry Pi 3 computer as the basic building block.

Here, I list some of the pertinent points regarding that design.

Minion Theme

The usual master-and-slaves paradigm for most supercomputer systems is replaced here with a gru-and-minions theme. I intend to add sound events at some point in the future, given the usual “headless computer” arrangement for servers. This should help to flag certain events as they’re happening and add some fun to the project as a whole.


Each squad of four computers would be contained in such a way that it could connect together with the next set of four.  The name for each squad is E=MC2 which stands for Expandable Minion Cube Cluster.


Each E=MC2 has its own internal Ethernet switch and a USB charging hub to power things inside. The first in the system also includes a shared USB-based thumbdrive for common resources as well as the code that you wish to run in parallel.


Everything internally is powered with a USB charger so that’s about 15W per computer (or core). The power cost then is less than half the per-core cost of a typical supercomputer for electricity, noting that your average supercomputer must also be cooled.


Weighing in at less-than-$300, the squad of computers has a per-core cost of less than $75. Throughout, I’m using open-source software. I hope to further minimize costs involved by renting time on a 3D printer locally rather than purchasing one.


Since I hope to show this project to others, the entire thing should be relatively mobile by design.

In the “known wi-fi” mode, a single power cable could be the only connection to the device, allowing a laptop to connect to it wirelessly. It would be necessary to first educate the gru node and the laptop with the wi-fi credentials, however.

In the “unknown wi-fi” mode, you would add an Ethernet cable to a laptop computer to connect to the system. It would be necessary to configure the laptop’s Ethernet adapter to match that of the internal wired network.

When the 3D printing work has been completed I envision a clear, self-contained, 6″ cube weighing in a under two pounds (minus the power cord). We’ll see how that plays out soon enough.

Technical Savvy

I’m trying to make this as easy as possible for others to repeat. I’m carefully documenting the hardware list to make this easier to source and so that the same set of 3D printing designs I use might accommodate your own attempt at this.

I do, however, assume that you would have some basic electronics experience, have some tools and a small budget to work with and that you understand your way around Linux terminal commands like ls, cp, mv, mkdir, cd, chmod, chown, sudo, apt-get install as well as how to map a drive on a network in either OS X or Windows, say.

You’d also need to know how git and how github works in order to pull the code and design files.

It will be helpful if you understand DNS, DHCP, the concept of IP addresses and how to configuring these on a computer.

Documentation in Real-Time

I’ve purchased the new hardware for this, having done some work already preparing the working image for gru, the master node of the system. I’ve created a repository for everything at e-mc2, noting that there are more than one file within the collection of instructions so far.

As I install the full set of software and dependencies again I will be updating the documentation so that everyone may follow along and be assured that I’ve not glossed over any of the details.

Design Hurdles

I had some problems with the first (several) attempts to power everything with a chassis-based switching power supply but the connections themselves proved to be too problematic. And given the open-sourced nature of the project I would hope that others would build their own so I deemed this attempt “too fussy”. Additionally, the “green” Ethernet switch’s tendency to lower its power demands before any nodes came on then confused this power supply which looked something like this:

  1. The “Green” Ethernet switch would power on and the switching power supply would adjust the input current and output power
  2. The switch would determine that none of the nodes had “linked in” to their Ethernet connections (yet)
  3. The switch then would go into green mode and lower its power consumption and the switching power supply then would attempt to toggle down the output power
  4. The switch and other devices wouldn’t get enough power and then would power cycle, repeating the pattern

This next iteration then changes the power system completely which so far promises to be much easier, resulting in solid connections to the devices.

Common Protocols and Code

I’ve decided to use the Message Passing Interface (MPI) for inter-node communications and the Samba software so that the coder may map a drive to the shared data/code area.

Since I like Node.js, I’ll be developing something so that this is a choice as well. The initial “Hello, Gru!” demo may likely be written in Python, however.


I’ve found a local place that rents 3D printers. Hopefully I can get some help designing the files necessary to house all this in a clear cube.

As far as external connections/openings to the cube, there should be one rectangular cutout for the IEC320C5 three-prong power plug and a Keystone receptacle for the Ethernet connector so that it can snap into place. Also, there should be some holes adjacent to an internally-mounted speaker. Optionally, there might be openings on both sides if a fan is added. Overall, it should be a pair of clear plastic parts which snap together to form a cube.

Internally, there should be screw holes and possibly slide rails or bumpers for the Ethernet switch, the USB charging hub and the four Raspberry Pi 3 computers. There should be room for five 1′ Ethernet cables as well as five or six 1′ micro-USB cables for power. As preferences go, it should be relatively easy to open up, remove a computer and its micro-SD card for the sake of maintenance, say.

Although it should operate well without a fan, I’m trying to source a usable 5V-powered fan for the design. Since some of you will want to overclock, this is probably a good idea, I’d guess. That being the case, a cube-to-cube side orientation of venting would create a continous flow of air through all. It may be difficult for everyone to source something like a 5V-to-12V boost module but that’s probably the route to go, combining this then with an inexpensive and readily-available 12V computer fan.

Using the Last USB Port Wisely

The existing design calls for four USB cables to power the computers and a fifth to power the Ethernet switch. That leaves one last USB port to power something. Here are some options.

  1. The existing design utilizes a tiny USB thumbdrive which goes directly into the gru node and is shared by all. Instead, this could be a USB-powered external drive with faster throughput, if so desired. One USB cable would connect the drive to gru and the second would provide power over USB to the charging hub.
  2. A small speaker attached to the grunode should allow sound events to be played in conjunction with code execution. Some speakers are USB-powered and this may be an option.
  3. A USB-powered fan would be the logical choice, however, for the remaining port.


In case you missed the link above, the repository is now at e-mc2 on github. As of today, it’s probably a bit premature to start your own supercomputer from these designs. I personally would wait until I’ve got more of the MPI-based coding in place and have added the step-by-step instructions for some of the dependencies.

Update 3/27/2017

Things are looking great for the repository and the supercomputer itself. The MPI-based code is now working as well as the website for managing the minions.

the story of the us$100m button

Once upon a time…

…in an enchanted forest of Interweb there lived a kindly old oracle by the name of Google. Most days would find him smoking a long pipe and—seated at the end of a very long line—dispensing answers to the person at the head of said line. See, everyone came to Google when they were looking for something they couldn’t find.

One might inquire of Google, “where can a man go to find a good pub around here?” and he’d then magic up a scroll instantly. On the scroll would be a carefully-constructed list of pubs and over in the marginalia would be a bunch of advertisements for pixie dust, faerie potions, &c. As it happened, he paid for his various sundries and such out of the monies which he received from the witches who paid for these advertisements.

Sometimes, though, Google’s hand would cramp up a bit after a long bout of magical writing like that especially on summer days when the sun grew hot and rather than handing the person a scroll he’d just get a twinkle in his eye and ask, “are ye feeling lucky?” and if the person nodded, he’d then just tap his wand on their shoulder and they’d instantly be transported to the top place which would have been on the scroll, if only he’d penned it up as before.

This carried on for some time as things tend to do. But then one day the witches hired a man whose job it was to count all the beans in the King’s silos. They wanted the man to use his advanced forms of math to cypher up the sum total of lost monies that Google was incurring by this practice of not scribing down those advertisements.

So the Royal COB (Counter-of-Beans) then set about to find out how often Google was taking this shortcut (“one soul a’ hundred”) and further, the total loss in pixie dust monies (“I fully a’sure ye it’s nigh less than a hundred-thousand-thousand of the paper scrip they call dollars a month’s sail west o’ here”). Well, the witches were fit to be tied, I’ll tell ye.

“Ye can’ot be doin’ tha’ anymore, Google”, they said. “Ye’re costin’ us out of hovel n home, ye are!”

And so,

…that’s the story of why Google can’ot just send ye on yer way anymore without the fairie dust adverts. The Royal COB and the witches simply won’t let him.

~~~ The End ~~~

free coffee on your birthday

So it’s my girlfriend’s birthday tomorrow and in conversation today I mentioned to her that Denny’s gives you a free meal if it’s your birthday and Starbucks gives you a free drink. Without missing a beat she said, “too bad you can’t create enough accounts on their website to drink for free all year”. Slightly evil, perhaps, but definitely brilliance at work.

Since I’m also a project manager, I started thinking about the logistics behind this free-Starbucks-for-life plan and it seems to be easy enough as implemented below:

  1. You’d probably start off by registering a dedicated domain name to track all the email forward permutations that you’ll need to pull this off.
  2. Next, register a free email mailbox somewhere like Gmail perhaps.
  3. Create a spreadsheet where you track the 365 different email identities/profiles which you would then use at Starbucks, for example.
  4. Back at the domain name registrar, setup email with a catch-all email forward which forwards to that single Gmail account.

Throughout the next year you’d then visit different Starbucks stores and snag several blank Starbucks cards (without putting any money on them). Feel free to put money on one of the cards if you’d like—I’d suggest going with the minimum here.

Back home on the Internet (or even in the store on your portable device), register a new card on their website, issuing the first profile/email address from your spreadsheet and entering the card’s number into your spreadsheet for tracking purposes. If you have a magic marker, then it might be useful to mark the card in some discreet way to more easily identify it from the rest.

The important part is to enter a sequentially-unique month + day combination for this card’s birthday information.

All inbound notification emails for any particular account from Starbucks would then land in that single email mailbox for later processing, if required. An email rule or two should prevent the average advertising attempts to land in a separate folder, perhaps, so that they don’t clutter the more important ones.

The Result?

Starbucks for life.

Each week, you’d pull several cards from your collection, the ones which correspond to the upcoming week’s “birthdays”. Walk in with the right card each day and pretend to be pleasantly surprised when you’re awarded your free drink.

If you’re an actor, feel free to really get into each character you’ve created.  For your Jacque Duboisson profile, you could fake a French accent, say. And then you’ve got Giovanni Bere, Hans Getränk, Juan Beber to name a few.

Evil Is As Evil Does

Should you do this? It’s probably too much trouble, honestly. But I would do something like this for Wells Fargo or US Bank or Chase Bank because they’re all evil themselves. Every day of the year they illegally charge people a $7.50 or even greater service fee for simply cashing a check locally issued from their own bank. I personally have a great stack of the receipts from them in which I was yet again charged this transaction fee for simply cashing a local check from their own branch.

“In form, a check is an order to the drawee bank to pay the face amount of the check to the payee.” ~ Justice Buford, U.S. Bankruptcy Court

So when the issuing bank imposes a fee to cash a check, this is by definition illegal since the check itself is a promise to pay the full amount indicated rather than a fraction of same.

It’s too bad that banks don’t get their karma handed back to them in some sort of Despicable Me plan like this.


server-side tone synth with node

I thought I’d work on another Raspberry Pi 3 project and this time was looking to expand my repertoire for server-side audio.  I suppose I was imagining an application in which you’d carry the Pi along with you using a USB-based power bank and plugging in your headphones, controlling the interface via your cellphone’s browser, let’s say.


Logically then this would need to be a Node.js—based webserver which could synthesize a sine wave tone with a specified frequency on both left/right audio outputs on the server itself (rather than streaming it back to the client browser).  I chose the Raspian image for the microSD card because, as a Debian modification, it’s likely the closest to the standard Ubuntu flavor of Linux which I work with the most.

Open Source

Searching the npm space I found nothing useful, to be honest. It’s rare when the open source world fails to deliver but this was one of those times. I was going to need to innovate on this one. There are many repositories out there which use the browser’s window object but that just wasn’t available here on the server. I installed module after module only to find that one of its dependencies relied upon that same pesky window object. So each time, I had to perform another npm remove --save whatever from my project to return things back to “square one”.

This research took a little longer than I’d hoped for but it turns out that Raspian out-of-box includes the Open Sound System (OSS) aspi-utils collection and its speaker-test program can be used in a terminal to generate tones from both speakers. Okay, so now how do you run terminal programs from JavaScript?

Starting External Programs From Node

It turns out that Node has an internal module called child_process which allows you to spawn (run) something you might normally invoke from the command line. It took some reading but I was able to navigate the documentation and to start a speaker-test session with the necessary arguments. One task down, (one to go).

Stopping External Programs From Node

Fortunately, Node also has an internal module process with a kill command to stop a running process.


It takes a bit of state management: the webserver needs to remember if you’ve started a process, what its process ID is and whether or not you’ve now stopped it. A proper open source project would support systems other than Linux but this is the starting point and this wouldn’t work, say, with a Windows-based computer using the PowerShell module control, for example.

Since this wasn’t an exercise in UX design the interface couldn’t really be any simpler. It’s your basic Express-generated website with the Pug view engine and a simple pull-down list for selecting some preset frequencies. Submitting your tone choice POSTs back to the same index page; selecting the Stop button POSTs to a virtually-routed /stop routine which then redirects back to the original index page.

Source Code

Check it out if you’re curious. I’ll likely be using this same technique to create a more self-contained module for managing external programs.

a year without air

A little over a year ago I was having frequent Tire Pressure Monitoring System (TPMS) light—related alerts on my Kia’s dashboard. Given the rather stupid government-mandated TPMS system I found myself having to replace at least one of the valve stems.  Instead, I opted for a new set of four tires, four new TPMS valve sensors and the vendor’s upgrade to fill each tire with nitrogen rather than the expected air most tires use.

Nitrogen isn’t that exotic of an element. In fact, 78% of air already is composed of it. The remainder of air is oxygen, water vapor, carbon dioxide and smaller concentrations of other gases. Probably the most compelling reason to fill a car tire with Nitrogen alone is that it’s a large molecule and is much less likely to escape through the rubber. Without the water vapor, the tire’s pressure remains constant over a wide range of temperatures. In fact, that’s the topic of this post:  I just drove an entire year all over the southwest U.S. and didn’t need to adjust my tire pressure, not even once.

I drove in weather over the past twelve months which ranged from freezing to above 100° through numerous deserts during the summer. And each tire remained within a pound of the recommended tire pressure all this time.

According to the U.S. Department of Energy’s website:

“You can improve your gas mileage by 0.6% on average—up to 3% in some cases—by keeping your tires inflated to the proper pressure. Under-inflated tires can lower gas mileage by about 0.2% for every 1 psi drop in the average pressure of all tires.”

If an average driver goes 12,000 miles per year and assuming $3/gallon for gasoline and my own 26 MPG average, under-inflated tires for that year equates to $88.38 (quite a bit more than what the upgrade cost for the Nitrogen-filled tires).

ubuntu core on the raspberry pi 3

The fun just never stops here as I begin with a new operating system on a second microSD for my newly-purchased Raspberry Pi 3. This time, it’s Ubuntu Core. This operating system from Ubuntu appears to be a big departure from the Ubuntu server or desktop versions I’m used to. In case you were wondering, I managed to install the new operating system with little trouble. It’s different, though, I’ll be the first to admit it.

Goodbye apt-get, hello snap…

Gone is the usual apt or apt-get interface for fetching code. It’s been replaced completely by snap. Honestly, apt has been the mainstay command for managing Ubuntu (and Linux) for a while now so this is quite the departure from the norm. Snap, in theory, will be a cross-Linux way of deploying code. From my initial research, it appears to be a lot like the Juju Charms for deploying services on a Metal-as-a-Service (MaaS) system. Like Charms, Snaps appear to have an up-stream and down-stream component to them, providers and consumers, if you will.

On the positive side of things, a Snap that you create would work on many different systems. In this way, it works a bit like Java or .net (somewhere, there’s an interpretive layer for the particular hardware but you don’t have to worry about that). Presumably, you mostly just worry about the interface you’re providing and the packaging requirements to create a Snap for submission to the store.

Since Snaps get digitally signed this makes them more like the Apple iTunes store metaphor that Microsoft, Google and everyone else seems to be going with these days. Digitally signing your programs both lowers the risk of rogue/evil code out there but it also puts a middleman into your money stream—someone like Apple will be there to charge the publisher a fee for making money on the store and for signing your developer’s certificate each year. At the moment, Canonical (the maker of Ubuntu) doesn’t charge for a Single-Sign On account but maybe if this becomes popular they will in the future.

Honestly, the entire concept of Snaps appears to be a watered-down clone of Apple’s iTunes distribution model.

Fee Structure for their Store

Not that this information is easily available, I managed to finally find it. From this page on Canonical’s website:

4. Pricing, fees and payment

  1. If you elect to distribute an App without charge, the payment terms of this Agreement will not apply with respect to the free App.

  2. If you set a price for your App we will collect fees from end users that purchase your App at the price you set. Within 30 days of the end of each calendar quarter, we will provide you with a report of the number of copies of each of your Apps sold and the amount of any payment due, which shall be the fee multiplied by the number of copies sold less any applicable taxes and our commission. Our commission is 20% of the total fees charged for the sale of your App, less any applicable taxes.

So they’re charging 20% commission for brokering your Snap. Compare this to Google’s flat 30% commission, Apple’s flat 30% commission plus $100/year developer license and Microsoft’s 30% commission plus $49/year developer license. Note that there are precious few Snaps available. Specifically, only one Snap has a price of $1 at this time and the remaining 547 are free. So until others are charging for their Snaps, don’t expect to make a dime selling yours, in other words. In a free world, nobody will open their wallet nor expect to.

The Future of Snaps

It’s difficult to say whether this entire concept will get traction. Linux has been the free alternative. The people who run Ubuntu, for example, like that aspect about the community. Will these people easily change their stripes and embrace a payment system in the future in which we pay for code? Remember, we’re talking about people who’d rather build from source instead of paying for a binary file. My gut tells me that they’re never going to go for it.

Should I Invest Time in Developing Snaps?

As a developer, having a variety of experience looks good on your résumé so yes, by all means, develop a Snap. And since we developers often communicate our value via our github page I’d suggest that these Snaps be free and open-source if possible.