Commentary on the seven words

[Bliss, Aaron]

Didn't mean to step on anyone's toes; I was just trying to help; I'm
sure some people will disagree, but it's generally a better security
practice not to use clear text protocols such as telnet or ftp whenever
possible, which why I recommend sftp and ssh... 

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



Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information.  If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited.  If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.