Cryptocurrencies, Mobile Payment Systems, and The Third World

M-Pesa is an electronic payment system popular in the third world.  It lets people send and receive payments with their cell phone.

It is a roaring success because A: mobile phones are a roaring success and B: most banks, payment products, and financial networks are a roaring failure in the developing world.  M-Pesa succeeded where banks failed.  Weird.

One might almost get the idea that the third world didn't trust banks.  Another theory might be that the poor in the third world were just too poor to nickle and dime to death with fees like the poor in the US, because they remained unbanked for a long time.

However, the poor in the third world were wealthy enough to buy some cell phone time, and began bartering that time in the early 21st century, effectively inventing their own electronic currency.  Smarties.

Seeing an opportunity, mobile phone provider Safaricom invented M-pesa, a mechanism for value exchange on their network.

Safaricom did some neat things with M-pesa, including innovating in microfinance, and involving entrepreneurs as M-pesa Agents - like little one-person bank branches.

Before M-pesa, Kenya was probably typical of African countries - more than 80% of the population was unbanked.(2)  None of those people used credit cards.

Now over 70% of households use M-Pesa, and many are getting traditional banking services through the M-Pesa system.  They still don't use credit cards.  Smarties.

All of their small electronic transactions are in M-pesa.  In June 2010, amazingly only three years after its intro, M-PESA transactions amounted to about 70% of the volume of electronic transactions in Kenya by volume, but only 2.3% by value. (1)

So it appears the third world is getting a good system for daily transactions that in many ways leapfrogs our dated credit-card-based system in functionality.

There are numerous advantages to their system.  Two obvious ones are that it's more convenient for lots of transaction types - you always have a phone and never have a bank or ATM when you need one; and the fees are more reasonable than most of the previously established systems for electronic funds transfer(3)(4)(5).

There are less obvious advantages, and much more interesting ones.  Take the case of the introduction of M-Pesa into Afghanistan:

"In 2009, the Afghan National Police began a test to pay salaries through mobile telephones, rather than in cash. It immediately found that at least 10% of its payments had been going to ghost policemen who didn’t exist; middlemen in the police hierarchy were pocketing the difference. Salaries for Afghan police and soldiers are calculated to be competitive with Taliban salaries, but beat cops and deployed soldiers had been receiving only a fraction of the amount paid by US taxpayers because of corruption in the payment system. Most Afghan cops assumed that they had been given a significant raise, when, in fact, they simply received their full pay for the first time--over the phone."(6)

Interestingly, the spread of M-pesa from Kenya to other third world countries appears to have introduced a reliable ledger and payment delivery system to organizations who did not have one.  Now they have one.  They pay their workers directly.  So do most employers who use M-pesa.  Pretty much everywhere it's used.

This makes me think it's just the tip of the iceberg for Safaricom.

I also think this level of prevalence of mobile payments creates a different mindset in it's users.

What happens when you want to pay one of your workers in the US?  You do it the old fashioned way.  The process gets touched by HR, Accounting, Legal, and probably by a payment processing corporation like ADP before the federal, state, and local agencies even look at it.  Eventually it ends up as a paper check in your employees hands or in their bank, a little lighter than you or your employee might have liked.

An entrepreneur in the US would expect to go about improving that system by incrementally relieving a pain point within it.  Entrepreneurs growing up with M-Pesa see this as a feature of a mobile app - they would expect the addition of a "this is for payroll" checkbox during a transaction would be enough to add a note to the transaction log - further accounting to be handled by any number of third party applications, or by themselves, or by Safaricom itself.

While the third world advances, the first spins it's wheels.  Numerous abortive attempts have been made to build similar or superior infrastructure to M-pesa (5).  Established players in banking and payment systems are scrambling to compete (see PingIt, Square, etc), but all are clunkier than M-pesa, and nothing has taken hold.

Part of the reason is just momentum, once dipped in the warm water of broadband and credit/debit cards, we see no reason to stop buying on Amazon with our laptop, or with our credit card at the grocery store.  We have a familiar, working solution in broadband and credit cards, although they cost us dearly.  As a group, we don't care all that much that merchants and expats get screwed by fees, and we just can't measure the impact to ourselves at the register.  Anyway, nuff' said.  We're missing another wave.  We'll get there, but we'll be toting the baggage of our old industries across the finish line in last place.  Back to the people who are doing it right.

I see a couple things happening: Mobile payment systems rapidly spreading across the third world, and, longer term, mobile payments system users getting heavily into cryptocurrencies.

Not being based in the third world, it's not a safe bet for me to predict anything about it, but I feel pretty good about those two bets, as they are already happening.  Kipochi is a bitcoin wallet that already integrates an M-Pesa-bitcoin gateway.  (9)  I'm sure there are others in the works, but I haven't looked.  M-Pesa is profitable (13) and fueling competition. (14)(15)

Why would an M-Pesa user be interested in Bitcoin?  Well, have you ever run an online store?  If you have, your anti-fraud software probably made it difficult for the third world to buy from you.  For good reason.  Statistically, you never want to accept a credit card from someone you don't know in the third world.  Those transactions are fraud 90% of the time.  The transaction cost is ridiculous to sell to Nigeria, because you personally have to talk to the person, and somehow work out whether they are honest before you can sell to them.  The lack of security inherent in credit card transactions creates enough friction to price the poor right out of the online transaction world for all but the largest, highest touch transactions (which they are not going to make, so they're out!).

Since Bitcoin solves the third worlds international fraud problem(10), someone in Africa using Kipochi can buy something from any online vendor that accepts Bitcoin[B].  A whole new world is about to open up to them.  Bitcoin will catch on in the third world (or some cryptocurrency will).  It might eat into Safaricoms transaction fees, but not too much.  It only makes sense to use Bitcoin for larger transactions.  Besides, the mobile carriers need something that will push all transactions onto the web eventually.  They are in the business of selling broadband, too.  If all their customers want to create online websites and sell product to one another for Bitcoins, it's a huge win for them.  Who knows, Safaricom might even strike a deal with Amazon to have their M-pesa Agents hold packages for people.

Obviously, Africa has to fix a few other things, but Amazon.com might be in there sooner than you think.

I'm serious.  Bitcoin, or something like it, by taking the fraud concern, friction, and transaction log concerns out of international commerce, fits M-Pesa like a glove, and could help to bring the third world into the first.  Bitcoin, plus rapid innovation in mobile payments, could even put the third world in an enviable position compared to the first with regard to financial technology. 

So who's killin' it in the third world?  Mobile carriers.  Did I just say that?  I know, it just seems nuts to anyone in the US.  The average US consumer knows that mobile carriers and banks will fight to the last breath to keep the status quo and kill innovation.  Innovation is pretty tough to kill...hmmm...excuse me while I grab some popcorn and watch that fight.  Keep fighting innovation mobile carriers and banks!  When the dust settles maybe we can get M-Pesa. [C]

