Archive

Smartmontools: aprendiendo a chequear tu disco duro…

Los discos duros modernos (y no tan modernos) vienen equipados con una tecnología conocida como S.M.A.R.T., el cual le permite al disco monitorear de manera contínua su propio estado de “salud” y alertar al usuario si es detectada alguna anormalidad, para que luego pueda ser corregida.

ADVERTENCIA: antes de continuar, sería recomendable hacer una copia de respaldo de todos sus datos importantes a pesar de todo lo que diga el S.M.A.R.T. Éste sistema es muy confiable pero no obstante, ésta información en alguno de los casos podría ser imprecisa, de hecho, los discos duro se dañan de manera inesperada, inclusive si el S.M.A.R.T te ha dicho que algo anda mal, posiblemente no tengas tiempo para respaldar tus datos o moverlos a un lugar más seguro.

¿Cómo instalar SMARTMONTOOLS?

Lo primero que debemos hacer, preferiblemente antes de instalar el SMT es chequear si nuestro disco duro soporta éste tipo de tecnología, lo cual puedes hacer visitando la página del fabricante de tu disco. De todas formas, si lo compraste después del año 1992, lo más seguro es que posea ésta tecnología.

Lo segundo, y no menos importante, es activar o asegurarte que en el BIOS de la tarjeta madre este activada ésta función. Lo puedes conseguir ya que luce algo como:

 S.M.A.R.T for Hard Disk:	Enable

Algunos BIOS no tienen ésta opción y reportan el S.M.A.R.T como inactivo, pero no te preocupes que el smartcl, uno de los dos programas de utilidad que tiene el Smartmontools, puede activarlo. Una vez que estemos seguros de todo ésto podemos proceder a instalar el Smartmontools, el cual, en la distribución que uso, Debian, es tan fácil como escribir en una terminal:

 $ aptitude install smartmontools

Y de esa manera ya queda automágicamente instalado el paquete el sistema. Si quieres verificar si ya lo tienes instalado, entonces tendrías que escribir en una terminal lo siguiente:

 $ aptitude show smartmontools

Y verificar que el atributo Estado se corresponda con Instalado. Una vez hecho ésto procedemos a verificar si nuestro disco soporta S.M.A.R.T con la siguiente línea de comandos:

$ smartctl -i /dev/hda

En caso que tu disco sea SATA tendrías que escribir la siguiente línea:

$ smartctl -i -d ata /dev/sda

La información se vería algo así:

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar family
Device Model:     WDC WD1200BB-00RDA0
Serial Number:    WD-WMANM1700779
Firmware Version: 20.00K20
User Capacity:    120,034,123,776 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Sep 24 22:27:09 2006 VET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Si tu disco es SATA pero tiene el soporte S.M.A.R.T desactivado, entonces deberás usar la siguiente línea de comandos para activarlo:

$ smartctl -s on -d ata /dev/sda

Aprendiendo a usar SMT

Estado de “salud” de nuestro disco duro

Para leer la información que SMT ha recopilado acerca de nuestro disco, debemos escribir la siguiente linea de comandos:

$ smartctl -H /dev/hda

Para discos SATA no es suficiente con sustituir hda con sda, sino que debemos añadir las opciones extras que usamos anteriormente para obtener la información del disco. La línea de comandos entonces quedaría así:

$ smartctl -d ata -H /dev/sda

Si lees PASSED al final de la información, no tienes que preocuparte. Pero si lees FAILED deberías empezar a hacer respaldo de tus datos inmediatamente, ya que ésto quiere decir que tu disco ha presentado fallas anteriormente o es muy probable que falle dentro de un lapso de aproximadamente 24 horas.

Bitácora de errores de SMT

Para chequear la bitácora de errores de SMT debemos escribir la siguiente línea de comandos:

$ smartctl -l error /dev/hda

De manera análoga al caso anterior, añadimos los comandos extras si nuestro disco es SATA. La línea de comandos quedaría así:

$ smartctl -d ata -l error /dev/sda

Si leemos al final de la información No errors logged todo anda bien. Si hay varios errores pero éstos no son muy recientes, deberías empezar a preocuparte e ir comprando los discos para el respaldo. Pero si en vez de ésto hay muchos errores y una buena cantidad son recientes entonces deberías empezar a hacer respaldo de tus datos, inclusive antes de terminar de leer ésta línea. Apurate! :D

