Precisión

Es fácil de olvidar, porque al verlo en el código no se ve nada de malo, pero hay que tener cuidado al comparar flotantes. Por ejemplo hoy que comparaba una variable x contra 0.001, habiéndole asignado a x 0.001, el resultado siempre era falso. Eso se debe a que internamente y por cuestiones de precisión los valores son distintos. Es por eso que si se fijan, nunca se hace for usando floats...

Cuidado con los "dummies"

Volvemos a lo mismo ... Esta vez decidí hacer un dummy de un programa de adquisición para simular una señal digital que cambia. Y pues ahi me tienen haciendo mis pruebas y rompiéndome la cabeza porque todos los datos parecían estar mal... Hasta empecé a revisar todos mis algoritmos, a darle vueltas al asunto hasta que... Me voy dando cuenta de que ¡el dummy estaba mal! Y era una tontería, en lugar de poner un 1.0, ponía un 1.1, lo que causaba que todos los datos se recorrieran y se creara un verdadero desastre... Es decir, el programa que quería validar siempre estuvo bien... Así que mi consejo es que antes de asumir que tu programa está mal, checa bien contra lo que lo estás validando. Así ahorrarás mucho tiempo perdido :)

Problemas que salen de la nada al adaptar código

Siempre que por alguna razón tengas que quitar un pedazo de código para adaptarlo rápidamente para otra cosa, ten cuidado con la indentación... Sobretodo cuando comentas partes o bloques de código... Hoy por andar con las prisas, me dio flojera acomodarlo porque pensé "Ayyy pues eso es estético, luego lo acomodo". Pero resulta que mi programa tronaba... Y pues de por si ni lo podía analizar bien porque estaba todo desacomodado, así que lo empecé a acomodar y ¡funcionó! Y no fue precisamente por arte de magia, sino porque el orden de las llaves había sido alterado y eso modificaba la secuencia de ejecución, provocando así el acceso al un índice de arreglo fuera de rango. Con esto se comprueba que eso de programar todo presionado ¡NO FUNCIONA!!!

dkms

- Para compilar e instalar módulos en el kernel se utiliza dkms. Con eso ya se inicia solito el módulo a la próxima vez que se reinicia la máquina, aunque el módulo se puede usar luego luego desde el momento que se instala.
- El archivo de configuración del kernel está en /boot/config-2.6.4-52-smp
- El directorio del kernel /usr/src/linux-2.6.4-52

No se puede iniciar entorno KDE o GNOME desde kdm

Este detallito si que me sacó canas verdes... Resulta que un día -al parecer de la nada- no pude volver a iniciar sesión desde KDM hacia KDE, Gnome o BlackBox. La única forma de iniciarlos era entrando a failsafe y desde ahi tecleando kde.Busqué información en todos lados y nunca pude encontrar una respuesta. Sin embargo, me di cuenta de que si creaba un nuevo usuario el problema ya no se presentaba y podía iniciar el entorno sin problemas.

Inicialmente respaldé todos los archivos de configuración y los borré de su ubicación original. Como había sospechado, el problema desapareció. Hecho esto, hice algunas pruebas más y me di cuenta de que el archivo .xinitrc era el problema. Ya había encontrado referencias a problemas con este archivo pero ninguna parecía ser mi caso. Sin embargo, terminé por darme cuenta de que el problema fue que el archivo .xinitrc estaba vacío. Esto es un problema ya que es el archivo que se lee al llamar a startx y, al estar vacío, causa que los entornos no se inicien.

Ya identificado hay de dos:
- Borrar este archivo (al fin que hay uno a nivel de sistema (/etc/X11/xinit/xinitrc). El archivo .xinitrc en el directorio de cada usuario es sólo para que el usuario pueda personalizar algunas cosas.
- Tomar el archivo a nivel de sistema y copiarlo al directorio del usuario renombrándolo como .xinitrc.

Cabe mencionar que yo tomé el primer camino :)

Descanso

Jajaja es muy triste pero pues ahorita no estoy teniendo actividad. Bueno no puedo negar que tener vacaciones es genial, sin embargo, tengo la incertidumbre sobre cuándo (o si) empezaré a trabajar. pero bueno trataré de disfrutar este tiempo de descanso y dejar de temer tanto...

Mañas de los scripts

Para no olvidar: Si empiezas un script con un comentario obtienes un mesaje de error "Cannot execute binary file" al ejecutarlo desde otro script. Así que para quitarse de problemas hay que iniciarlo con #!/bin/sh, que por cierto ya aprendí que no es nada más para que se vea más "apantallante" el script, sino que sirve para que los comandos se ejecuten en un nuevo shell. Hablando de eso, si ejecutas un script con esta notación:

. [nombredelscript]

entonces los comandos se ejecutan en el shell actual (esto es útil si quieres que se conserve alguna variable de shell al terminar la ejecución del script). Con esa notación ya no se toma en cuenta el #!/bin/sh (no se crea un nuevo shell)