(1) http://www.cgap.org/blog/10-things-you-thought-you-knew-about-m-pesa

(2) http://www.businessweek.com/articles/2013-03-06/what-africa-can-teach-us-about-the-future-of-banking

(3) http://www.safaricom.co.ke/personal/m-pesa/m-pesa-services-tariffs/tariffs

(4) http://www.mit.edu/~tavneet/M-PESA.pdf (page 7)

(5) http://usa.visa.com/download/merchants/Interchange_Rate_Sheets.pdf

(6) http://smallwarsjournal.com/jrnl/art/one-cell-phone-at-a-time-countering-corruption-in-afghanistan and http://en.wikipedia.org/wiki/M-pesa#Afghanistan

(7) http://www.fiercemobileit.com/story/nfc-mobile-payments-flop-says-gartner/2013-06-04

(8) http://www.mit.edu/~tavneet/M-PESA.pdf

(9) http://www.kipochi.com

(10) I'm going to cop out and refer you to this, which you should read and understand: http://bitcoin.org/bitcoin.pdf

(11) http://www.gsma.com/mobilefordevelopment/programmes/mobile-money-for-the-unbanked/mmu-examples/m-pesa

(A) 1 US Dollar is about 85 Kenyan shillings and about 1 milli-bitcoin.  At those ratios M-Pesa limits money out of a phone wallet to about one bitcoin per day.

(13) http://www.gsma.com/mobilefordevelopment/safaricom-m-pesas-h1-fy13-results-a-portrait-of-a-maturing-mobile-money-service

(14) http://techloy.com/2012/12/24/paga-reports-790-user-growth-in-its-first-year-faster-than-m-pesa-in-kenya-and-tanzania/

(15) http://www.businessdailyafrica.com/Corporate-News/Airtel-targets-MPesa-with-Equity-Bank-agency-deal/-/539550/1931908/-/93q174z/-/index.html

(16) Also interesting: http://www.gsma.com/mobilefordevelopment/programmes/mobile-money-for-the-unbanked/mmu-examples/m-pesa

(B) Yeah, I'm assuming that most major vendors will start to accept bitcoin and/or the gateway cost will approach zero.  Right now that's possible with Bitcoin Anything, etc., and it should get cheaper over time.

(C) That seemed like a nice way to end this blog post.  In reality, it's more complicated than that.  M-Pesa is dragging all other payment networks into the third world to compete.  What will happen in the first world is that we will need an equally innovative system to move our entrenched markets about.  I will make the popular contention, (among the other two readers of this blog) that some good old fashioned free market competition is in order to eliminate friction and grease the wheels of innovation.

Artificial intelligence: smart, in ways we neither intend nor understand.

Yet another commentary on the Atlantic article in which Chomsky clarifies the now obvious. (Photo from one of the many glorious scenes in The Presidents Analyst)

Robots as Mirrors

Evidently, I'm using my wiki to post writing and memoirs, google plus to blog, and google plus to store photos.

My most recent blog-like post on google plus is about emotions, or Robots as Mirrors:

https://plus.google.com/u/0/113618457816978698704/posts/2Qh8PsZWoLt

Anyway, rather than deprecate my blog and smugmug account completely, I'll keep posting some of the more interesting blog-like stuff here.


But I'll also drop a link to all my google plus postings here, just in case you want to see the less interesting stuff as well:

https://plus.google.com/u/0/113618457816978698704/posts

Here's one of the pictures I took recently - Cape Flattery in washington state - taken during toorcamp:

I wrote some stories: http://richbodo.pbworks.com/w/page/53769251/Short%20Stories

Got a bunch more in the pipeline.

Auto-autos - a little less biology in the loop

What I hear at the water cooler

I recently visited the Silicon Valley Open Source Automotive meetup at HackerDojo. Ostensibly required reading ahead of the meeting was the wired article on auto-autos. You kind of have to read that one as a backgrounder, but the summary: google already has dozens of robotic cars on the road driving around with you, and they are better drivers than humans. Been that way for a while. Yeah. I was surprised too. But wake up and smell the robotic equivalent of coffee, whatever that is. (Or just watch these robots make breakfast instead.)

Anyway, had a nice chat with some knowledgeable people. Some similar opinions to what I heard from electric car junkies at CES. Consensus at the meeting was in line with the wired article concerning the timeframe for commercial availability of auto-autos - 10 years or so.

What seemed to be totally unknown was the business model. Even the little baby steps of car automation, auto-parking, nicer computing systems with heads up displays, etc. are out of reach of the average consumer due to price concerns. Actually, I can't immediately think of any future car technologies that would save money on the initial purchase price of an automobile. So although everyone seems to accept that self-driving electric-hybrid robotic cars are the future, no one has a clear grasp on the business model that will enable that future. FWIW, from what I hear, that is the consensus at all the clued in major auto makers.

What we are on the cusp of is a form of transportation with a 10X advantage over what exists (at a higher initial price). You park it anywhere, and you can let it automatically drive you. It's safer, cheaper on energy, and frees up your time. It's like having a driver pull up when you want him, and chauffer you around. With luck, an auto-auto can drop you and park itself somewhere convenient (seriously, who wants spend their time parking or paying someone to drive you). Rich people will just buy these things outright, but the rest of us need another model.

A cursory amount of research reveals that big rental car companies are already renting electric cars. Local government intervention and purchase of advanced vehicle fleets occasionally pushes clean car tech as well. Without conflating electric cars with auto-autos too much, I believe that the markets and challenges are similar for both technologies.


Spin we're likely to hear

Briefly I'll mention psychology. There is, of course, fear - range anxiety, and any other anxiety that you can whip up in people about new car technology - this will definitely kill individual purchases. Certain segments of the American market which are primarily driven by fear are ... unretrievable. Those people will buy only what they are told to. But with a 10X value advantage the rest of us will get over that fear. Interesting thought - corporations are motivated to uncover the facts behind the FUD to improve the bottom line - corporations are FUD creators, not FUD consumers! Corporations are not easily scared away from value.

The energy industry has to be considering which side to weigh in on. Oil demand destruction is not in line with oil company interests. Interests that can afford the best congresspeople money can buy. Exxon predicts 60% of cars will be gas-only, 40% hybrid, by 2040, with a negligible sprinking of fully electric vehicles. Not in line with what I've been hearing elsewhere. Interestingly, though, they expect all oil demand increases to come from the commercial sector. On the other hand, it seems at least some public utilities might stand to gain power through charging and other infrastructure. They are also fleet customers.

Finally, there is no legal framework for robots driving cars, particularly without a human in the loop. However, everyone seems to be looking the other way right now. This is where the opponents will hit hard and fast, buying congressmen like it's black friday.

