Re: O.T - Federico Sciarretta Miliozzi" <sciarret@gmail.com
El día 4 de enero de 1980 00:01, l.hl.leyva <hliuber@iscm.vcl.sld.cu> escribió:
> El mar, 26-01-2010 a las 12:26 -0300, Felix Perez escribió:
>> El día 26 de enero de 2010 10:31, Adi@n RuiZ <adian@tdad.ssp.rimed.cu> escribió:
>> > Federico, si las preguntas que hacemos muchos no te gustan o las vez "MUY
>> > FACIL" date de baja de la lista, y sobre google, quizas y tu puedas
>> > buscar, otros muchos no tienen acceso.
>> >
>> Voy a actuar como abogado del diablo.
>> Ni su consulta ni la de Liuebr, hacen mención a que no disponen de
>> acceso a la web, asi que ni la lista ni los listeros tienen porque
>> asumir que no pueden buscar info en la red.
>> En muchas ocasiones, las consultas que algunos hacen su respuesta esta
>> en la misma documentación del paquete o en las man las cuales estan
>> instaladas en su mismo sistema.
>> En otras ocasiones los que consultan creen que esto es soporte técnico
>> de pago y creen que es obligación de la lista el resolver sus
>> problemas.
>> Hay algunos que su firma no se condice con la forma de escribir que
>> tienen, tanto en su forma con en su fondo.
>> Y por últmo esta lista no tiene poderes de supervaca :-)
>>
>> > Espero sepa medirse a la hora de referirse a algo o algun tema de la
>> > lista. Es de muy mal gusto, encontrarse con personas como usted o al menos
>> > con comentarios como los suyos sin conocer lo que sucede.
>> >
>> No se tiene porque suponer que todo el mundo conoce o esta pendiente
>> de lo que pase o no pase en la isla, cuando dos personas intentan
>> comunicarse el emisor debe esforzarse para que el receptor entienda su
>> mensaje, si el receptor no entiende es porque el emisor ha fallado
>> emitiendo su mensaje. Con esto digo que son ustedes, específicamente
>> los listeros cubanos, los que deben esforzarse al redactar los
>> mensajes a la lista, ser claros, precisos y aportar algún datos
>> adicional (tener o no tener acceso web por ej.).
>>
>> Saludos.
>>
>>
>> --
>> usuario linux #274354
>> normas de la lista: http://wiki.debian.org/NormasLista
>>
>>
> Felix, estas en toda tu razon, pero hermao,
> si alguien aca en lista un dia probo el plone y le dio bateo con el
> apache, enseguida recuerda y me da un norte,
> luego busco en la web, hasta donde llegue y sino encuentro nada vuelvo a
> preguntar en lista, de eso se trata,
> no de violar normas, ni de hacer pregunstas inteligentes, se trata de
> resolver el problema NO acosta de ustedes pero si con su experiencia,
> amigo, envié hace por dos web, ya estoy relacionandome con el tema,
> antes de estudiarlo imposible hacer una consuta inteligente, creo...
> amigo, nos escribimos que ya hoy estoy atrasado. Dame una mano que estoy
> jodido.
> un abrazo,
> liuber's
>
>
Estimado Liubers me consta usted no entra en algunas de las
puntualizaciones que hice, es más , me consta los esfuerzos que ha
echo teniendo una cuenta de email con restricciones y como se las ha
ingeniado para resolver sus problemas, pero hay otros usuarios
coterraneos suyo que la verdad es que no respetan nada, tengo un par
de ellos en el filtro.
Estimado en casos como el suyo cuente con mi experiencia (que no es
mucha) y mi ayuda, asi como también a todo el que respete ciertas
normas básicas y quiera aprender.
Puntualizando en lo de preguntas inteligentes, esto se refiere a una
serie de pautas del como hacer preguntas que logren obtener
respuestas, no se refiere a que se hagan preguntas tontas.
les dejo un enlace para los que tienen acceso web y sino lo pueden
leer aca mismo, disculpen por loextenso, peroes para los que no tienen
acceso web.
Cómo hacer preguntas de manera inteligente
Copyright © 2001 por Eric S. Raymond
Copyright de la traducción © 2001 por Jose M. Fernández
Índice de contenidos
Introducción
Antes de preguntar
Cuando preguntes
Cómo interpretar las respuestas
Sobre cómo no reaccionar como un perdedor
Preguntas que no hacer
Buenas y malas preguntas
Si no logras obtener respuesta
Introducción
En el mundo de los hackers, el tipo de respuestas que obtengas a tus
preguntas técnicas depende tanto de la manera en que formules tus
preguntas como de la dificultad de desarrollar la respuesta. En esta
guía se enseñará cómo preguntar de manera que puedas obtener una
respuesta satisfactoria.
Lo primero que tienes que entender es que a los hackers les gustan los
problemas realmente complejos y las buenas preguntas que les hagan
pensar en ellos. De no ser así no estaríamos aquí. Si nos proporcionas
una cuestión interesante te estaremos agradecidos; las buenas
preguntas suponen un estímulo y un regalo. Las buenas preguntas nos
ayudan a desarrollar nuestra comprensión, y a menudo revelan problemas
que podíamos no haber percibido o en los que de otra manera no
habríamos reparado. Entre los hackers, "¡Buena pregunta!" debe
entenderse como un sincero cumplido.
A pesar de esto, los hackers tienen la reputación de enfrentarse a las
preguntas sencillas con hostilidad o arrogancia. A veces parece como
si resultásemos hostiles a los principiantes o a los ignorantes. Pero
eso realmente no es cierto.
Lo que somos, de una manera no apologética, es hostiles con la gente
que parece no querer pensar o hacer sus deberes antes de plantear las
preguntas. La gente de ese tipo son sumideros de tiempo -- toman sin
dar a cambio, desperdician el tiempo que podríamos haber dedicado a
otra cuestión más interesante y con otra persona más merecedora de una
respuesta. A las personas de este tipo las llamamos "perdedores" (y
por razones históricas a veces escribimos "lusers".
Somos, de largo, voluntarios. Robamos el tiempo de vidas ocupadas para
responder preguntas, y a veces nos sobrecargan. Así que filtramos sin
tregua. En particular, desechamos las preguntas de quienes parecen ser
perdedores para ocupar el tiempo que dedicamos a responder preguntas
de una manera más eficiente, con los ganadores.
Tú no quieres ser uno de los perdedores. Tampoco quieres parecerte a
ninguno de ellos. La mejor manera de obtener una respuestas rápida y
eficiente es preguntando como un ganador — como una persona con
inteligencia, confianza en sí mismo e indicios de que necesita ayuda
con un problema en particular.
(Las mejoras a esta guía serán bienvenidas. Puede enviar sus
sugerencias (en inglés) a esr@thyrsus.com.)
N. del T.: "luser" es una contracción de los términos "user" (usuario)
y "loser" (perdedor).
Antes de preguntar
Antes de hacer una pregunta técnica por correo, en un grupo de
noticias o en el foro de un sitio web, haz lo siguiente:
1.
Intenta encontrar una respuesta leyendo el manual.
2.
Intenta encontrar una respuesta leyendo las FAQs
3.
Intenta encontrar una respuesta buscando en la web.
4.
Intenta encontrar la respuesta preguntándole a un amigo con más
experiencia.
Cuando hagas tu pregunta, destaca el hecho de que ya has hecho todo
esto; esto ayudará a establecer que no eres una esponja vaga y que
sólo estás desperdiciando el tiempo de los demás. Aún mejor, destaca
lo que hayas aprendido a partir de estas cosas. Nos gusta responder a
la gente que ha demostrado ser capaz de aprender de las respuestas.
Prepara tu pregunta. Piensa en ella. Las preguntas precipitadas
reciben respuestas precipitadas, o ni siquiera eso. Cuanto más hagas
para demostrar que has puesto pensamiento y esfuerzo en resolver tu
problema antes de pedir ayuda, más cerca estarás de recibirla
realmente.
Ten cuidado de no hacer la pregunta equivocada. Si haces una que esté
basada en asunciones erróneas, Hacker Al Azar seguramente te
responderá con algo literal e inútil mientras piensa "Qué pregunta más
estúpida...", y esperando que la experiencia de obtener una respuesta
a lo que has preguntado exactamente en vez de a lo que necesitas saber
te enseñará una lección.
Nunca asumas que tienes derecho a una respuesta. No lo tienes. Te
ganarás una respuesta, si te la ganas haciendo una pregunta
sustancial, interesante y que haga pensar— una que contribuya
implícitamente a la experiencia de la comunidad antes que solicitar de
manera pasiva conocimiento de los demás.
Por otra parte, un muy buen comienzo es dejar claro que puedes y
quieres participar en el proceso de desarrollar la solución. "¿Tiene
alguien alguna pista?" "¿Qué le falta a mi ejemplo?" y "¿Hay alguna
página que debiera haber consultado?" tendrán más probabilidades de
ser respondidas que "Publica por favor el procedimiento exacto que
debería seguir", porque estás dejando claro que estás realmente
deseoso de completar el proceso si alguien simplemente te orienta en
la dirección correcta.
Cuando preguntes
Elige el foro con cuidado
Ten cuidado al elegir dónde planteas tu pregunta. Seguramente te
ignorarán o te tacharán de perdedor si:
*
publicas tu pregunta en un foro en el que se encuentra fuera de
lugar (off topic)
*
publicas una pregunta muy elemental en un foro en el que se
esperan preguntas técnicas avanzadas, o viceversa
*
publicas el mensaje al mismo tiempo en grupos de noticas muy
diferentes (cross-posting)
Los hackers descartan las preguntas inapropiadas para intentar
proteger sus canales de comunicación de lo insustancial. No quieres
que te suceda eso.
Escribe de manera clara respetando la ortografía y la gramática
Sabemos por experiencia que los escritores descuidados y chapuceros
también piensan de manera desordenada y chapucera (a menudo lo
suficiente como para apostar por ello, no obstante). Responder a
pensadores descuidados y chapuceros no recompensa; mejor estaríamos
usando nuestro tiempo en cualquier otro lugar.
Por esto, es importante expresar tu pregunta de manera clara. Si no
puedes molestarte en hacer eso, nosotros no podemos molestarnos en
prestarte atención. Aprovecha el esfuerzo añadido en pulir tu
lenguaje. No tiene que ser nada estirado ni formal — de hecho, la
cultura hacker valora el habla informal, la jerga y el lenguaje cómico
usado con precisión. Pero tiene que ser preciso; tiene que haber
alguna indicación de que estás pensando y prestando atención.
Deletrea correctamente. No confundas "its" con "it's" o "loose" con
"lose". No ESCRIBAS TODO EN MAYÚSCULAS, eso se lee como si estuvieses
gritando, se considera poco "fino". Si escribes como un bobo medio
analfabeto probablemente te ignorarán. Escribir como un hax0r script
kiddie de l33t es el beso de la muerte absoluto y te garantiza que no
recibirás otra cosa que un silencio sepulcral (o, si tienes suerte, un
montón de desprecio y sarcasmo).
Si preguntas en un foro en el que no se usa tu idioma materno,
obtendrás una cantidad limitada de avisos por tus errores gramaticales
y de ortografía — pero ninguno añadido por tus argumentaciones
chapuceras (y sí, normalmente conocemos la diferencia). Además, a
menos que conozcas las lenguas de quienes te respondan, escribe en
inglés. Los hackers ocupados tienden a descartar las preguntas en
idiomas que no entienden, y el inglés es el idioma de trabajo en la
red. Al escribir en inglés minimizas las posibilidades de que
descarten tu pregunta sin leerla.
Envía las preguntas en formatos que sean fáciles de entender
Si artificialmente haces tu pregunta difícil de leer, tendrá más
probabilidades de ser ignorada en favor de una que no lo sea. Por
esto:
*
Envía el correo en texto plano, no en HTML.
*
No envíes correo en el que párrafos completos consten de una
única línea * múltiples veces. (Esto dificulta responder sólo a partes
del mensaje.)
*
Tampoco envíes mensaje codificados como MIME Quoted-Printable;
todos esos =20 esparcidos por el texto son feos y además distraen.
*
Jamás de los jamases esperes que los hackers puedan leer
formatos de documentos propietarios como Microsoft Word. La mayoría de
los hackers reaccionan a esto de igual manera que reaccionarías tú
ante un montón de estiércol humeante volcado en el umbral de tu
puerta.
*
Si envías correo desde una máquina con Windows, desactiva la
estúpida prestación "Smart Quotes" (citas inteligentes) de Outlook.
Esto es para evitar caracteres de basura esparcidos por tu mensaje.
Usa títulos específicos y con sentido
En las listas de correo o en los grupos de noticias, la cabecera del
mensaje es tu oportunidad de oro para atraer la atención de expertos
cualificados en aproximadamente 50 caracteres o menos. No los
desperdicies en balbuceos como "Por favor ayúdame" (de "POR FAVOR
AYÚDAME!!!" ya ni hablamos). No intentes impresionarnos con lo
profundo de tu angustia; mejor usa ese preciado espacio para una
descripción lo más concisa posible del problema.
Estúpido:
¡AYUDA! ¡El vídeo no funciona en mi portátil!
Inteligente:
Cursor del ratón deformado con XFree86 4.1, chipset de vídeo Loquesea MV1005
Sé preciso e informativo sobre tu problema
*
Describe los síntomas de tu problema o error con cuidado y claramente.
*
Describe el entorno en el que ocurre (máquina, S.O., aplicación,
loquesea).
*
Describe la investigación que llevaste a cabo para acotar una
posible respuesta al problema antes de hacer la pregunta.
*
Describe los pasos de diagnóstico que llevaste a cabo e intenta
solucionar el problema tú mismo antes de formular la cuestión.
*
Describe cualquier cambio reciente en tu ordenador o combinación
de software que pueda resultar relevante.
Hazlo lo mejor que puedas para anticiparte a las preguntas que un
hacker te haría, y para responderlas antes de tu solicitud de ayuda.
Simon Tatham ha escrito un excelente ensayo titulado Cómo informar de
errores de manera efectiva. Te recomiendo efusivamente que lo leas.
Describe los síntomas del problema, no tus suposiciones
No es útil decirle a los hackers lo que tú crees que está causándote
el problema. (Si tus teorías de diagnóstico fueran tan fiables,
¿estarías pidiendo ayuda a otros?) Por esto, asegúrate de que
únicamente estás contándoles los síntomas de lo que va mal y no tus
interpretaciones o teorías. Deja que ellos lleven a cabo las
interpretaciones y pronuncien su diagnóstico.
Estúpida:
Me salen errores SIG11 durante la compilación del núcleo, y
sospecho que haya podido romperse un hilo en uno de los circuitos de
la placa base. ¿Cuál es la mejor manera de comprobar eso?
Inteligente:
Mi K6/233 ensamblado por mí con una placa base FIC-PA2007 (chipset
VIA Apollo VP2) con 256MB Corsair PC133 SDRAM empieza a tener
frecuentes errores SIG11 sobre unos 20 minutos después de haberlo
arrancado durante el curso de compilaciones del núcleo, pero nunca
durante los primeros 20 minutos. Si reinicio no se reinicia el reloj,
pero si lo apago durante la noche sí. Pasar toda la RAM a la partición
de intercambio no ha servido de nada. A continuación os pongo la parte
relevante del registro de una típica sesión de compilación.
Describe los síntomas de tu problema en orden cronológico
Las pistas más útiles para averiguar qué ha ido mal se encuentran a
menudo en los acontecimientos inmediatamente anteriores. Por esto,
deberías describir con precisión lo que hiciste, y lo que hizo la
máquina, hasta el momento fatídico. En el caso de procesos por línea
de órdenes, disponer de un registro de la sesión (p.ej., usando la
utilidad del "script") y citando las veinte líneas o así relevantes
resultaría muy útil.
Si el programa en cuestión tiene opciones de diagnóstico (como -v para
prolijo) intenta pensar cuidadosamente en elegir opciones que puedan
añadir información de depuración útil para la transcripción.
Si tu mensaje acaba resultando muy largo (más de cuatro párrafos),
puede resultar útil comentar el problema de manera sucinta al
principio y luego hacerlo de manera cronológica. De esta manera, los
hackers sabrán dónde mirar al leer tu mensaje.
No solicites que te respondan por correo en privado
Los hackers creen que resolver problemas debería ser un proceso
público y transparente durante el cual un primer intento de respuesta
puede y debería corregirse si alguien con más conocimientos percibe
que la respuesta es incompleta o incorrecta. Además, obtienen parte de
su recompensa por responder al verse que son competentes y que poseen
conocimientos suficientes por parte de sus iguales.
Cuando pides una respuesta privada, estás interrumpiendo tanto el
proceso como la recompensa. No hagas eso. Es elección de quien
responde hacerlo en privado — y si lo hace, normalmente es porque
piensa que la pregunta es demasiado obvia o mal planteada como para
resultar interesante para otros.
Hay una excepción limitada a esta regla. Si piensas que puedes recibir
una gran cantidad de respuestas muy similares por el tipo de pregunta,
entonces las palabras mágicas son "mandadme las respuestas por
correo-e y haré un resúmen para el grupo". Se considera cortés ahorrar
a la lista de correo o al grupo de noticias una gran cantidad de
respuestas sustancialmente idénticas — pero evidentemente tienes que
mantener la promesa de resumirlas.
Evita las preguntas insustanciales
Resiste la tentación de cerrar tu consulta con preguntas
semánticamente nulas como "¿Puede ayudarme alguien?" o "¿Hay alguna
respuesta?" Primero: si has escrito la descripción de tu problema de
manera medianamente competente, ese tipo de preguntas añadidas sin más
resultan, como poco, supérfluas. Segundo: al ser supérfluas, los
hackers las encuentran molestas — y probablemente te devolverán
respuestas de una lógica impecable aunque ignorándote como "Sí, pueden
ayudarte" o "No, no hay ayuda para ti".
La cortesía nunca hiere, e incluso a veces hasta ayuda.
Sé cortés. Usa "Por favor" y "Gracias por adelantado". Deja claro que
aprecias el tiempo que emplea la gente ayudándote gratis.
Sé honesto, esto no es tan importante como (y no puede sustituir a)
ser correcto gramaticalmente, claro, preciso y descriptivo, evitar
formatos propietarios, etc; los hackers prefieren, por lo general, los
informes sobre errores concretos técnicamente aunque bruscos a la
vaguedad educada. (Si esto te deja contrariado, recuerda que valoramos
una pregunta por lo que nos enseña).
De todos modos, si obtuviste tus conocimientos técnicos en una
tómbola, la educación incrementará tus posibilidades de recibir una
respuesta útil.
Concluye con una breve nota sobre la solución
Envía una nota tras haber resuelto el problema a todos los que te
ayudaron; hazles saber cómo acabó todo y agradéceles de nuevo su
ayuda. Si el problema atrajo el interés general en una lista de correo
o grupo de noticias, entonces será apropiado publicar la nota allí.
La nota no tiene que ser larga ni desarrollada, un sencillo "Pepe -
que al final resulta que lo que fallaba era el cable. Gracias a todos.
- Jose Luis" será mejor que nada. De hecho, un resúmen corto y
agradable es mejor que una larga disertación a menos que la solución
requiera de cierta profundidad técnica.
Además de ser cortés e informativo, esta especie de seguimiento ayuda
a todos los que te asistieron a sentir una sensación satisfactoria de
cercanía al problema. Si tú no eres un hacker, créete que ese
sentimiento es muy importante para los gurús y expertos a quienes
pediste ayuda. Los problemas que acaban sin resolverse resultan
frustrantes; los hackers desean verlos resueltos. El buen karma que
aliviar ese picor te hará ganar te resultará de mucha ayuda la próxima
vez que necesites plantear una pregunta.
Cómo interpretar las respuestas
RTFM y STFW: cómo decirte que la has cagado seriamente
Hay una tradición antigua y venerada: si obtienes por respuesta un
"RTFM", la persona que lo envió piensa que deberías haberte leído el
puto manual. Casi con total seguridad estará en lo cierto. Ve y lee.
RTFM tiene un familiar más joven. Si recibes como respuesta "STFW",
quien te lo envía piensa que deberías haber Buscado en La Puta Web.
Casi con toda certeza tendrá razón. Ve y busca.
A menudo, quien envía una de estas respuestas está contemplando el
manual o la página web en cuestión mientras escribe. Estas respuestas
significan que piensa que (a) la información que necesitas es fácil de
encontrar, y (b) aprenderás más si buscas tú mismo la información que
si te la dan a "digerir" con cuchara.
Esto no debería ofenderte; según el estándar de los hackers, se te
está mostrando cierto respeto (aunque áspero, no lo neguemos) al
simplemente no ignorarte. Deberías agradecer la extrema amabilidad.
Si no entiendes...
Si no entiendes la respuesta, no devuelvas inmediatamente la solicitud
de una clarificación. Usa las mismas herramientas que utilizaste para
intentar resolver tu pregunta original (manuales, PUFs, la Web, amigos
con mayores destrezas) para entender la respuesta. Si necesitas pedir
una clarificación, intenta demostrar lo que has aprendido.
Por ejemplo, supón que te digo: "Suena como si tuvieses un zentry
atascado; necesitarás liberarlo." Entonces:
He aquí una mala pregunta: "¿Qué es un zentry?"
He aquí una buena pregunta: "Está bien, he leído la página de manual y
los zentrys sólo se mencionan bajo las variables -z y -p. En ninguna
de ellas se menciona nada sobre liberar a los zentrys. ¿Es una de
éstas o me estoy perdiendo algo?"
Sobre cómo no reaccionar como un perdedor
Hay bastantes posibilidades de que te equivoques más de una vez en
foros de la comunidad hacker -- de maneras detalladas en este artículo
o similares. Y se te dirá exactamente en qué te equivocaste,
posiblemente con profusos detalles. En público.
Cuando esto sucede, lo peor que puedes hacer es lamentarte por la
experiencia, denotar que te han asaltado verbalmente, pedir disculpas,
llorar, contener la respiración, amenazar con pleitos, quejarte a los
jefes de la gente, dejar la tapa del baño abierta, etc. En vez de eso,
esto es lo que tienes que hacer:
Superarlo. Es normal. De hecho, resulta saludable y apropiado.
Los estándares de la comunidad no se mantienen por sí mismos: los
mantiene la gente que los aplica activa, visiblemente, en público. No
te quejes de que todas las críticas se te deberían haber enviado por
correo privado: así no es como funciona esto. Ni resulta útil insistir
en que se te ha insultado personalmente cuando alguien comenta que
alguna de tus peticiones era errónea, o que sus opiniones diferían.
Ésas son actitudes de perdedores.
Ha habido foros de hackers en los que, aparte de un sentido de la
hipercortesía mal guiado, se ha prohibido la entrada a participantes
por enviar cualquier mensaje haciendo constar errores en los mensajes
de los demás, y se les ha dicho "No digas nada si no deseas ayudar al
usuario". El éxodo de los participantes más experimentados a otros
lugares les ha hecho descender al balbuceo sin el menor sentido y han
perdido toda su utilidad como foros técnicos.
Exageradamente "amigable" (de esa manera) o útil: Elige uno.
Recuerda: cuando ese hacker te diga que te has equivocado, y (no
importa cuán rudamente) te diga que no vuelvas a hacerlo, su actuación
te concierne a (1) ti y a (2) su comunidad. Sería mucho más sencillo
para él ignorarte poniéndote un filtro. Si no eres capaz de ser
agradecido ten al menos un poco de dignidad, no te quejes y no esperes
que te traten como una frágil muñeca sólo porque seas un recién
llegado de alma teatralmente hipersensible y con ilusiones de estar
autorizado a todo.
Preguntas que no hacer
He aquí algunas preguntas estúpidas que ya se han convertido en
clásicas junto con lo que los hackers están pensando cuando no las
responden.
P: ¿Dónde puedo encontrar el programa X?
P: Tengo problemas con mi máquina en Windows. ¿Podríais ayudarme?
P: Tengo problemas al instalar Linux o X. ¿Podríais ayudarme?
P: ¿Cómo puedo convertirme en root/robar privilegios de operador de
canal/leer el correo de alguien?
P: ¿Dónde puedo encontrar el programa X?
R: En el mismo lugar donde yo lo habría encontrado, imbécil -- al otro
lado de un buscador.. Dios, ¿Aún no sabe nadie cómo usar Google?
P: Tengo problemas con mi máquina en Windows. ¿Podríais ayudarme?
R: Claro. Tira esa basura de Microsoft e instala Linux.
P: Tengo problemas al instalar Linux o X. ¿Podríais ayudarme?
R: No. Necesitaría poder acceder físicamente a tu máquina para
resolver eso. Pide ayuda en tu grupo de usuarios de Linux local para
eso.
P: ¿Cómo puedo convertirme en root/robar privilegios de operador de un
canal/leer el correo de otra persona?
R: Eres un desgraciado por querer hacer esas cosas y un subnormal por
pedir a un hacker que te ayude.
Buenas y malas preguntas
Finalmente, voy a ilustrar con ejemplos cómo hacer preguntas de una
manera inteligente; he aquí pares de preguntas sobre el mismo
problema, una planteada de manera estúpida y otra de manera
inteligente.
Estúpida: ¿Dónde puedo encontrar información sobre el Funli Flurbamático?
Esta pregunta está pidiendo a gritos un"STFW" como respuesta.
Inteligente: He usado Google para intentar encontrar algo sobre el
"Funli Flurbamático 2600" en la Web, pero no he obtenido resultados
satisfactorios. ¿Sabe alguien dónde puedo encontrar información de
programación sobre este dispositivo?
Éste ya ha STFWado, y suena como si tuviese un verdadero problema.
Estúpida: No he conseguido compilar el código del proyecto loquesea.
¿Por qué está roto?
Asume que a todo el mundo le ocurre lo mismo. Qué arrogante.
Inteligente: El código del proyecto loquesea no compila bajo Nulix
versión 6.2. Me he leído las PUF, pero no aparece nada de problemas
relacionados con Nulix. Os pego aquí una transcripción de mi intento
de compilación; ¿es por algo que hice mal?
Ha especificado el entorno, se ha leído las PUF, ha mostrado el
error y no ha asumido que sus problemas son culpa de otra persona.
Quizá este chico se merezca algo de atención.
Estúpida: Tengo problemas con mi placa base. ¿Puede ayudarme alguien?
La respuesta de un hacker cualquiera a esto sería algo como "De
acuerdo. ¿Necesitas también eructar y que te cambie los pañales?"
seguido de una ligera presión sobre la tecla Supr.
Inteligente:He intentado X, Y y Z con la placa base S2464. Cuando eso
no funcionó, intenté A, B y C. Fíjense en ese curioso síntoma cuando
hice C. Obviamente el florbeador está gromiqueando, pero los
resultados no son los que podrían esperarse. ¿Cuáles son las causas
habituales del gromiqueo en las placas multiprocesador? ¿Sabe alguien
de alguna prueba más que pueda llevar a cabo para averiguar el
problema?
Esta persona, por otra parte, parece merecedora de una respuesta.
Ha mostrado su inteligencia en un intento de resolver el problema en
vez de esperar que le caiga una respuesta del cielo.
En la última pregunta, fijáos en la sutil pero importante diferencia
entre pedir "Dame una respuesta" y "Por favor, ayúdame a hacerme una
idea de qué diagnósticos adicionales puedo llevar a cabo para alcanzar
a ver la luz".
De hecho, la forma de la última pregunta se encuentra basada muy de
cerca en un incidente real que sucedió en Agosto de 2.001 en la lista
de correo del núcleo de Linux. Yo (Eric) era el que preguntaba
entonces. Estaba sufriendo misteriosos cuelgues con una placa Tyan
S2464. Los miembros de la lista aportaron la información crítica que
necesitaba para resolver el problema.
Al plantear la pregunta de la manera que la hice, le dí a la gente
algo con que entretenerse; hice fácil y atractivo para ellos que se
involucraran. Demostré respeto por la capacidad de mis compañeros y
les invité a consultarme también como compañero. También demostré
respeto por el valor de su tiempo haciéndoles saber los callejones sin
salida con los que ya me había topado.
Después de todo, cuando les dí a todos las gracias y remarqué lo bien
que había funcionado el proceso, un miembro de la lista de correo del
núcleo de Linux hizo la observación de que creía que había sido así no
porque yo tuvera un "nombre" en esa lista, sino porque hice la
pregunta de la manera adecuada.
Nosotros los hackers somos de alguna manera una ruda meritocracia;
estoy seguro de que tenía razón, y de que si me hubiese comportado
como una esponja se me habrían echado todos encima o me habrían
ignorado sin importar quien fuese. Su sugerencia de que había escrito
el completo incidente como una instrucción para otros condujo
directamente a la composición de esta guía.
Si no logras conseguir una respuesta
Somos conscientes que que hay mucha gente que sólo quiere usar el
software que escribimos y no está interesada en conocer los detalles
técnicos. Para la mayoría de la gente, un ordenador es meramente una
herramienta, un medio para un fin. Sabemos eso y no esperamos que todo
el mundo se interese en asuntos técnicos. No obstante, nuestro estilo
de responder se encuentra orientado a quienes sí se toman ese interés.
Por esto, si no obtienes respuesta, no te tomes como algo personal que
no sintamos que podamos ayudarte. Hay otros recursos a menudo mejor
adaptados a las necesidades de un principiante.
Hay muchos grupos de usuarios en línea y locales compuestos por
entusiastas del software incluso aunque nunca hayan escrito software
alguno ellos mismos. Estos grupos se forman de manera que la gente
pueda ayudarse entre sí y ayudar a los nuevos usuarios.
Hay además muchas compañías comerciales a las que puedes contratar
para que te presten su ayuda, tanto grande como pequeña. ¡Que no te
aterre la idea de tener que pagar por un poco de ayuda! Después de
todo, si al motor de tu coche se le rompe una junta seguramente
tendrás que llevarlo al mecánico y pagar para que te lo arreglen.
Incluso aunque el software no te costase nada, no puedes esperar que
el soporte sea siempre gratuito.
Para el software popular como Linux, hay al menos unos 10.000 usuarios
por cada desarrollador. Resulta imposible que una sola persona pueda
atender llamadas de soporte técnico de cerca de 10.000 usuarios.
Recuerda que aunque tengas que pagar por el soporte, estás aún pagando
mucho menos que si tuvieses que comprar el software (y el soporte para
el software de código cerrado es por lo general mucho más caro y menos
competente que el soporte para el software de código abierto).
Saludos.
--
usuario linux #274354
normas de la lista: http://wiki.debian.org/NormasLista
Reply to: