TechNotes

Structs, tipos y listas enlazadas

Jake — Mon, 13 Aug 2007 16:07:04 +0000

Cada vez que retomo la programación en C después de haberme dado más de un mes para oxidarme, hay algo que, por más que lo utilice, siempre tengo que volver a consultar: las structs. Una struct nos permite tener un registro con varios campos en una sola variable, pero no voy a explicar mucho más aquí. Voy a hablar de las distintas formas en las que se pueden declarar, que es lo que siempre olvido.

La declaración de una struct tiene la forma struct nombre_opcional { campos };. La forma más usual, al menos en mi caso, de declarar una struct y luego definir una variable con ese tipo es esta:

PLAIN TEXT

struct complejo {
float real, imaginario;
};
struct complejo n;

En ella creo una struct simple con dos campos, que son la parte real e imaginaria de un número complejo, y declaro la variable n como complejo. Aquí puede verse como el uso de una struct es similar al de un tipo, pero hay que recordar que es necesario que la declaración de la variable esté precedida de la palabra struct, como se ve en el ejemplo, pues los nombres de las structs no se incluyen de forma independiente en la tabla de símbolos del compilador, sólo asociados al modificador struct.

Si no vamos a usar muchas variables del mismo tipo, podemos hacer la declaración de n en un sólo paso, y podemos incluso omitir el nombre de la struct (por eso es opcional), como se ve en este otro ejemplo:

PLAIN TEXT

struct {
float real, imaginario;
} n;

En este caso la variable n es también un número complejo, pero si quisiéramos otra variable del mismo tipo en otro lugar del programa, tendríamos que reescribir toda esta declaración.

Si queremos evitar evitar tener que pasar por el tedioso trabajo de escribir la palabra struct cada vez que vamos a declarar una variable con el tipo struct complejo, podemos usar typedef. Typedef es una sentencia que permite crear nuevos nombres de tipo a partir de los tipos ya existentes. Su sintaxis es typedef tipo_anterior alias. Esto lo hacemos normalmente porque el tipo original es más complicado de escribir o porque un nuevo nombre añade información semántica de valor y hace el código más legible. Siguiendo con el ejemplo de los números complejos, podría crear un tipo llamado simplemente complejo de la siguiente forma:

PLAIN TEXT

typedef struct {
float real, imaginario;
} complejo;
complejo n;

Como vemos, en este caso se omite el nombre de la struct, de modo que es anónima, pero no nos hará falta porque, como estamos definiendo un nuevo tipo, podemos referirnos a ella con el nombre de éste: complejo. Hay que prestar especial atención al hecho de que, en esta ocasión, a la hora de declarar la variable n, no es necesario usar la palabra struct, ahora complejo se encuentra en la tabla de símbolos del compilador de forma independiente. En este caso podríamos haber indicado un nombre a la struct, pero no nos habría servido para nada, incluso podría haberse llamado complejo, igual que el tipo, pues al ir asociada a la palabra struct no existirían conflictos de nombres. Más abajo hay un ejemplo que puede aclarar este punto.

Para seguir explicando las diferentes posibilidades voy a dejar de lado los números complejos y usaré para los ejemplos siguientes una de las estructuras clásicas con las que cualquier programador tiene que enfrentarse alguna vez: una lista simplemente enlazada. En este caso usaré una lista de enteros. Las explicaciones, no obstante, son aplicables a cualquier struct que incluya entre sus campos algún puntero a sí misma.

La forma más común de crear esta estructura en la siguiente:

PLAIN TEXT

struct nodo {
int valor;
struct nodo *siguiente;
};
struct nodo *lista;

Ahora, si queremos crear un tipo nuevo para la struct que representa un nodo de la lista, NO podemos hacer esto:

PLAIN TEXT

typedef struct {
int valor
elem *siguiente;
} elem;
elem *lista;