Smarmy smarty-pants ill-informed theory

It seems that fleets are the current wedge by which electric vehicles and auto-autos are entering the market. And since even electric car nuts won't pop for the first auto-autos, renting from fleets makes sense, ala the carsharing models of zipcar, u-car-share, philly-car-share, hertz on-demand, etc. etc. Auto-autos actually make perfect sense for these fleets from an insurance perspective as well as an efficiency perspective, especially if the law will look the other way to driverless auto-autos.

Cab companies will love them as well. Cabbies will not. If there is any middle class left in the US in 10 or 20 years, they will probably be more likely to call an auto-auto to get to work than a cabbie.


First we replace the horse, then the rider.

We used to ride horses around. That lasted for what, 1000 years? It's still cool to own a horse and ride it around, for fun, I mean, but it's getting rare. Farming is done by robots, self-flying planes are almost there. Automatic cars are so close we can taste it. Tastes like robot.

Also see Brad Templetons stuff:

talk slides

website

We are all Agnostics now.

David Brin recently spoke at the Singularity Summit, a place where the attendees are, for the most part, transhumanists. They are there to discuss the creation of "small" gods - things just a little better than humans in some way, that will improve themselves.

I know that Mr. Brin recognizes that even these small gods, once self-improving, will be beyond detailed human understanding. He counsels the would-be creators of small gods that they should learn to better understand those who worship "large" gods - gods that create universes like ours, such as mentioned in the bible. To that end, his primary weapon is interpretation of the bible.

This creates a room full of agnostics.

No one who believes we can make a small god should believe we can understand a large god. As long as these people interpret the bible, they represent a belief in their interpretation, and therefore create a non-overlapping-magisteria. Basically, Brin removed the conflict between science and religion for those who will take his advice.

Brin is saying we need to rationalize in order to associate in order to survive. As it turns out, any suitable rationalization makes us nicer, more accepting people. I am proud that David Brin is one of us.

His final point discusses science as appreciation of God. He proposes that when children perform scientific experiments, their wonderment is a finer, more true appreciation of Gods creation than a wrote prayer or words extolling his greatness without really *appreciating* his great works. Scientific revelation is like someone saying to God, "I truly understand you, and I am truly impressed." and then proving it.

On the topic of appreciation, I have often thought that the universe is a self-organizing system that learns to appreciate itself.
But only for a moment. We are that spark of insane emotion burning brightly.
Humans are the love and the insanity in the universe, quickly extinguished.
Love oneself, respect others, a natural state of affairs, the best that can be hoped for, independent of scale, among parts of a whole.
The dream of a cohesive, thinking universe isn't a bad one. Better to be a cooperating part of any vastly superior force. No? Why not think of ourselves as the love in the universe?

What can I say? Humans rationalize compulsively.

Robot Arms Race

Continuing to catch up on Robot Futurism - I re-read Bill Joys article in Wired of over 10 years ago, Why the Future Doesn't Need Us - along with numerous rebuttals, references, and relevant discussions.

The central premise of Joys article is that we are creating dangerous stuff, and maybe we want to think about regulating ourselves. As GNR (Genetics, Nanotechnology, Robotics) tech advances, it gets easier and easier to destroy all human life. We need to considering slowing development of GNR tech, until we can properly defend against it's destructive potential.

Most of the rebuttals to his paper suggest that:

A) It's not that easy to create world-destroying stuff with GNR.
B) If the good guys don't figure out GNR tech, the bad guys will, so we need to go full steam ahead with fundamental research.
C) GNR applications are a moral imperative for quality of life reasons and the advantages outweigh the risks.
D) I don't like Bill Joy because he quoted the unabomber.
E) Anyway, you're right, we need to figure out how to regulate ourselves.

Most GNR sits precisely in the camp of biotech as a threat. Development cost will continue to shrink for weapons that could kill humans and spread quickly with total disrespect for borders.

