On Thu, 28 Nov 2002 11:26:38 -0500 rchrismon@rcn.com wrote: > On Thu, 28 Nov 2002 01:40:11 -0600, ABrady said: > > > > > > Secret hacker rule #11: hackers read manuals. > > > > -- > > > > Regards, > > > > > > > > Steve Sykes > > > > As for the secret hacker's rule, I work for a living. I don't have > > > time, patience, or inclination to read hundreds of pages of poorly > > > written documentation with no boolean search capability just to > > > find the one tidbit that might relate to the problem I'm having. > > > Sorry; it's my pet peeve. Where I work, the coding is not complete > > > until the documentation is (b-trieve) indexed. > > > Granted, it may be a bit intimidating to have to go through tons of > > documents to find answers. But many, including me, won't just hand > > you the answers you seek without first wanting you to show that > > you're serious about using Linux. Something as simple as this will > > usually get something. Things that are more involved may not. > > > > Generally all that some like me ask is that you do some of the work. > > We(I) won't just hand you the answers outright or you'll never learn > > anything. If not learning anything is what you want, there are > > platforms suited to those purposes. Linux isn't one of them. > > > > However, if you show an inclination toward trying to figure out how > > to do things on your own, and you find yourself stumped or unable to > > locate suitable documentation, we'll (I'll) bend over backward to > > help. > > > > Lack of time is a suitable excuse. But it won't always work, > > especially if it appears to be overused. > > > > Therapy is expensive, popping bubble wrap is cheap. You choose. > > Thank you for the thoughts and the earlier information. > > My response really was directed to Mr. Sykes. His message appears to > add nothing but his signature to your message. I am, therefore, > perplexed. Did he mean to add something that would help? Was he > reiterating your message in an attempt to say "me too?" Or, was he > trying to suggest that it's all so simple and I should RTFM? > > For the most part, I agree with you. I wouldn't be a developer if I > didn't like to figure things out. My peeve isn't with you -- or those > like us -- who don't want to abet peoples' laziness. In my practice as > a developer and manager, I truly believe -- and insist -- that the > project is not finished until the documentation is finished... and the > documentation ain't finished until, at the very least, it is keyword > indexed. > > The Linux community frequently presents it's documentation as HTML > pages with a hyper-linked table of contents. There is no mechanism for > searching the entire set of html pages for the keywords that will lead > me to the answer I seek. This, in my opinion, is not acceptable > documentation. The man pages, because of their very narrow scope, are > no better. The list archives are a gold mine of information but also > suffer from extremely limited search capability. Help files, > generally, don't exist. This is the ONE area where MS has the > advantage of Linux. There have been a large number of alternatives presented for indexing/archiving the mailing lists over the past few years. Those have been things that were done by individuals in their spare time. They have been limited to a few select groups at a time, or they've been short-lived because of the time and resources needed for maintaining them. While the efforts of those doing the archiving have been helpful, the limitations make the situation completely unsatisfactory. There have been a lot of people come and go that have lobbied for Redhat to do a better job of making the archives searchable. The current situation is generally how things end: not very useful. The whole documentation situation has been a complaint for a number of years as well. It's better than it was, but it still has a long way to go before it reaches a good enough level to make it actually useful.The HoWTOs have come a long way. The problem is that average users end up writing them. They are commonly missing the time, the tools or the knowledge of methods to make the documents friendlier to end users. With the way things are structured, it's highly unlikely that great documentation will become the norm. Only someone willing to spend the time and money to fix things can solve it. For little or no return no less, I don't see that happening. The "help" systems are in a similar boat. There are a number of WMs, and all do things essentially any way they choose, no matter how others choose to do things. For some, the "help' file is a README or a manpage. Since they're small-time operations (i.e. one guy doing everything), that isn't likely to improve much. Others spend a lot of time on the WM and little on the docs. Still others have a buggy WM and a great document explaining what they hope will work for people. Once you learn your way around on a lot of things, it actually starts to make some sense. That's not to say things can't be improved. But it gets easier to figure out _where_ you should look for something in particular, even if finding it in the docs can still be somewhat of a chore. Like so many things linux, if you can do anything to improve something, practically everybody will appreciate it in the end. > Now, I'd better don my asbestos suit. > > P.S. chbg still does not work for me. It doesn't work, it doesn't control backgrounds, it fails to compile? Not sure what "doesn't work" means. -- Weird enough for government work. -- Psyche-list mailing list Psyche-list@redhat.com https://listman.redhat.com/mailman/listinfo/psyche-list