A pesar que smartctl nos da una información muy valiosa acerca de nuestros discos, el tan solo revisar ésta no es suficiente, realmente se deben hacer algunas pruebas específicas para corroborar los errores que conseguimos en la información anterior, dichas pruebas las menciono a continuación.

Pruebas con SMT

Las pruebas que se van a realizar a continuación no interfieren con el funcionamiento normal del disco y por lo tanto pueden ser realizadas en cualquier momento. Aquí solo describiré como ejecutarlas y entender los errores. Si quieres saber más te recomiendo que visites ésta pagina o que leas las páginas del manual.

Lo primero sería saber cuáles pruebas soporta tu disco, lo cual logramos mediante la siguiente línea de comandos:

$ smartctl -c /dev/hda

De ésta manera puedes saber cuáles pruebas soporta tu disco y también cuanto tiempo aproximadamente puede durar cada una. Bien, ahora ejecutemos Immediate Offline Test ó Prueba Inmediata Desconetado (si está soportada, por supuesto), con la siguiente línea de comandos:

$ smartctl -t offline /dev/hda

Como ya sabemos, los resultados de ésta prueba no son inmediatos, de hecho el resultado de ésta linea de comandos te dirá que la prueba ha comenzado, el tiempo que aproximadamente va a demorar la prueba en terminar con una hora aproximada para dicha finalización, y al final te dice la línea de comandos para abortar la operación. En uno de mis discos, un IDE de 120Gb, demoró 1 hora, para que tengan una idea. Por los momentos sólo te queda esperar por los resultados. Ahora te preguntarás ¿Cómo puedo saber los resultados?, pues tan sencillo como ejecutar la línea de comandos para leer la bitácora del SMT y seguir las recomendaciones.

Ahora vamos a ejecutar Short self-test routine ó Extended self-test routine, Rutina corta de autoprueba y Rutina extendida de autoprueba, respectivamente (de nuevo, si están soportadas). Éstas pruebas son similares, sólo que la segunda, como su nombre lo indica, es más rigurosa que la primera. Una vez más ésto lo logramos con los siguientes comandos:

$ smartctl -t short /dev/hda
$ smartctl -t long /dev/hda

Luego vamos a chequear el Self Test Error Log ó Bitácora de errores de autopruebas:

$ smartctl -l selftest /dev/hda

Luego ejecutamos Conveyance Self Test ó Autoprueba de Transporte:

$ smartctl -t conveyance /dev/hda

Y por último chequeamos Self Test Error Log de nuevo.

Algo que tengo que resaltar es que el SMT tiene dos bitácoras, una de las cuales es la Bitácora de errores y la otra es la Bitácora de Errores de Autopruebas.

¿Cómo monitorear el disco duro automáticamente?

Para lograr ésto tendrás que configurar el demonio smartd para que sea cargado cuando se inicia el sistema. A continuación un pequeño HOWTO.

ADVERTENCIA: el siguiente HOWTO es para monitorear un disco IDE, programar todas las pruebas cada viernes de la semana, de 11:00 a.m a 2:00 p.m, y luego ejecutar un script de Bash si algún error es detectado. Éste script escribirá un reporte bien detallado y luego apagará el equipo para su propia protección.

El archivo de configuración de smartd se encuentra en /etc/smartd.conf, si éste no existe,
el cual sería un caso poco común, deberás crearlo en tu editor de elección.

...
#DEVICESCAN
...
/dev/hda \
-H \
-l error -l selftest \
-s (O/../../5/11|L/../../5/13|C/../../5/15) \
-m ThisIsNotUsed -M exec /usr/local/bin/smartd.sh

El script en Bash también puedes hacerlo en un editor de tu elección, y tendrá la siguiente forma:

#!/bin/bash
LOGFILE="/var/log/smartd.log"
echo -e "$(date)\n$SMARTD_MESSAGE\n" >> "$LOGFILE"
shutdown -h now

Luego de crear el script deberás hacerlo ejecutable cambiando sus atributos con la siguiente línea de comandos:

$ chmod +x /usr/local/bin/smartd.sh

Para probar todo, puedes agregar al final de tu /etc/smartd.conf la línea

-M test

y luego ejecutar el demonio. Nota que ésto apagará tu equipo, hayan errores o no. Luego si algo sale mal deberás chequear la bitácora del sistema en /var/log/messages con:

$ tail /var/log/messages