My conclusion is that labs that study these technologies need to be reasonably careful. The threat isn't huge now, but it will be someday. As with Brains article on Robot Economics (see my last post) the threat is vastly more serious if we are looking a dislocation in the face, rather than a very gradual ramping up of world-changing technologies. No one seems to know which we are looking at. A "Center for Nanotech Control" should probably be funded at a level commensurate with the threat. Depressingly, that's not happening (I hope I'm wrong, I hate being depressed, so please feel free to correct me).

In fact, relatively little has been written on the topic of nanotech defense in the last 5 years. There was a flurry of activity around Joys article, and that was that. It may not have been helpful that most of the predictions that were made publicly by prominent futurists around that time were significantly off. People just seem to have gotten disinterested.

I guess we're just going to have to be happy with the amazing benefits of GNR and not think too hard about the dangers for a while. We'll live forever until we're dead. Wait...

Robot Economics

For my one reader, a quick summary of the last of Marshall Brain's articles in his robot series


Marshall is speculating 30 years out from trends present today.

Robots = Greedy Bastards

He concludes that the centralization of wealth will become extreme as automation (which he calls robots) puts people out of work. So he comes up with a number of taxation schemes to generate a welfare state when this happens, without wanting to call it a welfare state. Well enough. He doesn't take it further than that.

He is probably right about the unemployment issue, because unlike other technologies, robots will create robots. We are making things that are as good or better than we are at most things. We are not making tools anymore that require lots of humans to operate. That's really the fundamental point, most of us will not be needed in this industrial revolution, and why this is worth reading and thinking about.

Orwell is looking smart right about now

It is an interesting read, because it puts you in the mindset of considering 50+ percent unemployment. It is very hard to imagine a way to transition to that level of unemployment from 10 percent unemployment, without generating much more tax revenue. Any other state is a war zone. A fiscally conservative state with few social services would be immediately crushed by internal forces. We do have to consider a very high level of taxation ( aka collective control aka socialism ) in a future that rapidly adopts a high level of automation ( aka robotic workforce), or we have to move to an Orwellian model to repress our citizenry (which is where we are going).

It is, of course, implied that the same or higher level of productivity will be obtained with only half the human workforce, and that our governments are not configured to act in advance of rapidly decreasing employment. We will be in a real pickle. It sounds reasonable as you read it. Over fifty percent unemployment never ends well.

So Brain throws out some plans for socialism (although he picks a narrow definition of socialism to escape this much maligned word). He doesn't take it too far, just covers some possible methods for collecting taxes.

There may also be principles involved when constructing a capitalist-socialist-robot utopia.

For one thing, you want to keep incentives aligned toward innovation. Take only the amount required from the captains of industry to provide a reasonable quality of life for the unemployed. Arguably, you want the unemployed to be innovators, and to be free to innovate and create jobs for themselves and others, but you also want them to be somewhat hungry - their lives not full of stress, but lacking highly desirable comforts. So you would start with the need, and work backwards - the captains of industry need to raise enough money to support the unemployed at a reasonable quality of life, after that point, they can make their lives as ridiculously good as they like with any extra earnings. Taxation methods can then be derived from this principle.

Taking that to the extreme, you have to consider what happens when this morphs into a society in which all work required to maintain the basic necessities human life is done by robots, including maintenance of the robots, generation of energy required, etc. This will raise the bar of social welfare to a fairly high level. It's a long way out, and quite a speculative story, but possible at some point. A lot of fundamental industries will run themselves, and the captains of industry themselves will be outmoded. Every human will be focused on innovation and new industries, as the old ones become, basically, part of nature. O.k. well, maybe I'm an optimist.

Overall, I found Brains robot articles a good way to encourage a geek like myself to think about the future of economics. What would you do for a living if you had your basic needs met for life, but still had the opportunity to make anything of yourself if you worked hard at it? The answer is, ultimately, you would seek your potential (metamotivation as per Maslow). I know I am metamotivated and I find others in the same state to be more fun to hang out with than those who are not. What model makes that world possible? Not the one we have when unemployment hits 50 percent.

And what about those whose metamotivation tends toward evil? The more things change, the more they stay the same. Hopefully our robot overlords won't have time for that shit, and I'm definitely not risking my exoskeleton for their greedy asses.


Marshall also wrote the following two articles on the same topic:

http://marshallbrain.com/robotic-faq.htm
http://roboticnation.blogspot.com/

Putting most things in my wiki - richbodo.pbworks.com

I have a wiki now.

I added notes on my trip to sierra leone there, which was interesting. I'll be adding to it, but the story is all there, including pictures, like these:

A few weeks back a lady from the BBC was interviewing us at Dana Street.

Well, I finally got a chance to listen to the blog post she made. I learned a little about the area myself so thought I would share it. In particular, there is a wonderful interview with some of the Olsons. Here it is. Have a listen. (Update: looks like the podcast download is broken. Reported it. I'll update this if I can find a fixed link.)

It reminded me how lucky I am to have been brought up here.

I may complain that it is impossible to find enough Obscure Sports in Silicon Valley to fill a quarterly blog post, but no one will stop me from making my own. Incidentally, after doing a little research, I have to say that San Francisco's little pinky toe forgets more about obscure sports every day than Silicon Valley ever knew.

Listening to that interview might also make people who grew up here a little sad considering what has been lost in the area.

I'm still finding cool things here, and I took some pictures of one of them. The Palo Alto Electric Car Show is held at Palo Alto High School every year, and for the last three or four years I have remembered to go. It's about 75% homemade vehicles and 25% commercial stuff, and there is always a test track where you can play with the smaller/slower things, like scooters, or...homemade joystick-controlled automagically balancing lawn chairs...



Daily Commuter Solar Trikes:



Model (T?) Conversions:



And a wildly fun electric bike-board product that rides like a combination of motorcycle, skateboard, and surfboard:



Tom has a great opportunity if he can market that thing. It's called the Zummer. I got to ride it and it's a blast and a half. I was grinning like an idiot the entire time. I could potentially even commute with it on the train. I hope all his business needs is some marketing money and a little economy of scale.

That's really the meat of it. Just incredibly neat stuff. Terrific fun. Even practical in some cases. Most of it built by entrepreneurs and enthusiasts on a shoestring. I didn't meet anyone who wasn't discussing their designs, or open to it.

I hope I'm not being too dramatic here. I really felt like I started to understand what Charlie Olson said. We don't have a lot of farms or orchards anymore. We have smog. And we have this.

Other stuff:

The guy who sells the conversion kits for my model of miata was there, too, but the price is still a bit steep (read: I'm still not wealthy). Still, I can dream. I took a few snaps of the commercial products as well...

Tango:



Mini:



Tesla:



I forgot to take a pictures of the Smart. It may not have been one of the factory conversions anyway. However, I did see a Cheap Copy of a Smart From China that the owner had to rebuild for safety reasons that would be embarassing to the guy in the electric lawn chair:



If making stuff was a sport, I could blog the Silicon Valley Making Stuff Sports Daily and I would have to become a cutthroat editor just to shrink it down. I used to go to more than one geeky "meetup" per day when I was in between jobs in the 90s, and we've come a long way from those days.

Script and Screen

At work we use script and screen for co-development and training.

If you want to work with others in a command line environment and don't use these yet, then you should definitely read this post.

Here's how we use it:

The first thing we do when we work together is we all ssh into the box we will work on.

Then we have the person driving start screen, a terminal multiplexor, and then script, a command logging tool.

Then everyone else logs into the drivers multiuser terminal session run by screen by typing screen -x, and can take over driving when needed. We all can read and write to the same set of terminals, and detach or reattach to the session as we come and go.

When we're done, we copy the drivers /home/driver/typescript file to someplace where we keep old training files like /backup/it/training/how_to_debug_that_thing.txt.

NOTE: screen can be used without script to do a similar job, and script can be used without screen to do a similar job. We just happen to use both.

Script:

Just type script to start it. It will start logging to your home directory in a file called typescript.

If you don't want to use screen, and just want to watch what someone else is doing, you can also try the -f option to flush output after each write. This is nice for telecooperation: One person does ‘mkfifo foo; script -f foo’ and another can supervise real-time
what is being done using ‘cat foo’.

Screen:

Setting up and using GNU screen as a collaborative development environment (pay careful attention to the slashes).

Your user is peter, and you want to pair program with user mike.
1) Install GNU screen on the server and learn the ScreenBasics.
2) Drop the following two lines into /home/peter/.screenrc:
multiuser on
addacl mike
3) Execute the following two commands to allow mike to use your screen sessions:
chmod +s /usr/bin/screen
chmod 755 /var/run/screen
4) Peter is already logged into a screen session
5) Mike can type:
screen -x peter/
6) Peter and mike can now look a the same screen windows/terminals and share the same i/o

ScreenBasics - commands you will actually use, in the order you will probably use them

'screen'	start screen session
'Ctrl-a c'	create a new terminal
'Ctrl-a "'	list the terminals in this session
(then hit the number of the terminal you want to switch to and hit enter)
'Ctrl-a Shift-a'	rename a terminal
'Ctrl-a F'	flush the screen when it gets screwed up
'Ctrl-a k'	kill a terminal
'Ctrl-a d'	detach from session
'screen -r'	re-attach to a screen session
'Ctrl-a S'	make two terminal panes in the window
'Ctrl-a Shift \	split the screen vertically
'Ctrl-a Tab'	next pane in this window
'Ctrl-a Q'	go back to one pane, current window

Other Screen Notes:

