I highly doubt a majority of businesses are going to lock themselves into one hosting provider's specific development platform just to take advantage of hosted servers that push themselves into the next layer.
I would have though the same thing about J2EE, but every site ends up using proprietary extensions in Websphere, or whatever, and then has an terrible time migrating to another platform. It's called "vendor lock-in". I don't see why it wouldn't happen again in the cloud. Heck, there are still plenty of MAJOR sites that only offer certain features in specific browsers.
If your drive dies, you go to your backup, not a recovery service. If you have to go to a service, either your data backup plan failed, or you have a specific forensic need.
Then choose DSL and cable, or DSL and fibre, etc. If you choose two DSL providers, it is extremely likely that both circuits will end up in the same CO (central office) and may even be on the same DSLAM (the DSL "interface" at the CO). If that device fails, or there's a problem at the CO, you're off the 'net on both links.
And I, the consumer, would buy a new device that is explicitly less functional than existing devices... why? You did it when you went from VHS to VHS with MacroVision.
You did it when you went from those to DVDs.
You did it when you went from DVDs to HD/BluRay.
You did it when you went from NTSC to QAM or ATSC. (substitute your national standards)
You'll do the NEXT time entrenched industry migrates to a new transport. Why? Because most people won't realize there's a choice and suffer the consequences of making it.
...MTBF, power consumption, ruggedness and noise level.
Similar story over at StorageMojo and Robin draws a similar conclusion.
MTBF - Infant failures about the same as discs, return rates higher
Power - Flash already near the bottom of the power curve, drives appear to have room to drop
Ruggedness - No moving parts a plus, perhaps countered by whole-block rewrites on write. Not enough data here
Noise - Flash wins, no contest
Bottom line? Not enough improvement to justify the cost, except in certain edge-conditions (like the eee PC).
I know of one author mentioned on TWIT - This Week In Tech. (I believe was John C Dvorak, but can't remember) that we was not going to put his book up on Audible.com just for the reason he wanted it not DRM'd.
That would have been Cory Doctorow, unsurprisingly. (I like Cory.)
I agree that QRCode is nifty, and hope that it and/or similar systems take off around the world, but this is a little different.
All the QRCode processing is done on-phone. This idea has a tightly-coupled client-server relationship, and is a step in the direction of distributed mobile code and data (overdue and welcome, in my book).
My biggest interest is how the trust model will work - if you subscribe to an image-processing service like this, do they own the picture, search metadata or profiling info? (Then again, I have trust issues.)
If the DRM is well-designed, the "secret" need only ever be known by a handful of people.
This is often the point of confusion. DRM cannot be completely effective, ever. DRM-protected content fundamentally requires three things be given to the end-user: A method of keeping the content controlled, a key to allow that content to be made available to the end-user, and the secured content itself. No matter how well-designed the lock, the publisher has to give the end-user the key for it to be used. Any further restrictions are simply enough smoke and mirrors to limit what a typical user can do. In the hands of a technologist, those distractions are ignored, and the unlocked content can be made available. I leave it to the/. community to provide counter-examples for each possible use-case.
Back in the day, certain wonks (myself included) were worried about the proliferation of social networking sites, and that records would not be transferable or interoperable between them. We worried that for example if you were dependent on a site and it went out of business, you'd have no way to extract your social network and take it with you.
Fast forward to today, and we see different behavior. People "friend" you all the time, and your social network becomes populated with many people, some of whom you've never met. At some point it becomes useless as an affinity group, and you'd like to cull the list to make it more useful. The trouble is you don't want to dismiss someone by removing them from your "friends" list, even though your relationship is tenuous at best. The cure appears to be that people abandon profiles and systems wholesale, and jump to a new system with a fresh profile. Friendster begat MySapce, then Facebook, etc. Abandoning the system alienates no one in particular, and lets the user start over with a fresh list.
I'd bet that the last thing users will want is to permanently carry all that baggage with them.
It works great over water. I used Boeing's Connexion service in ANA to and from Tokyo before the plug was pulled last December. A Skype test call was a little "chunky", but web, POP, and SSH sessions were OK.
Ok, I was in the same boat and think I just figured out what he means.
He means that the site offers to INSTALL CODE on your machine and you click Yes (e.g.: "Here's something to make you more secure, would you like to install it?") then you may be more likely to have been previously owned.
That's totally unclear in the article and confusing as all hell. With this piece of data, I see what point he's trying to make. I don't think it results in a secure transaction, but amusing.
While I can't speak to the integrity of the vendors in question, the technical details described do not hold up to examination.
First, cookies will not be available to a third-party site - the browser only returns them to the same URL that left them. If the scam site is able to run their code through the main site, then they can get the cookie.
Next, cookies are always written to disk.
Third, if the cookie is SSL encrypted, it's done at the main site's server and then sent over the http (or https) connection. Usually the cookie is a hash of some kind. Let's assume for a moment that it IS encrypted (and so that was done at the main site's server). The evil site would not have access to the main server's back-end (assumption - if they do, I'd say they're in collusion), and so would not have access to the symmetric key described. Basically, they couldn't use the cookie even if they could read it.
This all begs the question of what really happened in this transaction. Something appears to have happened, but it wasn't what was described.
Slashdot Mirror
Have you ever tried to talk out of ONE side of your mouth? Nobody can understand you.
Except dentists.
I would have though the same thing about J2EE, but every site ends up using proprietary extensions in Websphere, or whatever, and then has an terrible time migrating to another platform. It's called "vendor lock-in". I don't see why it wouldn't happen again in the cloud. Heck, there are still plenty of MAJOR sites that only offer certain features in specific browsers.
Use it for Amateur Radio Astronomy.
If your drive dies, you go to your backup, not a recovery service. If you have to go to a service, either your data backup plan failed, or you have a specific forensic need.
To the best of our understanding, Google keeps EVERYTHING. Think about that for a minute while I go off and Google something...
Then choose DSL and cable, or DSL and fibre, etc. If you choose two DSL providers, it is extremely likely that both circuits will end up in the same CO (central office) and may even be on the same DSLAM (the DSL "interface" at the CO). If that device fails, or there's a problem at the CO, you're off the 'net on both links.
You did it when you went from those to DVDs.
You did it when you went from DVDs to HD/BluRay.
You did it when you went from NTSC to QAM or ATSC. (substitute your national standards)
You'll do the NEXT time entrenched industry migrates to a new transport. Why? Because most people won't realize there's a choice and suffer the consequences of making it.
Similar story over at StorageMojo and Robin draws a similar conclusion.
MTBF - Infant failures about the same as discs, return rates higher
Power - Flash already near the bottom of the power curve, drives appear to have room to drop
Ruggedness - No moving parts a plus, perhaps countered by whole-block rewrites on write. Not enough data here
Noise - Flash wins, no contest
Bottom line? Not enough improvement to justify the cost, except in certain edge-conditions (like the eee PC).
Wow. Wrong and wrong.
Or you could listen to crank/solar-powered broadcasts on a radio with no external power source at all except the radio waves it receives.
That would have been Cory Doctorow, unsurprisingly. (I like Cory.)
Wow, like that would work. So in 90 days when 200 million factory workers don't get paid, the Chinese government is better off how?
I'm afraid it's more complex than you believe, and we have each other by the throat.
All the QRCode processing is done on-phone. This idea has a tightly-coupled client-server relationship, and is a step in the direction of distributed mobile code and data (overdue and welcome, in my book).
My biggest interest is how the trust model will work - if you subscribe to an image-processing service like this, do they own the picture, search metadata or profiling info? (Then again, I have trust issues.)
This is often the point of confusion. DRM cannot be completely effective, ever. DRM-protected content fundamentally requires three things be given to the end-user: A method of keeping the content controlled, a key to allow that content to be made available to the end-user, and the secured content itself. No matter how well-designed the lock, the publisher has to give the end-user the key for it to be used. Any further restrictions are simply enough smoke and mirrors to limit what a typical user can do. In the hands of a technologist, those distractions are ignored, and the unlocked content can be made available. I leave it to the /. community to provide counter-examples for each possible use-case.
Fast forward to today, and we see different behavior. People "friend" you all the time, and your social network becomes populated with many people, some of whom you've never met. At some point it becomes useless as an affinity group, and you'd like to cull the list to make it more useful. The trouble is you don't want to dismiss someone by removing them from your "friends" list, even though your relationship is tenuous at best. The cure appears to be that people abandon profiles and systems wholesale, and jump to a new system with a fresh profile. Friendster begat MySapce, then Facebook, etc. Abandoning the system alienates no one in particular, and lets the user start over with a fresh list.
I'd bet that the last thing users will want is to permanently carry all that baggage with them.
What, it's a truck now?
It works great over water. I used Boeing's Connexion service in ANA to and from Tokyo before the plug was pulled last December. A Skype test call was a little "chunky", but web, POP, and SSH sessions were OK.
Sprint. They were the first to lose the class-action lawsuit.
He means that the site offers to INSTALL CODE on your machine and you click Yes (e.g.: "Here's something to make you more secure, would you like to install it?") then you may be more likely to have been previously owned.
That's totally unclear in the article and confusing as all hell. With this piece of data, I see what point he's trying to make. I don't think it results in a secure transaction, but amusing.
First, cookies will not be available to a third-party site - the browser only returns them to the same URL that left them. If the scam site is able to run their code through the main site, then they can get the cookie.
Next, cookies are always written to disk.
Third, if the cookie is SSL encrypted, it's done at the main site's server and then sent over the http (or https) connection. Usually the cookie is a hash of some kind. Let's assume for a moment that it IS encrypted (and so that was done at the main site's server). The evil site would not have access to the main server's back-end (assumption - if they do, I'd say they're in collusion), and so would not have access to the symmetric key described. Basically, they couldn't use the cookie even if they could read it.
This all begs the question of what really happened in this transaction. Something appears to have happened, but it wasn't what was described.
Better than suggesting, I'd like to pay a bounty for some drivers I need. Anywhere I can do that?
I think this should be more like (though not literally) TOTAL_VULNERABILITIES = OS(X) * V(X), as happens when any two systems are integrated.
If you work with Amsat you can have your work shot into orbit. There are about 18 currently in operation, with launches starting in the 60's. Amsat is an international organization.
I believe that settlments are one difference between civil and criminal lawsuits. In criminal lawsuits it might be called a plea-bargain. IANAL.
Tell that to Yitzhak Rabin