El problema es que el tipo que se está definiendo no se encuentra disponible hasta que se ha terminado de definir (parece lógico, ¿no?), de modo que no podemos crear el puntero siguiente usando el nombre elem, porque en ese momento no se encuentra en la tabla de símbolos. Hay varias formas de resolver esto. La primera, y más usual, es darle un nombre a la struct y usarlo para declarar el puntero siguiente, en lugar de usar el nombre del tipo:

PLAIN TEXT

typedef struct nodo {
int valor;
struct nodo *siguiente;
} elem;
elem *lista;

Pero si esta mezcla no es de tu agrado, hay una forma en la que se puede usar el nombre del nuevo tipo para el puntero siguiente, y es declarando la struct y el tipo primero y definiendo los campos después:

PLAIN TEXT

typedef struct nodo elem;
struct nodo {
int valor;
elem *siguiente;
};
elem *lista;

Así, cuando llega la declaración del puntero siguiente, la sentencia que crea el tipo ha concluido y éste se encuentra ya en la tabla de símbolos. Aunque pueda parecer menos directa, es la que más me gusta y creo que la usaré a partir de ahora a menos que el caso concreto aconseje lo contrario.

Siguiendo este último ejemplo, podemos ver en este recorte lo que decía más arriba, que el nombre de la struct no es un identificador por sí sólo, así que podemos usarlo también para definir el tipo:

PLAIN TEXT

typedef struct nodo nodo;
struct nodo {
int valor;
nodo *siguiente;
} ;
nodo *lista;

Ahora lo más probable es que cuando vuelva a pasar un tiempo sin escribir en C, se me olviden muchas cosas excepto esta. En cualquier caso, espero que este post te haya sido de tanta utilidad como a mi

Algunas de mis lecturas para formarme, además del libro The C Programming Language, de Kernighan y Ritchie, han sido estas fuente 1, fuente 2, fuente 3 y fuente 4.

Opciones en las direcciones de Gmail

Jake — Fri, 20 Apr 2007 22:53:24 +0000

Gmail ofrece a sus usuarios la posibilidad de recibir su correo aún cuando se han aplicado algunas modificaciones a la dirección. La opción más conocida es la de usar el signo de la suma '+', para añadir cualquier cosa a la parte de usuario de la dirección. Por ejemplo, si mi dirección de correo es pipo@gmail.com, el correo enviado a pipo+loquesea@gmail.com me llegará también a mí. Esto resulta especialmente útil para mejorar la clasificación del correo mediante filtros.

Otra de estas opciones, que descubrí hoy por casualidad, es la de añadir puntos:

Gmail no reconoce los puntos (.) como caracteres en un nombre de usuario. De este modo, puedes añadir y eliminar puntos de tu nombre de usuario con el fin de variar la dirección de correo electrónico. Los mensajes enviados a tu.nombredeusuario@gmail.com y a t.u.n.o.m.b.r.e.d.e.u.s.u.a.r.i.o@gmail.com se recibirán en la misma bandeja de entrada, ya que los caracteres del nombre de usuario son los mismos.

Esto puede ser muy útil para los usuarios, aunque en mi caso quien más se ha beneficiado de esto son los spammers que me han seguido desde mis viejas cuentas de correo, que tenían un punto, a la de Gmail, que no lo tiene. Por fortuna, el filtro antispam que incorpora Gmail es lo suficientemente bueno como para que no sea una molestia.

Python en Windows sin ventana de DOS

Jake — Mon, 19 Feb 2007 23:00:13 +0000

En Windows se puede ejecutar un programa escrito en Python haciendo doble clic sobre él, pues se asocian los archivos de extensión .py al intérprete durante la instalación de éste. Aún cuando el programa que se ejecuta es una aplicación gráfica, se abre una ventana de DOS, que está ahí para dejar disponibles la entrada y salida estándar y la salida de errores. Sin embargo, muchas veces no interesa que aparezca, pues puede resultar molesta, o incluso confundir a usuarios poco avanzados que usen la aplicación.