1) If you don't want to use script, you can get screen to record sessions as well. I think it's 'Ctrl-a H'.

2) The default screen key bindings collide with readline and emacs commands. I should look into remapping them someday.  Hit Ctrl-a-a to go to the beginning of a line.

3) Record and play back real-time textcasts with scriptreplay as follows:

script -t 2>timingfile testscriptfile
scriptreplay timingfile testscriptfile

Note: scriptreplay is a tiny perl script that was left out of most red-hat derived linux-util packages to date. You can get it from a debian derived distro or find it here.

4) If you are using MacOS, you are behind on every open source software application in existence.   You will have to compile and patch screen, script, emacs, and whatever else you use to get a modern functionality set.

5) You can access the scrollback buffer by hitting Ctrl-[.  After that point, the normal vi-like scrolling commands work i-j-k-l, Ctrl-u-b-d-f.  Hit esc to get out of the mode that allows you to scroll.

Links:

** The homepages for script and screen (for GNU/Linux users):

Script is in util-linux: ftp://ftp.kernel.org/pub/linux/utils/util-linux/

Screen: http://www.gnu.org/software/screen/

** Some of the better articles on screen:

http://www.sun.com/bigadmin/features/articles/gnu_screen.html

http://www.kuro5hin.org/story/2004/3/9/16838/14935

http://aperiodic.net/screen/terminal

http://aperiodic.net/screen/multiuser

http://www.linuxjournal.com/article/6340

http://www.softpanorama.org/Utilities/Screen/screenrc_examples.shtml

Patching Screen for MacOS: http://old.evanmeagher.net/2010/12/patching-screen-with-vertical-split-in-os

Silicon Valley Obscure Sports Quarterly Review - Q208

Welcome to the first issue of SVOSQR. In Q2 I thought I would report on "up-and-coming" obscure sports (read: I'm lazy and the sports on meetup.com are not currently at the bleeding-edge of obscurity). Meetup.com links, pics and summaries follow.

Kickball

Friggin Rocktackulous. About 20 people show up. Pleased to find that although I am now older, heavier, and weaker, I can still get that satisfying PWING! sound out of kicking the ball and deforming it into a lively ovoid before the other team catches it. Margaritas afterward in Willow Glen. Surprising amount of blood involved.

Ultimate Frisbee

Super friendly pickup game at Eagle Park in MV. Show up to learn ahead of time. Usually works best if you pick someone approximately your own body shape to cover. Couldn't tell if we were keeping score - could be that I was unaware of the scoring mechanism, but I prefer to think that it's really that casual of a game. They meet in Sunnyvale, too.

Dodgeball

Silicon Valley is in desperate need of Dodgeball leadership!! Things are getting so bad that I have had to find pictures from other sports. The one silicon valley dodgeball meetup was held at Sky High, where they have a dodgeball room made out of trampolines (walls, ceilings, etc). Mixed group with lots of little kids and a few adults. It felt a little unfair to whale on the kids with a red rubber ball, but the realization that I could actually make them rotate on any one axis with a dodgeball strike kept my interest. Apparently, it's next to impossible to get old people to show up to a Dodgeball game. I tried to help and bring in a few folk, but could only drag one brave soul in with me. We were about half the group. Of course, now that the meetup group has gone inactive, there are dozens of interested people pledging to help. Will you be our Dodgeball leader (left picture - the guy who's winning), or will you be woefully unprepared for the next random strike (right picture - that is you).

A warning: There is not enough research to determine what obscure sports do to our bodies, exactly, but we do know that they fully condone the Bush adminstrations definition of torture. Any single obscure sport, picked up for the first time in maybe-ever, will find and cruelly torture muscles that you didn't know you had for weeks. Middle-aged humans are supposed to be dead, and therefore have not evolved to handle more than one attempt at obscure sports per month. Don't do it! But do let me know if you find an obscure sport in silicon valley that you would like me to try.

Thinking Deeply about Concentrated Solar

I always have Polya's How to Solve It on my desk.

There is this one little part of it that I think everyone ignores, at first, in the "Devise a Plan" section:

"If you cannot solve the proposed problem ... Could you imagine ... A more general problem?"

Inside, when we read that, we think, "Are you friggin' kidding me? A bigger, more general problem? HaHa! Ged ouuuda here! I'm a-simplifyn'!" and quickly skip ahead.

I think Divide and Conquer is the first algorithm that comes to our minds. But it makes us think small - we miss data and cannot apply economies of scope.

It's not like we planned to do that.

I think many people initially plan to look at problems through the end of the process, trying to consider all players, evaluating their historical behaviour and setting up a migration path for them, coming to some solution that takes into account as much data as is useful. (Some people might call this "systemic thinking")

But we get myopic too quickly. We get tired. We find an interesting bit and get focused on the minutia, or start arguing whether a given solution to one part of the problem is feasible or not, and we can't give it up.

I was feeling this way about Global Warming. I got bogged down in studying how amazingly unsuccessful activists are at manipulating governments. Turns out, that wasn't one of the more interesting bits.

And now we return you to our previously scheduled feature on Concentrated Solar:

As Jamais Cascio puts it, the Earth will be just fine, it's humanity that is screwed.

Humanity won't make it without quickly shifting to new forms of power. However, I think we now have at least one reasonable roadmap. You can read all about how this technology is can solve our energy problem lots of places.
Who could implement this the most quickly?

Oil companies and our current power monopolies don't want to be replaced. Want to avoid a fight with them? Give them an advantage in concentrated solar. Just get them the hell out of the way and start them working on this problem. No time for a fight, here.

More specifically, the world has enough sunlit land and money to solve this problem 100 times over. The first set of goodies (We include one 100-year land lease and one suitable tech grant per set (but no batteries)) goes to our current oil and power conglomerats. That should be enough to please any stock holder, line any pocket, and guarantee implementation.

The next 99 sets go to entrepreneurs, which should also help.

You win, oil companies. No one has to die over this. Nice big carrot for you. Just get it done.

Of course, if they can't do it, well, first your land lease will get pulled if you can't get a few PetaWatts to market inside 10 years, but more importantly...if you thought all humanities carrot was big...even weilded in our death throes, that stick has got to be devastating. And, frankly, we never liked you anyway.

I'll write my congressman for you! Good luck!

Debunking the Technological Singularity

I have been arguing, at my local coffee shop, that
an empathy test needs to be developed for computer software.

The Empathy Test would be unlike a Turing Test or a Voight-Kampf machine in that the purpose is not to determine whether a thinking machine is human. The purpose is to determine whether a thinking machine is a good match for human society.

Simply fooling a human into thinking that you feel his pain does not make you empathetic. I argue for testing a broad definition of empathy that is more useful to intelligent beings interacting in a civilized society. The pain of others need not be recognized by the subject. The pain must be felt as psychic stress in the subject. The program/subject, therefore, must be cognizant of it's own mortality, and pain must be a real threat to it's well being, as it is to us. Those guys in the asylum aren't exactly in endless loops, but they certainly have a few rogue processes. So the Empathy Test would be, in a sense, a destructive one that arguably mimics it's function in humans.

With luck, these empathy-equipped AIs will confirm the game-theoretic benefits of this feature and propogate it up to their designs. They will understand that this feature is for the preservation of lower races - an endangered species act, if you will. Alternately, it might just piss them off and subject us to summary disintegration. After all, how many programs have you killed today? How many lower species? On a macro scale, are we failing the empathy test?

In any case, I have found today that the point is moot! Recent historical research uncovers striking similarities between our past intellectual follies (SINGULARITARIANS MUST CLICK ON <-THAT LINK) and our current failed delusions of technological grandeur.

Clearly, I was entranced by the mental crack that is the singularity novel. For those of you with the same addiction, you can shoot up with this open content novel. Confirmed grade A stuff. But please, don't share dirty algorithms.

Rock genre terminology considered asinine

Recent craigslist internet engineering jobs, exclamation point:

** Rock Star (Affordable) Flash Developer Needed ASAP!

** Seeking a rock star DBA for our production environment!

** Great Opportunity for a Rock Star Intern!

Before interviewing for these positions, be sure to comb your mullet and put a cucumber down the front of your spandex pantsuit.

On any given day, about 30 craigslist job postings in my area are looking for "Rock Stars". They are all really looking for "programmers", so, as I am about to enter the job market, I happen across them with increasing frequency.

I have to ask myself: How the heck did "Rock Star" eclipse "productive"?...and why haven't other industries caught on? Where did this trend come from?

No, Captain Klaa(pictured) has not been going around writing corporate dress codes, and yes, perhaps these HR departments are a bit too exuberant(see below). But that's not why I'm looking into this.

I don't have a problem with the use of the term "Rock Star" per se. I don't want to make fun of anyone. I enjoyed Spinal Tap as much as the next guy.

No, I'm looking into this because the trend really got on my nerves. I couldn't put my finger on why that was; so I explored it, and learned something.

I think these employers are trying to do two things:

1) Find programmers that are very productive (top 1% preferrably).
2) Imply that they will treat them well.

