F3EL7-T3YL2-MBN5P-ZQI6R-YE8PI
Ever type that into a pop up box on your computer when installing software? If not, you’ve never installed anything from Microsoft (or many other companies) – at least not legally.
This morning I was copied on an email from my partner Ryan McIntyre to a company we are talking to about funding that said:
“I use Pro Tools and other pro audio software regularly and since the SW is quite expensive, the SW vendors go to great lengths to use copy-protection, and most audio plugins and applications (and there are dozens) have some sort of authorization code scheme, ranging from friendly to downright byzantine. It drives me nuts, but my constant exposure to it means I’ve formed some opinions about what is “easy” when it comes to entering authorization codes. The easiest plug-ins (authorization-wise) in the audio world use alphabetical codes broken up into strings of words, so instead of the longs strings of numbers, you get long strings of words, which are much easier for a human to enter without a mistake. A couple code examples might be:
HOUSE-BIRD-TRUCK-DRUM
FLINT-TRUE-SWORD-CALLYou get the idea. I’m assuming third-part auth-gen packages must exist to generate codes like these that give you a big enough address space yet also make guessing authorizations relatively difficult. And that you could relatively easily change your process at the manufacturer for associating MAC addresses with device IDs.”
I prefer auth-codes that are haikus. I wonder if there’s a patent on this?
Wow – Operating System Interface Design Between 1981-2009 is awesome (thanks Dave). It is a screenshot from every major graphical OS since the Xerox Alto. Some old favorites of mine include the Apple Lisa (1983), the Amiga Workbench (1985), Geos (1986), NeXTSTEP (1989), and OS/2 2.0 (1992). At some point in time I had a computer that ran these and/or installed them on a computer of mine.
As co-chairman of the Colorado Governor’s Innovation Council, I’ve been regularly exposed to the acronym ICT. It’s not a familiar or comfortably one to me and I chronically call it “CIT” or expand it incorrectly.
I am looking for a phrase that covers IT + Communications + Software + Internet. These are the four components of ICT that drive a huge chunk of business activity and innovation in Colorado. In my world as a VC, I call this software + Internet, but that doesn’t cover the full landscape.
My friends at Silicon Flatirons have put together a Wiki titled Innovation in Colorado and Information and Communications Technology (ICT) where we are compiling the history of the ICT ecosystem in Colorado. If you have participated in this in any way, feel free to jump on and add your thoughts and facts.
What’s your favorite phrase or acronym for this?
In response to my post The Beginning of the Real Mess in the Clouds I received several emails / twitters / comments saying some variation of “these are easy problems to address” or “the cloud computing providers will quickly fix all this stuff and even my mother will be able to use cloud computing.”
Uh huh. Here’s another one. We’ve got hundreds of these already and it has only been 75 days since we started the company.
A heads up to anyone attempting to connect to Slicehost using Java:
There is a subtle bug in the JDK (including 1.6), such that long username/password combinations (like the long username used with the Slicehost API) are encoded improperly in an HttpURLConnection. If you include the username in the URL, you will get a 401 error; if you attempt to use an Authenticator you will get an exception from Java that there is an invalid line. The solution is to override the base64encoder and set the authorization property manually OR potentially use the Apache Http client rather than the built-in JDK client.
Here is the basic code for the solution:
static final String Credential = "my Slicehost API username here"; // the part before the @
class LongLineBase64Encoder extends BASE64Encoder { @Override public int bytesPerLine() { return 1024; } }
…
URL ServiceURL = new URL("https://api.slicehost.com/slices.xml");
HttpsURLConnection Conn = (HttpsURLConnection) ServiceURL.openConnection(); String EncodedUsername = (new LongLineBase64Encoder()).encode(Credential.getBytes());
Conn.setRequestProperty("Authorization", "Basic " + EncodedUsername); Conn.connect();
What part of mess wasn’t I clear about? Oh, and my mother is really smart, but I’m betting that “The solution is to override the base64encoder and set the authorization property manually OR potentially use the Apache Http client rather than the built-in JDK client” doesn’t mean much to her.
We made a seed investment at the end of last year in a company called Standing Cloud. They are working on a set of application development and deployment tools for cloud computing that build on some of the ideas in the posts What Happened To The 4GL? and Clouditude. They’ve spent the first quarter of 2009 testing out a series of hypotheses we had concerning issues with Cloud Computing as well as building an first release of their cloud deployment tool.
Things in cloud computing land are much worse than our hypotheses, which were already suitably cloudy. Following is a simple example of a real issue that even a non-techie will be able to understand.
When starting cloud server instances via an API, it’s important to realize that the instance may become "available" from the perspective of the cloud provider system before all of its standard services are running. In particular, if your automated process will connect to the instance via ssh or http, it will be at least a few seconds after the instance appears before the applicable service is available. This problem generally does not arise if you start servers manually, because by the time you see that it is running, copy the IP address or domain name, and type the command or browser URL to connect, the services are usually ready. Possible solutions include:
- Wait a safe, predetermined amount of time. This is the simplest, but obviously is not robust.
- Attempt to open a socket on the applicable port (e.g., 22 or 80), and do so in a loop, with a brief sleep between attempts. These attempts will fail until the service starts, and you should have the loop time out after some period in case there is a deeper problem with the instance.
- In a similar loop, directly attempt to connect to the service. Depending on the SSH API you are using, this may have additional overhead or abstraction that is better avoided, but it is robust and likely to work.
A related, but more insidious issue is that the sshd authentication services are not necessarily available as soon as sshd is available on the port. Thus it is possible to connect to the service and have authentication fail, even though everything should be in order. A sufficient wait period or a loop is once again the solution. However, if the loop wait period is not sufficient, you may attempt too many failed authentications and lock yourself out of the system. Thus this approach has no fully robust solution aside from an empirically safe wait period either prior to authentication or in the loop wait.
Clearly these problems are tricky to diagnose if you are not aware of their idiosyncrasies.
A more robust but also more complex overall solution would be to incorporate a service on-board the instance that starts up at boot and checks the status of sshd from the inside, then makes an otherwise unused port available when the system is fully ready for connection and authentication. Of course, this requires that you can boot from a pre-configured image rather than a stock image, and it also requires that another port be open on the firewall.
The set of things like this is endless. In addition, each cloud computing environment has different nuances and each stack configuration adds more complexity to the mix. There are so many fun puns I that apply that I get giddy just thinking about all the storms ahead and the need for umbrellas.
I weigh 209.4 this morning. That’s down from 220 when I Declared A Jihad on My Weight on 10/27/08 although it doesn’t look like I’ll make my Anti-Charity goal of 200 by 1/31/09 (more on that in a post on 2/1/09).
I was thinking about my weight this morning as I entered it into the online system at GoWear. I thought about it again when I entered it into Gyminee. And then into Daytum. I’m going for a run in a little while so I’ll enter it again into TrainingPeaks.
Here’s what I’m doing:
Four times. Every day. Pretty ridiculous. If you reduce the data to its core elements, they are:
The only actual piece of data that I need to measure is weight. I measure this by standing on a scale each morning. The scale is a fancy one – it cost about $100, looks pretty, and has a bunch of extra things I don’t look at such as BMI. I have an identical scale in my house in Keystone (although the battery is dead and needs to be replaced.)
Some day, in the future, I’ll be able to step on the scale. And that will be it. My weight will automatically go into whatever online systems I want it to. I won’t have to do anything else.
Of course, one of the assumptions is that my scale(s) are “network compatible”. While you may joke that this is the age old “connect my refrigerator to the Internet problem” (and it is), I think it’s finally time for this to happen. As broadband and wifi become increasing ubiquitous and inexpensive, there is no reason that any electronic devices shouldn’t be IP connected, in the same way that microprocessors are now everywhere and pretty much everything has a clock in it (even if some of them still blink 12:00.)
So, accept this assumption. Then, I’m really only taking about a “Brad-centric” data payload. While I’ll have a lot more data than simply weight that I might want in my payload, let’s start with the simple case (weight). Right now, we are living in a system-centric world where data is linked first to a system and then a user. Specifically, you have to operate in the context of the system to create data for a user.
Why not flip this? Make things user-centric. I enter my data (or a machine / device collects my data.) I can configure my data inputs to feed data into “my data store” (which should live on the web / in the cloud). Then, systems can grab data from my data store automatically. All I have to do is “wire them up” which is a UI problem that – if someone is forward thinking enough – could also be solved with a single horizontal system that everyone adopts.
Right now there is a huge amount of activity around the inverse of this problem – taking widely diffuse data and re-aggregating it around a single user id. This deals with today’s current reality of how data is generated (system-centric) but doesn’t feel sustainable to me as user-generated data continues to proliferate geometrically.
Enough. As I said in my tweet earlier today, “thinking about data. thinking about running. thinking about thinking.” Time to go run and generate some more data.
Boulder AWS Anonymous held its first meeting last week, and there were eleven attendees despite the fact that the meeting had been inadvertently scheduled at the same time as Obama’s inauguration. Attendees represented a wide variety of uses and potential uses of Amazon Web Services, ranging from hosting popular websites and application development to load balancing, autoscaling, and internet telephony. The group is encouraging anyone in the area interested in getting updates to join their Google Group and/or to attend the next meeting at The Cup, 1521 Pearl St, at 10:00 am on Wednesday February 18.
If you are located in the Boulder / Denver area and doing stuff with Amazon Web Services, there is a new group forming called AWS Anonymous. Per the Colorado Startups blog, they are having their first meeting at The Cup in Boulder on January 20th at 10am. Just show up if you are interested – it’ll be easy to find them since they’ll be the nerds saying things like EC2 and S3.