His point is, that maybe he's trying to build a bridge, not go around the long way. -----Original Message----- From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list-bounces@xxxxxxxxxx] 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@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 -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