Y así corregir el problema. Ahora tendrás que quitar la línea

-M test

y guardar los cambios. Por último debes hacer que smartd sea cargado al momento del arranque, lo cual lo logras con la siguiente línea:

$ rc-update add smartd default

Algunos enlaces de interés:

Nota: Ésta artículo está basado en un HOWTO del Wiki de Gentoo

Audigy SE en Etch AMD64

Hace días me hice con una tarjeta de sonido Audigy SE de la marca Creative y la verdad tuve que dar bastante golpes para dar con la configuración correcta. ¿Cómo lo logré? Muy fácil: Googleando :).

Resulta que el sistema (Debian, of course) reconoce bien el dispositivo y carga de manera perfecta los módulos necesarios; de hecho el alsa-mixer me mostraba todos los canales de la tarjeta pero el único que parecía funcionar era el Analog Front y los otros parecían estar muertos. Casi daño el mouse de tando hacer clicks y darle hacia arriba y hacia abajo :). No podía creer que no funcionara!.

Googleando llegué a la página de la gente de Alsa y me encontré una manera de configurar los drivers. Ahi confirmé que el sistema me estaba cargando el módulo correcto, el snd-ca0106. Entonces, después de ver la pequeña lista de instrucciones, no voy a decir que me espanté y maldije a Creative, no, no lo hice, en ése momento miré al cielo y pregunté: ¡¿Acaso no existe una manera más fácil de lograr que suenen la benditas cornetas?! y la respuesta a mi pregunta vino del wiki de Gentoo, ¿qué cosas no? imagínense todo lo que googleé; bueno específicamente de la sección que dice VIA Envy24HT (ice1724) chip. Ahora se preguntarán.. ¿VIA? éste tipo está loco…. pues sí, VIA. ¿Y qué fué lo que hice? Abrí una terminal e hice lo siguiente:

$ gedit .asoundrc

Luego lo que hice fué copiar el contenido del segundo .asoundrc y pegarlo al mío, luego guardar los cambios y voilá, sistema de sonido 5.1 andando ;). Se preguntarán ¿Cómo hizo éste loco para saber que ese .asoundrc funciona con la Audigy SE?, bueno, con el proceso estándar, prueba error. Copiando y pegando cada uno de los ficheros.

Ahora que el sistema suena perfectamente bien me ha surgido una nueva interrogante, debido a que para poder graduar el volumen del sistema tengo que graduar los tres controles, y la pregunta es: ¿Habrá alguna forma de graduar el volumen para los tres controles al mismo tiempo? Que lo disfruten…

Muere Rob Levin

Rob Levin, el fundador de Freenode, ha muerto trágicamente luego de estar en coma debido a un accidente que sufrió mientras manejaba su bicicleta. Al parecer Levin fué arroyado por un vehículo el pasado 12 de septiembre mientras manejaba su bici y como consecuencias sufrió heridas graves. Estaba siendo tratado en un hospital local en Houston, Texas en el cual falleció el día de ayer.

Nuestras más sinceras condolencias a la familia de éste pionero.

Para enviar sus condolencias puede hacerlo a condolences@freenode.net

Debian GNU/Linux 4.0

Según puede verse en el sitio oficial del Proyecto Debian, en una noticia aparecida el día de hoy, Upcoming Release of Debian GNU/Linux 4.0, se confirma que el próximo mes de diciembre del presente año será la fecha de publicación de la siguiente versión 4.0 de Debian GNU/Linux, cuyo código nombre es “etch”.

Entre las novedades que podremos observar en esta nueva versión se encuentran las siguientes:

  • Será la primera versión que ofrezca soporte oficial a la arquitectura AMD64. De manera simultánea, esta versión se publicará para 11 arquitecturas.
  • La versión 4.0 ofrecerá la versión 2.6.17 del núcleo linux de manera predeterminada. Además, esta misma versión se utilizará en todas las arquitecturas y a su vez en el instalador.
  • Debian GNU/Linux 4.0 presentará la colección de compiladores de GNU versión 4.1.
  • Debian GNU/Linux deja de utilizar XFree86 como implementación de X11 (sistema de ventanas X) para darle paso a X.Org.
  • Al menejador de paquetes APT seguramente se le añadan algunas mejoras en cuanto a seguridad, admitiendo criptografía modo paranoico y firmas digitales.

Reuniones para eliminar fallos

