El petróleo aarkerio
Un museo mata a una exhibición viva ahuramazdah
Aprovechando el tema. mandrake
We have a menstrual situation here aarkerio
No te muevas!! blacksoul
CRIPTOGRAFÍA EN LA PRESIDENCIA DE PORFIRIO DÍAZ tonathiu
“Yo no tengo que explicarle por qué no: usted debe explicarme por qué sí.” tonathiu
Authors@Google: Noam Chomsky aarkerio
PDF Helper aarkerio
Emacs como IDE para CakePHP aarkerio
No hay justicia en el mundo
aarkerio
Pidiendo OpenSolaris 2008.5
vendaval
Sospechosismo
aarkerio
Sistema Infalible
ordbal
Calderón puede ser sujeto a juicio político, sostiene Carrancá
tonathiu
La Historia y sus mentiras
aarkerio
Jaime Maussan da por auténtico video trucado del chupacabras hecho en Blender 3D
asarch
Carta a Felipe Calderón
aarkerio
De mal en peor
aarkerio
Esperando al cartero
aarkerio
Karamelo
GNU/Linux
Hacktivismo
Debian
NetBSD
WWW
Guia Linux
Server Side
Ofimatica
Despabilando...
Mundo Maya
Literatura
Agora
Psicologia
Economia
Ambientalismo
Desarrollo
Biologia
Este artículo ha sido consultado en 409 ocasiones.
Unix nunca fue diseñado para evitar que la gente hiciera cosas estúpidas, porque esa política les habría evitado también hacer cosas inteligentes.
Doug Gwyn
12.1 Evitando errores
Muchos usuarios hablan de su frustración con el sistema operativo Unix en alguna ocasión, a menudo a causa de lo que ellos mismos han hecho. Una característica del sistema operativo Unix que muchos usuarios adoran cuando están trabajando bien, y odian después de una sesión hasta bien avanzada la noche, es que muy pocas órdenes piden confirmación. Cuando un usuario está despierto y funcionando, raramente piensa sobre ello, y esto es una ventaja, ya que le permite trabajar más eficientemente.
De todos modos, hay algunas desventajas. rm y mv no piden nunca confirmación, y esto conduce frecuentemente a problemas. Por eso, veamos una pequeña lista que puede ayudarle a evitar el desastre total:
o
¡Tenga copias de seguridad! Esto va dirigido especialmente a sistemas de un solo usuario, ¡todos los administradores de sistema deben realizar copias de seguridad de su sistema regularmente! Una vez a la semana es suficiente para salvar muchos ficheros. Para más información consulte The Linux System Administrator's Guide.o
Los usuarios individuales deben tener sus propias copias de seguridad, si es posible. Si usa más de una máquina regularmente, intente mantener copias actualizadas de todos sus ficheros en cada una de las máquinas. Si tiene acceso a una unidad de disquetes, puede hacer copias de seguridad en disquetes de su material crítico. En el peor de los casos, mantenga copias adicionales del material más importante que haya en su cuenta en un directorio separado.o
Piense sobre las órdenes, especialmente las "destructivas" como mv, rm, y cp antes de actuar. Debe ser también cuidadoso con las redirecciones (>), sobreescribirán sus ficheros cuando no esté prestando atención. Incluso el más inofensivo de los comandos puede convertirse en siniestro:/home/larry/report$ cp report-1992 report-1993 backups
puede convertirse fácilmente en desastre:
/home/larry/report$ cp report-1992 report-1993
o
El autor también recomienda, a partir de su propia experiencia personal, no hacer limpieza de ficheros a altas horas de la madrugada. ¿Que su estructura de directorios parece un poco desordenada a la 1:32am? Déjelo estar, un poco de desorden nunca ha dañado un ordenador.o
Sígale la pista a su directorio actual. A veces, el prompt que está usando no muestra en que directorio está usted trabajando, y el peligro acecha. ¡Es triste leer un mensaje en comp.unix.admin1 sobre un usuario root que estaba en / en vez de en /tmp! Por ejemplo:mousehouse> pwd
/etc
mousehouse> ls /tmp
passwd
mousehouse> rm passwd
La anterior serie de comandos podría hacer muy infeliz al usuario, al ver como eliminaron el fichero de contraseñas de su sistema. ¡Sin él la gente no puede acceder!
12.2 Qué hacer cuando algo va mal
12.3 No es fallo tuyo
Por desgracia para los programadores del mundo, no todos los problemas son a causa de errores del usuario. Unix y Linux son sistemas complicados, y todas las versiones conocidas tienen errores de programación (bugs2). Algunas veces esos errores son difíciles de encontrar y sólo aparecen bajo ciertas circunstancias.
Ante todo, ¿qué es un error? Un ejemplo de error es si le pide al ordenador que calcule "5+3" y contesta "7". Aunque este es un ejemplo trivial de que puede ir mal, la mayoría de los errores en programas de computadoras se relacionan con la aritmética en alguna forma extremadamente extraña.
_____________________________________________
1 Un foro de discusión internacional en Usenet, que trata sobre la administración de computadoras Unix.
2 Bug: (polilla, fam. bicho). Se denomina así a los errores que aparecen en un programa. Cuenta la leyenda que cuando los ordenadores eran unos monstruos llenos de válvulas, que ocupaban habitaciones enteras, un técnico que trataba de resolver un error en el Mark II de Harvard detectó que la causa era una polilla de verdad que se había colado entre las válvulas y provocaba pequeños cortocircuitos al revolotear de un lado a otro.
12.3.1 Cuando hay un error
Si la computadora da una respuesta errónea (¡compruebe que la respuesta es errónea!) o se bloquea, eso es un error. Si cualquier programa se bloquea o da un mensaje de error del sistema operativo, eso es un error.
Si un comando no finaliza nunca su ejecución, puede ser un error, pero debe asegurarse de que no le ha pedido que esté durante mucho tiempo haciendo lo que usted quería que hiciera. Pida ayuda si no sabe lo que hacía el comando.
Algunos mensajes le alertarán de la existencia de errores. Algunos mensajes no son errores. Revise la sección 3.4 y el resto de la documentación para estar seguro de que no son mensajes informativos normales. Por ejemplo, mensajes como "disk full" (disco lleno) o "lp0 on fire" (lp0 ardiendo) no son problemas de software, sino algo incorrecto en su hardware, no hay suficiente espacio libre en el disco, o la impresora está mal.
Si no puede encontrar información sobre un programa, es un error en la documentación, y debería ponerse en contacto con el autor de dicho programa y ofrecerse para escribirla usted mismo. Si algo está incorrecto en la documentación existente3, es un error en ese manual. Si algo aparece incompleto o poco claro en el manual, eso es un error.
Si no puede vencer al gnuchess al ajedrez, es un fallo de diseño en el algoritmo de ajedrez que usted usa, pero no necesariamente un error en su cerebro.
12.3.2 Notificando un error
Cuando esté seguro de haber encontrado un error, es importante asegurarse de que su información llega al lugar adecuado. Intente encontrar que programa causa el error, si no puede encontrarlo, tal vez pueda pedir ayuda en comp.os.linux.help o comp.unix.misc. Una vez encuentre el programa, intente leer la página del manual para ver quien lo escribió.
El método preferido para enviar notificaciones de errores en el mundo Linux es vía correo electrónico. Si no tiene acceso al correo electrónico puede ponerse en contacto con la persona que le suministró Linux, eventualmente, encontrará alguien que o bien tiene correo electrónico, o vende Linux comercialmente y por tanto quiere eliminar el mayor número de errores posibles. Recuerde, en todo caso que nadie está obligado a corregir ningún error a menos que tenga un contrato.
Cuando envíe una notificación de error, incluya toda la información que se le ocurra. Esto incluye:
o
Una descripción de lo que usted piensa que es incorrecto. Por ejemplo, "Obtengo 5 cuando calculo 2+2" o "Dice segmentation violation -- core dumped". Es importante decir exactamente que esté sucediendo para que el responsable del mantenimiento pueda corregir su error.o
Incluya cualquier variable de entorno relevante.o
La versión de su núcleo (mire en el fichero /proc/version) y sus bibliotecas de sistema (mire en el directorio /lib, si no puede descifrarlo, envíe un listado de /lib).o
¿Cómo ejecutó el programa en cuestión?, o, si era un error del núcleo, ¿qué estaba haciendo en ese momento?.o
Toda la información complementaria. Por ejemplo, el comando w puede no mostrar el proceso actual para ciertos usuarios. No diga simplemente, "w no funciona para cierto usuario". El error podría ocurrir debido a que el nombre del usuario tiene ocho caracteres de longitud, o cuando está accediendo a través de la red. En su lugar diga, "w no muestra el proceso actual para el usuario greenfie cuando accede a través de la red".o
Y recuerde, sea amable. La mayoría de la gente trabaja en el software libre por el gusto de hacerlo, y porque tienen un gran corazón. No los amargue, la comunidad Linux ha desilusionado ya a demasiados desarrolladores, y aún es pronto en la vida del Linux.
_____________________________________________
3 ¡Especialmente en ésta!
Última actualización: 2007-04-29 10:57:00-05
saidjose está: Instalando postgresql desde fuentes
3 hours, 9 minutes ago
saidjose está: Detenido en la instalacion de karamelo por que en ubuntu edgy no hay postgresql 2.8
3 hours, 9 minutes ago
rnstux está: buscando bugs!.....en el trabajo, hay un chingo de cucarachas!
3 hours, 41 minutes ago
aarkerio está: please reporten los bugs en Trac
4 hours, 45 minutes ago
vendaval está: meditando sobre los capchas
4 hours, 56 minutes ago
saidjose está: bajando e instalando karamelo
5 hours ago
Que estuvimos haciendo >>
10683 lecturas
Sexualidad infantil y juvenil
9412 lecturas
Anticoncepción de Emergencia
8188 lecturas
Rompiendo cualquier clave WEP en unos pocos minutos
7113 lecturas
Sinapsis y exocitosis
6478 lecturas
Mi primer CakePHP, mmmmm cakeee
5354 lecturas
Evolución filética en las hepáticas
4834 lecturas
BASH y Primeros Comandos
4111 lecturas
CakePHP II Active Record
3819 lecturas
Cómo convertirse en hacker
3691 lecturas
