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

RE: Commentary on the seven words

His point is, that maybe he's trying to build a bridge, not go around
the long way. 

-----Original Message-----
From: redhat-list-bounces redhat com
[mailto:redhat-list-bounces 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? 


> -----Original Message-----
> From: darrel barton
> Sent: Friday, August 25, 2006 2:11 PM
> To: redhat-list 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 
> 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 redhat com?subject=unsubscribe

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