[Pluto-help] if ( How to become an hacker && How make questions )

[(R)ex Sanna]

About 'pluto-help digest, Vol 1 #785 - 18 msgs'

# Chiedo scusa a tutti, ma vorrei fare un piccolo appunto: sono certo che tutti, 
# nella ml, sono contenti nel rispondere a ogni genere di quesiti. Io comunque 
# consiglio a tutti i neofiti di leggersi anche un po' di documentazione, e non 
# limitarsi a porre domande "secche". Il motivo? Andare oltre! Leggendo la 
# documentazione sarete (saremo, mi ci metto anche io, ovvio) in grado di
# sapere più cose, e di incappare in meno problemi!
# Mi raccomando, la mia non è una critica né una sgridata: è un consiglio!
# Studiando (e non solo sbagliando) si impara...

Come al solito concordo con te.
Dato che molti NON leggono, ho pensato che per lo meno quelli che sono gia' 
dentro, potrebbero almeno leggere quello che segue.
Non l'ho scritto io,ma un signore che e' tra i fondatori del movimento hacker..

E. S. Raymond
E credo non abbia bisogno di presentazioni..

PER TUTTI COLORO CHE SCARTERANNO QUESTA MAIL PERCHE' E' IN INGLESE,
CONSIGLIO DI PENSARE AL LORO FUTURO, IMPARANDO QUESTA LINGUA,
NON SEMPLICEMENTE TRASCURANDOLA.

e vi ricordo anche una cosa che ci si passa :

FOLLOW THE PATH :
LOOK TO THE MASTER
FOLLOW THE MASTER
WALK WITH THE MASTER
SEE THROUGH THE MASTER

BECOME THE MASTER

Ripetetevelo finche' non ci crederete, e sono sicuro che molte cose nella vostra vita
cambieranno cosi' come e' successo da questo lato della tastiera.
Non fermatevi alle apparenze, non cliccate e basta, cercate di essere meglio di questa
macchina che chiamano vita.. ;o)

Un vostro amico fidato.
(R)ex

To [in ordine sparso] :
Dido, Davide Canepa, limaCAT, Judas, Vegeta, KBurn, Snowtura, Tiz, Leon,
Bonzo, Mauro Soligo, Andrea Dinale, Alberto Piras, Christian Cioni, New, Beppe,
Leonardo Boselli, 2 Calzini, Migil, e tutti i geek che riceveranno questa mail nella loro mailbox..
[Che essa sia una Maildir o una Mailbox non fa differenza.. :o) ]


===================================================================
[Tratto da : How to become an hacker.]

1. The world is full of fascinating problems waiting to be solved.