What I think they really want is to:

1) Attract programmers who know they are very productive and easy to work with.
2) Imply that they their team is productive and easy to work with.

If you have recently read Joel Spolsky, you may feel the need to replace "productive" with "gets things done" - I won't feel bad.

Thinking about how these employers can get what they want, I found what I really want: a productive, easy-going team. The heart of my problem with a team of Rock Star's is that it's so far from that ideal.

I asked roughly the same questions that employers ask. It was so informative to me that I would recommend it to anyone looking for a job. Here's what I came up with:

1) How do I know I am productive?:

Well, I can measure it.

The employers who are looking for rock stars have probably read that timely tome - The Mythical Man Month, in which the productivity of programmers is said to vary by an order of magnitude by skill alone. Well, this is one of the things that is still true in that book, but not in the way most people probably think.

Most people know how to measure their own productivity. They can describe what they have produced, and discuss it at length. "I developed X in Y weeks and I here it is", etc.

To most employers, your past productivity in the domain of the job in question is the primary measure of your likely future productivity.

Most people are o.k. with that. It's just common sense that you improve at a task with experience. This is hard to measure, but anyone who plays chess might assume that from competent to expert there may be 100 or 1000X improvement in most fields to be gained by experience. As it turns out, this is a highly contentious assertion. No one knows how much experience really has to do with it.

In absence of a candidate that is productive in the required domain and easy to work with, an argument can be made that a candidate that is trainable and easy to work with will do.

Trainable is usually a secondary requirement, and you can measure it the same way you measure productivity, based on past performance. In the case of a programmer out of school, trainable may be the only applicable requirement.

The more experience and intelligence the better. That's nice, but...

2) How do I become more productive?

Most people have a decent understanding of the factors upon which their productivity depends. It may vary from person to person and purpose to purpose. For me, right now, it consists of four things that I seek to improve upon daily.

Domain experience:

Produce more. Focus on one job for a while, and you will become an expert. I may be an order of magnitude more productive at writing support scripts or IVR applications than I am at writing web applications. At some point in the near future, however, I expect this situation to reverse. This just makes sense. I am working on web apps every day. If I want to get good understanding the core concepts of a framework and writing large programs in that framework, then there is no substitute for doing that.

Tool expertise:

Programming tools are made from software and improve productivity. New and better tools come out every day. If I spend time every day learning tools, I will improve my productivity. Commit to this, and you will improve.

Mental and physical health:

Stay healthy. My levels of pain, discipline, and energy vary based on my lifestyle. I get up every morning and excercise, clean up, hug my wife, drink coffee, and solve a puzzle. If I don't get a healthy start to the day, or if I don't take care of myself in other ways, I am sure my productivity will suffer.

Environment:

As a programmer, I work best either in a quiet office or pairing with one or more team members at about the same skill level. I can rank environments for productivity as well. The library is fine, a coffee shop is not so good, and home is right out - too many non-work distractions. Nothing compares to a serious, conflict-free, office work environment.

All I can do here is be aware of the quality of my environment, which varies from job to job. Experimenting with environmental improvements can help, as do these helpful techniques for tough environmental situations.

Kaizen.

3) How do we know when someone is easy to work with?

Probably the most important and tricky part of the hiring process, for both the employer and the candidate, is measuring soft skills.

If a candidates tech skills are not up to par, you have to train them. Fine.

Employees with very poor soft skills can destroy an entire company. Experienced employers and employees know this. So what we are looking out for here, are the bottom few percent of the employee pool in soft skills. No one wants a report or a manager like that.

My soft skills can be measured, and so can those of any company. We just ask each other how we handle situations that matter, and check references.

For my part, I have to ask myself tough questions: How many co-workers have I helped, how many have I hindered, what tough problems have I solved with them, what have I learned, and how can I improve?

So how can I improve? Aside from discussing this with past co-workers, knowledge will help: PeopleWare.

It can't hurt to improve, but I think most people are probably o.k. on soft skills. Still, the better adjusted the team, the better for everyone.

And now, a word to folks advertising for Rock Stars:

I don't expect hiring managers to read this, but...

If you would like to project an image of your programming team, a gathering of Rock Stars is probably not what you want. Rock Stars are people who produce hit songs and are worshipped only as long as they keep pumping them out. A collection of rock stars are not likely to work together long.

Sounds like solo-superman programming while surrounded by dysfunctional sycophants and confrontational peers. Probably not what you meant. If that is really what you meant, then I suggest a different perspective.

