"Sounds to me like they are implying your data is secure until you have a chance to wipe it remotely. Maybe that was the "something" the "/. crowd" saw and jumped to the wild conclusion that their data was actually protected???"
You know, I read the paragraph you quoted and even after repeated readings never came to the conclusion that you did. In other words, nowhere does it say your data is protected by encryption. The feature it is touting is 'Remote Wipe' and that feature happens to use some encryption to do its business.
"Most users _never_ read their event log, so logging the failure like this is next to useless."
The original complaint was that Windows doesn't report disk errors, which is not true. If this were Linux, people would point out that the information desired is right there in the logs..
Software RAID isn't (wasn't?) even available on consumer desktop versions of Windows, so you'd expect some minimum level of cluefulness on the part of the user and less handholding on the part of Microsoft.
"The big problem in this picture is the way that Windows deals with drive errors. It doesn't report them and people commonly discover that one of the drives in a mirrored pair is dead when the second drive dies and leaves them with nothing."
Care to back that statement up? I've messed with software RAID in Windows 2003 server for years and have never had a drive failure not reported to the Event Log.
"You don't need to MD5 if you're using rsync. The rsync algorithm already uses checksums to ensure the files are bit-for-bit identical. In fact, rsync 3.x uses MD5."
Rsync, by default, does not necessarily do this. I've seen situations where rsync would happily copy files from a remote host over ssh to a destination host and the resulting files failed an independent MD5 test. Rsync was not causing this trouble - but it did fail to detect it. Forcing a checksum of every file (using "-c") would let rsync detect the failure to copy properly (after the entire file was done) and it would retry.
In the end, a router and one of the hosts were rebooted and the problem went away. The point is that just using rsync and ssh does not guarantee anything.
Two business sites that I need to visit on a regular basis don't work with Safari or Opera - but they work with IE and Firefox. Not to start a war, but if your code is specific to *any* browser, it's probably broken.
"There's no such thing as a hypervisor that has absolutely no performance penalty over running native."
Actually, back in the day, it was sometimes faster to run an operating system under VM (like DOS/VS) as the hypervisor was smarter about resource management than the guest OS was.
"I don't get the point of pressing a CD. Who has a CD player anyways nowadays?"
You're kidding, right? How about "everyone on the planet"?
Sure, there are *other* ways to listen to music, but your question was silly. I have three 'CD players' within reach. If I actually get up and count, I estimate I'll find half a dozen before I start opening boxes. After that, there's probably another half-dozen parked in old machines.
Ignoring all the off-topic responses, I'm waiting too.
I fear that the manufacturers of these products look at the tepid reaction from the market and think "There's no interest in this sort of thing", rather than "our product is crap and nobody will buy it".
Vinge-esque* contact lenses and all may arrive someday, but that day is a long way off. A lightweight HMD with decent resolution would be great.
A.
* Try "Fast Times at Fairmont High" for a Vinge short story with references to contact lens displays, wearable computing, etc.
"HAM, though not an acronym, is used and written with capital letter to show the respect and in remembrance of the three scientists who have contributed in..."
Right. That's complete bull-puckey. Fiction. Made up.
If you go back ten or twenty years ago, you'll find very few (if any) spellings of ham in capital letters. It's not an acronym, it's not meant to honor anyone, it's just a word. Specifically, if you go read some old QST magazines from the 40s, 50s, or 60s you'll see plenty of references to hams. Not in caps.
"a host of surprising new applications becomes possible"
Surprising? New?
No. Please read some Vernor Vinge. To stay on topic, I recommend "Fast Times at Fairmont High", which covers the concept of augmented reality quite well. Someone wake me when technology catches up to that.
That said, I think it's wonderful that someone is working on it.
"Seriously, do people still not realise that OS X is just UNIX with a pretty UI?"
Actually, I prefer to think of OS X as UNIX with a good UI. Alas, I can't say the same for the OS X Server tools.
A. (on topic: at my company we back up our database to three different boxes, in two different physical locations, every day. It's also replicated across the country to a secondary facility in realtime. The backups are periodically written to DVD and stored in a safety deposit box. Oh yea, all this is encrypted. I hope we're safe.)
"On a modern Linux distribution, it's actually okay to modify stuff that the vendor sends you"
Let me fix that for you. "On Linux, there's an attitude that it's ok to modify stuff the vendor sends you."
Good luck with that.
(I'm on a Mac, and I download ported-from-linux, OS X-installer packaged stuff from time to time, and more often than not it wants to install into/usr or/usr/bin with no option to go anywhere else (asterisk comes to mind). In my world, that means it doesn't get installed. Period. Yea, maybe I'll hack it up to install into/usr/local, but I generally don't have the time or inclination to fix broken stuff)
"Why are Apple's updater and Perl's CPAN shell both trying to update the same file? If the file's there as part of the Apple OS then only the OS's package manager should touch it, and Perl should leave it alone (installing its own version in/usr/local if necessary)."
Why must we learn these lessons again and again? Back in the beginning of time (1983), we learned the following:
Rule #1: Never change *anything* that [vendor] sends you
Rule #2: Always keep your stuff separate from [vendor]
"It's modded funny, but it is accurate. If you don't like Google's policy and they won't change it....vote with your feet. I actually uninstalled google earth because of this."
It's not funny. I also uninstalled all Google software from my machine, and then ran the directories removing any leftovers.
A. (and don't blather on about Apple Software Update - you can turn that off/tell it how often to update/etc.)
"While this is a good idea in the sense that no one likes being electrocuted, the risk of DC shock is more about burns than anything else, since there isn't any alternating current to cause fibrillation of the heart."
This is a dangerous misconception. At voltages strong enough to overcome the resistance of the skin and cause fibrillation, DC will kill you just as effectively as AC (maybe *differently*, but you'll still be dead).
Some people think that because defibrillators are primarily DC that DC isn't dangerous to your heart. An interesting tidbit is that originally, defibrillators were AC devices.
"I wonder how broken the intarwebs would be to me if I simply deleted all the MD5-based root certificates from my box? Would I even notice?"
I think a better idea would be to simply delete all the certificates from your box (CA certs included!). Then start marking individual web certs as trusted after you inspect them yourself.
"I find it in the same vain as taking warning stickers off of things, and letting darwinism do it's thing."
So roads should not have guardrails (just drive properly), bridges need not have handrails (watch where you're going), sidewalks not painted (should just 'look both ways'), ad nauseam, ad absurdum?
Slashdot Mirror
"...instead of trying to discredit my post with an obvious misdirection."
You clearly overestimate the significance I attribute to your post.
A.
"Sounds to me like they are implying your data is secure until you have a chance to wipe it remotely. Maybe that was the "something" the "/. crowd" saw and jumped to the wild conclusion that their data was actually protected???"
You know, I read the paragraph you quoted and even after repeated readings never came to the conclusion that you did. In other words, nowhere does it say your data is protected by encryption. The feature it is touting is 'Remote Wipe' and that feature happens to use some encryption to do its business.
A.
"It's like people who go 45 MPH in the left lane on a 55 MPH road. Yeah, that's definitely what the laws say you can do"
Actually, around here failure to keep right will net you a $100 fine. Just sayin'.
A.
we now return to your regularly scheduled thread
"Most users _never_ read their event log, so logging the failure like this is next to useless."
The original complaint was that Windows doesn't report disk errors, which is not true. If this were Linux, people would point out that the information desired is right there in the logs..
Software RAID isn't (wasn't?) even available on consumer desktop versions of Windows, so you'd expect some minimum level of cluefulness on the part of the user and less handholding on the part of Microsoft.
A.
"The big problem in this picture is the way that Windows deals with drive errors. It doesn't report them and people commonly discover that one of the drives in a mirrored pair is dead when the second drive dies and leaves them with nothing."
Care to back that statement up? I've messed with software RAID in Windows 2003 server for years and have never had a drive failure not reported to the Event Log.
A.
"So, what, bacteria don't deserve to survive?"
You are referring to the bacteria that we put into the clock?
Two wrongs don't make a right.
A.
"The universe is hostile, so impersonal; devour to survive, so it is, so it's always been."
There is a moral difference between "devour to survive" and "killing living things to power your clock".
disclaimer: I have no connection, nor do I wish to have any connection, with PETA or any of its members.
A.
(who chases flies out the window, where they can meet their demise in some spider's web)
"You don't need to MD5 if you're using rsync. The rsync algorithm already uses checksums to ensure the files are bit-for-bit identical. In fact, rsync 3.x uses MD5."
Rsync, by default, does not necessarily do this. I've seen situations where rsync would happily copy files from a remote host over ssh to a destination host and the resulting files failed an independent MD5 test. Rsync was not causing this trouble - but it did fail to detect it. Forcing a checksum of every file (using "-c") would let rsync detect the failure to copy properly (after the entire file was done) and it would retry.
In the end, a router and one of the hosts were rebooted and the problem went away. The point is that just using rsync and ssh does not guarantee anything.
A.
"I didn't invent anything this clever when I was 15. How about you?"
I could tell you what all the complainers were doing when they were 15, but I'm sure you know already...
A.
"especially if you develop for business sites"
Two business sites that I need to visit on a regular basis don't work with Safari or Opera - but they work with IE and Firefox. Not to start a war, but if your code is specific to *any* browser, it's probably broken.
A.
"There's no such thing as a hypervisor that has absolutely no performance penalty over running native."
Actually, back in the day, it was sometimes faster to run an operating system under VM (like DOS/VS) as the hypervisor was smarter about resource management than the guest OS was.
A.
"I don't get the point of pressing a CD. Who has a CD player anyways nowadays?"
You're kidding, right? How about "everyone on the planet"?
Sure, there are *other* ways to listen to music, but your question was silly. I have three 'CD players' within reach. If I actually get up and count, I estimate I'll find half a dozen before I start opening boxes. After that, there's probably another half-dozen parked in old machines.
A.
Ignoring all the off-topic responses, I'm waiting too.
I fear that the manufacturers of these products look at the tepid reaction from the market and think "There's no interest in this sort of thing", rather than "our product is crap and nobody will buy it".
Vinge-esque* contact lenses and all may arrive someday, but that day is a long way off. A lightweight HMD with decent resolution would be great.
A.
* Try "Fast Times at Fairmont High" for a Vinge short story with references to contact lens displays, wearable computing, etc.
"HAM, though not an acronym, is used and written with capital letter to show the respect and in remembrance of the three scientists who have contributed in ..."
Right. That's complete bull-puckey. Fiction. Made up.
If you go back ten or twenty years ago, you'll find very few (if any) spellings of ham in capital letters. It's not an acronym, it's not meant to honor anyone, it's just a word. Specifically, if you go read some old QST magazines from the 40s, 50s, or 60s you'll see plenty of references to hams. Not in caps.
A.
"Actually it is an acronym HAm Radio is High Frequency Amateur Radio."
and actually, you're making stuff up (and if not you, someone else).
A.
"a host of surprising new applications becomes possible"
Surprising? New?
No. Please read some Vernor Vinge. To stay on topic, I recommend "Fast Times at Fairmont High", which covers the concept of augmented reality quite well. Someone wake me when technology catches up to that.
That said, I think it's wonderful that someone is working on it.
A.
"do you have a backup copy of the encryption keys too?"
Inasmuch as they exist in the heads of multiple people who do not generally travel together, yes.
A.
"Seriously, do people still not realise that OS X is just UNIX with a pretty UI?"
Actually, I prefer to think of OS X as UNIX with a good UI. Alas, I can't say the same for the OS X Server tools.
A.
(on topic: at my company we back up our database to three different boxes, in two different physical locations, every day. It's also replicated across the country to a secondary facility in realtime. The backups are periodically written to DVD and stored in a safety deposit box. Oh yea, all this is encrypted. I hope we're safe.)
"On a modern Linux distribution, it's actually okay to modify stuff that the vendor sends you"
Let me fix that for you. "On Linux, there's an attitude that it's ok to modify stuff the vendor sends you."
Good luck with that.
(I'm on a Mac, and I download ported-from-linux, OS X-installer packaged stuff from time to time, and more often than not it wants to install into /usr or /usr/bin with no option to go anywhere else (asterisk comes to mind). In my world, that means it doesn't get installed. Period. Yea, maybe I'll hack it up to install into /usr/local, but I generally don't have the time or inclination to fix broken stuff)
A.
"Why are Apple's updater and Perl's CPAN shell both trying to update the same file? If the file's there as part of the Apple OS then only the OS's package manager should touch it, and Perl should leave it alone (installing its own version in /usr/local if necessary)."
Why must we learn these lessons again and again? Back in the beginning of time (1983), we learned the following:
Rule #1: Never change *anything* that [vendor] sends you
Rule #2: Always keep your stuff separate from [vendor]
(thank you Melinda)
"It's a lot simpler to make up a point than to actually make one, isn't it?"
And me without mod points. Damn.
A.
"It's modded funny, but it is accurate. If you don't like Google's policy and they won't change it....vote with your feet. I actually uninstalled google earth because of this."
It's not funny. I also uninstalled all Google software from my machine, and then ran the directories removing any leftovers.
A.
(and don't blather on about Apple Software Update - you can turn that off/tell it how often to update/etc.)
"While this is a good idea in the sense that no one likes being electrocuted, the risk of DC shock is more about burns than anything else, since there isn't any alternating current to cause fibrillation of the heart."
This is a dangerous misconception. At voltages strong enough to overcome the resistance of the skin and cause fibrillation, DC will kill you just as effectively as AC (maybe *differently*, but you'll still be dead).
Some people think that because defibrillators are primarily DC that DC isn't dangerous to your heart. An interesting tidbit is that originally, defibrillators were AC devices.
A.
"I wonder how broken the intarwebs would be to me if I simply deleted all the MD5-based root certificates from my box? Would I even notice?"
I think a better idea would be to simply delete all the certificates from your box (CA certs included!). Then start marking individual web certs as trusted after you inspect them yourself.
A.
"I find it in the same vain as taking warning stickers off of things, and letting darwinism do it's thing."
So roads should not have guardrails (just drive properly), bridges need not have handrails (watch where you're going), sidewalks not painted (should just 'look both ways'), ad nauseam, ad absurdum?
A.