Please fix the fonts in your email client. I have no problem with
HTML email, but it's coming across as Times New Roman at 6pt size.
On Wed, Aug 3, 2011 at 3:15 PM, Benjamin Smith <lists@xxxxxxxxxxxxxxxxxx> wrote:
> On Wednesday, August 03, 2011 08:30:02 AM Brian Mathis wrote:
>> > Wait - isn't that an alternative technology?!?
>>
>> No it's not, and you're making a stupid argument. Clearly there is a
>> difference between using a different client versus changing the entire
>> protocol stack across all systems it's being used for. Using a better
>> client mechanism involves maybe an hour or so worth of work, while
>> changing the entire protocol you're using requires changing every
>> service on every server in every company you might be interfacing
>> with. One of those is easy to do, the other one is likely impossible.
>
> As you make the point later, perl is a different technology than
> /usr/bin/ftp. Both can use the same protocol.
You really want to keep this ridiculous and utterly pedantic argument
going? OK.
Obviously using a different client method is, oh my god, *different*.
Technically, every time you run the same script, different electrons
would be used, so that's different too. Many of the other replies ask
"why not use this or that other protocol instead". Clearly this is
the context I am referring to here.
Please have conversations at a human level. We are not computers
trying to agree on some exact definition of a word before we can
continue with some protocol negotiation. The network protocol
implemented across a bunch of servers is different than a single
client used to access them, and that this is clearly what I'm
referring to.
>> I find it strange and annoying that so many times the answers to
>> questions like the OP's so often and so clearly miss the mark, as if
>> no one here understands what's actually involved in implementing a new
>> protocol stack across an enterprise or between enterprises.
>
> We're all doing some different, you know? Some of us have to deal with
> arcane "requirements" written by some midlevel bureaucrat. I prefer using
> sftp, scp, or post/https for secure file transfers. More than once I've been
> forced to use FTP for "security reasons", even after I try to explain
> otherwise.
My point is that this happens all the time. There are frequently
responses to questions that flippantly suggest something like "just
change your whole universe because doing it this other way is
marginally better". The poster didn't ask about that, and often knows
about the other options. But as you said, everyone has different
requirements, so the responses of "just change everything" are worse
than noise; they completely derail the conversation (as exemplified by
Les's insistence on beating the rsync drum into the ground).
>> >> The questionable thing is not using entrenched protocols, but using
>> >> old methods like redirecting ftp commands via STDIN into a client to
>> >> control it.
>>
>> > /bin/sh is an "old method". TCP is pretty ancient, as well. For that
>> > matter, UNIX is REALLY ancient. Yet somehow, they are not only still
>> > useful, but highly relevant. Wheels are also old technology!
>>
>> See above, re: stupid argument. If your objection is to the use of
>> the word "old" as opposed to something like "error prone", please
>> perform 's/old/error prone/g' in your head and save us the pixels.
>> P.S. Something becomes "old" when it's been replaced by a newer,
>> better way of doing things, not simply because of age.
>
> I see this nowhere in the standard definition for "old".
> http://dictionary.reference.com/browse/old
I once again refer you to, re: stupid argument
>> Redirecting commands into an ftp client (and, btw, I don't know if the
>> OP is doing this, but it's still amazingly common) is a provably bad
>> "old" method of doing things. You cannot deal with error conditions
>> or anything else that might come up. Using a scripting
>> language/library allows you to deal with these obvious problems.
>
> You might consider becoming familiar with expect, perhaps?
> # yum install expect;
I have used expect and it's only good as a last resort when you have
no other options. It's only marginally better than having a monkey
typing on the keyboard, and reacts just about as well to errors.
Using an actual client library gives you full control over both
functions and error handling, and generally takes much less effort
than expect to get working right. It's still better than redirecting
from stdin.
>> > I've been around the block long enough to know that those who are most
>> > certain they have the right answer right away are usually those least
>> > likely to have it. Science backs this conclusion up, it's called the
>> > Dunning-Kruger effect.
>
> Strange: no comment here?
I was going to throw it into the "stupid argument" category, but
decided to save the pixels. I'll also raise you an "irrelevant",
since this is not about certainty over "the right answer", it's about
the flexibility of the tools one uses to reach the answer. The
ability to discuss using better tools at all would seem to invalidate
the "incompetence denies them the meta-cognitive ability to recognize
their mistakes" tenet for that effect to applicable here.
-☙ Brian Mathis ❧-
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
