I am reading an article by Matt Asay about the position of "open source" in the "hype cycle". He asserts that 2010 has been the year that Open Source became "invisible", that it is no longer hyper-worthy news that some company is using or producing open source software, but that instead that open source has become the foundational default for infrastructure and tools software.
I think he is correct, and as a long term proponent of the "open source" project, dating back from when I was a young undergrad who had just read Stallman's manifesto, I am gratified that the concept is having been proven correct. But as professional open source advocate, and as an employee Eucalyptus Systems, a company that actually creates and distributes GPL-licenced open source infrastructure software, this makes my life more difficult.
In the past, one could "ride the wave" of the hype a bit, and take advantage of the opportunity to educate reporters and potential buyers to both evangulize the whole open-source project, and also the specific project one wants to present. That free ride for publicity is now over.
2010-12-06
RFID door opener
I live in a geekhouse, which is shared housing situation that is more social than an old-school boarding house, but less "into each other's business" then being "family". This kind of shared housing is a model that is popular with the geeky set, especially in my neighborhood in Seattle.
One of the problems with this situation is physical access control, that is, locking and opening the front door. There are a number of people who live there, a number more who have "walk in at any time" social status, plus out of town guests and visitors, and so forth. Keeping track of who has a key and recovering guest keys is awkward at best. And rekeying the locks would be very annoying.
I've been reading about RFID, MIFARE, and the Maker revolution for some time, and have decided to actually Make something interesting and useful. I'm building a way to open the door with an RFID card and/or a biometric.
So many people immediately say "but, it could get hacked!". And my response is: a break-and-enter criminal type would just break the window, and any hypothetical black-bagging spooks would just pick the lock. So adding this will not lower the actual security, and would increase it by decreasing the actual physical keys "out there".
So I'm starting with this project. Then I will add a fingerprint reader, and then run a link back to a server with a database, either over ethernet, zigbee, or some other link. I will use a digital output line to drive a transistor that will drive a relay that will drive a standard off-the-shelf electromagnet door striker (the thing that goes BUZZ when you get buzzed in). All of this stuff is off-the-shelf from places like AdaFruit.
Then I can start doing cool stuff on the server side, such as do the access lookup via RADIUS or LDAP, so existing scalable and federating identity systems can be used, across multiple units. And set it up so people can choose to do a Foursquare checkin when they touch in.
One of the problems with this situation is physical access control, that is, locking and opening the front door. There are a number of people who live there, a number more who have "walk in at any time" social status, plus out of town guests and visitors, and so forth. Keeping track of who has a key and recovering guest keys is awkward at best. And rekeying the locks would be very annoying.
I've been reading about RFID, MIFARE, and the Maker revolution for some time, and have decided to actually Make something interesting and useful. I'm building a way to open the door with an RFID card and/or a biometric.
So many people immediately say "but, it could get hacked!". And my response is: a break-and-enter criminal type would just break the window, and any hypothetical black-bagging spooks would just pick the lock. So adding this will not lower the actual security, and would increase it by decreasing the actual physical keys "out there".
So I'm starting with this project. Then I will add a fingerprint reader, and then run a link back to a server with a database, either over ethernet, zigbee, or some other link. I will use a digital output line to drive a transistor that will drive a relay that will drive a standard off-the-shelf electromagnet door striker (the thing that goes BUZZ when you get buzzed in). All of this stuff is off-the-shelf from places like AdaFruit.
Then I can start doing cool stuff on the server side, such as do the access lookup via RADIUS or LDAP, so existing scalable and federating identity systems can be used, across multiple units. And set it up so people can choose to do a Foursquare checkin when they touch in.
Problems at the physical layer and at the political layer of cloud computing
I was at the Seattle CloudCamp last week, and ended up on the unpanel. An "unpanel" is the unconference version of a panel talk. Half a dozen self admited "experts" are picked from the body of participants, then the body of participants are polled for questions, and then members of the panel take turns picking a question and answering it.
One of the questions was somewhat defiantly called out by Steve Riley, the public face of AWS security. From memory, it was "what applications can NOT be moved to the cloud. Give reasons why, with data"
While I understood his point, which is that most of the applications that people think cannot be moved to the cloud, actually can be, I took the question, and with a mix of humor and defiance, answered it.
There are two kinds of apps that cannot move to "the public cloud", especially as it exists right now.
The first kind are the set of high frequency realtime applications that have a sense/react cycle faster than the networking latency to the cloud provider's datacenter. As I tried to tweet immediately after, "CPUs are getting faster, faster than the speed of light is getting faster".
And the the second kind are the set of applications that piss off people like Senator Joe Lieberman, who will call up your cloud provider's CEO to threaten him, resulting in your account getting killed and the cloud provider issuing a press release lying about the call from the Senator.
Fixing these bugs in the physical layer and in the political layer of the public cloud is going to be... challenging.
One of the questions was somewhat defiantly called out by Steve Riley, the public face of AWS security. From memory, it was "what applications can NOT be moved to the cloud. Give reasons why, with data"
While I understood his point, which is that most of the applications that people think cannot be moved to the cloud, actually can be, I took the question, and with a mix of humor and defiance, answered it.
There are two kinds of apps that cannot move to "the public cloud", especially as it exists right now.
The first kind are the set of high frequency realtime applications that have a sense/react cycle faster than the networking latency to the cloud provider's datacenter. As I tried to tweet immediately after, "CPUs are getting faster, faster than the speed of light is getting faster".
And the the second kind are the set of applications that piss off people like Senator Joe Lieberman, who will call up your cloud provider's CEO to threaten him, resulting in your account getting killed and the cloud provider issuing a press release lying about the call from the Senator.
Fixing these bugs in the physical layer and in the political layer of the public cloud is going to be... challenging.
Subscribe to:
Posts (Atom)