Mostrando entradas con la etiqueta infosec. Mostrar todas las entradas
Mostrando entradas con la etiqueta infosec. Mostrar todas las entradas
lunes, 22 de agosto de 2016
Acceso a kali por ssh (configuración)
SSH (Secure SHell, en español: intérprete de órdenes seguro) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico de X (Sistema de Ventanas X) para poder ejecutar programas gráficos si tenemos ejecutando un Servidor X (en sistemas Unix y Windows).
Aveces necesitamos conectarnos a nuestro computador para realizar x tarea, en particular hablamos de nuestro querido kali linux y para hacerlo necesitamos conectarnos a el de forma segura, podemos hacerlo desde nuestro teléfono android incluso, peropara hacerlo tenemos que hacer algunas cositas...
veamos unos pasos
1.Instalar en Kali Linux remote SSH – openSSH server o el servidor ssh
2.Habilitar el servicio SSH remoto en kali Linux al arranque
martes, 26 de noviembre de 2013
Nessus en Kali Linux : Instalación e integración con Metasploit
Descargar e instalar Nessus
Primero, tenemos que ir a aquí y aceptar el acuerdo de licencia. Tras aceptarlo, tenemos que elegir la plataforma para la que queremos descargar el instalador, en nuestro caso, como es Backtrack 5, elegiremos la versión para Ubuntu 9.10/10.04 (en mi caso de 32 bits).Ahora, para instalarlo tenemos que ejecutar:
1 | sudo dpkg -i Nessus-4.4.1-ubuntu910_i386.deb |
Una vez instalado nos dice que tenemos que añadir un usuario mediante:
1 | /opt/nessus/sbin/nessus-adduser |
Registrando Nessus
Si no se registra en la página oficial, no se podrán utilizar los plugins para el descubrimiento de vulnerabilidades así que entraremos aquí para registrarlo, y seleccionamos la opción Using Nessus at Home. Aceptamos el acuerdo de licencia e introducimos nuestros datos para que nos llegue al correo el código de activación.En el correo que nos llegará además del código de activación nos indican como hay que activar el producto dependiendo de que sistema operativo tengamos, en nuestro caso, como Backtrack realmente está basado sobre Ubuntu, solo tenemos que:
1 | /opt/nessus/bin/nessus-fetch --register XXXX-XXXX-XXXX-XXXX-XXXX |
Integrando Nessus con Metasploit
Para arrancar el demonio de Nessus podemos ejecutar:1 | /etc/init.d/nessusd start |
Para integrarlo con Metasploit, tenemos que iniciar Metasploit primero, ya sea mediante el menú de Backtrack, o mediante el comando:
1 | msfconsole |
Ahora, recordando las credenciales del usuario que registramos anteriormente, utilizamos, para conectar con Nessus el siguiente comando:
1 | nessus_connect usuario:password@127.0.0.1 ok |
viernes, 28 de junio de 2013
Filtrado el código fuente de #Carberp que se vendía en U$S40.000
Carberp era un kit de crimeware privado comercializado mayormente en Rusia,
pero miembros de la organización fueron detenidos en Rusia en el 2012 y
tiempo después sale una versión comercial del troyano Carberp que normalmente se vende por U$S40.000
en mercado negro y en varios foros hackers.
Pues bueno, se ha filtrado la semana pasada el código fuente del malware Carberp ya que algunos de los
vendedores que pusieron a disposición el código lo hicieron dentro de un archivo protegido por una
contraseña, contraseña que fue publicada recientemente.
El paquete está siendo analizando en detalle en este momento por muchos investigadores,
pero ya han confirmado que el código fuente es genuino y que aún contiene el bootkit
(un conjunto de funciones que infectan computadores en el nivel más bajo y mantiene la persistencia).
Investigadores temen que suceda lo mismo que sucedio cuando el código fuente de ZeuS
se filtró hace un par de años, varios grupos de cibercrimen comenzaron a modificarlo
para añadir nuevas funcionalidades y hacerlo indetectable.
Los investigadores de la empresa rusa de investigaciones de delitos informáticos Group-IB
afirman que si bien el código fuente de Carberp es completo, el código fuente del módulo bootkit
es sólo parcial.
Más información:
http://blog.segu-info.com.ar/2013/06/filtrado-el-codigo-fuente-de-carberp.html
http://news.softpedia.es/Filtrado-el-codigo-fuente-del-malware-Carberp-363460.html
Descarga del Código fuente de Carberp
Contraseña del RAR: Kj1#w2*LadiOQpw3oi029)K Oa(28)uspeh
lunes, 25 de marzo de 2013
Metasploit + Armitage en BackTrack 5R1
Area: Explotation Tools
Requisitos:
- Instalacion de PostgreSQL
- Instalacion de PGAdmin3
- Configuraciones
apt-get install postgresql-8.4 libpq-dev postgresql-client-8.4 pgadmin3
Configurar PostgreSQL
sudo su postgres -c psql
ALTER USER postgres WITH PASSWORD 'nueva_clave';
\q
sudo passwd -d postgres
sudo su postgres -c passwd
gem install pg
update-alternatives --config ruby (Seleccionar 0 para "auto-mode")
msfupdate
Crear el siguiente script en /root/.msfr/msfconsole.rc
db_driver postgresql
db_connect postgres:"clave_postgresql"@127.0.0.1/msf3db
Finalmente ejecutamos el comando:
msfconsole
exit (para salir)
Revisamos el PGAdmin3 si es que se ha creado la Base de datos msf3db
Ejecutar el siguiente comando:
msfrpcd -f -U usuario_postgresql -P clave -a 127.0.0.1 -p 55554 -S
Luego de iniciado el script iremos a ejecurtar el armitage
Una vez abierta la ventana principal realizamos clic en el botón ? De la izquina inferior derecha
Agregamos el usuario y contraseña de postgres (los creados anteriormente), dejamos el host 127.0.0.1 sin puerto asociado por último el nombre de la base de datos.
Por último realizamos click en set y repetimos los datos de usuario y contraseña y agregamos el puerto creado en msfrpcd (55554) y luego click en connect
Estamos Listos para comenzar a utilizar esta poderosa herramienta
sábado, 1 de septiembre de 2012
¿Qué motiva a un verdadero hacker?
- Se trata de una persona curiosa, paciente y creativa que investiga y no se detiene hasta controlar un sistema o perfeccionar su técnica.
- El término se aplica a desarrolladores de software apasionados por la informática que depuran y arreglan errores en los sistemas.
- También a aquellos que se infiltran en un sistema informático con el fin de eludir o desactivar las medidas de seguridad.
La motivación del verdadero hacker es el puro conocimiento de una persona curiosa, paciente y creativa que investiga y no se detiene hasta controlar un sistema o perfeccionar su técnica, según el último informe del Instituto Nacional de Tecnologías de la Comunicación (Inteco) sobre esta figura.
El estudio ha añadido que la palabra se utiliza tanto para definir a un desarrollador de software apasionado por la informática que depura y arregla errores en los sistemas, como para referirse a aquel que se infiltra en un sistema informático con el fin de eludir o desactivar las medidas de seguridad.El texto, de carácter divulgativo, tiene el objetivo de aportar más información sobre una figura tan ligada al mundo de la seguridad informática y ha señalado que actualmente "el término hacker puede tener connotaciones positivas y negativas en función del concepto que se maneje", según ha detallado esta semana Inteco en un comunicado.
Este análisis aborda los diferentes aspectos del 'hacking' y sus motivaciones y ha detallado si los objetivos del hacker soneconómicos o de otro tipo "se debería encasillar" a esta figura "en subtipos dentro de la cultura hacker", según el instituto estatal.
El documento concluye con una atención a la profesionalización de esta figura y diferencia, por un lado, el llamado 'hacking ético', que engloba todos aquellos servicios prestados para la seguridad de las empresas tanto por hackers como por consultores y expertos en seguridad y, por otro, el mercado negro y la ciberdelincuencia organizada.
En este último aspecto, el informe indica que "cuando el mercado no puede absorber en empresas lícitas el conocimiento de las personas con talento hacker, pueden aparecer otras organizaciones que intenten rentabilizar sus habilidades en otras áreas orientadas a la criminalidad" que, como las mafias, "se dedican al lucro propio de forma profesional".
El Observatorio de la Seguridad de la Información del instituto, con sede en León, ha recordado que el 'hacking' está íntimamente ligado al nacimiento de Internet y a las oportunidades económicas, técnicas y sociales que supuso desde sus inicios en la década de los 60 y 70.
Fuente: http://www.20minutos.es
sábado, 4 de agosto de 2012
DNS Spoofing con Ettercap en Backtrack5 – Tutorial
En este tutorial aprenderemos como verificar si alguna terminal de nuestra red es propensa a sufrir un ataque MITM (Man in the Middle), asi que primero que nada spoofing es muy diferente a sniffing, en el sniffing solo capturaremos o veremos los paquetes salientes de la red que estemos vigilando, mientras que Spoofing basicamente seremos una direccion de salida, basicamente podremos ser el router. Esto nos permitira hacer ciertos trucos…
Spoofing es una accion muy general, asi que hay varios tipos de spoofing, DNS spoofing, IP spoofing, y mas.
Que es DNS Spoofing?
DNS Spoofing es un ataque bajo la categoria MITM, ademas DNS Spoofing MIMA contien:
Envenenamiento ARP
Robo de sesiones
Robo de SSL
Spoofing de DNS
Cada ataque tiene su propia importancia, y las explicaremos en otro articulo cada uno. Pero por ahora sigamos con nuestro tutorial.
Ahora la pregunta es: Como realizar un spoofing de DNS, asi que para este tutorial ocuparemos Ettercap
Que es Ettercap?
De acuerdo al sitio oficial “Ettercap es una suite para pruebas MITM en redes LAN. se centra en vigilar en vivo conexiones y usando filtros para separar la informacion.”
Tiene soporte para Windows,Linux,BSD y OSX
Que necesitamos?:
Un sistema operativo (Linux o Windows)
Ettercap
Social Engineering Toolkit (SET)
Voy a ocupar Backtrack para este tutorial, ustedes puede usar cualquier otro OS, y ocupare el SET para poder hacerle spoof a mi IP y hacerla un sitio web.
Un saludo a los que lean este re-post.
lunes, 9 de julio de 2012
Volcado de contraseñas con mimikatz
mimikatz es una herramienta que entre otras características permite el volcado de contraseñas en texto claro de un sistema Windows, la exportación de certificados marcados como no exportables o la obtención de hashes de la SAM.
Una de las principales ventajas que presenta frente a otras herramientas como wce, es que aún no es demasiado popular y los antivirus no la detectan como aplicación maliciosa. Tan solo 5 de 41 la tienen catalogada como tal. ¡A ver lo que dura!
Para ver cómo funciona, mejor ver algunos ejemplos de uso.
1.- Nombre de usuario y PC
Para empezar y ver la sintaxis, algo sencillo. Obtención del nombre de usuario y el PC.
a.- Iniciar mimikatz desde la ruta en la que se haya descargado e invocar el módulo system con el comando "user" para sacar el nombre de usuario: system::user
b.- El nombre del equipo con el comando "computer" del módulo system:system::computer. Sencillo, ¿verdad?
2.- Contraseñas en claro de un dominio.
Como es lógico, es necesario tener permisos de administrador ya que la herramienta no explota ninguna vulnerabilidad de escalada de privilegios. En este ejemplo se hará uso junto a psexec de sysinternals para el uso remoto contra la dirección IP remota: 172.16.X.X
a.- Se autentica contra el servidor remoto (del que se volcarán las contraseñas) mediante el comando: net use \\172.16.X.X\admin$ que solicitará las credenciales.
b.- Se copia la librería auxiliar "sekurla.dll" en el directorio System32 del sistema remoto, proporcionada con el propio mimikatz: copy sekurla.dll \\172.16.X.X\admin$\system32
c.- El tercer paso es la ejecución de mimikatz, usando la arquitectura que corresponda, ya sea 32 o 64 bits: psexec /accepteula \\172.16.X.X\ -c mimikatz.exe
d.- Una vez arrancado se verifica que hay acceso al privilegio: SeDebugPrivilege, con el comando: privilege::debug aunque esto no es necesario si se tiene acceso SYSTEM.
e.- Se procede a inyectar la librería en el proceso de LSASS: inject::process lsass.exe sekurlsa.dll
f.- Por último, se solicitan las contraseñas con: @getLogonPasswords
Solucionar el problema no es sencillo, ya que requiere deshabilitar los Security Support Providers (SSP) TsPkg y Wdigest de la clave: HKLM\SYSTEM\CurrentControlSet\Control\LSA\Security Packages en caso de Windows 7 y 2008, opción no soportada por Microsoft y que rompe el Network Level Authentication (NLA) de RDP, dejando este de funcionar.
3.- Exportación de certificados.
Para exportar certificados, marcados como NO exportables, mimikatz parchea la CryptoApi y luego intenta la exportación. El ejemplo para mi equipo local:
a.- Se arranca mimikatz ejecutando el binario de la arquitectura que corresponda:C:\tmp\mimikatzz\x64\mimikatz
b.- Igual que en el caso anterior, se verifica el acceso a SeDebugPrivilege mediante:privilege::debug que debe responder "OK".
c.- Se procede al parcheo de la CryptoApi con el comando: crypto::patchcapi
d.- Se intentan exportar dos veces los certificados con la instrucción: crypto::exportCertificatespero falla, indicándolo con un resultado "KO".
e.- Cuando esto ocurre, hay que probar varias veces a parchear la cryptoapi y exportar, hasta que funciona tal y como muestra la captura. Dependiendo de la versión de Windows, será necesario usarcrypto::patchcapi o por el contrario crypto::patchcng
Referencias:
http://blog.opensecurityresearch.com/2012/06/using-mimikatz-to-dump-passwords.html
http://computer-forensics.sans.org/blog/2012/03/09/protecting-privileged-domain-accounts-disabling-encrypted-passwords#
http://blog.gentilkiwi.com/mimikatz
Leer más: Segu-Info: Volcado de contraseñas con mimikatz http://blog.segu-info.com.ar/2012/07/volcado-de-contrasenas-con-mimikatz.html#ixzz20AtcDPA0
Under Creative Commons License: Attribution Non-Commercial Share Alike
viernes, 20 de abril de 2012
Man in the middle con Cain y Abel (Tutorial)
Man in the middle con Cain y Abel
Hola!
Muy buenas a todos/as!
El ataque del “hombre en el medio” es algo, que no es nuevo ni mucho menos.
He creado un escenario súper sencillo en una red local.
El escenario es el siguiente.
Tenemos el pc de usuario en una parte de la red LOCAL y luego el atacante, con el símbolo del DragoN.
El atcante tiene Windows 7 y el usuario Windows XP.
Lo que haremos primero será poner la tarjeta en modo promiscuo, de manera que pondremos la tarjeta a escuchar todos los paquetes en la red.
Aquí tenemos el rango de la red LOCAL en el cual, nos mantendremos a la escucha.
Ahora detectaremos los equipos en la red, para poder hacer el ataque
Activamos el snifer y el ARP en Cain y Abel
En la pestaña de Snifer y en Hosts, escaneamos por MAC ADRESS.
Seleccionamos hacer todos los test para que empiece a descubrir todos los equipos de la red.
Podemos ver los equipos que va encontrando
Ahora que ya sabemos las IP de la red local, le damos a la tecla +
Aquí tenemos las diferentes IP’s, seleccionamos la Ip de la puerta de enlace.
Seleccionamos todos los host para hacer el man in the middle, y hacer poisoning
El ataque man in the middle ya ha empezado.
El ataque poisoning, ya está haciendo efecto, hasta que veremos lo siguiente
Podemos ver abajo el aviso de Full-routing, significa que el ataque man in the middle ha tenido éxito.
Y cuando el usuario acceda con algunas credenciales, como HTTP, FTP, SMB, quedarán registradas en Cain y Abel
Y hasta aquí un proceso de ataque de Man in the middle con Cain y Abel
El post original pueden verlo desde aqui
Si les funciona quiero comentarios ... saludos =D
El post original pueden verlo desde aqui
Si les funciona quiero comentarios ... saludos =D
viernes, 9 de marzo de 2012
ARP Spoofing (BackTrack)
El ARP Spoofing, también conocido como ARP Poisoning o ARP Poison Routing, es una técnica usada para infiltrarse en una redEthernet conmutada (basada en switch y no en hubs), que puede permitir al atacante husmear paquetes de datos en la LAN (red de área local), modificar el tráfico, o incluso detenerlo.
El principio del ARP Spoofing es enviar mensajes ARP falsos (falsificados, o spoofed) a la Ethernet. Normalmente la finalidad es asociar ladirección MAC del atacante con la dirección IP de otro nodo (el nodo atacado), como por ejemplo la puerta de enlace predeterminada (gateway). Cualquier tráfico dirigido a la dirección IP de ese nodo, será erróneamente enviado al atacante, en lugar de a su destino real. El atacante, puede entonces elegir, entre reenviar el tráfico a la puerta de enlace predeterminada real (ataque pasivo o escucha), o modificar los datos antes de reenviarlos (ataque activo). El atacante puede incluso lanzar un ataque de tipo DoS (Denegación de Servicio) contra una víctima, asociando una dirección MAC inexistente con la dirección IP de la puerta de enlace predeterminada de la víctima.
Para realizar un ataque ARP-SPOOFING necesitamos tener BACTRACK que es una distribución de Linux que se la puede descargar de Internet.
2.- Escribir en un shell de la consola de bactrak el siguiente comando: arpspoof –t “esto hace que le enviemos replis falsos a las victimas” indicandoles nuestra MAC-ADDRRESS a cada una de ellas.
3.- En otro shell escribimos el siguiente comando:
echo 1 > /proc/sys/net/ipv4/ip_forward el cual modifica una variable de entorno del Kernel de Linux que permite al bactrack reeenviar los paquetes que recibe de las victimas.
4. Verificamos el envenenamiento de las cache ARP
5.- Y listo ya tenemos envenenadas las tablas arp de las victimas y de este modo podemos redireccionar cualquier paquete que sea transmitido por la red, es decir, la información que viaja desde una máquina a otra primero llega a nuestra maquina (hacker) y luego llega a su destino y viceversa.
Capturas de pantalla:
El principio del ARP Spoofing es enviar mensajes ARP falsos (falsificados, o spoofed) a la Ethernet. Normalmente la finalidad es asociar ladirección MAC del atacante con la dirección IP de otro nodo (el nodo atacado), como por ejemplo la puerta de enlace predeterminada (gateway). Cualquier tráfico dirigido a la dirección IP de ese nodo, será erróneamente enviado al atacante, en lugar de a su destino real. El atacante, puede entonces elegir, entre reenviar el tráfico a la puerta de enlace predeterminada real (ataque pasivo o escucha), o modificar los datos antes de reenviarlos (ataque activo). El atacante puede incluso lanzar un ataque de tipo DoS (Denegación de Servicio) contra una víctima, asociando una dirección MAC inexistente con la dirección IP de la puerta de enlace predeterminada de la víctima.
Para realizar un ataque ARP-SPOOFING necesitamos tener BACTRACK que es una distribución de Linux que se la puede descargar de Internet.
1. Asignar direcciones IP a las máquinas:
| DIRECCIONES IP | MASCARA | MAD ADDRESS | |
| HACKER (Bactrak) | 190.131.18.207 | 255.255.255.0 | 00:0c:29:e7:7a:2b |
| 1 VICTIMA (Windows Xp) | 190.131.18.210 | 255.255.255.0 | 00:0C:29:20:D6:09 |
| 2 VICTIMA (Windows Xp) | 190.131.18.211 | 255.255.255.0 | 00:0C:29:84:1D:41 |
2.- Escribir en un shell de la consola de bactrak el siguiente comando: arpspoof –t “esto hace que le enviemos replis falsos a las victimas” indicandoles nuestra MAC-ADDRRESS a cada una de ellas.
3.- En otro shell escribimos el siguiente comando:
echo 1 > /proc/sys/net/ipv4/ip_forward el cual modifica una variable de entorno del Kernel de Linux que permite al bactrack reeenviar los paquetes que recibe de las victimas.
4. Verificamos el envenenamiento de las cache ARP
5.- Y listo ya tenemos envenenadas las tablas arp de las victimas y de este modo podemos redireccionar cualquier paquete que sea transmitido por la red, es decir, la información que viaja desde una máquina a otra primero llega a nuestra maquina (hacker) y luego llega a su destino y viceversa.
Capturas de pantalla:
martes, 3 de enero de 2012
Cómo hacer preguntas de manera inteligente...
En esta ocasión quiero compartirles la traduccion de una de las cosas que en o personal me ayudo a pensar antes de hacerle una pregunta aun experto todos los créditos por la traduccion son para Jose M. Fernández
y sin mas aquí esta el articulo ...
y sin mas aquí esta el articulo ...
Copyright © 2001 por Eric S. Raymond
Copyright de la traducción © 2001 por Jose M. Fernández
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 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).
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 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).
Suscribirse a:
Entradas (Atom)