I could suggest a different analogy...A construction crew is a closer match than a Rock band. It could be that your construction crew wants to design and build the next Guggenheim and drink beers after work, but it's a construction crew all the same.

Better yet, drop the analogies. Mention your team, your management style, your process and your product. Mention that you would like applicants to discuss what they have actually produced, providing examples where possible. Maybe lead with something like: "Highly productive team seeks C programmer" - or whatever actually describes your team and what you are looking for.

Mention that soft skills are important up front. This is a very good sign.

And...Rock on.

Swig-C-Ruby-Pointers Hello World

I'm trying to write C libraries to do some things on the Mac that are not easy to do with Ruby. I found that I had to read several documents and experiment around a bit with SWIG to call a C library function that took a pointer as an argument. This is just one of those things that should not take that much time to figure out.

C library functions that take pointers as arguments and return ints (that covers most of the c library functions I have written) ultimately return an array to Ruby. Uncovering that little factoid, and the swig interface format required to make that process work, was the tough bit.

So, I'm taking a few more minutes to make sure you don't have to do that (and to make sure I don't have to do that long after I forget about this exercise).

Step Zero: get swig.

I install all open source software on the mac with fink. Fink Swig

Step One: Copy my example code - inline below.

I provide what you need to make a ruby callable module called Example that contains the C function SimpleFunc() that you will call with a little ruby test program called testsum.rb.

user-64-9-234-209:~/src/c/simplelib richbodo$ ls -l
total 48
-rw-r--r-- 1 richbodo richbodo 61 Oct 12 16:24 example.i
-rw-r--r-- 1 richbodo richbodo 42 Oct 12 15:52 extconf.rb
-rwxr-xr-x 1 richbodo richbodo 90 Oct 12 16:41 get_it_done.sh
-rw-r--r-- 1 richbodo richbodo 46 Oct 12 16:36 sum.c
-rw-r--r-- 1 richbodo richbodo 24 Oct 12 15:46 sum.h
-rw-r--r-- 1 richbodo richbodo 67 Oct 12 15:57 testsum.rb

Three of these files you already understand:

sum.c - your library

int SimpleFunc(float *modify_me)
{
*modify_me = 5;
return 1;
}

sum.h - your library header - not used by swig unless you tell it to - don't need it here.

testsum.rb - ruby program that calls your library

require 'example'
afloat = 2
# The first return value gets set as expected in first_returnval.
# However, SWIG puts the float in a second return value.
first_returnval,second_returnval = Example.SimpleFunc(afloat)
puts "Your float is #{first_returnval}, and the return value is: #{second_returnval}"

The other three files are specific to getting your swig library going:

• example.i - a definition of your library for swig in swigs definition language. INOUT is a SWIG typemap, so typemaps.i is required.
  

%module example
%include "typemaps.i"
%apply float *INOUT { float *modify_me };
int SimpleFunc(float *modify_me);

• extconf.rb - a ruby program that creates a makefile for your library

require 'mkmf'
create_makefile('example')

• get_it_done.sh - the commands that you run to generate a ruby module from your c library using swig

#!/bin/bash
rm *.o
rm *.bundle
rm wrap_example.c
rm Makefile
swig -ruby example.i
ruby extconf.rb
make
sudo make install
ruby testsum.rb

Step 2: Run the get_it_done.sh script to build and test your module. (it will ask for your password to install the library)

user-64-9-234-209:~/src/c/idlerlib richbodo$ ./get_it_done.sh
rm: wrap_example.c: No such file or directory
creating Makefile
gcc -fno-common -g -O2 -fno-common -pipe -fno-common -I. -I/sw/lib/ruby/1.8/i686-darwin -I/sw/lib/ruby/1.8/i686-darwin -I. -I/sw/include -c example_wrap.c
gcc -fno-common -g -O2 -fno-common -pipe -fno-common -I. -I/sw/lib/ruby/1.8/i686-darwin -I/sw/lib/ruby/1.8/i686-darwin -I. -I/sw/include -c sum.c
cc -dynamic -bundle -L"/sw/lib" -o example.bundle example_wrap.o sum.o -lruby -ldl -lobjc
install -c -p -m 0755 example.bundle /sw/lib/ruby/site_ruby/1.8/i686-darwin
Your float is 5.0, and the return value is: 1

Step 3: Look at the five new files you just created, and understand what they do:

user-64-9-234-209:~/src/c/simplelib richbodo$ ls -l
total 152
-rw-r--r-- 1 richbodo richbodo 3009 Oct 12 16:42 Makefile
-rwxr-xr-x 1 richbodo richbodo 16316 Oct 12 16:42 example.bundle
-rw-r--r-- 1 richbodo richbodo 61 Oct 12 16:24 example.i
-rw-r--r-- 1 richbodo richbodo 17695 Oct 12 16:42 example_wrap.c
-rw-r--r-- 1 richbodo richbodo 5744 Oct 12 16:42 example_wrap.o
-rw-r--r-- 1 richbodo richbodo 42 Oct 12 15:52 extconf.rb
-rwxr-xr-x 1 richbodo richbodo 90 Oct 12 16:41 get_it_done.sh
-rw-r--r-- 1 richbodo richbodo 46 Oct 12 16:36 sum.c
-rw-r--r-- 1 richbodo richbodo 24 Oct 12 15:46 sum.h
-rw-r--r-- 1 richbodo richbodo 644 Oct 12 16:42 sum.o
-rw-r--r-- 1 richbodo richbodo 67 Oct 12 15:57 testsum.rb

• example_wrap.c - created by the swig command, this a c wrapper for your library with a bunch of additional wrapper functions that translate your functions and data into ruby callable functions and data. see chap 21 in the pickaxe.
• Makefile - this is the makefile that was generated by extconf.rb. It will compile your library and that wrapper and make the mac bundle for you.
• sum.o - the object file generated from sum.c
• example_wrap.o - the compiled version of example_wrap.c
• example.bundle - mac osx stores code in bundles, so make makes one and puts it in your site-ruby directory when you type "make install"
  

So that' it. You make that swig interface file, you call swig. Example_wrap.c gets created. You make the extconf.rb file and run it. A makefile gets created for you. You make your project by calling make and you are done.

References:

• Chapter 21 in the pickaxe book.
• The ruby swig page: http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn5
• The swig basics page: http://www.swig.org/Doc1.3/SWIG.html#SWIG_nn3
• Apple Developer Docs: http://developer.apple.com/documentation/
  

Method for organizing volunteer efforts

The Cancer Beatdown

At it's simplest, it's just a task manager for researchers who would like to utilize volunteers in the search for a cure. For volunteers, it's a way to get their hands bloody at cancers expense. "No, you won't cure cancer, but maybe once in a while, you can come on over here and get a few good licks in". And, yes, I'm going to continue to refer to fighting cancer in more colorful ways than just "fighting cancer". It's quite satisfying.

No money, no donations of protons or neutrons. Just electrons, photons, and elbow grease. This isn't a site for beggin; it's just a site that invites others to get in on the beatdown while the beatin' is good.

The idea is based on the premise that the pool of smart, motivated volunteers is underused and underorganized by the cancer research community. In other words:

1) there are a lot of very smart people who would get a profound satisfaction from knowing that they contributed in some small way to developing a cure for cancer.

