Yeah, that's RAID 10. If this bug affects RAID 10, then it's a bigger deal than if it only affects RAID 0.

As I said:

Yes, I understood. And I way saying, yes, it seems clear that we would all care more if it were a problem with RAID 5.

I understand that you think "we would respond differently if this were RAID 5" is a sign of hypocrisy or something. But it's not really that.

It's a little like saying, "There was a design flaw in trash cans that cause items stored in the trash can to be damaged." And people respond by saying, "Yeah, well... that's not great, but it could be worse. Things stored in trash cans are usually things nobody cares about anyway."

And then you say, "Would you respond differently if this trash can problem were discovered in long-term storage bins?"

And so the response is, "Yes, we would care more about that. Of course we would all care more about that. Because people probably care about things in long-term storage bins, and usually put trash in trash cans. I understand that someone somewhere may be storing their valuable family heirlooms in trash cans, but they probably shouldn't be doing that."

I think you missed my point. I don't doubt such people exist. I doubt such people are generally safeguarding information that I think is important.

I'm going to go ahead and say that it mitigates the serious of the damage caused in actuality since most IT people entrusted with serious and important data aren't going to be that stupid. I mean, yes, I've seen some pretty stupid things, and I've seen professional IT techs set up production servers with RAID 0, but it's a bit of a rarity. There could still be some serious damage, but much less than if it were a bug affecting RAID 5 volumes.

I suspect not, since his point seemed to be that you shouldn't be using RAID 0 for data that you care about anyway.

It doesn't really make it ok for a bug to exist that destroys RAID 0 volumes, but it does mitigate the seriousness of the damage caused. And it's true: Don't use RAID 0 to store data that you care about. I don't care if the MTBF is long, because I'm not worried about the mean time, but the shortest possible time between failures. If we take 1,000,000 drives and the average failure rate is 1% for the first year, it's that that comforting to the 1% of people whose drives fail in that first year.

Nonsense.

It depends on what the data is, and what and how it's being used. There is no "correct" organization, and no "one true way" to deal with data. I would not recommend going around cramming documents into some set organization without understanding where the data is coming from and what people hope to do with it.

Your organization may work for your purposes, within the constraints of the company or organization you work in. I've supported a lot of different types of companies over the years, and personally, I've never found a one-size-fits-all solution. In each case, it really pays off to start off with no assumptions, and figure out what will work for that specific situation.

As an IT person, I hate questions like this. There's not enough information to give a solid answer. For example:

* What kinds of documents are you talking about? Text? Photos? Spreadsheets?
* What is the source of the documents? Are these currently printed out documents that need to be scanned back in? Are they currently digital, and in a particular file format?
* What will people need to do with them when these documents are retrieved? Do they need to be able to edit the documents?
* How much does formatting matter? If someone retrieves the document in 5 years, will it be important that all the line breaks and page breaks are in the same place? Does it need to have all of the correct fonts? Or are you more interested in being able to have access to the information itself?
* When you say that the application will need to allow ".docx, doc, .pdf, etc", what formats are in "etc"?

There may be many other relevant questions, my point is that there just isn't enough detail here. In general, if the most important thing is that you have a printable document that you want to be able to print out from any machine, maintaining the formatting as much as possible, then PDF is a pretty good choice (be sure to embed the fonts and include searchable text!). If you already have a bunch of Word documents and you want the formatting unchanged, and would like the capability to edit the document after it's retrieved, then I'd typically just recommend keeping it as a .docx. It keeps things simple, will be widely supported, and prevents the risk of something going wrong while you're converting to another format. If you like the idea of using .docx because of what I just said, but want something more "open", then ODF is probably worth looking into.

Really, there are only so many choices, and each have advantages depending on your specific needs.

There's no subways to JFK either, really. Yes, yes, you can transfer to the Air Train, which is better than the bus. But honestly, there's no subways to any of the airports. No matter what, you have to transfer to some other train or bus or something, or else take a car.

And sure, JFK may be more convenient for you, but it's less convenient for other people. I can spend over an hour transferring trains trying to get to JFK and pay $2.50 for the subway and $5 for the air train, or spend $50 for a car to JFK and take god-knows-how-long depending on traffic, or I can spend $20 on a car to LaGuardia and be there in 20 minutes. Guess which option I prefer.

Or, hopefully, it means Dropbox has more money to pour into development, improving the services they provide. Unfortunately, it usually just means that some billionaire will be billionairier.

Yeah, that's what I was thinking. My understanding is that the NSA officially claims not to collect information on US citizens when the data resides solely in the U.S. However, they do monitor data going in and out of the U.S., so if you're an American located in the U.S., then storing data outside of the U.S. seems to open you to monitoring.

On the other hand, I also thought part of what Snowden released showed that they didn't exactly stick to their own rules, and they were collecting all kinds of data that they weren't really supposed to. I could be wrong about that, though. Reporting on the issue has been terrible.

To play the devil's advocate, have you considered that maybe younger people always are "whiney, lazy, idiots," and older people are the ones with enough experience to see it.

More likely this is a feature that people want so that they can easily/automatically spin up Linux VMs in Hyper-V environments, without having to make use of a bunch of different scripts in a bunch of different languages.

What about an IDE for formulating normal scripts that mere mortals can even remember?

I don't see what the objection to an IDE is. If I'm writing anything more than the simplest script, I find it helpful to have some kind of debugging tools.

It's not really fair to say that Powershell is, "a kludged attempt to bring CMD.exe to something closer to bash.... 20 years later." You can argue that it's kludged (I don't think it really is) or that it's late to the game (it is), but it's not really like Bash. Bash treats everything like text, whereas Powershell treats everything as an object. Bash relies on a lot of stand-alone applications being chained together, whereas Powershell tends to have more built-in functionality which is supplemented by various extensions.

Whether you like those differences or not is a different issue, I suppose, but it's not like Bash. It's not even trying to be like Bash.