Kaotik Labs

Debido a un problema en un servidor acabé teniendo que monitorizar los eventos de un sistema de ficheros ext3 para comprobar que ciertos ficheros estaban siendo escritos en el disco. Para ello, busqué información relativa al tema y encontré dnotify. Dnotify trabaja abriendo tantos descriptores de ficheros como directorios intentas monitorizar de esta forma monitoriza el cambio de estado de un directorio pero implica el tener algún método de monitorizar los cambios internos de los ficheros dentro del directorio. Además implica problemas adicionales al no poder desmontar las unidades monitorizadas ya que se encuentran secuestradas por el descriptor del fichero. Otro de sus inconvenientes se destapa al tratar de monitorizar una gran cantidad de archivos. En estos casos es probable llegar al limite máximo de descriptores de ficheros permitidos en el equipo, produciendo un comportamiento errático del mismo. Por fortuna, encontré inotify, una herramienta de monitorización de cambios en fiche

Después de un par de tardes trabajando en el tiempo libre sobre la demo de flocking he consegido ya algo un poco más respetable. Finalmente he conseguido superar algunos de los problemas que me he encontrado a la hora de implementar el algoritmo correctamente. Entiendo correctamente al hecho de que los componentes de la manada sólo tomen como referencia a sus vecinos más cercanos y no al conjunto global como estaban haciendo hasta ahora. De todos modos, esta implementación aún puede mejorarse muchísimo, añadiendo acciones de no comportamiento, dimensión Z y sobre todo, dandole un pequeó enfoque de juego que aproveche el algoritmo. Si tengo tiempo intentaré darle un par de vuelta más. De momento aquí dejo lo que tengo hecho. Adjunto el ejecutable en formato zip. flocker2x El video del ejemplo: Y los algoritmos en pseudocódigo. REGLA DE COHESIÓN: PROCEDURE rule1(boid b J ) Vector pc J FOR EACH BOID b IF b != b J THEN pc J = pc J + b.position END IF E

El NSLU2 suele venir en dos versiones distintas, una corriendo a 133Mhz y otra 266Mhz. El micro siempre es el mismo, por lo tanto, cabe pensar que esta restricción se impuso para restringir el uso del SLUG como servidor linux genérico. He visto que normalmente las nuevas versiones vuelven a venir a 266Mhz, pero para aquellos que tenga un SLUG capado, os explico el método para overclockearlo. Debemos empezar comprobando la velocidad a la que corre para determinar si es necesario el overclock. Para ello, lanzaremos el siguiente comando. # cat /proc/cpuinfo Si el campo de los BogoMips de salida es similar a 131, tendremos una de las placas capadas. Si es 266, tenemos uno de los modelos sin capar, por lo que no necesitamos hacer nada, ya que la placa corre a su velocidad adecuada. Una vez detectado un SLUG capado deberemos de realizar las siguientes acciones para overclockearlo: Abrir el SLUG. Este proceso debe de hacerse con precacución ya que puede romperse la pestaña

Hace tiempo me interesé por los algoritmos de flocking o movimientos de manada. Esto pude sonar a chino, pero simplemente se trata de tratar emular los movimientos en conjunto de los pajaros, bancos de peces, ovejas…, vamos, cualquier conjunto de animales en movimiento. Las reglas de movimiento, a pesar de que puedan parecer complejas a simple vista, estan basadas sólo en tres simples leyes: Repulsión : Intentar no chocar con los compañeros. Alineamiento : Avanzar en una dirección semejante a la de tus compañeros. Cohesión : Acercarse hacia el centro del grupo. De la media de estos valores se extrae el vector director de cada individuo. VectorDirector = (Repulsión + Alineamiento + Cohesión)/3 Pues con esta idea intenté ayer programar una pequeña demo para implementarlo. Aquí os pongo un video de como esta quedando. Aún quedan por retocar varias cosas ya que algunas reglas no las estoy aplicando estrictamente. La parte más importante que no esta implementada es el