"How can you even speculate about that? (...) basically you're saying 99% of the population should be screwed because 1% "
That's USA; not a democracy but a republic. That, yes, 99% of population should pay attention to the other 1% and not crush them by their own majority is not a speculation but the very nature of USA as per the specs. And then...
"Why should we favor that 1%? If they want cheap mail"
Mail and press are the basis of free speech. Need I to say any more?
Quoting James Madison, "It is of great importance in a republic not only to guard the society against the oppression of its rulers but to guard one part of the society against the injustice of the other part. If a majority be united by a common interest, the rights of the minority will be insecure."
"You still pay more (0.55 EUR vs. 0.44 USD), but the US service is definitely worse. In Germany, mail is delivered within half a day 99% of the time (drop it off at 5pm, get it in the mail at 9am), in the US it is two to three business days."
Take size into account. Germany is about the size of a State, so in order to compare you should know how much intrastate mail takes. In the other hand, USA can be compared to EU and definetily posting something from Germany to, say, Italy does not take one working day but more 3-5.
"So, you say people have to force you in order for you to acknowledge their free contribution?"
No, he didn't say so. But what he said is that if you forcibly want something, you'd better put it on write in a binding way or else you'll get it... or not. Not rocket science, anyway.
"The ability to map complex relationships. I don't want 50 alerts that I can't reach host X, host Y, etc. I want one alert that I can't reach router A."
Nagios do this. I know, I configured mine that way.
"Even better, I want to map things so that I can say "end user application XYZ is not accessible in Kansas due to X being down"."
Nagios can do that, while I never deployed it that way.
"I want my monitoring solution to understand HA and service degredation."
Nagios do this. I know, I configured mine that way.
"I want programmable rules about what happens when X is down or Y is down."
Don't know what exactly do you mean, but if you mean the ability to automatically trying to recover a failing state, I think Nagios can do that. Not that I would want go that path: I'm quite averse to "self-healing" systems and prefer early and meaningful alerts and then push brains into it.
"I want many options for escalation. If X doesn't acknowledge, try Y after 15 mins, etc."
Nagios do this. I know, I configured mine that way.
"I don't ever, ever want a pager to explode or be flooded. A problem should be noticed once and tracked. There should be no pager blizzards."
Nagios do this. I know, I configured mine that way.
"Of course, I don't want this thing relying on my mail system for paging because, of course, my mail system could go down. An ability to dial out if the mail system is down would be nice."
Nagios do this. I know, I configured mine that way.
"I want agents, hooks, interfaces, third-party add-ons, and every possible way of tying something into the monitoring system. I don't want dumb limitations like "you can only get an exit code from the OS and it acts on that" or something. For big monitoring, it's almost mandatory that some kind of API for agents is exposed."
Don't know what exactly you mean, but I know you can extract out of Nagios the very same information it is managing though i.e. a socket or push it to a database for further inspection. Apart of this, it's open sourced, you know.
"I want "I'm working on it, stop paging" blackouts. I want to be reminded to lift them."
Nagios do this. I know, I configured mine that way (well, to autolift the "I'm working on it" after Nagios detects the service on-line again... and it automatically closes the previously opened ticket on our service desk too).
"I want it to tie into my change-management system. If I open a ticket and say that server X is down for 2 hours on this date, I don't want to have to remember to black it out."
Nagios do this. I know, I configured mine that way.
"I want reports. I don't care about silly little charts and graphs, but a history of everything that has every gone wrong with device Y would be nice."
Nagios do this. I know, I configured mine that way. It is the "little charts and graphs" where Nagios is quite lacky, in fact.
"I want more info on my page-receiving device than just "HOST X IS DOWN". I want context so I can decide if I have to drop everything immediately."
Nagios do this. I know, I configured mine that way.
"These are some of the things that make sane large monitoring systems. I don't think any open source product has all of them, alas"
You didn't research on this that so much. Please note that I'm not affiliated to Nagios in any way, but I'm just a satisfied user.
"Yes, but the point was not that they used "contradicts", but "flatly contradicts", which sounds like it shouldn't. So, yeah, I think AC's point is completely valid."
No, it isn't. AC's point is right but it is irrelevant too. The point of saying that EU's past decisions "flatly contradict" this USA decision is about how strange it seems the case that high order legal experts from cultures basically so similar can reach to so opposite positions on things that seems to be so basic as what's privacy in our current computerized world. And yes, it seems quite strange.
What the USA decision seems to forget is the "prudence in valuation" principle: while an IP address can't really identify a person undoubtfully on all cases, it is relevant enough as a general matter to be protected under privacy laws, being that privacy is a highly valued principle (definetly above a privately held company's quarter benefits).
So, in practical terms:
* The RIAA wants to use an IP as a clear proof that someone entered into criminal offense? The "prudence in valuation" would indicate that an IP address is not proof enough. But!
* The RIAA wants to freely collect IP address-bounded activities disregarding privacy laws (since "IP is not personal data")? Then "prudence in valuation" would dictate that RIAA can't do that since an IP address is near enough to be boundable to a single person as to be protected under privacy laws.
By the way, that's basically the interpretation of EU courts (to date: RIAA-like European institutions' greed and power are a constant menace to change this) .
"Without ID: "I am Napoleon!" "Here's a white coat, sire. Long Sleeves, befitting Imperial majesty."
With ID: "I am Napoleon! Release me!" *displays falsified ID* "At once! Please forgive us you majesty!""
And then you are basically talking about a no-problem.
Without money, at the restaurant: I'm hungry, give me a roast-beef. Sorry sir, no money, no menu. With falsified money, at the restaurant: I'm hungry, give me a roast-beff. Well, in theory the restaurant owner has now a problem, in fact, falsified money is not such a big deal: we know how to make good enough bank notes.
A falsified ID is a theoretical problem too, that any citizen on countries with ID cards will confirm you to be "not such a big deal" either (even less than falsified money: since there are much, much less ID cards than bank notes, they are quite harder to falsify too).
"If we all have unique id numbers to identify us, then someone can impersonate us by knowing that number."
That's plain stupid.
Here, on Slashdot you are identified as Palestrina. If you were right I could impersonate you on Slashdot by knowing that you are identified here as Palestrina which I already know. See the stupidness? One thing is your identification which, by definition must be public, and a completly different thing is how to stablish the link between you, the real person, and your identifying tag. Obviously doing it by the fact that you know a public identity seems to be not quite an intelligent movement.
"The US government is responsible for Social Security Numbers, yes. If the security of that system is vulnerable to social engineering, then it should take reasonable steps to eliminate that security hole."
And what exactly the security problem is?
Let's accept that SSNs are in fact unique. Then, what's the problem with using them in order to qualify you as "you"? And provided that SSNs are a good and acepted way to stablish you as "you" what's the problem with letting know your SSN to whichever you want to know you as "you"? There should be no problem to tell your SSN to whichever you would say your name since they are the same thing.
And then here comes the problem: you can't get into a bank and retire the founds of John Smith just by saying "Hi, I'm John Smith and I want all my money" still you can do quite a lot of things by the equivalent of "Hi, I'm 12355564899 and I want all my money". That's the stupid part, giving more authority to someone saying -and I mean plain saying, "I'm 12355564899" than "I'm John Smith" when they both are basically the same thing.
"What were the steps that led down the slippery slope of using them for identification?"
The problem is not that the SSN is used for identification, with very few corner cases is guaranteed to be unique, so it's a good candidate. The problem is when it's used for *qualified* identification, and not the number but just knowing it. That's the mad part. Proper nouns have been used for ages as an identificative token: "Hi, Joe, this is my friend Mike" and there's no problem with that (given a much limited scope, of course). But you really know that me calling myself "John Doe" doesn't give to that token too much authority.
The problem is not identifying somebody as being 1243839845B, which is not a bad idea provided there's only one 1243839845B and there's an interest on univocally identifying people (which is a different problem). The problem comes when all the comprobation you do is the like to "Hey, he must certainly be 1243839845B. How do you know? Because so he says".
This is in fact an acknowledged problem almost everywhere but USA: that's why you are identified as 1243839845B, not because you say so but because you say so *and* can produce an ID card with that number, your photograph and your fingerprints on it.
Disregarding the question of nationwide identification being good or bad (and in fact, USA has already disregarded this problem too or else the SSN wouldn't be used for identification purpouses) this news seems to be absourd out of USA: well, my ID number is 34980233, there you have... so what?
"That's nice, but the submitter is asking about RAID 1."
I think he's asking the wrong question anyway.
"Based on past experiences, I have decided that only my data is worth saving"
See? He is asking for backup, not RAID. It has been said one thousand times but it seems it must be said again: RAID is *NOT* in order to protect your data. NOT, NOT, NOT and then NOT again.
RAID (not talking about RAID-0) is there in order to enhance your data's avaliability (as in, say, instead of being able to get to my data 99% of the time, I can get to it 99,9%) but when it's hosed, it's hosed. To protect your data you need backups, not RAID.
"Of course, such a setup should secure my data"
Of course not. Of course you will get quite a funny face when you discover it. Quite more or less the one that had the guy from this story, about six months ago, with the very enlightning title "Why Mirroring Is Not a Backup Solution": http://hardware.slashdot.org/article.pl?sid=09/01/02/1546214
"Even more importantly, I want any drive and its data to be as safe and portable as possible"
Then, *even* if RAID could be considered for data security (which is not) you already answered your question: as a general matter, hardware RAID will only work when using exactly the same controller model, possibly up to its minor revision. You can't count to break a hardware-managed mirror, take one disk to a standard SATA controller and get any data out of it. If your controller dies and miracolously doesn't take the disks with it you can't count on buying a different RAID card (as it will most probably be in about a year for consumer-grade hardware) and get any data out of the mirror. So you should go with software RAID.
"...are you saying that MySQL doesn't support foreign key constraints?"
It does... on innodb tables, not on myisam. Most mysql implementations will create tables using myisam unless explictily told otherwise and just will silently ignore foreign key constraints is such a case.
But that was not the point for this case: the app was using mysql because it was "legacy"; you can bet it is not using foreign keys and it's managing intertable data integrity in code. And then, most implementations need using foreing keys almost as soon as it has more than two tables. What was the use-case in practice for a RBDM without such support (as it was back in the not so distant day) but plain ignorance? Not to say there *can* be a use case for going without referential integrity but just look at data schemas of most apps you can download from, say, freshmeat, take it as a reference for the other bazillions of internal-only apps in use in companies and tell me on straigth face that an abysmal majority of them are not using mysql due to plain ignorance.
"Really, you don't need to learn PostgreSQL if MySQL is meeting your needs."
The real problem is that MySQL only *seems* to meet some needs because the one with them doesn't know any better.
Nine out of ten times (to say the least) when somebody has told me "but MySQL covers my needs" it turned out he had no idea what their real needs were and what were the tools he could use (both "real" and logical) so he could pick the best fitted.
While ignorance is a reason, it's not a very glamurous one.
"the original poster did state that his app was working fine as is with MySQL."
So he thinks. From past experience I'd bet he simply doesn't know better.
"I've still got one application hitting a MySQL database because it works fine - all it does it let the company secretaries enter in phone calls that their bosses receive in a help desk type fashion)"
And since you are using MySQL all your referential management is done in code (phone table should have person's id column as a foreign key from persons table, for instance). Not only it makes it more bug-prone but it makes it more difficult to modify or add new features.
"The key thing was this company hired top notch security and admins and let them do their job."
Do you think they went for free or at a cost? And do you think that once hired everything was done or that such a staff needed counseled further costs on antivirus/malware fees and appliances, on test environments, on hours to develop and test proper policiesIf at a cost... don't you think proper all these things should be added to the TCO of the solution?
"This is really the cost of hiring unqualified people just because they MCSE's and the like."
Isn't it Microsoft's slogan that it's very easy to manage and competent technicians cheaper than their unix colleages and is it not the MSCE the very approved means from Microsoft to mark a valid professional for its products? Oh, and by the way, does Microsoft give MSCEs for free now, or are they at a cost too?
"People use whatever technology is good for them."
Wrong!!! People use whatever technology they *think* is good for them. That's what marketing is for.
"Each has costs, each has benefits, each has security issues, each has usability issues, each has moron users, each has technical users that can hack it to make it work, each is attacked by criminals to exploit, each can be used by governments where they see fit, each can be used by non-profits where it fits, and each can cost whatever the f*ckin' money it wants, each can be bought by whomever in a box, DVD, flash drive, ftp, torrent, or whatever..."
Which is far long to say each share the same costs, which is the very point of the article.
"you can put the cost into the "stupidity" column if you wish:)"
But then do not forget that "Linux is difficult and you will need very expensive sysadmins, but Windows is easy and even a drunk monkey can manage it". When your clients don't want to pay for hardening their systems they do because they already payed for Microsoft products and they were sold on Microsoft products because they are simple and functional, so their "stupidity" is a direct output from the fact they are using Microsoft. You can put the cost into the "stupidity" column if you want it but don't forget that the "stupidity" column still does sum up to the TCO of choosing Microsoft by design.
"One of the companies I consult for has something like 30,000 desktops. They were not affected by Conficker in any way shape or form. In fact, I think they were bitten by the "anna kournikova" thing back in 2000 or 2001, and never again had any problems with worms or viruses. How is this possible? I don't know. Maybe some common sense was involved."
Have you stopped to think that maybe it was not only "common sense"? That it might be some money involved too? That maybe the "kournikova experience" meant some heads were cutted off and new more senior ones were hired and trained and payed at higher rates; that new expenditures in antivirus, security appliances, more man-hours in maintenance, procedure approvals, testing deployments and staff education were incurred and that all those things might came at a price tag, surely at a cost percieved as lower than the "kournikova incident" but still at a very real and undenyable cost?
"That's clever, isn't it? It's a great argument, assuming you have the IQ of a sponge to begin with."
Sorry, I was a bit unattendant... it's your argument and IQ the ones you are talking about?
"I work in IT, in a 100% Windows shop (the only non-Windows we have is ESX running under multiple Windows installs) and we simply do not have any problems with any form of malware, at all."
Don't you deploy antivirus on your systems, neither servers nor desktops? Do you think those antivirus go for free and that don't take away maintenance resources? Do you think those antivirus never threw any compatibility problem with any other service? Do you think they don't take up hard disk, RAM and CPU?
"I guarantee you that no matter what OS you run, you're going to run into problems if you don't take precautions to protect your software from malicious code."
And I agree 100% with you. It's about what the relative costs for those "precautions" are with regards to the platform. I'm not like you and my "house" is not 100% windows but about 90% Linux 10% Windows and I can tell you a significant difference does in fact exist.
"As for these people cleaning up Conficker...talk about a bad example! The vulnerability that Conficker takes advantage of has been patched for what...8 months now?"
So you want to talk about "real world" when it fits to your argument but avoid it when you don't like it?
"I wouldn't be complaining about the malware or the cost of removing it, I'd be firing the IT department en masse"
So you feel it's proper to talk about costs regarding compatibility issues basically maliciously provoked by Microsoft itself as a lock-in strategy (we are talking about "real world" after all) but you think firing your entire IT staff, hiring new ones, training them and hoping they'll be any better than the old ones will come for free, did I get it?
"she doesn't have Conficker because I set her Windows updates to do themselves automatically."
Ok, now I get it: your mother PC is the nearest you've been to a corporate environment, or else you'd never talk about automatic Windows updates as a solution.
"That is how easy THAT is."
Yes: filtering your facts in order to reach to simple solutions that won't account for all the "corner cases" of your real scenario is always easy. It's only that it's irrelevant too.
"Not that its exempt, its that should people target Linux as much, the figure would likely be the same."
So, since if Linux were as popular as Windows it would be affected for malware recovering costs as high as Windows, we don't have to consider malware-related costs in a comparation. OK, I'll take it, even if that's just an untested hypothesis.
But now you will have to do the same: * Costs related to hardware incompatibilities? Not. Were Linux as popular as Windows, hardware support would be there, in the stock kernel. * Costs related to retraining? Not. Were Linux as popular as Windows, well... it would be as known as Windows. * Costs related to hiring the rare Linux knowledgeable admin? Not now: being Linux popular brings as many admins as on the Windows side.
And then, in the end, open source is *still* free of licensing costs (both direct and indirect due to expended hours on the corporate money-printing mill).
"And as that argument sways more users toward FOSS, the cost/benefit for malware writers will change."
But if that's the case, it will be *then*, not *now*.
"for FOSS we have no reasonable track record. So to me, that's background noise."
For me, having about 200 Linux systems, both servers and PCs my "background noise" says "malware-related costs to-date: zero". Surely my manager will say "but, hey, let's inflate this number since making our real numbers out of our real bills to get our real TCO would be a bit myopic, you know".
"imagine a world where the customer doesn't bear the cost of the vendor's mistakes. I know, crazy..."
Not so crazy: that's the world as of today: the customer does never bear the cost of the vendor's mistakes; it bears the cost of its very own mistakes... choosing the wrong providers, for instance.
Slashdot Mirror
"and dump MySQL altogether."
How can this been modded up as "insightful"??? Everybody knows it's not "dump mysql" but "mysqldump"!!!
(/me ducks away)
"How can you even speculate about that? (...) basically you're saying 99% of the population should be screwed because 1% "
That's USA; not a democracy but a republic. That, yes, 99% of population should pay attention to the other 1% and not crush them by their own majority is not a speculation but the very nature of USA as per the specs. And then...
"Why should we favor that 1%? If they want cheap mail"
Mail and press are the basis of free speech. Need I to say any more?
Quoting James Madison, "It is of great importance in a republic not only to guard the society against the oppression of its rulers but to guard one part of the society against the injustice of the other part. If a majority be united by a common interest, the rights of the minority will be insecure."
"You still pay more (0.55 EUR vs. 0.44 USD), but the US service is definitely worse. In Germany, mail is delivered within half a day 99% of the time (drop it off at 5pm, get it in the mail at 9am), in the US it is two to three business days."
Take size into account. Germany is about the size of a State, so in order to compare you should know how much intrastate mail takes. In the other hand, USA can be compared to EU and definetily posting something from Germany to, say, Italy does not take one working day but more 3-5.
"They shouldn't teach any language. Seriously."
Well, maybe English.
"So, you say people have to force you in order for you to acknowledge their free contribution?"
No, he didn't say so. But what he said is that if you forcibly want something, you'd better put it on write in a binding way or else you'll get it... or not. Not rocket science, anyway.
"What you want in large-scale monitoring is:"
Let's see:
"The ability to map complex relationships. I don't want 50 alerts that I can't reach host X, host Y, etc. I want one alert that I can't reach router A."
Nagios do this. I know, I configured mine that way.
"Even better, I want to map things so that I can say "end user application XYZ is not accessible in Kansas due to X being down"."
Nagios can do that, while I never deployed it that way.
"I want my monitoring solution to understand HA and service degredation."
Nagios do this. I know, I configured mine that way.
"I want programmable rules about what happens when X is down or Y is down."
Don't know what exactly do you mean, but if you mean the ability to automatically trying to recover a failing state, I think Nagios can do that. Not that I would want go that path: I'm quite averse to "self-healing" systems and prefer early and meaningful alerts and then push brains into it.
"I want many options for escalation. If X doesn't acknowledge, try Y after 15 mins, etc."
Nagios do this. I know, I configured mine that way.
"I don't ever, ever want a pager to explode or be flooded. A problem should be noticed once and tracked. There should be no pager blizzards."
Nagios do this. I know, I configured mine that way.
"Of course, I don't want this thing relying on my mail system for paging because, of course, my mail system could go down. An ability to dial out if the mail system is down would be nice."
Nagios do this. I know, I configured mine that way.
"I want agents, hooks, interfaces, third-party add-ons, and every possible way of tying something into the monitoring system. I don't want dumb limitations like "you can only get an exit code from the OS and it acts on that" or something. For big monitoring, it's almost mandatory that some kind of API for agents is exposed."
Don't know what exactly you mean, but I know you can extract out of Nagios the very same information it is managing though i.e. a socket or push it to a database for further inspection. Apart of this, it's open sourced, you know.
"I want "I'm working on it, stop paging" blackouts. I want to be reminded to lift them."
Nagios do this. I know, I configured mine that way (well, to autolift the "I'm working on it" after Nagios detects the service on-line again... and it automatically closes the previously opened ticket on our service desk too).
"I want it to tie into my change-management system. If I open a ticket and say that server X is down for 2 hours on this date, I don't want to have to remember to black it out."
Nagios do this. I know, I configured mine that way.
"I want reports. I don't care about silly little charts and graphs, but a history of everything that has every gone wrong with device Y would be nice."
Nagios do this. I know, I configured mine that way. It is the "little charts and graphs" where Nagios is quite lacky, in fact.
"I want more info on my page-receiving device than just "HOST X IS DOWN". I want context so I can decide if I have to drop everything immediately."
Nagios do this. I know, I configured mine that way.
"These are some of the things that make sane large monitoring systems. I don't think any open source product has all of them, alas"
You didn't research on this that so much. Please note that I'm not affiliated to Nagios in any way, but I'm just a satisfied user.
"Yes, but the point was not that they used "contradicts", but "flatly contradicts", which sounds like it shouldn't. So, yeah, I think AC's point is completely valid."
No, it isn't. AC's point is right but it is irrelevant too. The point of saying that EU's past decisions "flatly contradict" this USA decision is about how strange it seems the case that high order legal experts from cultures basically so similar can reach to so opposite positions on things that seems to be so basic as what's privacy in our current computerized world. And yes, it seems quite strange.
What the USA decision seems to forget is the "prudence in valuation" principle: while an IP address can't really identify a person undoubtfully on all cases, it is relevant enough as a general matter to be protected under privacy laws, being that privacy is a highly valued principle (definetly above a privately held company's quarter benefits).
So, in practical terms:
* The RIAA wants to use an IP as a clear proof that someone entered into criminal offense? The "prudence in valuation" would indicate that an IP address is not proof enough.
But!
* The RIAA wants to freely collect IP address-bounded activities disregarding privacy laws (since "IP is not personal data")? Then "prudence in valuation" would dictate that RIAA can't do that since an IP address is near enough to be boundable to a single person as to be protected under privacy laws.
By the way, that's basically the interpretation of EU courts (to date: RIAA-like European institutions' greed and power are a constant menace to change this) .
"Without ID: "I am Napoleon!" "Here's a white coat, sire. Long Sleeves, befitting Imperial majesty."
With ID: "I am Napoleon! Release me!" *displays falsified ID* "At once! Please forgive us you majesty!""
And then you are basically talking about a no-problem.
Without money, at the restaurant: I'm hungry, give me a roast-beef. Sorry sir, no money, no menu.
With falsified money, at the restaurant: I'm hungry, give me a roast-beff. Well, in theory the restaurant owner has now a problem, in fact, falsified money is not such a big deal: we know how to make good enough bank notes.
A falsified ID is a theoretical problem too, that any citizen on countries with ID cards will confirm you to be "not such a big deal" either (even less than falsified money: since there are much, much less ID cards than bank notes, they are quite harder to falsify too).
"If we all have unique id numbers to identify us, then someone can impersonate us by knowing that number."
That's plain stupid.
Here, on Slashdot you are identified as Palestrina. If you were right I could impersonate you on Slashdot by knowing that you are identified here as Palestrina which I already know. See the stupidness? One thing is your identification which, by definition must be public, and a completly different thing is how to stablish the link between you, the real person, and your identifying tag. Obviously doing it by the fact that you know a public identity seems to be not quite an intelligent movement.
"The US government is responsible for Social Security Numbers, yes. If the security of that system is vulnerable to social engineering, then it should take reasonable steps to eliminate that security hole."
And what exactly the security problem is?
Let's accept that SSNs are in fact unique. Then, what's the problem with using them in order to qualify you as "you"? And provided that SSNs are a good and acepted way to stablish you as "you" what's the problem with letting know your SSN to whichever you want to know you as "you"? There should be no problem to tell your SSN to whichever you would say your name since they are the same thing.
And then here comes the problem: you can't get into a bank and retire the founds of John Smith just by saying "Hi, I'm John Smith and I want all my money" still you can do quite a lot of things by the equivalent of "Hi, I'm 12355564899 and I want all my money". That's the stupid part, giving more authority to someone saying -and I mean plain saying, "I'm 12355564899" than "I'm John Smith" when they both are basically the same thing.
"What were the steps that led down the slippery slope of using them for identification?"
The problem is not that the SSN is used for identification, with very few corner cases is guaranteed to be unique, so it's a good candidate. The problem is when it's used for *qualified* identification, and not the number but just knowing it. That's the mad part. Proper nouns have been used for ages as an identificative token: "Hi, Joe, this is my friend Mike" and there's no problem with that (given a much limited scope, of course). But you really know that me calling myself "John Doe" doesn't give to that token too much authority.
The problem is not identifying somebody as being 1243839845B, which is not a bad idea provided there's only one 1243839845B and there's an interest on univocally identifying people (which is a different problem). The problem comes when all the comprobation you do is the like to "Hey, he must certainly be 1243839845B. How do you know? Because so he says".
This is in fact an acknowledged problem almost everywhere but USA: that's why you are identified as 1243839845B, not because you say so but because you say so *and* can produce an ID card with that number, your photograph and your fingerprints on it.
Disregarding the question of nationwide identification being good or bad (and in fact, USA has already disregarded this problem too or else the SSN wouldn't be used for identification purpouses) this news seems to be absourd out of USA: well, my ID number is 34980233, there you have... so what?
"That's nice, but the submitter is asking about RAID 1."
I think he's asking the wrong question anyway.
"Based on past experiences, I have decided that only my data is worth saving"
See? He is asking for backup, not RAID. It has been said one thousand times but it seems it must be said again: RAID is *NOT* in order to protect your data. NOT, NOT, NOT and then NOT again.
RAID (not talking about RAID-0) is there in order to enhance your data's avaliability (as in, say, instead of being able to get to my data 99% of the time, I can get to it 99,9%) but when it's hosed, it's hosed. To protect your data you need backups, not RAID.
"Of course, such a setup should secure my data"
Of course not. Of course you will get quite a funny face when you discover it. Quite more or less the one that had the guy from this story, about six months ago, with the very enlightning title "Why Mirroring Is Not a Backup Solution": http://hardware.slashdot.org/article.pl?sid=09/01/02/1546214
"Even more importantly, I want any drive and its data to be as safe and portable as possible"
Then, *even* if RAID could be considered for data security (which is not) you already answered your question: as a general matter, hardware RAID will only work when using exactly the same controller model, possibly up to its minor revision. You can't count to break a hardware-managed mirror, take one disk to a standard SATA controller and get any data out of it. If your controller dies and miracolously doesn't take the disks with it you can't count on buying a different RAID card (as it will most probably be in about a year for consumer-grade hardware) and get any data out of the mirror. So you should go with software RAID.
AND TAKE BACKUPS.
"...are you saying that MySQL doesn't support foreign key constraints?"
It does... on innodb tables, not on myisam. Most mysql implementations will create tables using myisam unless explictily told otherwise and just will silently ignore foreign key constraints is such a case.
But that was not the point for this case: the app was using mysql because it was "legacy"; you can bet it is not using foreign keys and it's managing intertable data integrity in code. And then, most implementations need using foreing keys almost as soon as it has more than two tables. What was the use-case in practice for a RBDM without such support (as it was back in the not so distant day) but plain ignorance? Not to say there *can* be a use case for going without referential integrity but just look at data schemas of most apps you can download from, say, freshmeat, take it as a reference for the other bazillions of internal-only apps in use in companies and tell me on straigth face that an abysmal majority of them are not using mysql due to plain ignorance.
"Really, you don't need to learn PostgreSQL if MySQL is meeting your needs."
The real problem is that MySQL only *seems* to meet some needs because the one with them doesn't know any better.
Nine out of ten times (to say the least) when somebody has told me "but MySQL covers my needs" it turned out he had no idea what their real needs were and what were the tools he could use (both "real" and logical) so he could pick the best fitted.
While ignorance is a reason, it's not a very glamurous one.
"the original poster did state that his app was working fine as is with MySQL."
So he thinks. From past experience I'd bet he simply doesn't know better.
"I've still got one application hitting a MySQL database because it works fine - all it does it let the company secretaries enter in phone calls that their bosses receive in a help desk type fashion)"
And since you are using MySQL all your referential management is done in code (phone table should have person's id column as a foreign key from persons table, for instance). Not only it makes it more bug-prone but it makes it more difficult to modify or add new features.
"Opening your mouth too much isn't against the law. /.ers should know this."
Who told about law? Not me. Opening your mounth too much maybe is not illegal but it is non-compatible with being school principal.
"SHE HAD ALREADY GRADUATED!!!"
HE STILL WAS SCHOOL PRINCIPAL!!!
"I see nothing that he did that would render him any less capable of performing duties as a principal."
Luckily you won't be choosing principal for my son's school anytime soon.
"Every OS should be covered by AV and kept up to date with latest patches / versions etc."
Yes. And on top of that, proper security policies should be enacted and the users properly trained on their equipment usage.
And all of these comes at a cost that sums up to the TCO of the solution.
And that's exactly the point of the article.
"The key thing was this company hired top notch security and admins and let them do their job."
Do you think they went for free or at a cost? And do you think that once hired everything was done or that such a staff needed counseled further costs on antivirus/malware fees and appliances, on test environments, on hours to develop and test proper policiesIf at a cost... don't you think proper all these things should be added to the TCO of the solution?
"This is really the cost of hiring unqualified people just because they MCSE's and the like."
Isn't it Microsoft's slogan that it's very easy to manage and competent technicians cheaper than their unix colleages and is it not the MSCE the very approved means from Microsoft to mark a valid professional for its products? Oh, and by the way, does Microsoft give MSCEs for free now, or are they at a cost too?
"People use whatever technology is good for them."
Wrong!!! People use whatever technology they *think* is good for them. That's what marketing is for.
"Each has costs, each has benefits, each has security issues, each has usability issues, each has moron users, each has technical users that can hack it to make it work, each is attacked by criminals to exploit, each can be used by governments where they see fit, each can be used by non-profits where it fits, and each can cost whatever the f*ckin' money it wants, each can be bought by whomever in a box, DVD, flash drive, ftp, torrent, or whatever..."
Which is far long to say each share the same costs, which is the very point of the article.
"you can put the cost into the "stupidity" column if you wish :)"
But then do not forget that "Linux is difficult and you will need very expensive sysadmins, but Windows is easy and even a drunk monkey can manage it". When your clients don't want to pay for hardening their systems they do because they already payed for Microsoft products and they were sold on Microsoft products because they are simple and functional, so their "stupidity" is a direct output from the fact they are using Microsoft. You can put the cost into the "stupidity" column if you want it but don't forget that the "stupidity" column still does sum up to the TCO of choosing Microsoft by design.
"One of the companies I consult for has something like 30,000 desktops. They were not affected by Conficker in any way shape or form. In fact, I think they were bitten by the "anna kournikova" thing back in 2000 or 2001, and never again had any problems with worms or viruses.
How is this possible? I don't know. Maybe some common sense was involved."
Have you stopped to think that maybe it was not only "common sense"? That it might be some money involved too? That maybe the "kournikova experience" meant some heads were cutted off and new more senior ones were hired and trained and payed at higher rates; that new expenditures in antivirus, security appliances, more man-hours in maintenance, procedure approvals, testing deployments and staff education were incurred and that all those things might came at a price tag, surely at a cost percieved as lower than the "kournikova incident" but still at a very real and undenyable cost?
"That's clever, isn't it? It's a great argument, assuming you have the IQ of a sponge to begin with."
Sorry, I was a bit unattendant... it's your argument and IQ the ones you are talking about?
"The only reason "maintenance" on software is required is because it is sold to the customer BROKEN."
Or the environment changes
Or the requirements change
"This notion that Linux or MacOS doesn't get hit due to lack of "popularity" is just a self serving dellusion"
Or it amounts as only a partial explanation.
Who the heck modded this insigthful? Does "insightful" means "it holds my side, everything else is moot" now?
"I work in IT, in a 100% Windows shop (the only non-Windows we have is ESX running under multiple Windows installs) and we simply do not have any problems with any form of malware, at all."
Don't you deploy antivirus on your systems, neither servers nor desktops? Do you think those antivirus go for free and that don't take away maintenance resources? Do you think those antivirus never threw any compatibility problem with any other service? Do you think they don't take up hard disk, RAM and CPU?
"I guarantee you that no matter what OS you run, you're going to run into problems if you don't take precautions to protect your software from malicious code."
And I agree 100% with you. It's about what the relative costs for those "precautions" are with regards to the platform. I'm not like you and my "house" is not 100% windows but about 90% Linux 10% Windows and I can tell you a significant difference does in fact exist.
"As for these people cleaning up Conficker...talk about a bad example! The vulnerability that Conficker takes advantage of has been patched for what...8 months now?"
So you want to talk about "real world" when it fits to your argument but avoid it when you don't like it?
"I wouldn't be complaining about the malware or the cost of removing it, I'd be firing the IT department en masse"
So you feel it's proper to talk about costs regarding compatibility issues basically maliciously provoked by Microsoft itself as a lock-in strategy (we are talking about "real world" after all) but you think firing your entire IT staff, hiring new ones, training them and hoping they'll be any better than the old ones will come for free, did I get it?
"she doesn't have Conficker because I set her Windows updates to do themselves automatically."
Ok, now I get it: your mother PC is the nearest you've been to a corporate environment, or else you'd never talk about automatic Windows updates as a solution.
"That is how easy THAT is."
Yes: filtering your facts in order to reach to simple solutions that won't account for all the "corner cases" of your real scenario is always easy. It's only that it's irrelevant too.
"Not that its exempt, its that should people target Linux as much, the figure would likely be the same."
So, since if Linux were as popular as Windows it would be affected for malware recovering costs as high as Windows, we don't have to consider malware-related costs in a comparation. OK, I'll take it, even if that's just an untested hypothesis.
But now you will have to do the same:
* Costs related to hardware incompatibilities? Not. Were Linux as popular as Windows, hardware support would be there, in the stock kernel.
* Costs related to retraining? Not. Were Linux as popular as Windows, well... it would be as known as Windows.
* Costs related to hiring the rare Linux knowledgeable admin? Not now: being Linux popular brings as many admins as on the Windows side.
And then, in the end, open source is *still* free of licensing costs (both direct and indirect due to expended hours on the corporate money-printing mill).
"And as that argument sways more users toward FOSS, the cost/benefit for malware writers will change."
But if that's the case, it will be *then*, not *now*.
"for FOSS we have no reasonable track record. So to me, that's background noise."
For me, having about 200 Linux systems, both servers and PCs my "background noise" says "malware-related costs to-date: zero". Surely my manager will say "but, hey, let's inflate this number since making our real numbers out of our real bills to get our real TCO would be a bit myopic, you know".
"imagine a world where the customer doesn't bear the cost of the vendor's mistakes. I know, crazy..."
Not so crazy: that's the world as of today: the customer does never bear the cost of the vendor's mistakes; it bears the cost of its very own mistakes... choosing the wrong providers, for instance.