http://wiki.centos.org/HowTos/SoftwareRAIDonCentOS5
has:
dd if=/dev/zero of=/dev/sda bs=512 count=64 dd if=/dev/zero of=/dev/sdb bs=512 count=64
Will the joker who put in this particular gem without any warnings or a clear explanation for those who need a clueby4 with regards to file systems please either remove the instructions or add a very clear warning that damage to file systems that is not recoverable will result if run on the wrong disk(s).
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
Christopher
Chan Chung Hang Christopher wrote:
http://wiki.centos.org/HowTos/SoftwareRAIDonCentOS5
has:
dd if=/dev/zero of=/dev/sda bs=512 count=64 dd if=/dev/zero of=/dev/sdb bs=512 count=64
Will the joker who put in this particular gem without any warnings or a clear explanation for those who need a clueby4 with regards to file systems please either remove the instructions or add a very clear warning that damage to file systems that is not recoverable will result if run on the wrong disk(s).
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
The document's first sentence clearly states the purpose of the document:
"This article addresses the setting up of a software (mdraid) RAID1 at install time on systems without a true hardware RAID* controller."
The part being important here is "install time." So I think it's pretty clear. Is it the document writer's fault that other didn't read this part? I don't think so.
Regards, Max
I would agree with Max. Doing things you don't know requires you to have a bit of knowledge before proceeding like warnings in a few configuration files to not to go ahead and doom your production systems if you clearly don't understand what any configuration may have been for. It said what it did and Chan, you don't need to obviously show your rudeness to a public mailing list.
On Wed, Aug 12, 2009 at 7:48 AM, Max Hetrick maxhetrick@verizon.net wrote:
Chan Chung Hang Christopher wrote:
http://wiki.centos.org/HowTos/SoftwareRAIDonCentOS5
has:
dd if=/dev/zero of=/dev/sda bs=512 count=64 dd if=/dev/zero of=/dev/sdb bs=512 count=64
Will the joker who put in this particular gem without any warnings or a clear explanation for those who need a clueby4 with regards to file systems please either remove the instructions or add a very clear warning that damage to file systems that is not recoverable will result if run on the wrong disk(s).
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
The document's first sentence clearly states the purpose of the document:
"This article addresses the setting up of a software (mdraid) RAID1 at install time on systems without a true hardware RAID* controller."
The part being important here is "install time." So I think it's pretty clear. Is it the document writer's fault that other didn't read this part? I don't think so.
Regards, Max _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--- A player who makes a team great is more valuable than a great player. Losing yourself in the group, for the good of the group, that’s teamwork.
On Wed, Aug 12, 2009 at 10:41:10PM +0800, Chan Chung Hang Christopher wrote:
http://wiki.centos.org/HowTos/SoftwareRAIDonCentOS5
has:
dd if=/dev/zero of=/dev/sda bs=512 count=64 dd if=/dev/zero of=/dev/sdb bs=512 count=64
Will the joker who put in this particular gem without any warnings or a clear explanation for those who need a clueby4 with regards to file systems please either remove the instructions or add a very clear warning that damage to file systems that is not recoverable will result if run on the wrong disk(s).
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
Christopher
Dumb people will find ways to be dumb no matter how much you dumb things down... :)
Your "successor" could easily have followed the above instructions on the completely wrong system as well or done something eqaully destructive with another command in that or other HOWTO's...
Nothing wrong with putting a warning or replacing "sd[ab]" with something bogus though if the authors like.
Ray
Ray Van Dolson wrote:
Dumb people will find ways to be dumb no matter how much you dumb things down... :)
You can't teach or bottle common sense... ;)
Even with no warnings on the document, the first sentence states this is for install time.
Anyone that has ever installed an OS should know that when you install an OS during install time, it's going to overwrite data on the drives. If they don't know that part, then they have no business installing anything anywhere, ever. :)
Regards, Max
On Wed, 2009-08-12 at 10:56 -0400, Max Hetrick wrote:
Ray Van Dolson wrote:
Dumb people will find ways to be dumb no matter how much you dumb things down... :)
You can't teach or bottle common sense... ;)
Even with no warnings on the document, the first sentence states this is for install time.
Anyone that has ever installed an OS should know that when you install an OS during install time, it's going to overwrite data on the drives. If they don't know that part, then they have no business installing anything anywhere, ever. :)
Regards, Max
--- Why not direct them to a shell to just enumerate the drives? df
JohnStanley
On Wednesday 12 August 2009, Ray Van Dolson rayvd@bludgeon.org wrote:
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
I think this seriously highlights the need to hire competent system administrators.
The reason you want to wipe the beginning of the drive is that some fake-raid controllers write crap to the drive and if you leave it there some linux installers (anaconda, at least) will install dm-raid using that info rather than setup md raid using normal linux conventions. Which is exactly what that section of the instruction says. My kickstart scripts do the same thing and for the same reason.
Let me be even more clear - if your successor doesn't know what dd does, or what drives correspond to /dev/sda and /dev/sdb in the box he's working on, he has no business being within 10 feet of a production server without careful supervision.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Alan Hodgson Sent: Wednesday, August 12, 2009 12:21 To: CentOS mailing list Subject: Re: [CentOS] Dangerous Software Raid instructions on Wiki
On Wednesday 12 August 2009, Ray Van Dolson rayvd@bludgeon.org wrote:
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why
he bothers
to actually read HowTos) and on a production box (who
wants pop-corn
and soda? Sorry, the er support conversation will not be
on irc) and
I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that
just follow
Confusing sarcasm aside, there is value to not having high damage command able to be so easy to copy, paste, destroy.
How about /dev/sdX /dev/sdY and call it a day.
whatever you tell them to do without thinking if you do
not list out
things they first have to think about or questions they
first need to answer.
I think this seriously highlights the need to hire competent system administrators.
The reason you want to wipe the beginning of the drive is that some fake-raid controllers write crap to the drive and if you leave it there some linux installers (anaconda, at least) will install dm-raid using that info rather than setup md raid using normal linux conventions. Which is exactly what that section of the instruction says. My kickstart scripts do the same thing and for the same reason.
Let me be even more clear - if your successor doesn't know what dd does, or what drives correspond to /dev/sda and /dev/sdb in the box he's working on, he has no business being within 10 feet of a production server without careful supervision.
within 10 feet of a production server WITH OR without careful supervision.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
Alan Hodgson wrote:
Let me be even more clear - if your successor doesn't know what dd does, or what drives correspond to /dev/sda and /dev/sdb in the box he's working on, he has no business being within 10 feet of a production server without careful supervision.
What physically corresponds to /dev/sda and /dev/sdb isn't necessarily predictable these days. For example you can initialize a single drive as a volume with some common raid controllers, then swap that drive's position in the drive bays or reverse a pair and each will still show as the /dev/sd? device where it was initialized instead of what you'd expect from the current location.
On Wed, Aug 12, 2009 at 12:21 PM, Alan Hodgsonahodgson@simkin.ca wrote:
I think this seriously highlights the need to hire competent system administrators.
The reason you want to wipe the beginning of the drive is that some fake-raid controllers write crap to the drive and if you leave it there some linux installers (anaconda, at least) will install dm-raid using that info rather than setup md raid using normal linux conventions. Which is exactly what that section of the instruction says. My kickstart scripts do the same thing and for the same reason.
Let me be even more clear - if your successor doesn't know what dd does, or what drives correspond to /dev/sda and /dev/sdb in the box he's working on, he has no business being within 10 feet of a production server without careful supervision.
This thread seriously highlights the sort of attitudes that are causing major issues in IT in general, and have been for years. Whenever someone makes a mistake, we point fingers and call them stupid. We haughtily proclaim that only people who "know what they are doing" should have a job -- as if we had never been short on time, ventured into an area outside our expertise, or been a beginner.
The fact is that we all have a million things to do and only a fixed amount of time. It's simply not possible for anyone to be a complete expert in everything at all times. We've all been in a position where something needs to be done immediately and you don't know everything about the product/system. I would wager that is more common than the situation where you know everything about everything before performing any actions.
Additionally, IT often has the unique benefit that users can quickly contribute to a feedback loop that informs you directly with what they are having trouble with. Other industries, such as advertising, marketing, sales, etc... would *kill* to have that sort of feedback.
And what do we do with it? In this case, someone has effectively filed a bug on the documentation, and all we can do is spew about how stupid the person is. It doesn't matter if the information is there /somewhere/; the bug is that it's not clear, or it's presented in a confusing way, or it is potentially dangerous and that danger can be easily mitigated (Jason Pyeron has got the right idea).
Instead of taking the lazy approach of dismissing someone as stupid, prove that your haughtiness is justified by engaging on how to fix the problem. You've been presented with an opportunity to make something better than it was before. Take it.
Brian Mathis wrote:
This thread seriously highlights the sort of attitudes that are causing major issues in IT in general, and have been for years. Whenever someone makes a mistake, we point fingers and call them stupid. We haughtily proclaim that only people who "know what they are doing" should have a job -- as if we had never been short on time, ventured into an area outside our expertise, or been a beginner.
The fact is that we all have a million things to do and only a fixed amount of time. It's simply not possible for anyone to be a complete expert in everything at all times. We've all been in a position where something needs to be done immediately and you don't know everything about the product/system. I would wager that is more common than the situation where you know everything about everything before performing any actions.
Additionally, IT often has the unique benefit that users can quickly contribute to a feedback loop that informs you directly with what they are having trouble with. Other industries, such as advertising, marketing, sales, etc... would *kill* to have that sort of feedback.
And what do we do with it? In this case, someone has effectively filed a bug on the documentation, and all we can do is spew about how stupid the person is. It doesn't matter if the information is there /somewhere/; the bug is that it's not clear, or it's presented in a confusing way, or it is potentially dangerous and that danger can be easily mitigated (Jason Pyeron has got the right idea).
Hmmm, not sure I agree with you here. Where I work, and in most places I've seen, if someone isn't competent enough on the Linux command line, he/she doesn't get close to a production system until he/she is taught or learned enough to be trusted.
A company just doesn't turn someone free on Linux servers with root access if he/she doesn't know what they are doing. That is just plain stupidity.
Your argument does apply, however, to this thread, the original poster suggested that the author of the article was wrong, and should be more clear about his commands. When in fact, the very first sentence of the article stated it was for *install time* which to me is pretty clear and concise.
If you have employees working for you and they don't know or understand enough to know that when you install an OS, it's going to wipe the drives, then I'd be doing one of two things. 1) teaching my employees, or 2) not allowing them access to a production system of all things.
Yes, education is important, very important. But the issue with this thread wasn't about that. It was about someone stating that the author of an article was wrong or not clear enough on instructions, when in my opinion, the author was extremely clear with the very first sentence of the guide.
If I don't know something about a system or piece of software, I set up a test server at work and play with it. I certainly don't play with it on a production environment, mis-read or not read at all the guide I'm working with, and then go back and try to blame the author.
Instead of taking the lazy approach of dismissing someone as stupid, prove that your haughtiness is justified by engaging on how to fix the problem. You've been presented with an opportunity to make something better than it was before. Take it.
Aside from some sarcasm, no one was being arrogant or rude in their responses. What problem? The problem that someone didn't clearly read through the how to before they started typing commands? How is that anyone's fault here on the list or on the wiki? It's no one's fault except the person typing things they clearly haven't thought about.
I think everyone's comments are spot on. You don't let people who aren't educated onto an installation with root access. If that's how you run your shops, then so be it, but that's not normal in my experience.
Regards, Max
On Wed, Aug 12, 2009 at 1:26 PM, Max Hetrickmaxhetrick@verizon.net wrote:
Brian Mathis wrote:
This thread seriously highlights the sort of attitudes that are causing major issues in IT in general, and have been for years. Whenever someone makes a mistake, we point fingers and call them stupid. We haughtily proclaim that only people who "know what they are doing" should have a job -- as if we had never been short on time, ventured into an area outside our expertise, or been a beginner.
The fact is that we all have a million things to do and only a fixed amount of time. It's simply not possible for anyone to be a complete expert in everything at all times. We've all been in a position where something needs to be done immediately and you don't know everything about the product/system. I would wager that is more common than the situation where you know everything about everything before performing any actions.
Additionally, IT often has the unique benefit that users can quickly contribute to a feedback loop that informs you directly with what they are having trouble with. Other industries, such as advertising, marketing, sales, etc... would *kill* to have that sort of feedback.
And what do we do with it? In this case, someone has effectively filed a bug on the documentation, and all we can do is spew about how stupid the person is. It doesn't matter if the information is there /somewhere/; the bug is that it's not clear, or it's presented in a confusing way, or it is potentially dangerous and that danger can be easily mitigated (Jason Pyeron has got the right idea).
Hmmm, not sure I agree with you here. Where I work, and in most places I've seen, if someone isn't competent enough on the Linux command line, he/she doesn't get close to a production system until he/she is taught or learned enough to be trusted.
A company just doesn't turn someone free on Linux servers with root access if he/she doesn't know what they are doing. That is just plain stupidity.
Your argument does apply, however, to this thread, the original poster suggested that the author of the article was wrong, and should be more clear about his commands. When in fact, the very first sentence of the article stated it was for *install time* which to me is pretty clear and concise.
If you have employees working for you and they don't know or understand enough to know that when you install an OS, it's going to wipe the drives, then I'd be doing one of two things. 1) teaching my employees, or 2) not allowing them access to a production system of all things.
Yes, education is important, very important. But the issue with this thread wasn't about that. It was about someone stating that the author of an article was wrong or not clear enough on instructions, when in my opinion, the author was extremely clear with the very first sentence of the guide.
If I don't know something about a system or piece of software, I set up a test server at work and play with it. I certainly don't play with it on a production environment, mis-read or not read at all the guide I'm working with, and then go back and try to blame the author.
> Instead of taking the lazy approach of dismissing someone as stupid, > prove that your haughtiness is justified by engaging on how to fix the > problem. You've been presented with an opportunity to make something > better than it was before. Take it.
Aside from some sarcasm, no one was being arrogant or rude in their responses. What problem? The problem that someone didn't clearly read through the how to before they started typing commands? How is that anyone's fault here on the list or on the wiki? It's no one's fault except the person typing things they clearly haven't thought about.
I think everyone's comments are spot on. You don't let people who aren't educated onto an installation with root access. If that's how you run your shops, then so be it, but that's not normal in my experience.
Regards, Max
There are 2 faults here, the documentation and the responses to the thread.
The fix for the documentation is to change the example to a command that does no damage if it is copied/pasted. That's an easy fix and can only serve to force the user to read the guide more in depth. Changing the device names to "/dev/sdX" "/dev/sdY" is much more unlikely to cause damage to a system if they were copied verbatim, and the capitals and use of X and Y is more likely to trigger someone to stop, as X and Y are frequently used as indicators to replace something else with. In my own documentation, I highlight those areas with a yellow background to be sure people know where to substitute real values.
It also helps to understand how people read instructions. When they look at a page, they see {big blob of useless introduction text}, then they see "Step 1, do this". They almost always go right to Step 1. I'd bet $100 that everyone reading this thread has done that more than once, recently. It's not good enough to put the warnings so far separated from the actual commands. You might have some feelings about how things *should* be done, but you don't get to make that decision for people, you just need to know it and work within it.
As far as the replies here go, the first one insinuates that the person can't follow instructions, the second one calls the person dumb, and others say that the person is incompetent, and compares their intelligence to that of a bottle. That IS rude and arrogant in my book, and your final sentence only continues with the passive-aggressive swiping that goes on too often in IT realms.
Chan Chung Hang Christopher wrote:
http://wiki.centos.org/HowTos/SoftwareRAIDonCentOS5
has:
dd if=/dev/zero of=/dev/sda bs=512 count=64 dd if=/dev/zero of=/dev/sdb bs=512 count=64
Will the joker who put in this particular gem without any warnings or a clear explanation for those who need a clueby4 with regards to file systems please either remove the instructions or add a very clear warning that damage to file systems that is not recoverable will result if run on the wrong disk(s).
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
Christopher
This should be directed to the -docs list, not here.
Thanks
At Wed, 12 Aug 2009 22:41:10 +0800 CentOS mailing list centos@centos.org wrote:
http://wiki.centos.org/HowTos/SoftwareRAIDonCentOS5
has:
dd if=/dev/zero of=/dev/sda bs=512 count=64 dd if=/dev/zero of=/dev/sdb bs=512 count=64
Will the joker who put in this particular gem without any warnings or a clear explanation for those who need a clueby4 with regards to file systems please either remove the instructions or add a very clear warning that damage to file systems that is not recoverable will result if run on the wrong disk(s).
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
Yes indeed! Do we need an article titled "dd considered dangerious"?
Christopher _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Chan Chung Hang Christopher wrote:
http://wiki.centos.org/HowTos/SoftwareRAIDonCentOS5
has:
dd if=/dev/zero of=/dev/sda bs=512 count=64 dd if=/dev/zero of=/dev/sdb bs=512 count=64
Will the joker who put in this particular gem without any warnings or a clear explanation for those who need a clueby4 with regards to file systems please either remove the instructions or add a very clear warning that damage to file systems that is not recoverable will result if run on the wrong disk(s).
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
Just to make it even clearer and thwart any further damages, I edited the page to include:
"This article addresses the setting up of a software (mdraid) RAID1 at install time on systems without a true hardware RAID* controller. The following dd commands will destroy all information on the disks. If you have data on the drives that you need access to, please backup the drives."
If anyone destroys any other production systems, it's their own fault if they can't read the guide in the first paragraph and understand.
Now, let this thread die on this list, or take it over to the docs list to continue.
Regards, Max
Max Hetrick wrote:
Chan Chung Hang Christopher wrote:
http://wiki.centos.org/HowTos/SoftwareRAIDonCentOS5
has:
dd if=/dev/zero of=/dev/sda bs=512 count=64 dd if=/dev/zero of=/dev/sdb bs=512 count=64
Will the joker who put in this particular gem without any warnings or a clear explanation for those who need a clueby4 with regards to file systems please either remove the instructions or add a very clear warning that damage to file systems that is not recoverable will result if run on the wrong disk(s).
My successor at my previous job has gleefully followed those instructions (he seriously needs a clueby4 which is why he bothers to actually read HowTos) and on a production box (who wants pop-corn and soda? Sorry, the er support conversation will not be on irc) and I think this seriously highlights the need for HowTo writers to seriously consider their audience as dumb monkeys that just follow whatever you tell them to do without thinking if you do not list out things they first have to think about or questions they first need to answer.
Just to make it even clearer and thwart any further damages, I edited the page to include:
"This article addresses the setting up of a software (mdraid) RAID1 at install time on systems without a true hardware RAID* controller. The following dd commands will destroy all information on the disks. If you have data on the drives that you need access to, please backup the drives."
If anyone destroys any other production systems, it's their own fault if they can't read the guide in the first paragraph and understand.
1) The Title of the article says "How to Setup a Software RAID on CentOS 5" 2) My successor is a real HK bred and born person so his command of the English language is like most such persons; that is to say, very poor. 3) Regarding not letting him within ten feet of a production server, well, that is not my business anymore. When I was there, I was the lone ranger and so is my replacement. I guess it serves my previous boss right who felt he could just pick anybody of the street to replace because I only have high school education. Too bad he had to wait for over six months to get what he has now. 4) Max, I actually agree with you but hey, the world is not perfect. There will be clueless people given jobs they are not really suitable for but we cannot just tell them to get lost can we now?
Now, let this thread die on this list, or take it over to the docs list to continue.
Posted too to centos-docs for any further discussion.
Chan Chung Hang Christopher wrote:
- The Title of the article says "How to Setup a Software RAID on CentOS 5"
- My successor is a real HK bred and born person so his command of the
English language is like most such persons; that is to say, very poor. 3) Regarding not letting him within ten feet of a production server, well, that is not my business anymore. When I was there, I was the lone ranger and so is my replacement. I guess it serves my previous boss right who felt he could just pick anybody of the street to replace because I only have high school education. Too bad he had to wait for over six months to get what he has now. 4) Max, I actually agree with you but hey, the world is not perfect. There will be clueless people given jobs they are not really suitable for but we cannot just tell them to get lost can we now? Posted too to centos-docs for any further discussion.
Someone added a very bright disclaimer, so all should be good in the future. I do agree with others that using /dev/sdX would probably be wise as well in documentation, but that doesn't fix the true root of the problem. People really should watch cutting and pasting, or typing, commands on a Linux root without understanding what it is that the commands are doing.
Is it possible you could help him with some basic Linux lessons then, and/or point him to some beginner material so this doesn't happen again.
I just had a problem with blaming the author of a document, (I didn't even write it) when the user did not read the document. If he doesn't speak or read English well, then that doesn't help that, nor does adding warnings help either if he can't read English well.
I'm not certain what languages the page has been translated to, but perhaps look into that for him as well. Or can you translate the page?
Regards, Max
Max Hetrick wrote:
Someone added a very bright disclaimer, so all should be good in the future. I do agree with others that using /dev/sdX would probably be wise as well in documentation, but that doesn't fix the true root of the problem. People really should watch cutting and pasting, or typing, commands on a Linux root without understanding what it is that the commands are doing.
Is it possible you could help him with some basic Linux lessons then, and/or point him to some beginner material so this doesn't happen again.
I just had a problem with blaming the author of a document, (I didn't even write it) when the user did not read the document. If he doesn't speak or read English well, then that doesn't help that, nor does adding warnings help either if he can't read English well.
I'm not certain what languages the page has been translated to, but perhaps look into that for him as well. Or can you translate the page?
Sorry for posting that to the main list. I hit reply and didn't see that the reply to was still set for the main list.
Again, Max, well said ;)
On Thu, Aug 13, 2009 at 4:53 AM, Max Hetrick maxhetrick@verizon.net wrote:
Max Hetrick wrote:
Someone added a very bright disclaimer, so all should be good in the future. I do agree with others that using /dev/sdX would probably be wise as well in documentation, but that doesn't fix the true root of the problem. People really should watch cutting and pasting, or typing, commands on a Linux root without understanding what it is that the commands are doing.
Is it possible you could help him with some basic Linux lessons then, and/or point him to some beginner material so this doesn't happen again.
I just had a problem with blaming the author of a document, (I didn't even write it) when the user did not read the document. If he doesn't speak or read English well, then that doesn't help that, nor does adding warnings help either if he can't read English well.
I'm not certain what languages the page has been translated to, but perhaps look into that for him as well. Or can you translate the page?
Sorry for posting that to the main list. I hit reply and didn't see that the reply to was still set for the main list. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Max Hetrick wrote:
Chan Chung Hang Christopher wrote:
- The Title of the article says "How to Setup a Software RAID on CentOS 5"
- My successor is a real HK bred and born person so his command of the
English language is like most such persons; that is to say, very poor. 3) Regarding not letting him within ten feet of a production server, well, that is not my business anymore. When I was there, I was the lone ranger and so is my replacement. I guess it serves my previous boss right who felt he could just pick anybody of the street to replace because I only have high school education. Too bad he had to wait for over six months to get what he has now. 4) Max, I actually agree with you but hey, the world is not perfect. There will be clueless people given jobs they are not really suitable for but we cannot just tell them to get lost can we now? Posted too to centos-docs for any further discussion.
Someone added a very bright disclaimer, so all should be good in the future. I do agree with others that using /dev/sdX would probably be wise as well in documentation, but that doesn't fix the true root of the problem. People really should watch cutting and pasting, or typing, commands on a Linux root without understanding what it is that the commands are doing.
Some rather explicit warnings or enough obfuscation could have made him come begging for help again rather leaving a major mess.
Is it possible you could help him with some basic Linux lessons then, and/or point him to some beginner material so this doesn't happen again.
Have tried...I can only take that so far. Unfortunately, experience seems to be the most memorable teacher.
I just had a problem with blaming the author of a document, (I didn't even write it) when the user did not read the document. If he doesn't speak or read English well, then that doesn't help that, nor does adding warnings help either if he can't read English well.
Bye bye data ought to be clear enough. I am just saying writers of HowTos should perhaps consider certain people that they are not targeting as possible readers. My incomplete vpopmail howto has no commands that will mess up a system whether package wise or data wise.
I'm not certain what languages the page has been translated to, but perhaps look into that for him as well. Or can you translate the page?
No can do. I am not a typical HK person. Not bred in Hong Kong (and therefore not racist like most locals) but bred in Sierra Leone. So I am illiterate in Chinese characters nevermind whether it is the traditional or simplified system. I cannot help out much with the local LUG. The few who do have a fair command of English are also the ones who help the others out - in Chinese. I will try asking them.
-
Alan Hodgson -
Bassu -
Brian Mathis -
Chan Chung Hang Christopher -
Jason Pyeron -
JohnS -
Les Mikesell -
Max Hetrick -
Ned Slider -
Ray Van Dolson -
Robert Heller