La forma más sencilla que he encontrado para evitar que aparezca esta ventana de DOS con los programas Python es cambiar la extensión del ejecutable principal de .py a .pyw, con esto en vez de abrirse con python.exe, se abrirá con pythonw.exe, que está pensado especialmente para estos casos

Problemas al compilar blas-atlas en Gentoo

Jake — Fri, 02 Feb 2007 17:35:14 +0000

Esta es una de esas entradas que pongo aquí sobre todo para evitar olvidarme si me enfrento de nuevo al mismo problema.

Ayer estaba en la biblioteca estudiando para un examen de control digital y necesitaba usar octave para hacer algunas pruebas. Descubrí con horror que iba mal cuando se quedó colgado al pedirle las raíces de un polinomio:

octave:1> v = roots([1 3 2 0 2])

Tuve que interrumpir la operación con el típico Ctrl+C porque, además, el octave estaba usando en ese momento el 100% de CPU según top. Lo sorprendente es que al volver a intentar la misma operación, en vez de colgarse, me mostró este error:

octave:1> v = roots([1 3 2 0 2]) error: dgeev failed to converge error: evaluating assignment expression near line 65, column 9 error: evaluating if command near line 62, column 5 error: evaluating if command near line 59, column 3 error: called from `roots' in file `/usr/share/octave/2.1.73/m/polynomial/roots.m' error: evaluating assignment expression near line 1, column 3

El problema no sólo aparecía con la función roots, sino con muchas otra de las que necesitaba, que quizá usaban ésta en su código. Un poco de investigación al llegar a casa me hizo saber que el problema estaba en que había compilado la versión de octave ofrecida como estaba por Gentoo sin Blas entre sus uses. En el Changelog de octave decía que en la versión más reciente (2.1.73-r2), Blas había dejado de ser opcional.

Desenmascaré entonces esta versión de octave y comenzó la instalación de blas-atlas, que es una de las implementaciones de ¡Blas disponibles. Pero duró poco, la instalación se detuvo con un mensaje en pantalla que decía que tenía que ejecutar la instalación en modo interactivo. Seguí los pasos indicados pero, independientemente de las opciones que escogiese en el proceso, la compilación fallaba.

En un hilo del foro de Gentoo donde había un usuario quejándose del mismo problema que yo, el desarrollador encargado del ebuild de octave en Gentoo aconsejaba desenmascarar las últimas versiones de blas-atlas y blas-lapack (además de dos de sus dependencias que también estaban enmascaradas). Hecho esto repetí el intento de instalación y esta vez no sólo me hizo menos preguntas que antes sino que aparentemente estaba funcionando.

El proceso de compilación de blas-atlas es largo, y por la salida que ofrece en ocasiones parece que ha entrado en un ciclo infinito. Pero no pierdas la calma, que no es así; cada iteración es diferente y no se ciclan, así que resiste la tentación de cancelar. No puedo decir cuanto tardó porque me fui a dormir, pero esta mañana, cuando le pregunté a octave de nuevo por las raíces del mismo polinomio de ayer, me respondió esto rápidamente:

octave:1> v = roots([1 3 2 0 2]) v = -1.79051 + 0.55231i -1.79051 - 0.55231i 0.29051 + 0.69660i 0.29051 - 0.69660i

Una advertencia, aunque aparece en pantalla antes de empezar: Si tienes un procesador que ajusta su velocidad a las necesidades del software, desactiva esta opción y deja una velocidad fija de procesador durante la compilación, porque blas-atlas hace pruebas de rendimiento para optimizarse y una velocidad variable del procesador puede traer resultados no deseados.

Eso es todo, Jake out.

La codificación de caracteres en Python

Jake — Thu, 01 Feb 2007 00:26:39 +0000

