RE: Commentary on the seven words

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ditto...  But...  WDYWTDT?

;) 

-----Original Message-----
From: redhat-list-bounces@xxxxxxxxxx
[mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of darrel barton
Sent: Friday, August 25, 2006 2:11 PM
To: redhat-list@xxxxxxxxxx
Subject: Commentary on the seven words


As a programmer, I routinely turn to guru's for support -- especially
for operating system and utility advice and assistance and there are
SEVEN words -- seven very unwelcome words that I hear from time to time
that 
drive me up the wall.   Not George Carlin's 7 words but another set:

Why Do You Want To Do That?

I don't want to seem like I'm attacking anyone here, because I know that
almost everyone means well and help, whether it's what we intend or not
-- 
is still help.  But there is a danger too.   When someone writes to say

200 PORT command successful. Consider using PASV. Hangs.

and the response he gets is "try sftp" there seem to be a hugely missing

ingredient:   All we did was give the man a work around to a problem.
Even 
if there are 400 alternatives ... FTP is SUPPOSED to work and someone 
should CARE that it doesn't.   Well, sftp helped him and he's on his way

and that's great.   The only problem is that, in this case, 'sftp' was 
merely a workaround to a problem and if people aren't careful, Linux
will become wat the original AT&T Unix was -- and that is to say nothing
more that a PILE of workarounds.

I wrote in with a complaint that Linux will allow a process (like Tar,
Cpio, DD, etc) to create archives larger than that same system can read 
back.   Think of it as that elusive Write Only Memory we're all heard 
about.   Several people contacted me and told me all about Gzip and how
to 
make the archive smaller and other people said it wasn't Linux' fault it

was the file's fault and etc., etc., and etc.   I wonder if these same 
people would be so forgiving of a workaround if the problem was that
Linux would allow a process to write to disc blocks in excess of the
number of physical blocks without reporting errors?

There is a guy that wants to be able to log in to ROOT via Telnet and 
people write back telling him that he doesn't want to even do that.
Well 
guess what?   I administrate one system that has 128 clients on it and
it's 
NOT EVEN CONNECTED TO THE INTERNET.   Or .. Intranet.   One server, 128 
thin clients.   Why can't I log on to Root from one of those clients if
I 
want to without the 262 additional levels of complication that ssh 
provides?   (OK -- I know that YOU have never ever EVER had a problem
with 
ssh.  Nor anyone you've ever known.  And every ssh client you have ever
seen works seamlessly with every ssh server that's ever been written ..
but trust me, out there ... once ... back in 1986 .. there WAS a guy who
had ssh problems.

So when a guy writes to ask about how to enable root login from telnet,
can't someone just say "I hope you know that's not as secure as ssh --
but here's how you enable that ...... ?

Please just remember that some of us here have been slogging through
this stuff for the last 20 years, trying to get an application to run, a
documented operating system function to actually function -- and
occasionally get enough things working that a client actually PAYS 
us.   We're not always here to hear about the way we coulda, shoulda, 
woulda restructured the whole process around stuff that some of you guys
only invented last week, ok?

"Why Do You Want To Do That?"

Would be a more fair question if someone needed that answer in order to
better understand the request -- but far too often it's not that -- it's
the beginning of someone telling me how THEY think I should be doing my
job.

So please, folks, the next time we want to do something differently that
you think you'd do it if you were in our shoes ... cut us some slack and
just help us out, OK?  We'd do the same for you.









-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux