X-IPI Cepero Bonilla-MailScanner: Found to be clean X-MailScanner-Envelope-From: [email protected] X-Spam-Status: No
Muy bueno el artículo. Pero ( y sin ninguna intención de desvariar ) ¿En esta lista somos hackers? > Leete esto: "Cómo hacer preguntas de manera inteligente"[1] > [1] http://www.nova.uci.cu/website/foros/viewtopic.php?f=30&t=167 > Saludos, > Orlan2 > ******************************* > Por si no tienes navegación, aquí lo pego: > ******************************* > 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 [email protected].) > > 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). > > > __________________________________________________________________________ > Este mensaje ha sido analizado por Kaspersky Antivirus y se considera > que está Libre de Virus. *****Red Informática***** > Empresa Provincial Productora y Distribuidora de Alimentos de Holguín > > > _______________________________________________ > Cancelar suscripción > https://listas.softwarelibre.cu/mailman/listinfo/linux-l > Buscar en el archivo > http://listas.softwarelibre.cu/buscar/linux-l > -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio.
_______________________________________________ Cancelar suscripción https://listas.softwarelibre.cu/mailman/listinfo/linux-l Buscar en el archivo http://listas.softwarelibre.cu/buscar/linux-l
