Commentary on the seven words

[Marc Wiatrowski]

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.
> 
> 
> 
> 
> 
> 
> 
> 
>