I came back from a genetic research conference a couple of months ago where an IT professional at Argonne National Labs spoke about his efforts to build a compute and storage capability there to support the needs of the genetic sequencing community at the lab. Unllike BackBlaze, which has about 200-300 machines, he was managing over 250,000 cores (so, what, maybe 15,000 machines?) and said that it was getting to the point where it would be cheaper for him to move to a cloud service provider.
The lesson I took away from that is that at the small scale, you can probably do it more cheaply, but as you scale up, the larger outfits end up offering a better deal, which isn't all that surprising.
I thought that might be an interesting data point, since you basically said the same thing in your last paragraph.
Not only did I read the article, I read their blog post. And the original blog post they had about their 67 TB pod, back when they first wrote it.
You know how I know that? They explicitly state that they don't have any costs for replacement hard drives over 3 years, because they're *all under warranty* for 3 years. When a drive fails, they get a new one from the manufacturer, no questions asked.
There's no such thing as not having any costs. They employ Sean to replace drives and build pods full time. That's a cost, and it's not included in their charts at the bottom of the blog post. Bandwidth isn't either, and they never claim it is. Read on.
And yes, actually, they do include bandwidth in the cost. They disclose it within the same paragraph.
And this is where it gets interesting. In the paragraph you refer to, they say it costs $2100 for them to run a rack of 10 pods for one month. If each pod has 135TB, and we define 3PB to be 3000TB, then we need 23 pods to get 3PB (this is assuming all they use is their new pod design, which they don't, they also use their less dense legacy design as well). But let's not get off track.
So, 2.3 racks (23 pods total), each costing $2100 a month to operate in terms of *space rental*, *power* and *bandwidth*. This is the cost that includes bandwidth. So, assuming we run 2.3 racks for 36 months, we get $2100 * 36 * 2.3 = $173,880, just to operate 3PB for 3 years. That doesn't even include the cost to build them, or Sean's salary. And yet, somehow, at the bottom of their post, they assert that it costs a *total* of $96,000 to build and operate 3PB for three years. Odd, no?
My point is that the costs they quote at the bottom of their blog post are inaccurate. Even if you take out bandwidth, which they state is roughly 1/3 of their operating costs, we're still talking about $116k of operating costs, above and beyond the cost to build the machines.
Even after you factor all that in, they still aren't beginning to offer the service that Amazon or Google does. Again, my point is they are misleading folks when they compare their product to Amazon as though they have the same features. They don't.
First: ALL Marketing is misleading. That is what marketing does. Accentuate the positive, eliminate the negative. So complaining about that is just idiotic.
OK, there's also the concept of truth in advertising. I sense you want to argue about this, but false comparisons are different than "accentuating the positives".
Second: You could have a couple dozen Backblaze units, pay for a tech to monitor them 24/7/365 and replace all the drives twice over for what Amazon charges for the same thing. Sure that doesn't included cost for premises, and HighSpeed Internet to multiple locations. But still, that is aggregated with all the other clients.
Amazon doesn't charge for one data center with a couple dozen rack-mounted machines being watched by one tech. If that's what you think S3 is, you are mistaken.
Third: what are you paying for in the "cloud", I mean besides ethereal concepts. Does Amazon tell you how they do things? You probably know less about Amazon (and the others) setup so you're comparing something you know something about (not everything) verses something you know almost nothing about, and the complain that they aren't doing it in a comparable way. You don't know.
Actually, I know quite a bit. Even if you ignore things I learned on the job, if you just read their basic literature about what they offer, you can see that they use Dynamo on the back end and that they have infrastructure "designed to provide 99.999999999% durability and 99.99% availability of objects over a given year", as well as "sustain the concurrent loss of data in two facilities.". I happen to know how they derived those numbers, but that's not a useful discussion...the numbers were honestly derived, even if they can't empirically show them to be correct (the service simply hasn't been around long enough for that). The point is that S3 is in an entirely different ballpark from what BackBlaze offers.
Fourth: Your basic assumption is that Backblaze has no contigency for drive replacement, which is false. Since these are "new" drives there might be insufficient data about failure rates and therefore the actual cost of replacement (never mind warranties) or having drives in both Hot and Cold Spare setups. I'm sure that Backblaze in their $5/MO service figures what it costs to store data, have spares, keep the Datacenter running and profitable. Even if they double the cost to $10, it still puts the others to shame.
No, my basic assumption is that they don't factor in the costs for drive replacement. They say in their blog post that they have drives that are out of warranty. They don't include the costs to replace them in their analysis. Even for the drives that *are* under warranty, they don't factor in the cost of identifying them, ordering replacements from the manufacturer, and replacing the actual drive. In other words, I'm asserting that the dominating cost isn't necessarily the drive, it's the labor. They even say that the "hidden costs" of doing all this are the labor. They don't discuss what they pay Sean, but they aren't factoring it in to their graphs at the bottom of the post.
Have you compared the data loss rates for the last three years between Amazon and Backblaze?
No, I'm asking them to.
Can you even compare or is that data held secret (see point 1b).
S3 has a service level agreement for the durability of the data. I haven't seen this from BackBlaze. I still maintain that the services aren't comparable in any meaningful way.
My point here, is that you're pulling shit out of your ass and thinking it doesn't stink.
I'm not sure what you're trying to say here.
Even if it isn't directly comparable, it is at least in the realm of consideration, EVEN if everything you said is true. And at 10 times less in cost, that can buy a lot
I didn't mean to assert that BackBlaze's product has no place in the market. Heck, I'd love to build a couple of their pods for home use. My only point was that it is a product that has very different strengths than S3. The only reason I picked S3 in the comparison is because *they* picked S3 when they decided to discuss pricing.
I'm not sure I ever said anything about having to think about it. I can tell you that S3 runs at least triple redundancy (enough to survive the loss of two data centers simultaneously). That's a very different product from what BackBlaze is selling.
My problem with Backblaze is their marketing is very misleading...they pit these storage pods up against cloud storage and assert that they are "cheaper", as though a storage pod is anything like cloud storage. It isn't. Sure, there's the management software issue that's already been mentioned, but they do no analysis on redundancy, power usage, security, bandwidth usage, cooling, drive replacement due to failure, administrative costs, etc. It's insulting to anyone who can tell the difference, but there are suits out there who read their marketing pitch and decide that current cloud storage providers like Google and Amazon are a rip off because "Backblaze can do the same thing for a twentieth the price!" It's nuts.
You can see this yourself in their pricing chart at the bottom of their blog post. They assert that Backblaze can store a petabyte for three years for either $56k or $94k (if you include "space and power"). And then they compare that to S3 costing roughly $2.5 million. In their old graphs, they left out the "space and power" part, and I'm sure people complained about the inaccuracies. But they're making the same mistake again this time: they're implicitly assuming the cost of replicating, say, S3, is dominated by the cost of the initial hardware. It isn't. They still haven't included the cost of geographically distributing the data across data centers, the cost of drive replacement to account for drive failure over 3 years, the cost of the bandwidth to access that data, and it is totally unclear if their cost for "power" includes cooling. And what about maintaining the data center's security? Is that included in "space"?
On a side note, I'd be interested to see their analysis on mean time between data loss using their system as it is priced in their post.
You could say the Backblaze is serving a different need, so it doesn't need to incur all those additional costs, and you might be right, but then why are they comparing it to S3 in the first place? It's just marketing fluff, and it is in an article people are lauding for its technical accuracy. Meh.
You're glossing over the (very important) point about what exactly the rules in the store are. Sure, from a legal perspective, you can say "Their store, their rules" and be done with it. But from a practical perspective it matters a lot if they have a rule that says you can't re-implement the functionality present in current (or planned) official applications, as Apple had/has (I'm not current on their stance in this regard). Google, on the other hand, goes out of their way to point out that you can replace many components of the underlying system, like the contacts, email, dialer, and home applications. To say that both systems have rules, and therefore they are both the same is disingenuous; it would be a bit like saying "Well, the United States has laws, and so does North Korea, so they're basically the same."
Which brings me to my second point. For years, no one really knew what the rules were in Apple's store. Apps that developers had spent months on were magically rejected. There was no transparency. Compare with Google's store, which has very clear, transparent rules that developers must agree to before they can ever submit an application for inclusion in the market. I hear that Apple has tried to increase transparency recently, but I don't know to what extent they have succeeded.
If you consider both those differences, and then pile on the fact that even if Kongregate fails to abide by the rules, even though they agreed to them before submitting their application, Android users can still visit their website and install the application that way, you have a system that by all measures is more "open" than Apple's.
And all of that ignores the fact that the operating system itself is open source and can (an is!) used and modified freely by dozens (or hundreds) of companies around the globe.
All that is to say: the differences between the two systems are deep and far-reaching, not merely the fact that applications can be installed from a website on Android, but not iOS.
His point was that the app store is governed - you have no idea whether Apple will ever let your app make it into the actual store (see Google Voice). They might perfectly well say that it is an exact duplicate of a for-pay app, and it is therefore rejected. Remember, Apple takes 30%, so it's in their best interest to put more apps behind the pay wall. And we already know that Apple can reject any app for any reason (FCC inquiries notwithstanding).
There are many aspects to security. When I referenced it above, I was referring to wasting the security personnel's time (and yours) - i.e. it is a win for them to be able to wave your bag through, and it is a win for you as well.
I noticed shortly after I wrote the comment that there was another way to read that ("We're more secure when we carry 2oz bottles of fluid") but didn't want to clarify unless someone came along and forced the issue. Here we are.
Converting 2 fl. oz. to "real units" is left as on exercise for the reader. Assuming you're interested and not just flaunting metric superiority, may I suggest "2 fl oz in ml" on Google?
Poor reasoning. He didn't ask for a lesson in what trips their wire of suspicious, he asked *why* they were going through his stuff. The answer can be as simple as "We saw an object on the xray that might be contraband." or even "We have reason to believe a prohibited item may be in your bag." It doesn't actually tell the passenger a whole lot, but at least it categorizes the event as "we think we may have some evidence" vs. "It's totally random" vs. "You look nervous, so we're giving you more attention."
But let's face it - no one likes security, and it's fair to know what can hang you up - that's why they publish the rules. If they come out and say "Hey, you had a container that was exactly 3oz of liquid, sometimes we can't tell if it goes over the limit without closer inspection", then you can start carrying 2oz bottles of contact solution to put yourself further in the "safe" area. It's good for you, and it's good for security.
Further, hoping that the enemy doesn't know what magic lines you've drawn as a basis for your security is a horrible plan. Security should be tight because it's tight, not because no one knows the ways in which it sucks. It's the old argument over whether open source is more vulnerable because everyone can see the code; time and again it has been shown that open source can be at least as secure as closed source.
Not everyone shares your views about what role sex plays in a relationship. You view it as more binding than marriage, and synonymous with "consummation of marriage". Many view it as recreation primarily, and procreation as a secondary concern. I'm fairly sure sex existed long before marriage.
As Richard Feynman said: "Physics is like sex. Sure, it may give some practical results, but that's not why we do it."
Dead on. In the Mac ad where the PC gets sick, it is *not* the implication that PC users are getting sick, it's that PCs get viruses. In the ad where there are two "agents" that the PC has to ask permission from to do anything, it isn't the user asking permission, it is the PC. In even the most recent ad, Hodgman refers to "my frustrated users don't need to hear about that." Yeah, I'm going with the clear implication that he *is* the computer, and is not representing his users.
Apple may say in the ads that Windows is more annoying than OS X, but in reality, they provide bootcamp and support users who choose to run both OS X and Windows on their Mac computers. So from the religion perspective, Apple just wants you to buy their hardware...they don't mind if you run Windows on it. Arguing that MS is somehow taking the high ground by *not* saying "Apple has it wrong" is kind of strange.
Further, in the Mac ads, the people are standing in for actual machines. In the MS ad, people are standing in for...people. So the whole "I'm a PC" thing has kind of an odd ring to it. If anything, it is pushing a notion of your identity being strongly linked to what operating system you use. Since there are no "users" in the Mac ads, that tone is absent. From this perspective, the MS ads are more religious than the Mac ads, since they are defining *who people are* in terms of what kind of computer they use.
Wait, so now my internet connection is like a gun? And besides, what's wrong with leaving my gun on the table? I always leave it there - then again, I *do* live in California...
Good points. As I said, I am in no way wed to Twitter, my point was that it turned around how the status is received and let the recipient decide, and it is simple. If we can find a way for OpenID and/or Jabber technologies to implement this, so much the better, IMO.
Sounds like I didn't make my point well. What Twitter does is allow the recipient to determine how they receive your updates (if at all), rather than you determining for them.
Twitter is important. This was going to be a blog post, but whatever. I don't know if Twitter itself will be successful, but something like it is key. It changes the AIM/Facebook/Skype, etc. model of "posting your status" around by letting the recipient determine how they receive the data you post (do they have to check for it? Is it in their "feed"? Do they get notified by SMS?). As a poster, you don't know how the information you provide will be consumed by others. This makes it fundamentally different than the out-of-the-box (meaning "default") experience on traditional "post your status" services. Usually, when you email someone, they have to check the email and then they get your message. If you want a "push" message, you have to change services (SMS, call). Same with status - traditional status messages are "pull" only for the consumer - they have to check to see what your status is - they can't be notified.
But Twitter has something else: its simple. It really only does one thing. A lot of people who use Facebook don't understand what Twitter offers: "I can post status on Facebook and do a ton of other stuff, too. Why use Twitter?" Good question, which leads me to my point.
I think if we adopt a Unix philosophy with these services by keeping them simple and providing an open API (command-line switches and stdin/stdout, if you will), we can engage in service composition; the combination of many simple services into complex structures using standard interfaces.
Where can this be used? Well, in my case, I use Twitter, read news on Google Reader, vote and post on Slashdot, Reddit and Digg, maintain a blog and have a Facebook account. A service like FriendFeed pulls all these together, and is then an "object" that I can work with. So, instead of heading over to Facebook to update my status, I can post to Twitter from Emacs (twit.el, I'm not joking), have FriendFeed harvest that info and populate my Facebook page using their app for Facebook. Again, composition of simple services to make complex things happen. If I share a story on Reader, FriendFeed picks that up as well and will update my homepage and my FaceBook page with the info. This is a great example of reuse - who wants to update 15 services to let their friends know they'll be out of town or to tell them about some news story they saw that was cool?
Yeah, you're right. There was *no* innovation that went into the internet, peer-to-peer networks, digital music encoding and cd ripping.
On a serious note, the analogy is actually quite good, but the two events occur a meta-level apart: buggies died because of a new product, CDs are dying because of a new way of conceiving of the market.
On topic, the guy has no point - selling CDs *is* selling DRM free digital music. Whether you sell it online or in plastic disc form is immaterial to the piracy issue. Unless we're going to start selling only DRM-laden material, DRM only pissed off legitimate customers - anyone who wants to pirate can head over to TPB and start downloading. No technical expertise needed.
Slashdot Mirror
Tons of folks use GWT, and that cross-compiles Java to JavaScript. This doesn't seem much different.
Even their own math on the auxiliary costs doesn't add up. I outline the what I think are the inconsistencies in a peer thread to this one.
S3 is redundant. They compared themselves to S3.
I came back from a genetic research conference a couple of months ago where an IT professional at Argonne National Labs spoke about his efforts to build a compute and storage capability there to support the needs of the genetic sequencing community at the lab. Unllike BackBlaze, which has about 200-300 machines, he was managing over 250,000 cores (so, what, maybe 15,000 machines?) and said that it was getting to the point where it would be cheaper for him to move to a cloud service provider.
The lesson I took away from that is that at the small scale, you can probably do it more cheaply, but as you scale up, the larger outfits end up offering a better deal, which isn't all that surprising.
I thought that might be an interesting data point, since you basically said the same thing in your last paragraph.
You didn't read the article.
Not only did I read the article, I read their blog post. And the original blog post they had about their 67 TB pod, back when they first wrote it.
You know how I know that? They explicitly state that they don't have any costs for replacement hard drives over 3 years, because they're *all under warranty* for 3 years. When a drive fails, they get a new one from the manufacturer, no questions asked.
There's no such thing as not having any costs. They employ Sean to replace drives and build pods full time. That's a cost, and it's not included in their charts at the bottom of the blog post. Bandwidth isn't either, and they never claim it is. Read on.
And yes, actually, they do include bandwidth in the cost. They disclose it within the same paragraph.
And this is where it gets interesting. In the paragraph you refer to, they say it costs $2100 for them to run a rack of 10 pods for one month. If each pod has 135TB, and we define 3PB to be 3000TB, then we need 23 pods to get 3PB (this is assuming all they use is their new pod design, which they don't, they also use their less dense legacy design as well). But let's not get off track.
So, 2.3 racks (23 pods total), each costing $2100 a month to operate in terms of *space rental*, *power* and *bandwidth*. This is the cost that includes bandwidth. So, assuming we run 2.3 racks for 36 months, we get $2100 * 36 * 2.3 = $173,880, just to operate 3PB for 3 years. That doesn't even include the cost to build them, or Sean's salary. And yet, somehow, at the bottom of their post, they assert that it costs a *total* of $96,000 to build and operate 3PB for three years. Odd, no?
My point is that the costs they quote at the bottom of their blog post are inaccurate. Even if you take out bandwidth, which they state is roughly 1/3 of their operating costs, we're still talking about $116k of operating costs, above and beyond the cost to build the machines.
Even after you factor all that in, they still aren't beginning to offer the service that Amazon or Google does. Again, my point is they are misleading folks when they compare their product to Amazon as though they have the same features. They don't.
First: ALL Marketing is misleading. That is what marketing does. Accentuate the positive, eliminate the negative. So complaining about that is just idiotic.
OK, there's also the concept of truth in advertising. I sense you want to argue about this, but false comparisons are different than "accentuating the positives".
Second: You could have a couple dozen Backblaze units, pay for a tech to monitor them 24/7/365 and replace all the drives twice over for what Amazon charges for the same thing. Sure that doesn't included cost for premises, and HighSpeed Internet to multiple locations. But still, that is aggregated with all the other clients.
Amazon doesn't charge for one data center with a couple dozen rack-mounted machines being watched by one tech. If that's what you think S3 is, you are mistaken.
Third: what are you paying for in the "cloud", I mean besides ethereal concepts. Does Amazon tell you how they do things? You probably know less about Amazon (and the others) setup so you're comparing something you know something about (not everything) verses something you know almost nothing about, and the complain that they aren't doing it in a comparable way. You don't know.
Actually, I know quite a bit. Even if you ignore things I learned on the job, if you just read their basic literature about what they offer, you can see that they use Dynamo on the back end and that they have infrastructure "designed to provide 99.999999999% durability and 99.99% availability of objects over a given year", as well as "sustain the concurrent loss of data in two facilities.". I happen to know how they derived those numbers, but that's not a useful discussion...the numbers were honestly derived, even if they can't empirically show them to be correct (the service simply hasn't been around long enough for that). The point is that S3 is in an entirely different ballpark from what BackBlaze offers.
Fourth: Your basic assumption is that Backblaze has no contigency for drive replacement, which is false. Since these are "new" drives there might be insufficient data about failure rates and therefore the actual cost of replacement (never mind warranties) or having drives in both Hot and Cold Spare setups. I'm sure that Backblaze in their $5/MO service figures what it costs to store data, have spares, keep the Datacenter running and profitable. Even if they double the cost to $10, it still puts the others to shame.
No, my basic assumption is that they don't factor in the costs for drive replacement. They say in their blog post that they have drives that are out of warranty. They don't include the costs to replace them in their analysis. Even for the drives that *are* under warranty, they don't factor in the cost of identifying them, ordering replacements from the manufacturer, and replacing the actual drive. In other words, I'm asserting that the dominating cost isn't necessarily the drive, it's the labor. They even say that the "hidden costs" of doing all this are the labor. They don't discuss what they pay Sean, but they aren't factoring it in to their graphs at the bottom of the post.
Have you compared the data loss rates for the last three years between Amazon and Backblaze?
No, I'm asking them to.
Can you even compare or is that data held secret (see point 1b).
S3 has a service level agreement for the durability of the data. I haven't seen this from BackBlaze. I still maintain that the services aren't comparable in any meaningful way.
My point here, is that you're pulling shit out of your ass and thinking it doesn't stink.
I'm not sure what you're trying to say here.
Even if it isn't directly comparable, it is at least in the realm of consideration, EVEN if everything you said is true. And at 10 times less in cost, that can buy a lot
I didn't mean to assert that BackBlaze's product has no place in the market. Heck, I'd love to build a couple of their pods for home use. My only point was that it is a product that has very different strengths than S3. The only reason I picked S3 in the comparison is because *they* picked S3 when they decided to discuss pricing.
I'm not sure I ever said anything about having to think about it. I can tell you that S3 runs at least triple redundancy (enough to survive the loss of two data centers simultaneously). That's a very different product from what BackBlaze is selling.
My problem with Backblaze is their marketing is very misleading...they pit these storage pods up against cloud storage and assert that they are "cheaper", as though a storage pod is anything like cloud storage. It isn't. Sure, there's the management software issue that's already been mentioned, but they do no analysis on redundancy, power usage, security, bandwidth usage, cooling, drive replacement due to failure, administrative costs, etc. It's insulting to anyone who can tell the difference, but there are suits out there who read their marketing pitch and decide that current cloud storage providers like Google and Amazon are a rip off because "Backblaze can do the same thing for a twentieth the price!" It's nuts.
You can see this yourself in their pricing chart at the bottom of their blog post. They assert that Backblaze can store a petabyte for three years for either $56k or $94k (if you include "space and power"). And then they compare that to S3 costing roughly $2.5 million. In their old graphs, they left out the "space and power" part, and I'm sure people complained about the inaccuracies. But they're making the same mistake again this time: they're implicitly assuming the cost of replicating, say, S3, is dominated by the cost of the initial hardware. It isn't. They still haven't included the cost of geographically distributing the data across data centers, the cost of drive replacement to account for drive failure over 3 years, the cost of the bandwidth to access that data, and it is totally unclear if their cost for "power" includes cooling. And what about maintaining the data center's security? Is that included in "space"?
On a side note, I'd be interested to see their analysis on mean time between data loss using their system as it is priced in their post.
You could say the Backblaze is serving a different need, so it doesn't need to incur all those additional costs, and you might be right, but then why are they comparing it to S3 in the first place? It's just marketing fluff, and it is in an article people are lauding for its technical accuracy. Meh.
Thanks so much for taking the time to write this. Great points all around. Well played.
You're glossing over the (very important) point about what exactly the rules in the store are. Sure, from a legal perspective, you can say "Their store, their rules" and be done with it. But from a practical perspective it matters a lot if they have a rule that says you can't re-implement the functionality present in current (or planned) official applications, as Apple had/has (I'm not current on their stance in this regard). Google, on the other hand, goes out of their way to point out that you can replace many components of the underlying system, like the contacts, email, dialer, and home applications. To say that both systems have rules, and therefore they are both the same is disingenuous; it would be a bit like saying "Well, the United States has laws, and so does North Korea, so they're basically the same."
Which brings me to my second point. For years, no one really knew what the rules were in Apple's store. Apps that developers had spent months on were magically rejected. There was no transparency. Compare with Google's store, which has very clear, transparent rules that developers must agree to before they can ever submit an application for inclusion in the market. I hear that Apple has tried to increase transparency recently, but I don't know to what extent they have succeeded.
If you consider both those differences, and then pile on the fact that even if Kongregate fails to abide by the rules, even though they agreed to them before submitting their application, Android users can still visit their website and install the application that way, you have a system that by all measures is more "open" than Apple's.
And all of that ignores the fact that the operating system itself is open source and can (an is!) used and modified freely by dozens (or hundreds) of companies around the globe.
All that is to say: the differences between the two systems are deep and far-reaching, not merely the fact that applications can be installed from a website on Android, but not iOS.
"...use the knowledge you gained on the job to get a better one."
Laughable, indeed. That's called "experience".
His point was that the app store is governed - you have no idea whether Apple will ever let your app make it into the actual store (see Google Voice). They might perfectly well say that it is an exact duplicate of a for-pay app, and it is therefore rejected. Remember, Apple takes 30%, so it's in their best interest to put more apps behind the pay wall. And we already know that Apple can reject any app for any reason (FCC inquiries notwithstanding).
There are many aspects to security. When I referenced it above, I was referring to wasting the security personnel's time (and yours) - i.e. it is a win for them to be able to wave your bag through, and it is a win for you as well.
I noticed shortly after I wrote the comment that there was another way to read that ("We're more secure when we carry 2oz bottles of fluid") but didn't want to clarify unless someone came along and forced the issue. Here we are.
Converting 2 fl. oz. to "real units" is left as on exercise for the reader. Assuming you're interested and not just flaunting metric superiority, may I suggest "2 fl oz in ml" on Google?
Poor reasoning. He didn't ask for a lesson in what trips their wire of suspicious, he asked *why* they were going through his stuff. The answer can be as simple as "We saw an object on the xray that might be contraband." or even "We have reason to believe a prohibited item may be in your bag." It doesn't actually tell the passenger a whole lot, but at least it categorizes the event as "we think we may have some evidence" vs. "It's totally random" vs. "You look nervous, so we're giving you more attention."
But let's face it - no one likes security, and it's fair to know what can hang you up - that's why they publish the rules. If they come out and say "Hey, you had a container that was exactly 3oz of liquid, sometimes we can't tell if it goes over the limit without closer inspection", then you can start carrying 2oz bottles of contact solution to put yourself further in the "safe" area. It's good for you, and it's good for security.
Further, hoping that the enemy doesn't know what magic lines you've drawn as a basis for your security is a horrible plan. Security should be tight because it's tight, not because no one knows the ways in which it sucks. It's the old argument over whether open source is more vulnerable because everyone can see the code; time and again it has been shown that open source can be at least as secure as closed source.
Not everyone shares your views about what role sex plays in a relationship. You view it as more binding than marriage, and synonymous with "consummation of marriage". Many view it as recreation primarily, and procreation as a secondary concern. I'm fairly sure sex existed long before marriage.
As Richard Feynman said:
"Physics is like sex. Sure, it may give some practical results, but that's not why we do it."
Dead on. In the Mac ad where the PC gets sick, it is *not* the implication that PC users are getting sick, it's that PCs get viruses. In the ad where there are two "agents" that the PC has to ask permission from to do anything, it isn't the user asking permission, it is the PC. In even the most recent ad, Hodgman refers to "my frustrated users don't need to hear about that." Yeah, I'm going with the clear implication that he *is* the computer, and is not representing his users.
Apple may say in the ads that Windows is more annoying than OS X, but in reality, they provide bootcamp and support users who choose to run both OS X and Windows on their Mac computers. So from the religion perspective, Apple just wants you to buy their hardware...they don't mind if you run Windows on it. Arguing that MS is somehow taking the high ground by *not* saying "Apple has it wrong" is kind of strange.
Further, in the Mac ads, the people are standing in for actual machines. In the MS ad, people are standing in for...people. So the whole "I'm a PC" thing has kind of an odd ring to it. If anything, it is pushing a notion of your identity being strongly linked to what operating system you use. Since there are no "users" in the Mac ads, that tone is absent. From this perspective, the MS ads are more religious than the Mac ads, since they are defining *who people are* in terms of what kind of computer they use.
Wait, so now my internet connection is like a gun? And besides, what's wrong with leaving my gun on the table? I always leave it there - then again, I *do* live in California...
This would have sucked when I switched from Qwerty to Dvorak last August.
Good points. As I said, I am in no way wed to Twitter, my point was that it turned around how the status is received and let the recipient decide, and it is simple. If we can find a way for OpenID and/or Jabber technologies to implement this, so much the better, IMO.
Sounds like I didn't make my point well. What Twitter does is allow the recipient to determine how they receive your updates (if at all), rather than you determining for them.
Twitter is important. This was going to be a blog post, but whatever. I don't know if Twitter itself will be successful, but something like it is key. It changes the AIM/Facebook/Skype, etc. model of "posting your status" around by letting the recipient determine how they receive the data you post (do they have to check for it? Is it in their "feed"? Do they get notified by SMS?). As a poster, you don't know how the information you provide will be consumed by others. This makes it fundamentally different than the out-of-the-box (meaning "default") experience on traditional "post your status" services. Usually, when you email someone, they have to check the email and then they get your message. If you want a "push" message, you have to change services (SMS, call). Same with status - traditional status messages are "pull" only for the consumer - they have to check to see what your status is - they can't be notified.
But Twitter has something else: its simple. It really only does one thing. A lot of people who use Facebook don't understand what Twitter offers: "I can post status on Facebook and do a ton of other stuff, too. Why use Twitter?" Good question, which leads me to my point.
I think if we adopt a Unix philosophy with these services by keeping them simple and providing an open API (command-line switches and stdin/stdout, if you will), we can engage in service composition; the combination of many simple services into complex structures using standard interfaces.
Where can this be used? Well, in my case, I use Twitter, read news on Google Reader, vote and post on Slashdot, Reddit and Digg, maintain a blog and have a Facebook account. A service like FriendFeed pulls all these together, and is then an "object" that I can work with. So, instead of heading over to Facebook to update my status, I can post to Twitter from Emacs (twit.el, I'm not joking), have FriendFeed harvest that info and populate my Facebook page using their app for Facebook. Again, composition of simple services to make complex things happen. If I share a story on Reader, FriendFeed picks that up as well and will update my homepage and my FaceBook page with the info. This is a great example of reuse - who wants to update 15 services to let their friends know they'll be out of town or to tell them about some news story they saw that was cool?
Wow. I've been coding distributed systems in Java and Jini for 4 years and I didn't know a lot of this stuff. Good set of posts - thanks.
Yeah, you're right. There was *no* innovation that went into the internet, peer-to-peer networks, digital music encoding and cd ripping.
On a serious note, the analogy is actually quite good, but the two events occur a meta-level apart: buggies died because of a new product, CDs are dying because of a new way of conceiving of the market.
On topic, the guy has no point - selling CDs *is* selling DRM free digital music. Whether you sell it online or in plastic disc form is immaterial to the piracy issue. Unless we're going to start selling only DRM-laden material, DRM only pissed off legitimate customers - anyone who wants to pirate can head over to TPB and start downloading. No technical expertise needed.