Cuando escribimos un script en Python y éste contiene cadenas de caracteres que no están escritas en inglés, es posible que éstas contengan caracteres que no se encuentran entre los definidos por el ASCII. En este caso, si no se le dice a Python cómo debe tratarlas, éste se queja.

Tomemos, por ejemplo, este script que tan sólo muestra en pantalla una cadena de texto:

PLAIN TEXT

PYTHON:

#!/usr/bin/env python
# Las tildes no están a salvo en los comentarios
print "Las tildes no están a salvo en las cadenas de texto"

Si ejecutamos este script tal como está ahora, tendremos una desagradable sorpresa:

jake@aurora /tmp $ chmod u+x encoding.py jake@aurora /tmp $ ./encoding.py sys:1: DeprecationWarning: Non-ASCII character '\xc3' in file ./encoding.py on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details Las tildes no están a salvo en las cadenas de texto

La URL que devuelve el intérprete corresponde a una propuesta de extensión de Python (PEP), aceptada hace tiempo, que indica cómo especificar la codificación de caracteres no ASCII.

Básicamente, lo que dice es que Python interpreta todo como ASCII a menos que se le indique lo contrario con un comentario especial que tiene que estar en la primera o la segunda línea y debe casar con la expresión regular: coding[:=]\s*([-\w.]+). Esto significa que si usas Vim o emacs para editar el código python puedes utilizar la sintaxis propia de cada uno para indicarle al editor la codificación del archivo y así matar dos pájaros de un tiro. Además, como bien dice el artículo, se puede usar incluso el lenguaje natural; podría escribir:

PLAIN TEXT

PYTHON:

#!/usr/bin/env python
# Este archivo usa el encoding: utf-8
# Las tildes no están a salvo en los comentarios
print "Las tildes no están a salvo en las cadenas de texto"

Aunque yo prefiero usar la sintaxis de Vim, que es, dicho sea de paso, mi editor favorito

PLAIN TEXT

PYTHON:

#!/usr/bin/env python
# vim: set fileencoding=utf-8 :
# Las tildes no están a salvo en los comentarios
print "Las tildes no están a salvo en las cadenas de texto"

Y si ejecutamos esta nueva versión vemos que ahora no hay quejas:

jake@aurora /tmp $ ./encoding.py Las tildes no están a salvo en las cadenas de texto

Comprobaciones de particiones en el arranque

Jake — Wed, 20 Dec 2006 02:58:00 +0000

Resulta muy molesto, y más en un portátil, que las comprobaciones de las particiones ext3 se hagan en Linux (al menos en Ubuntu) automáticamente durante el arranque. En muchas ocasiones enciendo el ordenador con prisa, con la única intención de consultar algún detalle rápido. Y entonces se programa una comprobación de una de las particiones de mi disco duro. Es una situación dificil, pues la operación no puede cancelarse ni tampoco reiniciar resuelve el problema. En estas ocasiones no parece quedar más remedio que esperar.

No obstante, la frecuencia de estas comprobaciones puede configurarse. Pueden incluso ser desactivadas. Una rápida lectura a la página de manual del programa tune2fs me llevó a la solución:
jake@aurora:~$ sudo tune2fs -i 100d -c 100 /dev/sda5 tune2fs 1.39 (29-May-2006) Se pone la cuenta de montajes máxima a 100 Setting interval between checks to 8640000 seconds

Con esto, las comprobaciones sobre la partición /dev/sda se harán cada 100 veces que se reinicie el ordenador (antes estaba a 20) o bien cada 180 días, lo que ocurra antes.

Cuidado con Ubuntu en los portátiles Dell

Jake — Tue, 12 Dec 2006 01:13:15 +0000

La semana pasada tuve un momento de crisis. Cuando fui a encender a Aurora (Dell Inspiron 640m) me encontré con una pantalla negra que únicamente tenía este texto:

Time-of-day clock stopped

Al reiniciar volvía a aparecer la misma pantalla y no podía tan siquiera acceder a la BIOS.