En la misma noticia podemos enterarnos que el Proyecto Debian está planeando algunas reuniones previas al nuevo lanzamiento en búsqueda de fallos y establecer las debidas correcciones, de esta manera, se ofrecerá al público una versión que presente la mínima cantidad de errores críticos de programación.

Estas reuniones se llevarán a cabo en varias ciudades alrededor del mundo. Por lo tanto, podrá participar el mayor número de personas en la búsqueda y corrección de estos errores de programación.

Si usted está interesado en participar pero no puede reunirse personalmente con los desarrolladores en las distintas ciudades que se describen en BSPMarathon, puede conectarse al canal #debian-bugs en el servidor irc.debian.org y de esta manera participar.

La situación en Venezuela

En mi humilde opinión, considero oportuno que la comunidad Debian Venezuela debe tomar las riendas en este asunto, organizar reuniones para eliminar fallos en nuestra distribución favorita, aprovechando la cercanía del Día Debian para organizar actividades de este tipo. ¿Qué opinan en este sentido?.

ULAnix

Hace ya algún tiempo que la beta #3 de esta distribución LiveCD basada en Debian salió.

Podría decirse que ULAnix es la primera distribución GNU + Linux que nace dentro de una universidad venezolana, Universidad de Los Andes. Aunque muchos afirman que la primera distro venezolana con aval universitario fue Cachapa, no es cierto, Antonio Lopez, el creador de Cachapa, realizó dicho proyecto como una meta personal, posteriormente la Universidad de Carabobo se interesó en Cachapa. Al final, lo importante no es ser el primero, lo importante es que estas distribuciones han sido fruto del trabajo de venezolanos.

ULAnix es una iniciativa del Parque Tecnológico de Mérida.

Básicamente el equipo de trabajo está conformado por los profesores: Gilberto Díaz y Jacinto Dávila, el desarrollo está a cargo del bachiller Jesús Molina.

Si usted desea una copia de esta distribución puede obtenerla desde el repositorio: http://ftp.ula.ve/linux/distribuciones/ulanix/ o desde el mirror que he habilitado en http://ulanix.milmazz.com/.

El equipo de trabajo alrededor de ULAnix agradece que la mayor cantidad de personas se haga con esta distribución, la pruebe e informen los errores que vayan consiguiendo. Aún no existe una página oficial para el proyecto, aunque al parecer se está trabajando en ello, opcionalmente, puede notificar los errores de software en el foro de ULAnux.

Próximamente espero estar probando intensivamente esta distribución y realizar las observaciones que considere pertinentes.

gUsLA: Grupo de Usuarios de Software Libre de la Universidad de Los Andes

Un grupo de compañeros de estudio y mi persona por fin hemos iniciado una serie de actividades para formar el Grupo de Usuarios de Software Libre de la Universidad de Los Andes.

El día de hoy, hicimos entrega de una carta al Consejo de Escuela de Ingeniería de Sistemas, solicitando un aval académico para lograr llevar a cabo las siguientes actividades:

  • Charlas.
  • Festivales de instalación.
  • Atención al usuario.
  • Otras actividades de naturaleza académica.

Esta solicitud la hicimos ya que consideramos necesaria la creación de un Grupo de Usuarios que se encargue de:

  • Difundir y promover el Software Libre en la Universidad de los Andes.
  • Difundir las bases filosóficas detrás del modelo del Software Libre.
  • Demostrar la calidad técnica del Software Libre.
  • Demostrar a los usuarios finales cuan fácil es utilizar GNU/Linux.
  • Fomentar el intercambio de conocimientos en Talleres, Foros, Charlas y/o encuentros con grupos de usuarios de otras latitudes.
  • Adaptación al proceso de cambio fomentado por el ente público (decreto 3390).

En este momento hemos contactado a ciertos profesores que han mostrado interés en la iniciativa, la idea es involucrar a todas aquellas personas relacionadas con la Universidad de Los Andes.

En resumen, el objetivo principal que pretende alcanzar nuestro grupo es: El estudio, desarrollo, promoción, difusión, educación, enseñanza y uso de sistemas operativos GNU/Linux, GNU/Hurd, FreeBSD, y de las herramientas libres que interactúan con estos, tanto en el ámbito nacional como en el internacional. Es importante resaltar en este instante que No se perseguirán fines de lucro, ni tendremos finalidades o actividades políticas, partidistas ni religiosas; seremos un grupo apolítico, abierto, pluralista y con fines académicos.