2) there are a lot of researchers who will buy that exposing some of their tasks in a sensical way to an army of smart people who want to work on them could speed their work.

One case in which this might work is:

A researcher needed to develop a significant new body of software, and was looking to task some portions of that development out to volunteers in a test-driven manner - "I write the tests, you guys make as many as you can pass before I do".

I recently participated in agile development of this sort, using pivotals excellent agile project manager, which is influencing my thinking on this type of application.

The basic site workflow for Cancer Beatdown is as expected:

1) Site manager invites a few researchers who are doing promising work.

2) Researchers post the task, whether it's stuffing envelopes on-site or coming up with a new way to search a massive database for correlations. The required form of the solution is also specified.

3) Volunteers propose solutions.

Some sensical reputation/core user policies would be adopted - i.e. Researchers or the site manager can invite more researchers, after vouching for them. Volunteers are invested in performance.

Personally, I would love to volunteer for some well-defined and promising projects in which I could invest one day per month. I know some people who would never consider such a thing, and some that would invest considerably more time. What do you think?

Selling on Ebay

Just found this old draft of ebay instructions. If you are going to start selling stuff on ebay, copy these conditions of auction and live by them, it will save you a lot of time and money. The one adjustment you will have to make regards buyer feedback. I stopped selling on ebay when they stopped allowing negative buyer feedback. You can just pull or rewrite those three lines:

Conditions of Auction:

You must agree with our Conditions of Auction prior to bidding. Please do not bid if you do not agree to these conditions.

Shipping Policy:

You will pay shipping as described in the auction.

To avoid damaged goods and provide timely shipment, we will ship as follows:

We only ship air, on-line trackable, on-line signature-required, and fully insured. Internationally, we only ship USPS Express Mail Service.

We do not ship ground by any carrier.

To ship, we require your name, confirmed address, and valid phone number.

We reserve the right to cancel the transaction if we cannot reach you by phone.

Payment Policy:

To avoid fraud, we will ship as follows:

We require payment prior to shipping. We ship within seven days of receipt of payment, usually much faster.

We do not accept payments by check, moneygram, western union, or partial payments of any kind.

Return Policy:

You can return the product within 30 days of receipt if not satisfied for any reason subject to the terms and conditions below.

*** You agree to:

Fully insure any returned item, to the full value of the auction, and to ship via an on-line, trackable, air service.

Provide on-line tracking information on date of shipment.

You will be fully refunded within two days of receipt of goods that are in the same condition they were in when shipped to you.

You agree that we may deduct any costs associated with damaged or missing goods returned from your refund.

Right to refuse sale:

To avoid scams, we reserve the right to refuse sale to buyers with:

* No Feedback
* Poor Feedback
* Private Feedback
* Unconfirmed Shipping Addresses or incomplete contact details.

Service Policy:

No service is provided. No service guarantees are provided.

We will, on a best-effort basis, answer questions via email anytime, or via phone by appointment.

We don't mind answering any questions at all, and we typically get back to you same-day.

Again, those are the conditions of sale. You must agree with those conditions prior to bidding. If you take exception with any of those, please do not bid, or contact us before you bid so that we can work it out. Thank you!

Telepathy UIs

Here is a rundown of "brainwave" game controllers. (bonus idea included)

I first heard about an implementation of one of these in the early 90s by a company called "the other 90%" run by former Atari founder Ron Gordon. AFAICT, very few were sold. Anyway, I still believe it worked. So I had a discussion with someone about this last night. He didn't believe it. Here is some history on the topic:

1974 - EEG control (Sobell - VA Neuropsychology Lab) - Still looking for the actual research study.

1996 - CNN reporting on The other 90% (Atari's Ron Gordon) MindDrive application:

2004 - BBC reporting on MIT implementation

2006 - MSNBC interviews Don Clark of Wall Street Journal reporting on Emotiv game controller.

The reason this works is twofold. First, the composite electrical activity of your brain can be measured and decomposed by frequency and a half dozen clean signals can be discerned. I would call these brainwaves but, according to wikipedia, that is frowned upon for some reason. Second, these patterns change according to thought activity, which is under our control.

Anyway, if one reads about non-invasive brain computer interfaces, it becomes apparent that there is plenty of research in the area. There are also several successful and useful implementations. Not all of them EEG based.

Bonus Idea:

Wouldn't it be cool if:

My jabra bluetooth headset could also send composite brainwave activity to my wildly powerful cell phone, or maybe even my uber-powerful computing cluster at Name_Your_Favorite_Company? In that case, I could generate messages by thinking, while the headset reported the current character.

I have heard somewhere that these game controllers allow you to manipulate 6 tokens based on training them to understand when you think in certain ways.

The first idea that comes to mind is the concept of scrolling through groups of tokens. Lets try sending telepathic messages to each other with just the thoughts Up/Down. (After taking a look at some EEG decompositions, two tokens is, for some reason, quite believable to me.)

Me: Think Up
Headset Audio: "A through E"
Me: Think Up
Headset Audio: "F through L"
Me: Think Down
Headset Audio: "F through L it is - F"
Me: Think Up
Headset Audio: "G"
Me: Think Up
Headset Audio: "H"
Me: Think Down
Headset Audio: "H is the first letter."
...

You get the idea. So you form some text, which gets sent to whoever you are configured to send this stuff to. This gets converted to speech and played back in their headset. They, in turn, send you text with their bluetooth audio/telepathy headset.

Not at all the best UI, but if you can really train yourself to manipulate six binary tokens, the sky is the limit. Can't you just see schoolteachers spectrum-jamming bluetooth signals?

I would appreciate a study that shows a Non-Invasive BCI that was reliably trained to a larger number of tokens. Until then I'll limit my imaginings to two.

Even with two, it is easy to see that the combination of mic/earpiece/brainwaves is powerful. Imagine setting the context with voice: i.e. saying "computer doors" or "computer radio volume", then just thinking up or down to lock or unlock the doors, or control radio volume.

I hope that no one patents this crap and charges exhorbitant amounts of money for this type of tech.

Update: I have to add this link to a cool open-source EEG hardware project: http://pceeg.wikia.com/wiki/Main_Page

You would be surprised what you can find in Open Hardware these days. I will post specs of all the components of the device I describe if I have time. There should be prior are for every component.