El servicio de atención al cliente de Dell no era una opción, pues no está operativo los sábados. Un poco de investigación me llevó a un informe de errores con título Ubuntu corrompe el reloj de tiempo real en algunos portátiles Dell. Allí decía que quitando la pila de la BIOS y volviendo a ponerla se resolvía el problema. Esta me pareció una solución interesante, pero eso fue antes de saber que la pila está debajo del teclado y que tenía que desarmar medio portátil para llegar a ella. Por suerte, Dell pone a disposición de sus clientes una fabulosas instrucciones, con fotos y detalles de cuidado, para desmontar cada modelo de portátil de la marca e identificar las distintas partes (son los llamados manuales de servicio, que sólo están disponibles en inglés). En mi caso, seguí las instrucciones específicas para cambiar la pila de la BIOS del Inspiron 640m. Claro que, después de efectuar esta operación, tuve que volver a configurar todos los parámetros de la BIOS para dejarlos como los tenía antes de la crisis.

Esta fotografía la tomé durante el proceso, justo después de haberle quitado la pila a Aurora. El rectángulo azul indica la posición de la pila.

Esta experiencia ha servido con creces para que me plantee probar otras distribuciones. Tengo ahora Gentoo en el punto de mira, y es más que probable que sea la próxima.

Escoger el orden de tarjetas de sonido con Alsa en Ubuntu

Jake — Wed, 06 Dec 2006 03:27:27 +0000

Uno de los problemas que tuve al actualizar la distribución de Ubuntu Linux de Asimov de Dapper Drake a Edgy Eft tenía que ver con el sonido.

Asimov tiene una tarjeta de sonido incluida en la placa, que nunca uso, porque tengo una Sound Blaster 128 PCI que sí uso. Dapper nunca reconoció la primera, pero Edgy sí, y ahora había tomado el control del sonido del sistema. Yo quería poner la Sound Blaster como principal, pero teniendo ambas disponibles.

Encontré la solución en este hilo del foro de Ubuntu. Ejecuté:

jake@asimov:~$ cat /proc/asound/modules 0 snd_via82xx 1 snd_ens1371

Como puede verse, la tarjeta VIA, incluida en la placa base, estaba la primera.

Edité entonces la configuración de Alsa en /etc/modprobe.d/alsa-base. Ojo aquí, pues, por alguna razón que desconozco, en el foro se indica otro nombre de archivo que en mi caso no existía, y la configuración de Alsa la encontré en /etc/modprobe.d/alsa-base, como he dicho.

jake@asimov:~$ sudo vi /etc/modprobe.d/alsa-base

Añadí estas dos líneas al final:

options snd-ens1371 index=0 options snd-via82xx index=1

Fíjate en que el guión bajo (_) de antes se sustituye aquí por un guión (-). El parámetro index indica en el orden en que se tomarán las tarjetas en el sistema (empezando por cero). Para que estos cambios se hiciesen efectivos en el sistema, ejecuté:

$ sudo update-modules

Y reinicié la máquina. Al volver a entrar, mi tarjeta principal ya era la Sound Blaster:

jake@asimov:~$ cat /proc/asound/modules 0 snd_ens1371 1 snd_via82xx

Actualización de Ubuntu: de Dapper a Edgy

Jake — Wed, 06 Dec 2006 01:23:33 +0000

Asimov tiene instalado Windows 2000 Professional y Ubuntu Linux. A finales de octubre se publicó una nueva versión de Ubuntu: Edgy Eft. Una semana después tuve tiempo de actualizar mi Dapper Drake. Aunque podría haber hecho una actualización por red, decidí descargar el CD de instalación. Entre los disponibles para descarga, escogí ubuntu-6.10-alternate-i386.iso, ahora no recuerdo por qué (estos olvidos son los que quiero evitar con este blog )

Normalmente no grabo estas isos hasta que necesito llevarlas a algún otro lugar, y no era el caso. De modo que seguí estos pasos para evitar grabar el CD.