Personalmente, debo agradecer a José Parrella por haberme facilitado un borrador del documento constitutivo/estatutario del Grupo de Usuarios de Linux de la Universidad Central de Venezuela (UCVLUG), lo hemos utilizado como base para formar el nuestro, aunque será discutido por ahora en una lista privada de estudiantes y profesores que han manifestado interés en participar.

Esperamos con ansiedad la decisión del Consejo de Escuela de Ingeniería de Sistemas.

Decisión del Consejo de Facultad de la Universidad de Los Andes

Según informa la profesora Flor Narciso en un comunicado, el Consejo de Facultad de la Universidad de Los Andes en una sesión ordinaria llevada a cabo el día de ayer, 13 de Junio de 2006, se aprobó la reprogramación del semestre.

Esta noticia toma por sorpresa a muchas personas, me incluyo, imagínense tener que asistir a clases cinco sábados seguidos para lograr culminar las actividades el día 21 de Julio de 2006, por supuesto, debemos agradecerles a todos esos revolucionarios que generaron caos en la ciudad por esta decisión del Consejo de Facultad, en verdad, ¡muchas gracias!.

Los días 17, 24 de Junio y los días 1, 8 y 15 de Julio las clases se dictarán en el mismo horario, correspondiente a los días Lunes, Martes, Miércoles, Jueves y Viernes respectivamente.

La fecha que corresponde a la finalización de las evaluaciones queda para el día 21 de Julio de 2006.

Todas asignaturas con proyectos, en mi caso 4, la entrega de los mismos será realizada el día 4 de Septiembre de 2006.

Las notas definitivas serán dadas a conocer en el intervalo comprendido del 4 al 8 de Septiembre de este mismo año.

Ya para culminar, en definitiva, citando al profesor y amigo Richard Márquez: Se pasaron…

XXXII Aniversario EISULA

Según lo manifiesta la profesora Flor Narciso en un comunicado, el día de mañana, 14/06/2006, se celebrará una misa conmemorativa del XXXII Aniversario de la Escuela de Ingeniería de Sistemas a las 9:00 a.m. en la Sala de Reuniones de la Escuela.

Además, en el horario comprendido de 4:00 a 6:00 p.m. se llevará a cabo el seminario titulado Técnicas Emergentes en Automatización Industrial a cargo de los ingenieros Jesús Durán, Lisbeth Pérez y Jorge Vento.

El seminario se realizará en el Auditorio A de la Facultad de Ingeniería de la Universidad de Los Andes.

Están todos cordialmente invitados a participar en estas actividades.

El algoritmo de Dijkstra en Perl

Hace ya algunos días nos fué asignado en la cátedra de Redes de Computadoras encontrar el camino más corto entre dos vértices de un grafo dirigido que no tuviese costos negativos en sus arcos, para ello debíamos utilizar el algoritmo de Dijkstra. Además de ello, debía presentarse el grafo y la ruta más corta en una imagen, para visualizarlo de mejor manera.

Cuando un profesor te dice: No se preocupen por la implementación del algoritmo de Dijkstra, utilice la que usted prefiera, pero les agradezco que la analicen. Además, pueden utilizar el lenguaje de programación de su preferencia. Estas palabras te alegran el día, simplemente eres feliz.

Por algunos problemas que tuve con algunos módulos en Python, no lo hice en dicho lenguaje de programación, no vale la pena explicar en detalle los problemas que se me presentaron.

Lo importante de todo esto, es que asumí el reto de realizar la asignación en un lenguaje de programación practicamente nuevo para mí, aunque debo reconocer que la resolución no me causó dolores de cabezas en lo absoluto, a continuación algunos detalles.

En primer lugar, formularse las preguntas claves, ¿existe algún módulo en Perl que implemente el algoritmo de Dijkstra para encontrar el camino más corto?, ¿existe algún módulo en Perl que implemente GraphViz?

En segundo lugar, buscar en el lugar correcto, y cuando hablamos de Perl el sitio ideal para buscar es search.cpan.org, efectivamente, en cuestión de segundos encontre los dos módulos que me iban a facilitar la vida, Bio::Coordinate::Graph, para encontrar la ruta más corta entre dos vértices en un grafo y GraphViz, para pintar el grafo.

En tercer lugar, verificar en tu distro favorita, Debian, si existe un paquete precompilado listo pasa ser usado, para GraphViz existe uno, libgraphviz-perl, así que para instalarlo es tan fácil como:

# aptitude install libgraphviz-perl

Para instalar el módulo Bio::Coordinate::Graph, primero debía debianizarlo, eso es tan sencillo como hacer.

# dh-make-perl --build --cpan Bio::Coordinate::Graph

Luego debe proceder a instalar el fichero .deb que se generó con dh-make-perl, para lograrlo hago uso del comando dpkg, eso es todo. Por cierto, acerca del comando dh-make-perl ya había hablado en la entrada Perl: Primeras experiencias.

Encontrando el camino más corto

Según dice la documentación del módulo Bio::Coordinate::Graph debemos hacer uso de un hash de hashes anónimos para representar la estructura del grafo, en ese momento recordé algunas palabras que José Luis Rey nos comentó en la primera parte del curso de Perl, vale resalta la siguiente: Si usted no utiliza un hash, no lo está haciendo bien.

my $hash = {
		'6' => undef,
		'1' => {
			'2' => 1
			},
		'2' => {
			'6' => 4,
			'4' => 1,
			'3' => 1
			},
		'3' => {
			'6' => 1
			},
		'4' => {
			'5' => 1
			},
		'5' => undef
	};

Algo que es importante saber es que en Perl las estructuras de datos son planas, lo cual es conveniente. Por lo tanto, vamos a tener que utilizar referencias en este caso, pero luego nos preocuparemos por ello. Ahora solo resta decir que, la estructura hecha a través de un hash de hashes es sencilla de interpretar, las llaves o keys del hash principal representan los vértices del grafo, ahora bien, las llaves de los hashes más internos representan los vértices vecinos de cada vértice descrito en el hash principal, el valor de los hashes más internos representa el peso, distancia o costo que existe entre ambos vértices, para aclarar la situación un poco: El vértice 2, tiene como vecinos a los vértices 3, 4 y 6, con costos de 1, 1 y 4 respectivamente. Puede ver una muestra del grafo resultante.

De manera alternativa puede utilizar un hash de arrays para representar la estructura del grafo, siempre y cuando todos los costos entre los vértices sean igual a 1, este método es menos general que el anterior y además, este tipo de estructura es convertida a un hash de hashes, así que a la final resulta ineficiente.

Una vez definida la estructura del grafo corresponde crear el objeto, esto es realmente sencillo.

my $graph = Bio::Coordinate::Graph->new(-graph => $hash);

Lo que resta es definir el vértice de inicio y el vértice final, yo los he definido en las variables $start y $end, luego de ello, debemos invocar al método shortest_path, de la siguiente manera:

my @path = $graph->shortest_path($start, $end);

En el array @path encontraremos los vértices involucrados en el camino más corto.

Pintando el grafo

Una vez hallado el camino más corto entre dos vértices dados en un grafo dirigido con un costo en los arcos siempre positivos, lo que resta es hacer uso del módulo GraphViz, hacemos uso del constructor del objeto de la siguiente manera:

my $g = GraphViz->new();

Usted puede invocar al constructor con distintos atributos, para saber cuales usar le recomiendo leer la documentación del módulo.

Ahora bien, yo quería distinguir aquellos vértices involucrados en el camino más corto de aquellos que no pertenecían, así que lo más sencillo es generar una lista de atributos que será usada posteriormente. Por ejemplo:

my @shortest_path_attrs = (
				color => 'red',
			);

Una vez definidos los atributos, debemos generar cada uno de sus vértices y además, establecer los arcos entre cada uno de ellos. Para ello haremos uso de los métodos add_node, add_edge.

foreach my $key (keys %$hash){
	$g->add_node($key);
	foreach my $neighbor (keys %{$hash->{$key}}){
		$g->add_edge($key => $neighbor, label => $hash->{$key}->{$neighbor});
	}
}

El bloque de código anterior lo que hace es agregar cada uno de los vértices que se encuentran en el hash que representa la estructura del grafo, para cada uno de estos vértices, se añade cada uno de los arcos que lo conectan con sus vecinos, nótese el manejo del operador flecha (->) para desreferenciar las referencias al hash de hashes anónimos.

Una vez construidos los nodos y sus arcos, ¿cómo reconocer aquellos que pertenecen al camino más corto?, bueno, toda esa información la podemos extraer del array que hemos denominado @path.

