On 8/8/2013 5:42 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-08 at 07:59 +0200, Per Jessen wrote:
Carlos E. R. wrote:
What I wonder is why only dd is in the current instructions.
Because 'dd' is the tool typically used for that sort of thing. 'cp' and 'cat' in that context are at least a bit unusual. Besides, there isn't really much gained by adding two alternatives ....
Well, one poster at the forum failed to create the stick by any of our published methods, and succeeded using 'cp'. I guess that he mistyped something, but I can't be sure.
The cp syntax is a tiny bit easier, perhaps... :-?
The fact that using the wrong tool for a given job happened to work once, even while a particular user failed for unknown reasons to use the right tool, does not change the fact that it is really the wrong tool for that job. A user may fail to get lumber home in a truck with a manual transmission because he doesn't know how to work a clutch and manual gears, and succeed by sticking it on top of his car which has an automatic transmission, yet the car was still the wrong tool for that job and you should never actually write down documentation that mis-educates new people about the best way to transport lumber. cp "happened to work" in this case because of the particulars of the version of cp, the os, etc. But writing raw images to device nodes in an exact, reproducible, predictable manner is not an advertised function of cp. So if it worked, it was by happenstance. Even if it worked 500 times on every version of linux available right now, that is still happenstance. All those versions of linux still probably derive their version of cp from the same gnu base, with the only differences being age. While dd is specifically made to do exactly that. It doesn't just happen to work for that also. Probably the main difference behind the scenes is the assurance that dd will write one byte after another contiguously, no skipping around to use free blocks wherever they may be. Cp apparently just happens to end up doing that too if the target is not a file, but, it's still not how cp is documented, and relying on undocumented behaviour like that is simply a bad habit. Relying on behavior that is inconsistent with the norm is also a bad habit that will tend to mess up and confuse people later. It's better to get the proper understanding of what cp does in the normal case and leave it at that. For instance, the new user does this cp operation and sees that it works. Later they may be surprised to discover the hard way after who knows how much head banging and wasted time, that cp does not write contiguous blocks even though it did when writing to a device. Call it simply "best practices" if you want a shorter way to explain why one tool is used and not another. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org