Primero copié la imagen iso en /media

$ sudo cp ubuntu-6.10-alternate-i386.iso /media

Luego creé el directorio /media/edgycd y añadí esta línea al /etc/ftab

/media/ubuntu-6.10-alternate-i386.iso /media/edgycd iso9660 loop

De este modo puedo montar la iso como si estuviese poniendo el CD con solo hacer:

$ sudo mount /media/edgycd

Siguiendo las instrucciones de Este comentario hice esto una vez montado:

$ gksu sh /media/edgycd/cdromupgrade

Y ahí comenzó directamente la actualización, preguntándome si quería descargar de la red los paquetes que no estuviesen en el CD-ROM. Por supuesto, respondí que sí.

Pasó un buen rato descargando e instalando paquetes. Acepté todas las modificaciones que me mostró y al final reinicié.

Los gráficos de arranque: Usplash

En el menú de selección de grub escogí el kernel para 386 y en el siguiente paso la pantalla se puso en negro y me mostró un error de frecuencia. El monitor de Asimov es un TFT LG FLATRON L1750SQ, de 17" que soporta 1280x1024@75Hz. Me enteré de que se trataba de un problema de los gráficos que se muestran durante el arranque y encontré la solución aquí. Funcionó a la primera, ya me aparecía la imagen de inicio. Venía a decir (traduzco)

Intenta esto en la línea de comandos:
$ sudo nano /etc/usplash.conf

Debería parecerse a esto:

# Usplash configuration file
xres=1024
yres=768

Si haces cambios, asegúrate de que ejecutas luego este comando:
$ sudo update-initramfs -u

Los kernels anticuados de Dapper

Los kernels que tenía instalados en Dapper eran los dos últimos disponibles en los repositorios oficiales de la rama 2.6 para i386 y k7. En Edgy, las versiones especializadas, como k7 o 686 han sido sustituidas por una sola llamada generic. Al parecer la razón es que no merecía la pena el esfuerzo de mantener desarrollos paralelos porque al final las diferencias no eran notables. Como yo no había personalizado mi kernel en Dapper, podía borrarlos con tranquilidad una vez comprobado, eso sí, que los nuevos funcionaban bien.

Todas las pruebas anteriores las había hecho con el de i383 y cuando probé el generic no funcionó. Se quedaba todo parado en el arranque. Investigando un poco encontré la solución (otra vez) en este hilo del foro de Ubuntu, donde se explica que la actualización a Edgy no creó el script initramfs para el kernel genérico, de modo que el problema se resuelve creándolo manualmente:

jake@asimov:~$ sudo mkinitramfs -o /boot/initrd.img-2.6.17-10-generic jake@asimov:~$ sudo update-grub

Antes de reiniciar, y como al menos ya tenía el de i386 que funcionaba bien, usé aptitude para quitar todos los núcleos anteriores. Busqué primero todos los kernels instalados:

jake@asimov:~$ sudo aptitude search linux-image | grep ^i i linux-image-2.6.15-26-386 - Linux kernel image for version 2.6.15 on 386. i A linux-image-2.6.15-26-k7 - Linux kernel image for version 2.6.15 on AMD K7 SMP/UP i A linux-image-2.6.15-27-386 - Linux kernel image for version 2.6.15 on 386. i A linux-image-2.6.15-27-k7 - Linux kernel image for version 2.6.15 on AMD K7 SMP/UP i linux-image-2.6.17-10-386 - Linux kernel image for version 2.6.17 on i386 i linux-image-2.6.17-10-generic - Linux kernel image for version 2.6.17 on x86/x86_64 i linux-image-386 - Linux kernel image on 386. i linux-image-generic - Generic Linux kernel image i linux-image-k7 - Obsoleted by: linux-image-generic

