Commentary on the seven words
Burke, Thomas G.
tg.burke at ngc.com
Fri Aug 25 18:25:40 UTC 2006
His point is, that maybe he's trying to build a bridge, not go around
the long way.
-----Original Message-----
From: redhat-list-bounces at redhat.com
[mailto:redhat-list-bounces at redhat.com] On Behalf Of Marc Wiatrowski
Sent: Friday, August 25, 2006 2:23 PM
To: 'General Red Hat Linux discussion list'
Subject: RE: Commentary on the seven words
When someone going down a dead end road stops and asks for directions,
do you explain the correct route or help him make a new road the way he
is headed?
marc
> -----Original Message-----
> From: darrel barton
> Sent: Friday, August 25, 2006 2:11 PM
> To: redhat-list at redhat.com
> 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 at redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
More information about the redhat-list
mailing list