for (my $count=0; $count < = $#path; $count++){
	$g->add_node($path[$count], @shortest_path_attrs);
	$g->add_edge($path[$count] => $path[$count+1], @shortest_path_attrs) unless ($count+1 > $#path);
}

Según dice la documentación del módulo GraphViz todos los atributos de un vértice del grafo no tienen que definirse de una sola vez, puede hacerse después, ya que las declaraciones sucesivas tienen efecto acumulativo, eso quiere decir lo siguiente:

$g->add_node('1', color => 'red');

Es equivalente a hacer las siguientes declaraciones sucesivas.

$g->add_node('1');
$g->add_node('1', color => 'red');

Lo que resta por hacer en este instante es exportar el objeto creado, puede crear por ejemplo un PNG, texto sin formato, PostScript, entre otros.

Yo decidí generar un fichero PostScript:

$g->as_ps("dijkstra.ps");

Por supuesto, les dejo una muestra de los resultados. Los vértices cuyo borde es rojo, son aquellos involucrados en el camino más corto desde el vértice inicio al vértice final, los arcos que marcan la ruta más corta también han sido coloreados.

Como siempre, todas las recomendaciones, comentarios, sugerencias son bienvenidas.

WordPress 2.0.3

WordPress Matt Mullenweg anunció hace pocos días la disponibilidad de la versión 2.0.3 para WordPress, la versión más reciente hasta ahora de la serie estable 2.0.

Características en la versión 2.0.3

En esta nueva versión se puede observar.

  • Mejoras en cuanto al rendimiento.
  • Mejora en el sistema que permite importar entradas o posts desde Movable Type o Typepad.
  • Mejora en cuanto al manejo de los enclosures 1 para podcasts 2.
  • Corrección de errores de seguridad.

Se corrige el error de seguridad que permitía la inyección de código PHP arbitrario si se encontraba activo el registro libre de usuarios, era necesario desmarcar la casilla de verificación Cualquiera puede registrarse para subsanar el error, dicha casilla puede encontrarla en el área administrativa bajo OpcionesGeneral.

Si lo desea, puede apreciar la lista completa de las correcciones realizadas para esta versión, algunas de las que llamaron mi atención fueron la #2463 y el #2548, en ambas correcciones se aprecia la optimización en cuanto al rendimiento de WordPress.

Pasos para actualizar desde la versión 2.0.2 a 2.0.3

  1. Eliminar el contenido de la carpeta /wp-admin.
  2. En caso de utilizar el directorio /wp-includes/languages, debe respaldarlo. (Opcional).
  3. Eliminar el contenido de la carpeta /wp-includes.
  4. Eliminar todos los ficheros del directorio raíz de tu instalación de WordPress, excepto el fichero de configuración, wp-config.php.
  5. Descargar y descomprimir la nueva versión de WordPress.
  6. Restaurar las carpetas /wp-admin y /wp-includes. En caso de haber realizado el paso 2, recuerda restaurar también la carpeta /wp-includes/languages.
  7. Restaurar los ficheros del directorio raíz de tu instalación de WordPress.
  8. En el paso anterior, no es necesario colocar los ficheros wp-config-sample.php, license.txt, ni el readme.html, bien puedes eliminarlos si gustas.
  9. Ingresa en el área administrativa, proceda a actualizar la base de datos.

Eso es todo, como siempre, recuerde que es recomendable eliminar los ficheros install.php y upgrade.php, los cuales se encuentran en el directorio /wp-admin

Después de actualizar a la versión 2.0.3

Aún después de actualizar WordPress, existen algunos comportamientos extraños. Cuando usted edita un comentario aparecerá un cuadro de dialogo que le preguntará si está seguro de realizar dicha acción, de igual manera sucede si usted intenta editar un enlace o un usuario, entre otras cosas.

Si usted quiere deshacerse de esos comportamientos extraños, le recomiendo instalar el plugin WordPress 2.0.3 Tuneup, los errores que corrige este plugin hasta su versión 0.3 son: #2760, #2761, #2764, #2776, #2782.

De acuerdo al roadmap de WordPress se espera que la versión 2.0.4 esté lista para el día 30/06/2006.

  1. Un enclosure es una manera de adjuntar contenido multimedia a un feed RSS, simplemente asociando la URL del fichero a la entrada particular. Esta característica es de vital importancia para la difusión del podcasting.[regresar]
  2. Mayor información acerca del podcasting[regresar]