I specifically quoted OPs statement about Explorer, a core Windows component, and Adobe, a popular, non-Microsoft program, and was responding to that. I don't know if various Office programs exhibit this behavior, but if they do, the people at Microsoft responsible should be blamed. But not the people at some unrelated division.

The point was that this isn't something inherent to the design of Windows. It was something that was caused by the choice of flags used by the programmers when calling the Windows API. With that said, there's a legitimate issue in renaming under Windows, caused by the operating system itself, but it doesn't involve files; it involves directories: you cannot rename a directory if a file inside that directory is open.

Oh look, I can't rename that file in Explorer until I close the file in Word (repeat for any other program and file). [...] Hell, I can't even rename a PDF file that I happen to simultaneously have open in Adobe Reader, and it's read-only!

Don't blame Windows for that. Blame the programmers who coded the app in which you opened the file. Because they are the ones who called CreateFile to open the file, and set the share mode to either 0 (which means that nobody else can open the file) or to FILE_SHARE_READ (which means others can only open the file to read its contents). If they had set the share mode to FILE_SHARE_DELETE in one API, you could delete and rename the file to your heart's content!

But I guess it's just easier to just blame Microsoft.

TNG certainly showcased a tablet like device (the "PADD") in most of the shows.

[...] the "educational" software available on linux (for free no less) is vastly more available/abundant than on windows

Even if that is true, that may not be the only concern. When your book comes with a CD and bundled apps that require Windows, the abundance of other software (free or not) on Linux doesn't help. When your school requires that a certain online-test-taking application (really, just a custom shell for an IE control) be used to access the online tests, that your Linux browser of choice can also render HTML (better than IE, even) doesn't help.

There is more to this than "let's get kids using Linux, yay!". The simple fact of the matter is Windows is used in the vast majority of desktop and so educational software written by publishers and used by school usually targets that platform. Kids have to use Windows software if their school curriculum mandates the use of materials that only run on Windows. It's no different than the situation some of us face at work, where we have to run the software that our employers require. I have to run Windows at work, because I develop software for a living and the company develops Windows software. I also have to use Outlook because that's what the IT department requires and they don't care that Thunderbird can also access the mail server too.

I don't necessarily disagree re: OpenOffice/LibreOffice/whateverit'scalledtoday. It is pretty good in saving most basic stuff in vanilla .doc although I wouldn't call it perfect. I've never used the spreadsheet and presentation apps, so I can't speak to those but let's assume that they are also good enough for the majority of school work.

The problem is that this isn't the only suite of apps that kids have to use for school work, your sisters' experience notwithstanding. Some of those apps, luckily, are done in Java, so they can work on Linux systems, but not all. A friend of mine had to deal with a number of Windows-only apps that are required for his kids schoolwork, and he eventually gave up and installed XP, rather than deal with Wine or contacting the school and the publisher. So while in your particular case and context, Linux works fine, you should be careful about extrapolating that, therefore, Linux works fine for everyone in the same context.

As for your contention that most stuff is done through a browser, online, it's true that more and more stuff is now done through browsers. That's not as great as you imagine. Do you know how many educational applications have browser version checking and how many of them actually "require" the use of IE? The reason, of course, is that they want to minimize their testing & support, and the webapp might work perfectly on your browser of choice once you tweak the browser agent string. And while you may be able to easily figure that out and do the necessary tweaks, this isn't about you. It's about a kid that has no idea about Linux, Windows and browser agent strings, or about their technically inept parents.

Does not compute... He didn't say there's NO educational software available on Linux. Only that most such software (and games) are Windows-only. Which is certainly true.

And while it may be fine to say that there are Linux alternatives for some educational apps, good luck having a kid find the Linux alternative to the particular app that comes with the book used in the class or the one which his school/teacher requires that he use. But let's say the kid does find the Linux alternative. Unless that alternative is 100% compatible with the Windows version (which the teacher is likely to use) vis-à-vis the files/output it generates then it's practically useless.

But only practically. Through the wonders of the GPL we can tell the kid to fix the app and commit the changes back to the community and everyone will be happy. Especially the kid who will make a dead-on Homer Simpson "Oh, look at me! I'm making people happy! I'm the Magical Man from Happy-Land, in a gumdrop house on Lollipop Lane!"

But that only keeps you safe if your storage media is somehow stolen. Given that the media is soldered into the phone, that's an unlikely scenario.

First of all, it is not an unlikely scenario. Why should someone bothering with getting the media when they can simply get the container of the media much more easily. Secondly, that is the only scenario where encryption helps -- your phone is stolen, or taken by police or somesuch. I would venture to say that is a very probable scenario, and from a risk analysis point of view one that must be addressed. And that's why encryption makes sense.

But if the attacker can gain access to your phone (or computer) so as to modify it and then return it for you to reuse it's game over. There's nothing that can protect against such an attack.

There is no real way of storing a password securely in an encrypted form, without requiring a password to decrypt it.

That is certainly true. But at the same time, it points to how Android (or iOS, or WP7 and so on) could implement better security. Encrypt all files (say with AES-128 for the purposes of this discussion) using a randomly generated AES key. Then encrypt that key with a password/passphrase required when the phone boots. This would ensure that data would be stored securely when at-rest, which is a step in the right direction.

Protecting the device while it's running is, of course, trickier. Clearly, the device needs to be able to securely lock itself and allow unlocking only when the proper credentials are used. A more tricky question is what happens when you plug a USB port into the device. Ideally, the system should prompt in a secure fashion, asking for authorization to enable the USB port. Furthermore, critical security-related files, such as the keychain and any encrypted data stores should only be exportable in their encrypted form.

Someone might, at this point say, "ahh! but the attacker can install some special software on the phone and it's game over!" True, an attacker can do that. He can gain access to a computer/smartphone, modify it and then return it for you to use. Frankly, there's no way to protect against that scenario, and it is not the scenario that encryption is supposed to solve. Encryption is meant to allow your data to be secure and non-accessible after the device itself is taken from you -- whether it is stolen by a thief or taken by the police during a traffic stop or during an arrest.

OK, so you store a hash. Now this means that the hash (remember, hashes are one-way -- you can't get the password back from the hash) itself must be usable to log into your account. In other words, the hash itself is a password. Password hashing is meaningful only on the server-side (by server-side, in this case, I mean whichever side of the protocol does the validation of the username/password and grants access) and not on the client side.

DriveShare is pretty nice. It's really kind of addictive to be able to access all my files from my iPhone and from any machine and to not worry about having to give Dropbox (or any Dropbox) access to it.