Being a hacker is lots of fun, but it's a kind of fun that takes lots of effort. 
The effort takes motivation. Successful athletes get their motivation from a kind 
of physical delight in making their bodies perform, in pushing themselves past 
their own physical limits. Similarly, to be a hacker you have to get a basic 
thrill from solving problems, sharpening your skills, and exercising your intelligence.
If you aren't the kind of person that feels this way naturally, you'll need to become 
one in order to make it as a hacker. Otherwise you'll find your hacking energy is 
sapped by distractions like sex, money, and social approval.
(You also have to develop a kind of faith in your own learning capacity 
-- a belief that even though you may not know all of what you need to solve a problem, 
if you tackle just a piece of it and learn from that, you'll learn enough to solve
the next piece -- and so on, until you're done.)


2. No problem should ever have to be solved twice.

Creative brains are a valuable, limited resource. They shouldn't be wasted 
on re-inventing the wheel when there are so many fascinating new problems waiting out there.
To behave like a hacker, you have to believe that the thinking time of other 
hackers is precious -- so much so that it's almost a moral duty for you to share 
information, solve problems and then give the solutions away just so other hackers 
can solve newproblems instead of having to perpetually re-address old ones.
(You don't have to believe that you're obligated to giveall your creative product away, 
though the hackers that do are the ones that get most respect from other hackers. 
It's consistent with hacker values to sell enough of it to keep you in food and rent and computers. 
It's fine to use your hacking skills to support a family or even get rich, as long as 
you don't forget your loyalty to your art and your fellow hackers while doing it.)


3. Boredom and drudgery are evil.

Hackers (and creative people in general) should never be bored or have to drudge 
at stupid repetitive work, because when this happens it means they aren't doing what 
only they can do -- solve new problems. This wastefulness hurts everybody. 
Therefore boredom and drudgery are not just unpleasant but actually evil.
To behave like a hacker, you have to believe this enough to want to automate 
away the boring bits as much as possible, not just for yourself but for everybody 
else (especially other hackers).
(There is one apparent exception to this. Hackers will sometimes do things that 
may seem repetitive or boring to an observer as a mind-clearing exercise, or in 
order to acquire a skill or have some particular kind of experience you can't have otherwise. 
But this is by choice -- nobody who can think should ever be forced into a situation that bores them.)
.



====================================
Per coloro che han letto e sono interessati a sapere di piu', consiglio il seguente link:

	http://www.tuxedo.org/jargon

Cosi' non ci saranno problemi di incomprensione in alcune mails..
E Vegeta evitera' di impazzire a cercare in dizionari non corretti.. ;o)



====================================
Per quanto invece concerne il modo di porre domande in una ML ecco che sempre il Guru,
si presta anche a dire come sarebbe bello agire.. 
====================================
Introduction :

In the world of hackers, the kind of answers you get to your technical questions depends as much 
on the way you ask the questions as on the difficulty of developing the answer. This guide will teach 
you how to ask questions in a way that is likely to get you a satisfactory answer.
The first thing to understand is that hackers actually like hard problems and good, thought-provoking 
questions about them. If we didn't, we wouldn't be here. If you give us an interesting question to chew 
on we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop 
our understanding, and often reveal problems we might not have noticed or thought about otherwise. 
Among hackers, "Good question!" is a strong and sincere compliment.
Despite this, hackers have a reputation for meeting simple questions with what looks like hostility or arrogance. 
It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true.
What we are, unapologetically, is hostile to people who seem to be unwilling to think or to do their 
own homework before asking questions. People like that are time sinks - they take without giving back, 
they waste time we could have spent on another question more interesting and another person more 
worthy of an answer. We call people like this "losers" (and for historical reasons we sometimes spell it "lusers").
We realize that there are many people who just want to use the software we write, and have 
no interest in learning technical details. For most people, a computer is merely a tool, a means to an end; 
they have more important things to do and lives to live. We acknowledge that, and don't expect 
everyone to take an interest in the technical matters that fascinate us. Nevertheless, our style 
of answering questions is tuned for people who do take such an interest and are willing to be 
active participants in problem-solving. That's not going to change. Nor should it; if it did, 
we would become less effective at the things we do best.
We're (largely) volunteers. We take time out of busy lives to answer questions, and at times we're 
overwhelmed with them. So we filter ruthlessly. In particular, we throw away questions from people
who appear to be losers in order to spend our question-answering time more efficiently, on winners.
If you find this attitude obnoxious, condescending, or arrogant, check your assumptions. We're not 
asking you to genuflect to us - in fact, most of us would love nothing more than to deal with you as 
an equal and welcome you into our culture, if you put in the effort required to make that possible. 
But it's simply not efficient for us to try to help people who are not willing to help themselves. 
If you can't live with this sort of discrimination, we suggest you pay somebody for a commercial 
support contract instead of asking hackers to personally donate help to you.
If you decide to come to us for help, you don't want to be one of the losers. 
You don't want to seem like one, either. The best way to get a rapid and responsive answer i
s to ask it like a winner - to ask it like a person with smarts, confidence, and clues who just 
happens to need help on one particular problem.
(Improvements to this guide are welcome. You can mail suggestions to esr a thyrsus.com. 
Note however that this document is not intended to be a general guide to netiquette, and I will 
generally reject suggestions that are not specifically related to eliciting useful answers in a technical forum.)



Before You Ask

Before asking a technical question by email, or in a newsgroup, or on a website chat board, do the following:


Procedure 1. 

Try to find an answer by inspection or experimentation.

Try to find an answer by reading the manual.

Try to find an answer by reading a FAQ.

Try to find an answer by searching the Web.

Try to find an answer by asking a skilled friend.

Try to find an answer by reading the source code.

When you ask your question, display the fact that you have done these things first; 
this will help establish that you're not being a lazy sponge and wasting people's time. 
Better yet, display what you have learned from doing these things. We like answering 
questions for people who have demonstrated that they can learn from the answers.
Use tactics like doing a Google search on the text of whatever error message you get. 
This might well take you straight to fix documentation or a mailing list thread that will answer your question.
Prepare your question. Think it through. Hasty-sounding questions get hasty answers, 
or none at all. The more you do to demonstrate that you have put thought and effort into 
solving your problem before asking for help, the more likely you are to actually get help.
Beware of asking the wrong question. If you ask one that is based on faulty assumptions, 
J. Random Hacker is quite likely to reply with a uselessly literal answer while thinking 
"Stupid question...", and hoping that the experience of getting what you asked for 
rather than what you needed will teach you a lesson.
Never assume you are entitled to an answer. You are not; you aren't, after all, paying 
for the service. You will earn an answer, if you earn it, by asking a question that is 
substantial, interesting, and thought-provoking - one that implicitly contributes to the experience 
of the community rather than merely passively demanding knowledge from others.
On the other hand, making it clear that you are able and willing to help in the process of developing 
the solution is a very good start. "Would someone provide a pointer?", "What is my example missing?" 
and "What site should I have checked?" are more likely to get answered than 
"Please post the exact procedure I should use." because you're making it clear that you're truly
willing to complete the process if someone can simply point you in the right direction.


When You Ask




Choose your forum carefully
Be sensitive in choosing where you ask your question. You are likely to be ignored, or written off as a loser, if you:

post your question to a forum where it is off topic

post a very elementary question to a forum where advanced technical questions are expected, or vice-versa

cross-post to too many different newsgroups

post a personal email to somebody who is neither an acquaintance of yours nor personally responsible for solving your problem

Hackers blow off questions that are inappropriately targeted in order to try to protect their 
communications channels from being drowned in irrelevance. You don't want this to happen to you.
Shooting off an email to a person or forum which you are not familiar with is risky at best. 
For example, do not assume that the author of an informative web page wants to be your free consultant. 
Do not make optimistic guesses about whether your question will be welcome 
-- if you are unsure, send it elsewhere, or refrain from sending it at all.
When selecting a newsgroup or mailing list, don't trust the name by itself too far; 
look for a FAQ or charter to verify that your question is on-topic. Read some of the back 
traffic before posting so you'll get a feel for how things are done there.
Know what your topic is! One of the classic mistakes is asking questions about the Unix or Windows 
programming interface in a forum devoted to a language or library or tool that is portable across both. 
If you don't understand why this is a blunder, you'd be best off not asking any questions at all until you get it.
In general, questions to a well-selected public forum are more likely to get useful 
answers than equivalent questions to a private one. There are multiple reasons for this. 
One is simply the size of the pool of potential respondents. Another is the size of the audience; 
hackers would rather answer questions that educate a lot of people than questions which only serve a few.
Understandably, skilled hackers and authors of popular software are already receiving 
more than their fair share of mistargeted messages. By adding to the flood, you could in 
extreme cases even be the straw which breaks the camel's back -- quite a few times, 
contributors to popular projects have withdrawn their support because the collateral damage
in the form of useless email traffic to their personal accounts became unbearable.
==========================================================================================

Per chi conosce :

su
cd /pub
more smoke
more beer
more freedom

chown you:users -R /world

cat THIS!

-- 
# ------------------------------------------------------------------------
# Take it. Use it.. Human knowledge belongs to the world..
# ------------------------------------------------------------------------