La primera columna indica si un paquete está instalado (i) o no (p), pero con grep ^i se filtran las líneas que empiezan por i, de modo que sólo se muestran los instalados. Tomé los nombres de los que tenían número inferior a 2.6.17 y los eliminé todos con aptitude:

jake@asimov:~$ sudo aptitude purge linux-image-2.6.15-26-386 linux-image-2.6.15-26-k7 linux-image-2.6.15-27-386 linux-image-2.6.15-27-k7 linux-image-k7

Fíjate en que eliminé también el paquete dummy linux-image-k7 porque, debido a los mencionados cambios en la política de variantes del núcleo, ya no tenía sentido tenerlo instalado.

Cuando terminó la desinstalación, el aptitude se encargó de reconfigurar el grub para que se guardasen los cambios. Y entonces sí que era momento de reiniciar, para ver un grub limpio, y comprobar que el kernel genérico funcionaba correctamente.

En efecto, tras estos cambios, todo parecía estar en orden. El menú de grub se veía mucho más limpio y el kernel genérico se cargó sin problemas.

Edgy vs Mplayer

Mplayer es mi reproductor de vídeo favorito, por eso lo tenía instalado en Dapper. Pero Edgy decidió que mplayer no era bueno y lo desinstaló sin preguntarme. Yo, por otra parte, decidí que lo quería de vuelta y lo volví a instalar

Cuando instalo mplayer, normalmente suelo poner estos 4 paquetes:

mplayer
mplayer-skins
mplayer-fonts
mplayer-doc

Comprobé cuales de ellos no estaban instalados:

jake@asimov:~$ sudo aptitude search mplayer | egrep ' mplayer(\-doc\b|\-fonts\b|-skins\b| )' c mplayer - The Ultimate Movie Player For Linux i mplayer-doc - The Ultimate Movie Player For Linux (Docum c mplayer-fonts - Fonts for mplayer i mplayer-skins - Skins for the Ubuntu mplayer Package

Y ví que mplayer y mplayer-fonts aparecía como eliminado aunque con archivos de configuración presentes (es lo que indica la c). Parecía un problema de solución simple:

jake@asimov:~$ sudo aptitude install mplayer mplayer-fonts

Y efectivamente, lo fue. Ya podía volver a ver vídeos con mi reproductor favorito. Además, los archivos de configuración anteriores se mantuvieron tras la instalación, de modo que no tuve que configurar nada más nada.

Fin (o casi)

Después de resolver estos problemas y un pequeño percance con el sonido que ya comentaré en otro post, el sistema estaba actualizado y funcionando correctamente.

¡Hola mundo!

Jake — Tue, 05 Dec 2006 23:13:48 +0000

Comienzo este proyecto con el más que conocido «¡Hola Mundo!» que tanto hemos visto al dar los primeros pasos en un nuevo lenguaje de programación. No voy a describir en este post el propósito de este weblog, pues ya lo he hecho en la sección Acerca de.

Tan sólo quiero hacer dos cosas en esta entrada.

La primera es darte la bienvenida, y transmitirte mi deseo de que encuentres razones para acompañarme un largo tiempo.

La segunda es, para ir entrando en calor, presentarte mis máquinas.

En la foto puedes ver, de izquierda a derecha a Aurora, Asimov y Nostromo. He puesto la foto en flickr y le he añadido notas, así que si sigues el enlace podrás ver con más exactitud qué es cada cosa (pasa el ratón sobre la imagen en la página de flickr y saldrán las notas)

Aurora es un Dell Inspiron 640m con un procesador Centrino Duo a 2GHz y 2GB de RAM
Asimov es un sin marca con un procesador AMD Sempron 2600 (1,6 GHz) y 512 MB de RAM
Nostromo es un Dell Optiplex GX240 con un procesador Intel Pentium IV a 1.50GHz, y 512 MB de RAM

Sé que no es entrar mucho en detalle, pero supongo que con el tiempo te iré contando un poco más de cada uno (probablemente cuando me den problemas).