I'm going to have to cut this up into 2-3 blog posts as it wasn't written for this type of medium. So bare with me, the first is going to be on Politics and Usability. It's for the lay reader, so for those of you who normally follow my blog this should be reaffirmation reading. For everyone else, I hope this helps to give a very top-level honest overview of the issue. (This was an intro rough cut of an article to be released with a paper I wrote earlier this year. It has been sitting here for sometime. Realistically it's not laziness that has prevented me writing but lack of time sadly. I'll need to massage the rest into another post).
The idea of a unifying unique identifier or Single Sign-On (SSO) has been around for some time now. Implementors of these systems have put together several different methods of getting this done whether through OpenLDAP, NIS or some other glue. The idea of OpenID implementations itself bears some background however because OpenID is actually a specification and most if not all current implementations follow that specification.
Politics
It's the unspoken verbiage, or simply the bit rot of code but the politics surrounding single sign-on identity is essentially about the same as a Mexican Standoff with a bit of Catch-22. The twist is that the court of public opinion is between the providers, watching, waiting. The idea of allowing the user or customer access to your wealth and dearth of services via their Google id, if you are Yahoo doesn't sound that enticing. However, if one goes out of the way to explicitly disable service you become the legion of bad interoperability, the all of this is mine guy. Yes, that guy. The first one to step out into the foray of public opinion "cutting off access" earns the that glorious badge. We've seen this type of behavior recently between Facebook and Google in regards to contact data. Google didn't feel the quid pro quo there and logically cut that source of information off to Facebook. Even though Facebook was more the proponent of "bad behavior" the court of public opinion was squarely against Google. As in, they had to defend their position. Subsequently we end up with headlines like "Google vs Facebook For Control of Your Reputation" or "Google Vs Facebook: Who's Right & Who's Wrong?" Interestingly enough this was over nothing more than contact data but as we all know, data is a very valuable commodity. So, surely many companies are in competition right now and that competition is good for us all. Even for the purveyors of other online services and venues it is a good thing. That aside for all the versus articles one would think that using your Google ID to sign into Facebook would be forbidden. Thankfully, you would be wrong.
Facebook OpenID Capable - Figure 1
Fortunately, that tidbit is really no secret to anyone actually involved with the single sign-on problem, drafters, implementors, management and all of the in-betweens understand this weird paradoxical stance very well. If we take a look at Figure 1 we can see OpenID clearly works with my Google account; even though we can clearly see Google isn't displayed at all; politics. If you are reading this as a user and are juggling an average of two or more ids to sign-in to different systems, unfortunately, you are experiencing the problem first-hand. The good news is that OpenID as implemented by most of the major providers does work. That said and let us pass this issue of politics there are also clearly implementation problems that don't make it easy. Which is compounded with the obvious lack of marketing and usability and finally of the functionality and service itself.
The OpenID specification as it currently stands is extremely flexible and the idea of the actual OpenID itself is a solid one. Primarily as a universal unique identifier it leaves authentication to the site or organization you choose to manage your id. It's essentially the panacea that we have all wanted in regards to identification. One unique key, that opens all doors for all the services that we want to use. Unfortunately do to this flexibility we run into implementation problems and this can make the problem a bit more complicated as far as implementation goes.
Usability
The crux of the OpenID issue is primarily the usability piece. The simple fact is that a majority of user are so honed in to bad practice they don't want to change. They want to sign-on as "steve_mcqueen99" and enter their secure password "12345678". 99% of you are saying, well, the password is obviously hilarious (while adding a "change" my password mental note). The other piece is the id "steve_mcqueen99". It's pretty unique, until you realize that steve_mcqueen99 looks something like this "??????99_" and someone in Quy Kim China likes Steve McQueen just as much as you. How do we go about making very unique ids? OpenID uses URI's which is where we hit our first usability issue.
The id is actually a URI (Uniform Resource Identifier) which looks something like this http://profiles.google.com/christopher.warner which in this case also happens to be my unique Openid with Google. The problem with this is that most of our user base simply can't differentiate between a URI and a URL (Uniform Resource Locator) and in all actual fact that URI does indeed link to a URL of my public web profile at Google.
Can you imagine asking for my id over the phone in trouble shooting a problem? The conversation would sound something like this.
"Ok sir, let me just have your unique id and I will be able to process that for you"
"Of course, that's h t t p colon slash profiles dot google dot com slash christopher dot warner"
Next up data migration between services, social malaise, pushing auth to the browser and finally into a formal RFC and WG specification.
I'm going to try in earnest to keep this post updated with relevant information about Specification Pepsi - Openindiana Build 148 as i'm now calling it.
Specification Pepsi Openindiana Build 148
-
How much energy does the entire machine use?
On initial boot with the Samsung Optical SH-223L/BEBS spinning up we hit 95 watts, the system then drops to about 50watts and as it idles out drops to between 47 and 48 watts. While pushing the machine using all 4 drives as stated in the spec, we fluctuate between 50 and 57 watts.
-
Why the 750w ATX Power supply?
Based on the above data the 750w would seem to be overkill but in my specific case I have multiple units plugged into the motherboard. If one doesn't plan on adding more than 4-6 hard drives you could easily get away with a 200-250 watt power supply. I'm going to search around for one and update the original specification.
-
Do you need to have the optical drive?
Not necessarily, you could technically remove the optical drive after install of the specification if you wanted to save on initial start up power. However the unit spins up only on start-up and considering it will be rarely if ever used, it's pretty much a complete non-issue.
-
No ECC memory, will that be an issue?
In the original specification I noted the addition of ECC memory. Well, the Intel D5x doesn't support ECC memory most likely to save as much energy as possible. It also doesn't support Dual Channel memory, again for the same reason. Not the biggest deal in the world for this machine as it's primarily used for storage and technically speaking the likelyhood of getting severe degradation or errors are low. Still, it would of been a nice to have. To my knowledge I don't know of any mini-itx motherboard manufacturers that support ECC memory. At least not yet.
-
Instead of the D510, why not the D525?
Well, if we take a
quick look at a comparison between the D510 and the D525 we see that we gain a minute speed bump in processing and DDR3 instead of DDR2 and wattage remains unchanged. None of this quite frankly mattered to me at the time as the D510 was roughly $20.00 USD less. None of the stated improvements would significantly speed up the function of archival and storage. This obviously changes if you plan to do compression or encryption with ZFS in which case it may then become useful. In reality though it would make much more sense to apply that extra $20.00 USD to a proper gzip or encryption off-board card.
-
How much will it cost you to operate this unit?
I pay roughly 9 cents per kwh off the top of my head. I'll have to update with exacts next time I check but based on that number we are looking at close to $3.05 USD per month with the machine running at an average of 0.47kw/h or roughly $37.00 USD a year. Not such a horrible price for the machine that backs up my lively hood. Not that bad at all.
The Murky Grey that is Openid – Rough Cut
I'm going to have to cut this up into 2-3 blog posts as it wasn't written for this type of medium. So bare with me, the first is going to be on Politics and Usability. It's for the lay reader, so for those of you who normally follow my blog this should be reaffirmation reading. For everyone else, I hope this helps to give a very top-level honest overview of the issue. (This was an intro rough cut of an article to be released with a paper I wrote earlier this year. It has been sitting here for sometime. Realistically it's not laziness that has prevented me writing but lack of time sadly. I'll need to massage the rest into another post).
The idea of a unifying unique identifier or Single Sign-On (SSO) has been around for some time now. Implementors of these systems have put together several different methods of getting this done whether through OpenLDAP, NIS or some other glue. The idea of OpenID implementations itself bears some background however because OpenID is actually a specification and most if not all current implementations follow that specification.
Politics
It's the unspoken verbiage, or simply the bit rot of code but the politics surrounding single sign-on identity is essentially about the same as a Mexican Standoff with a bit of Catch-22. The twist is that the court of public opinion is between the providers, watching, waiting. The idea of allowing the user or customer access to your wealth and dearth of services via their Google id, if you are Yahoo doesn't sound that enticing. However, if one goes out of the way to explicitly disable service you become the legion of bad interoperability, the all of this is mine guy. Yes, that guy. The first one to step out into the foray of public opinion "cutting off access" earns the that glorious badge. We've seen this type of behavior recently between Facebook and Google in regards to contact data. Google didn't feel the quid pro quo there and logically cut that source of information off to Facebook. Even though Facebook was more the proponent of "bad behavior" the court of public opinion was squarely against Google. As in, they had to defend their position. Subsequently we end up with headlines like "Google vs Facebook For Control of Your Reputation" or "Google Vs Facebook: Who's Right & Who's Wrong?" Interestingly enough this was over nothing more than contact data but as we all know, data is a very valuable commodity. So, surely many companies are in competition right now and that competition is good for us all. Even for the purveyors of other online services and venues it is a good thing. That aside for all the versus articles one would think that using your Google ID to sign into Facebook would be forbidden. Thankfully, you would be wrong.
Facebook OpenID Capable - Figure 1
Fortunately, that tidbit is really no secret to anyone actually involved with the single sign-on problem, drafters, implementors, management and all of the in-betweens understand this weird paradoxical stance very well. If we take a look at Figure 1 we can see OpenID clearly works with my Google account; even though we can clearly see Google isn't displayed at all; politics. If you are reading this as a user and are juggling an average of two or more ids to sign-in to different systems, unfortunately, you are experiencing the problem first-hand. The good news is that OpenID as implemented by most of the major providers does work. That said and let us pass this issue of politics there are also clearly implementation problems that don't make it easy. Which is compounded with the obvious lack of marketing and usability and finally of the functionality and service itself.
The OpenID specification as it currently stands is extremely flexible and the idea of the actual OpenID itself is a solid one. Primarily as a universal unique identifier it leaves authentication to the site or organization you choose to manage your id. It's essentially the panacea that we have all wanted in regards to identification. One unique key, that opens all doors for all the services that we want to use. Unfortunately do to this flexibility we run into implementation problems and this can make the problem a bit more complicated as far as implementation goes.
Usability
The crux of the OpenID issue is primarily the usability piece. The simple fact is that a majority of user are so honed in to bad practice they don't want to change. They want to sign-on as "steve_mcqueen99" and enter their secure password "12345678". 99% of you are saying, well, the password is obviously hilarious (while adding a "change" my password mental note). The other piece is the id "steve_mcqueen99". It's pretty unique, until you realize that steve_mcqueen99 looks something like this "??????99_" and someone in Quy Kim China likes Steve McQueen just as much as you. How do we go about making very unique ids? OpenID uses URI's which is where we hit our first usability issue.
The id is actually a URI (Uniform Resource Identifier) which looks something like this http://profiles.google.com/christopher.warner which in this case also happens to be my unique Openid with Google. The problem with this is that most of our user base simply can't differentiate between a URI and a URL (Uniform Resource Locator) and in all actual fact that URI does indeed link to a URL of my public web profile at Google.
Can you imagine asking for my id over the phone in trouble shooting a problem? The conversation would sound something like this.
Next up data migration between services, social malaise, pushing auth to the browser and finally into a formal RFC and WG specification.