Today I have been at the monthly meeting of the Python Madrid group where I did a keynote about HTML5 and what benefits can offer to the Python web developers, and also showed ShareIt! as a proof of the technology potential. Althought some technical problems with the projector, finally I was able to show it and was a sucess :-)
They liked so much the idea behind of ShareIt! and were very interested on the technology behind it, specially about how I'm using WebSockets for the DataChannel-polyfill and if the final native implementations will support high estress use like the one ShareIt will so or maybe bigger ones (I believe someone is thinking about highly masive videochats... :-D ) but also they asked me a very interesting question that I didn't thought about: the most important building blocks on ShareIt! are annonimity and confidentiality, being the users identified by a random UID at load and with encrypted communications (both WebSockets with TLS and DataChannels by the specification), but since I'm not a security expert, there is an important security hole regarding to annonimity, so it's critical: to be able to do the PeerConnection, you need to transfer your SDP to the other peer to be able to do the connection, but the fact is that it has your public IP on the origin field (just the ID used by DataChannel-polyfill, by the way...), so this way the other end can be able to connect to you... but also know where you are. And it's done both ways. If at one of the ends there is a men in black listening (here at Spain we have La Innombrable, that it's scarier) and send him your shared files list, you have a problem.
They suggested me to use some type of friends white list based on public key for authenticity of the other pair, but since you can connect to anyone to fetch the data in a distributed way and not end having a lot of limited, private networks, this in unfeasable. Anyway, I got the idea banging on my head and think found a solution: just ask for authentification when you query a files list. This way, since for tranfering chunks you look for the files by their hash, you don't know what is being requested except if you have already the file with that hash, so you'll need to ask for all the combinations of the hash (on Tiger TTH, 2^192 combinations, bigger than the ZFS address space), and something similar would happen if you do a fulltext search over the network, so it's impracticable. The only attack point would be ask directly to a specific peer for its files list, and since this is something that you'll not do too much frequently (you want to fetch a file, doesn't matter where he comes), this can be easily filtered only allowing to do it if you have exchange a public key with the other peer (something you should do only if you know who is at the other end...), so you know the request is legit and also you can send the files list data cyphered with that key. Easy and unobstrusive :-)
Another option would be just to remove entirelly the files list request mechanism and only allow searching for files. This would limit the functionality of the protocol, but would be fairly more simple and secure, so maybe it's a good option for a future version...
Mostrando entradas con la etiqueta Python. Mostrar todas las entradas
Mostrando entradas con la etiqueta Python. Mostrar todas las entradas
viernes, 19 de octubre de 2012
viernes, 5 de octubre de 2012
Online Python Tutor
Online Python Tutor, un tutor online de Python, que no solo permite hacer pequeños programas para aprender sino que ademas te muestra paso a paso todo lo que sucede internamente con una animacion: asignacion de variables, llamada a funciones, datos en la pila de programas... El unico pero que le veo es la reasignacion de variables que queda un poco confusa (un paso intermedio para mostrar el recolector de basura funcionando seria mucho mas claro y realista), pero si algo asi se usara en primero de carrera se prevendrian despues muchos dolores de cabeza... :-D
domingo, 15 de abril de 2012
A veces veo eventos...
A pesar de los fallos relativos al git-svn y tener que trabajar unicamente con el repositorio de GitHub... no he podido resistirme ni tener las manos quietas y he picado mas codigo :-P ¿Y en que he estado liado estos ultimos dias en lugar de estudiar los examenes? Pues ni mas ni menos que con el task manager :-D
El primer paso fue hacer que se imprieran los ticks fuera del driver del temporizador, ya que ahi no hacian nada util. Ahora se estan enviando por el motor de eventos en distintos periodos de tiempo: milisegundos (para lo que he tenido que aumentar la precision del timer, suerte que solo es una variable :-) ), centesimas, decimas y segundos. Asi aunque quizas lo sobrecargue un poco simplemente tengo que acoplarme a la frecuencia adecuada, en este caso centesimas (lo estandar), aunque podria hacer que el cambio de contexto fuese incluso mas rapido si quisiera.
Despues, empece con la definicion basica de lo que seria un proceso internamente para poder delegarles eventos (registrarse directamente en el gestor de eventos del sistema queda un poco feo y complicado, y mas si de todas formas habra que buscar los callbacks dentro de los procesos). Al principio pense en reutilizar la libreria de threads que he hecho para la asignatura de Fundamentos de Sistemas Distribuidos... hasta que me di cuenta que setjmp() y longjmp() son dependientes de cada sistema o no tengo manera posible de implementarlos por el momento :-/ asi que descarte esa idea y me centre por el momento en como hacer para delegar los eventos a sub-diccionarios, y aqui me encontre con otro problema: ¡un diccionario no es una funcion! Asi que como solucion rapida estoy usando un segundo diccionario a la espera de desarrollar mas como seria el tipo Event.
Por ultimo y no menos importante, en un acto de inspiracion divina (en concreto de Morfeo ;-) ) se me ocurrio que aunque actualmente este todo funcionando en el mismo espacio de usuario, podria trabajar con los eventos de los procesos de forma independiente a traves de funciones estaticas... incluso aunque esten en un mismo archivo, siempre que sea este el que se importe. Esto redunda en codigo repetido, si, pero quizas se pueda arreglar pasando las estructuras por parametros. Lo que si que es interesante es el hecho de que el preprocesador se ejecuta de forma lineal, con lo que abusando de el un poco, he conseguido renombrar las funciones relaccionadas con los eventos en el lado de las aplicaciones igual que en el lado del kernel, con lo que solo hace falta cambiar el include para poder pasar el codigo de un lado a otro :-D Esto ultimo es mas util de lo que parece, ya que aparte de hacer el codigo mas limpio, quizas pueda aplicarlo tambien a las llamadas al sistema, y por tanto, que se puedan mover los drivers del espacio de usuario al espacio de kernel de forma totalmente transparente :-D
Como veis, esta todo bastante "en el aire" a la espera de poder dividir el codigo cuando termine el concurso y poder analizar y hacer pruebas independientes de cada parte, pero lo cierto es que al final me esta quedando un API bastante curiosa y flexible y, sobretodo, puramente orientada a eventos (que es lo que queria... :-D )
Update 23:39:
He intentado demostrar mi teoria respecto a usar la misma firma en los syscalls y ha funcionado, pero no como esperaba... sino mejor: puesto que ahora tengo el codigo mas aislado entre sus partes (y sobretodo a nivel de makefile), a la hora de compilarlo cada parte se compila con sus correspondientes syscall.h y syscall.c sin interferirse, luego no hacen falta hacer trucos de ningun tipo: las firmas de los syscalls son iguales que las de las funciones que representan dentro del kernel de forma nativa :-D Chulo, ¿eh? :-)
El primer paso fue hacer que se imprieran los ticks fuera del driver del temporizador, ya que ahi no hacian nada util. Ahora se estan enviando por el motor de eventos en distintos periodos de tiempo: milisegundos (para lo que he tenido que aumentar la precision del timer, suerte que solo es una variable :-) ), centesimas, decimas y segundos. Asi aunque quizas lo sobrecargue un poco simplemente tengo que acoplarme a la frecuencia adecuada, en este caso centesimas (lo estandar), aunque podria hacer que el cambio de contexto fuese incluso mas rapido si quisiera.
Despues, empece con la definicion basica de lo que seria un proceso internamente para poder delegarles eventos (registrarse directamente en el gestor de eventos del sistema queda un poco feo y complicado, y mas si de todas formas habra que buscar los callbacks dentro de los procesos). Al principio pense en reutilizar la libreria de threads que he hecho para la asignatura de Fundamentos de Sistemas Distribuidos... hasta que me di cuenta que setjmp() y longjmp() son dependientes de cada sistema o no tengo manera posible de implementarlos por el momento :-/ asi que descarte esa idea y me centre por el momento en como hacer para delegar los eventos a sub-diccionarios, y aqui me encontre con otro problema: ¡un diccionario no es una funcion! Asi que como solucion rapida estoy usando un segundo diccionario a la espera de desarrollar mas como seria el tipo Event.
Por ultimo y no menos importante, en un acto de inspiracion divina (en concreto de Morfeo ;-) ) se me ocurrio que aunque actualmente este todo funcionando en el mismo espacio de usuario, podria trabajar con los eventos de los procesos de forma independiente a traves de funciones estaticas... incluso aunque esten en un mismo archivo, siempre que sea este el que se importe. Esto redunda en codigo repetido, si, pero quizas se pueda arreglar pasando las estructuras por parametros. Lo que si que es interesante es el hecho de que el preprocesador se ejecuta de forma lineal, con lo que abusando de el un poco, he conseguido renombrar las funciones relaccionadas con los eventos en el lado de las aplicaciones igual que en el lado del kernel, con lo que solo hace falta cambiar el include para poder pasar el codigo de un lado a otro :-D Esto ultimo es mas util de lo que parece, ya que aparte de hacer el codigo mas limpio, quizas pueda aplicarlo tambien a las llamadas al sistema, y por tanto, que se puedan mover los drivers del espacio de usuario al espacio de kernel de forma totalmente transparente :-D
Como veis, esta todo bastante "en el aire" a la espera de poder dividir el codigo cuando termine el concurso y poder analizar y hacer pruebas independientes de cada parte, pero lo cierto es que al final me esta quedando un API bastante curiosa y flexible y, sobretodo, puramente orientada a eventos (que es lo que queria... :-D )
Update 23:39:
He intentado demostrar mi teoria respecto a usar la misma firma en los syscalls y ha funcionado, pero no como esperaba... sino mejor: puesto que ahora tengo el codigo mas aislado entre sus partes (y sobretodo a nivel de makefile), a la hora de compilarlo cada parte se compila con sus correspondientes syscall.h y syscall.c sin interferirse, luego no hacen falta hacer trucos de ningun tipo: las firmas de los syscalls son iguales que las de las funciones que representan dentro del kernel de forma nativa :-D Chulo, ¿eh? :-)
lunes, 2 de abril de 2012
Un empujoncito...
Bueno, como ya sabreis, nos encontramos en la recta final del concurso de este año, y aunque ya habia pensado en abandonarlo debido a la de lio que he tenido ultimamente y a que literalmente habia perdido la inspiracion... lo cierto es que soy un testarudo :-P
Asi que ya me veis, puesto que habia que entregar un pequeño informe detallado en el Readme del proyecto y tambien subirlo a la forja del concurso, me puse a revisar el codigo por si encontraba donde estaba el fallo por el cual no leia desde el teclado ni se procesaban correctamente los eventos lanzados por las interrupciones, y de pura casualidad los encontre, o al menos encontre una posible solucion añadiendole un pequeño retraso y cambiando los eventos a minusculas (creo que tiene que ver con la busqueda de entradas dentro del diccionario). Segun un amigo mio lo del retraso es debido a una condicion de carrera, pero lo cierto es que no tengo demasiadas ganas de investigarlo por ahora ya que tengo pensado hacer un rediseño completo del proyecto, principalmente convirtiendo el core en un proyecto independiente (libGaia) gracias al hecho de que en PyMite4Multiboot el codigo es practicamente el mismo, con lo que ademas me sera tambien mucho mas facil testearlo (como ya me paso cuando converti AntiORM en un proyecto independiente de PirannaFS).
En resumen: que ya leo desde el teclado correctamente, y acabo de darme cuenta que tenia muy cerquita y al alcance de la mano el poder tener "algo" que se pareciese minimamente a un sistema operativo multitarea y ademas con un esbozo muy claro de cual seria la API de las aplicaciones, en lugar de ser todo una macedonia defrutas callbacks lanzados por eventos. Vale, de acuerdo: un unico espacio de direcciones, todo hardcodeado, sin memoria dinamica... me referia mas al hecho de que aislando los eventos de las aplicaciones en su propia cola (en lugar de usar la del sistema) y el poder cambiar de "aplicaciones" a partir de las interrupciones del reloj del sistema quedaria mas claro cuales son los conceptos a partir de los que queria basar el proyecto. ¿Deberia haberme centrado mas en el proyecto en lugar de dedicar el tiempo a AntiORM? Probablemente. ¿Y respecto a PyMite4Multiboot? No lo creo, ya que justamente al ser mas facil desarrollar sobre el y permitirme ver las cosas desde otro punto de vista no solo he podido definir mejor como orientar el desarrollo futuro del proyecto (o sea: crear libGaia y modularizarlo) y ademas me ha sido mas facil resolver los fallos que tenia con el teclado. En cualquier caso, como dijo Linus Tordvalds y muy especialmente aplicado al software libre, si no es divertido no merece la pena hacerlo... :-D
Ahora, ¿que me depara el futuro? Bueno, a corto plazo centrarme en los examenes (me esperan dos semanas de aupa...), y despues quizas intente a definir la API de las aplicaciones si me da tiempo a hacerlo antes de que termine el plazo de evaluacion del concurso. Despues sin lugar a dudas aislar libGaia y todos los sub-proyectos que han aparecido a lo largo de este año y englobarlos dentro de ChaOS Project, el sistema operativo que llevo queriendo hacer desde que tenia 10 años y lo que realmente hizo que me motivara a desarrollar PirannaFS y Gaia (y que no subiera el codigo a la forja hasta el ultimo momento... :-P En Git los branchs y forks son cosas de cada dia, pero en SVN son casi como invocar a
Cthulhu...), y por ultimo continuar con el desarrollo de libGaia, Uranus y PyMite4Multiboot ya durante el verano o bien durante el año que viene, esta vez ya centrandome en darles una consistencia y una calidad al codigo, principalmente haciendo que funcione correctamente la memoria dinamica y el funcionamiento en espacio de usuario (aunque la tentacion de aprovechar PyMite para hacerme un sistema operativo y un kernel en Python me esta rondando mucho la cabeza... :-P ).
Asi que ya me veis, puesto que habia que entregar un pequeño informe detallado en el Readme del proyecto y tambien subirlo a la forja del concurso, me puse a revisar el codigo por si encontraba donde estaba el fallo por el cual no leia desde el teclado ni se procesaban correctamente los eventos lanzados por las interrupciones, y de pura casualidad los encontre, o al menos encontre una posible solucion añadiendole un pequeño retraso y cambiando los eventos a minusculas (creo que tiene que ver con la busqueda de entradas dentro del diccionario). Segun un amigo mio lo del retraso es debido a una condicion de carrera, pero lo cierto es que no tengo demasiadas ganas de investigarlo por ahora ya que tengo pensado hacer un rediseño completo del proyecto, principalmente convirtiendo el core en un proyecto independiente (libGaia) gracias al hecho de que en PyMite4Multiboot el codigo es practicamente el mismo, con lo que ademas me sera tambien mucho mas facil testearlo (como ya me paso cuando converti AntiORM en un proyecto independiente de PirannaFS).
En resumen: que ya leo desde el teclado correctamente, y acabo de darme cuenta que tenia muy cerquita y al alcance de la mano el poder tener "algo" que se pareciese minimamente a un sistema operativo multitarea y ademas con un esbozo muy claro de cual seria la API de las aplicaciones, en lugar de ser todo una macedonia de
Ahora, ¿que me depara el futuro? Bueno, a corto plazo centrarme en los examenes (me esperan dos semanas de aupa...), y despues quizas intente a definir la API de las aplicaciones si me da tiempo a hacerlo antes de que termine el plazo de evaluacion del concurso. Despues sin lugar a dudas aislar libGaia y todos los sub-proyectos que han aparecido a lo largo de este año y englobarlos dentro de ChaOS Project, el sistema operativo que llevo queriendo hacer desde que tenia 10 años y lo que realmente hizo que me motivara a desarrollar PirannaFS y Gaia (y que no subiera el codigo a la forja hasta el ultimo momento... :-P En Git los branchs y forks son cosas de cada dia, pero en SVN son casi como invocar a
Cthulhu...), y por ultimo continuar con el desarrollo de libGaia, Uranus y PyMite4Multiboot ya durante el verano o bien durante el año que viene, esta vez ya centrandome en darles una consistencia y una calidad al codigo, principalmente haciendo que funcione correctamente la memoria dinamica y el funcionamiento en espacio de usuario (aunque la tentacion de aprovechar PyMite para hacerme un sistema operativo y un kernel en Python me esta rondando mucho la cabeza... :-P ).
domingo, 26 de febrero de 2012
PyMite from Interruption Space
Se que ultimamente estoy hablando mucho de PyMite en lugar de sobre Gaia, mi verdadero proyecto para el concurso de este año, pero puesto que en cierto modo se me quedo la espinita clavada por la tonteria del bug por usar una version de Python demasiada moderna, lo cierto es que lo he estado usando como campo de pruebas para despues aplicar las mejoras a Gaia directamente. Sin embargo, esta vez mi trabajo en PyMite se merece un post por derecho propio:
PyMite capturando los scancodes del teclado mediante eventos. Si niños: he conseguido capturar y procesar interrupciones directamente desde dentro de Python :-D
¿Que como lo he hecho? Bien, vayamos por partes:
- En primer lugar, hace falta tener funcionando un gestor de interrupciones en C. Esto no es demasiado problema, puesto que tambien es necesario para poder capturar las interrupciones del reloj del sistema (que eso ya lo habia conseguido) y para poder capturar las interrupciones del teclado para poder usarlo como entrada estandar, asi que eso ya estaba listo. Trivial, vamos.
- Una vez hecho eso, el siguiente es añadir handlers para las interrupciones que queremos manejar (en principio todas). Para ello, me he hecho una funcion init() nativa dentro de events.py (un nuevo modulo que he hecho para gestionar los eventos, luego hablo mas de ello) que se encarga de inicializar la cola de eventos, de registrar el handler para las interrupciones en los que estamos interesados para que las guarde en la cola de eventos, y tambien de guardar un puntero a la funcion que se va a encargar despues de extraer los eventos y procesarlos, esta vez ya en Python. Todo el codigo esta sacado de Gaia con pequeñas modificaciones ya que la filosofia de diseño de hacerlo puramente orientado a eventos es comun para los dos, asi que he decidido reutilizar la idea de usar una unica cola global de eventos y que despues se vayan "bombeando" y procesando secuencialmente uno detras de otro como pequeñas unidades de codigo atomicas e independientes, muy inspirado en como funcionan Node.js o el motor de eventos Twisted (del cual soy un fan declarado... :-D ).
- Una vez que se produce una interrupcion, se lanza el handler que hemos definido para manejarlos (tambien nativo) el cual simplemente añade un nuevo evento a la cola de eventos, llama al bombeador de eventos y sale de la interrupcion (esta fue sencilla... ;-) ).
- Finalmente, el bombeador de eventos se asegura de que nadie mas los esta procesando (principalmente porque se haya producido una interrupcion mientras todavia no se habian terminado de procesar los pendientes) y en tal caso, va vaciando la cola de eventos y procesandolos uno a uno ejecutando las funciones que se hubiesen registrado para cada uno de ellos. Al tener que acceder a la cola de eventos y estar esta declarada en C estoy usando un par de funciones nativas para comprobar si esta vacia y para extraer uno de los eventos, nada mas.
Simple, facil y para toda la familia :-D Y por supuesto, todo subido al repositorio... :-)
Sin embargo hay truco: por un lado, no estoy generando eventos en Python propiamente dichos, sino que solo estoy guardando el nombre del evento. Esto es asi para que el handler fuera mas pequeño al posponer la conversion a objetos Python y volviera antes de la interrupcion, pero sin lugar a dudas si quiero usar una cola de eventos unica tendre que cambiarlo. Otra opcion seria el tratar las interrupciones en dos pasos, con una cola de interrupciones y despues convertirlas y añadirlas a la cola de eventos en un paso posterior. Esto aislaria por completo el procesamiento de interrupciones de el de eventos con lo que quedaria muchisimo mas limpio, pero tambien añadiria mas retrasos... habra que estudiarlo. Otro truco que usa que me ha sugerido el propio autor de PyMite (aunque al final no lo estoy haciendo como el me ha propuesto) y que es mas interesante, es que al tener PyMite su propio gestor de hilos y ademas puede cambiar automaticamente de uno a otro si ha estado uno de ellos mucho tiempo en la CPU (¿hilos preemptivos? eso en mi barrio se le llama procesos... :-P ) lo estoy aprovechando y en lugar de procesar los eventos directamente (con lo que el "proceso" que estaba en ejecucion cuando se produjo la interrupcion se queda esperando) los estoy lanzando en un nuevo hilo para que se procesen de forma autonoma mas adelante y asi poder volver inmediatamente de la interrupcion :-)
Por otra parte, hay espacio para limpiar codigo y para optimizar para aburrir. En primer lugar, actualmente no es threadsafe puesto que no estoy usando ninguna estructura que lo haga. En Gaia el bombeo de eventos esta protegido con un lock, pero al necesitar guardar la funcion a usar para el bombeo desconozco si podria usar una funcion nativa (supongo que si), por lo que estoy usando un simple booleano (¡¡¡error!!! :-S ), asi que eso tengo que arreglarlo pronto. Tambien estaria la posibilidad de usar la clase Queue de Python, pero tiene muchas dependencias que la libreria estandar de PyMite no me satisface, asi que por el momento descartado. Por ultimo, claro esta, lo que he comentado anteriormente de separar la cola de interrupciones de la de eventos, pero esa es otra historia... :-D En resumen, que en unos commits estara listo ;-)
Y eso es todo por ahora, me falta explicar como se usan dichas interrupciones desde Python pero eso lo explicare en otro post (aunque lo cierto es que ahora deberia centrarme en estudiar para los examenes... :-/ ). Lo que si me he dado cuenta es que el problema de la limitacion de memoria para el kernel en x86 es real, ya que me ha vuelto a pasar con PyMite aunque increiblemente en PyMite ha tardado mucho mas en aparecer que con Gaia: ha sido eliminar las funciones de acceso a los puertos de entrada/salida que no estaba usando y arreglarse el problema... :-/
P.D.: para los que no lo hayan entendido, el titulo del post es una parodia de Plan 9 from User Space, el port para Unix/Linux de las librerias del sistema operativo Plan 9, con el cual tengo una relacción de amor-odio digna de poner en el Facebook como "es complicado"... :-P
martes, 21 de febrero de 2012
lunes, 20 de febrero de 2012
PyMite
Originariamente no iba a desarrollar Gaia, todo fue fruto de las circunstancias. Desde siempre tuve claro que mi sistema operativo tendria una arquitectura microkernel, sin embargo tambien queria que fuera seguro y facil de entender, de ahi que la arquitectura exokernel fuera ganando fuerza: el menor codigo posible corriendo como supervisor, y todo lo demas corriendo como espacio de usuario. Esto se podria potenciar mas si no solo se usan dos ejecutables distintos (Gaia y Uranus) sino que directamente estaban escritos en dos lenguajes distintos, y que dos mejores opciones que mis grandes amores C++ y Python :-D
Proyectos para hacer un sistema operativo en Python ha habido algunos, pero no han llegado a buen termino, en parte por la mala fama que tiene Python de ser lento (lo cual no es "tan" cierto...). Sin embargo poco antes de comenzar la edicion del concurso de este año descubri la existencia de PyMite, y en ese momento vi claro que es lo que debia hacer :-D
PyMite aka Python-on-a-chip es una maquina virtual Python diseñada para correr sobre microcontroladores de 8 bits... y sin sistema operativo por debajo, directamente sobre el metal :-) Ironicamente, aunque existe la posibilidad de compilarlo para escritorio para pruebas no habia ninguna plataforma echa para que corriera sobre PCs estandar directamente, luego ¿que mejor manera de colaborar con el software libre? Y ademas, me conseguia una base solida sobre la que programar mi sistema operativo comodamente sin tener que diseñarme mis propias estructuras de datos: dos por el precio de uno :-)
Asi que me puse a ello, mirando documentacion y haciendo pruebas. Lo tenia todo listo, y a la hora de ejecutar... fallo. Un bug tan raro que ni el programador original pudo decirme que podria pasar :-( Habia perdido un tiempo precioso y ademas ya estaba mentalizado en desarrollar de una vez por todas mi propio sistema operativo, por lo que decidi cambiar mi proyecto de portar PyMite a la arquitectura x86 a desarrollar mi propio exokernel que sustituyera la labor que realizaria PyMite de abstraer a bajo nivel el hardware, y asi surgio Gaia, la madre tierra.
Sin embargo, la semana pasada recibi un e-mail sobre no-se-que indicandome que podria ser mi version de Python ya que al ser muy reciente generaba bytecodes que eran interpretados como basura. Al principio no sabia a que se referia hasta que vi de donde procedia: ¡era el bug que notifique hacia 5 meses! La verdad que no confiaba mucho en una idea feliz tan absurda, aunque tenia sentido asi que decidi probarla: me baje mi viejo codigo, compile el entorno usando Python 2.6 en lugar del 2.7.2 que viene por defecto, ejecuto... y no me lo podia creer, la excepcion habia desaparecido. ¡El ultimo paso que me faltaba, al final lo tenia! :-D Tarde, pero al menos ya no me quedaba con el regusto de no haberlo conseguido: PyMite estaba corriendo sobre una nueva plataforma y todo gracias a mi... y al mensaje de un desconocido :-D
Asi que estos dias le he estado dando un pequeño empujon canibalizando el codigo de Gaia (al igual que hace 5 meses hice en sentido inverso) y lo cierto es que me estoy llevando una grata noticia: no solo me esta siendo mucho mas facil entender como hacer las cosas al haberme peleado antese-mail con Gaia (y ademas ya funciona el timer con PyMite :-P ) sino que ademas, ¡casi no estoy picando codigo! ¡¡Todo es copy & paste!! :-D Luego en cierto sentido creo que "parte" de mi proposito al desarrollar Gaia se esta cumpliendo: un framework para hacer facil el desarrollo de sistemas operativos sin tener que preocuparse de las menudeces porque ya estan hechas :-) Por el momento el copy&paste es descarado porque al pillarme la noticia un poco por sorpresa actualmente Gaia de framework tiene poco... pero si que el codigo esta bastante claro con lo que no me esta costando nada adaptarlo :-)
Lo bueno de esto es que me va a servir para tener otro entorno de pruebas aparte de ChaOS para aumentar la portabilidad y abstraccion de Gaia, lo cual es bueno, y ademas tambien me permite colaborar con un proyecto de software libre bastante grande, lo cual esta genial :-D De momento estoy pensando en separar la libreria del sistema a un proyecto aparte (GaiaLib), con vistas a en el futuro sustituirla por NewLib (aunque lo cierto es que no me esta quedando nada mal... :-D ), y quien sabe si no podre sacar mas codigo reutilizable. Al final con la tonteria, lo que iba a ser un simple proyecto para el concurso ya van colaboraciones en cuatro distintos... :-P
Proyectos para hacer un sistema operativo en Python ha habido algunos, pero no han llegado a buen termino, en parte por la mala fama que tiene Python de ser lento (lo cual no es "tan" cierto...). Sin embargo poco antes de comenzar la edicion del concurso de este año descubri la existencia de PyMite, y en ese momento vi claro que es lo que debia hacer :-D
PyMite aka Python-on-a-chip es una maquina virtual Python diseñada para correr sobre microcontroladores de 8 bits... y sin sistema operativo por debajo, directamente sobre el metal :-) Ironicamente, aunque existe la posibilidad de compilarlo para escritorio para pruebas no habia ninguna plataforma echa para que corriera sobre PCs estandar directamente, luego ¿que mejor manera de colaborar con el software libre? Y ademas, me conseguia una base solida sobre la que programar mi sistema operativo comodamente sin tener que diseñarme mis propias estructuras de datos: dos por el precio de uno :-)
Asi que me puse a ello, mirando documentacion y haciendo pruebas. Lo tenia todo listo, y a la hora de ejecutar... fallo. Un bug tan raro que ni el programador original pudo decirme que podria pasar :-( Habia perdido un tiempo precioso y ademas ya estaba mentalizado en desarrollar de una vez por todas mi propio sistema operativo, por lo que decidi cambiar mi proyecto de portar PyMite a la arquitectura x86 a desarrollar mi propio exokernel que sustituyera la labor que realizaria PyMite de abstraer a bajo nivel el hardware, y asi surgio Gaia, la madre tierra.
Sin embargo, la semana pasada recibi un e-mail sobre no-se-que indicandome que podria ser mi version de Python ya que al ser muy reciente generaba bytecodes que eran interpretados como basura. Al principio no sabia a que se referia hasta que vi de donde procedia: ¡era el bug que notifique hacia 5 meses! La verdad que no confiaba mucho en una idea feliz tan absurda, aunque tenia sentido asi que decidi probarla: me baje mi viejo codigo, compile el entorno usando Python 2.6 en lugar del 2.7.2 que viene por defecto, ejecuto... y no me lo podia creer, la excepcion habia desaparecido. ¡El ultimo paso que me faltaba, al final lo tenia! :-D Tarde, pero al menos ya no me quedaba con el regusto de no haberlo conseguido: PyMite estaba corriendo sobre una nueva plataforma y todo gracias a mi... y al mensaje de un desconocido :-D
Asi que estos dias le he estado dando un pequeño empujon canibalizando el codigo de Gaia (al igual que hace 5 meses hice en sentido inverso) y lo cierto es que me estoy llevando una grata noticia: no solo me esta siendo mucho mas facil entender como hacer las cosas al haberme peleado antese-mail con Gaia (y ademas ya funciona el timer con PyMite :-P ) sino que ademas, ¡casi no estoy picando codigo! ¡¡Todo es copy & paste!! :-D Luego en cierto sentido creo que "parte" de mi proposito al desarrollar Gaia se esta cumpliendo: un framework para hacer facil el desarrollo de sistemas operativos sin tener que preocuparse de las menudeces porque ya estan hechas :-) Por el momento el copy&paste es descarado porque al pillarme la noticia un poco por sorpresa actualmente Gaia de framework tiene poco... pero si que el codigo esta bastante claro con lo que no me esta costando nada adaptarlo :-)
Lo bueno de esto es que me va a servir para tener otro entorno de pruebas aparte de ChaOS para aumentar la portabilidad y abstraccion de Gaia, lo cual es bueno, y ademas tambien me permite colaborar con un proyecto de software libre bastante grande, lo cual esta genial :-D De momento estoy pensando en separar la libreria del sistema a un proyecto aparte (GaiaLib), con vistas a en el futuro sustituirla por NewLib (aunque lo cierto es que no me esta quedando nada mal... :-D ), y quien sabe si no podre sacar mas codigo reutilizable. Al final con la tonteria, lo que iba a ser un simple proyecto para el concurso ya van colaboraciones en cuatro distintos... :-P
sábado, 11 de febrero de 2012
Featuring Norm
Como os dije en mi anterior entrada, debido al estres y desesperación que me estaba ocasionando el que Gaia cascara por cualquier tonteria decidi darme un respiro y mejorar en mi sistema de archivos, y una de esas mejoras fue justamente quitar todas las referencias a SQLite de la capa de abstracción a la base de datos y limpiarla un poquito. ¿Que pasa? Que como tiene la caracteristica de que es bastante generica al tener todas las consultas SQL en archivos externos, entonces ya no hay ninguna referencia al sistema de archivos y se podria aislar como un paquete independiente para poder usarlo en otros proyectos. Pues bien: un poco de magia con la ayuda de GitHub, un poquito de limpieza de codigo para que quede mas presentables y unas cuantas optimizaciones (las cuales incluso han hecho que PirannaFS sea mas limpio y rapido :-) ) y asi es como nacio Norm.
Tradicionalmente, los ORM se han usado para definir a alto nivel los datos, de forma que fuera facil de usar para el programador, pero de esta forma se pierde el control de como se estan guardando (lo cual no es malo, es la mayoria de los casos no es del todo importante), y ademas al hacerlo de una forma generica ralentizando el acceso y termina siendo un cuello de botella y creando problemas en aplicaciones que necesitan un gran rendimiento.
Sin embargo, Norm funciona al reves: en lugar de centrarse en la aplicacion y generar internamente el codigo SQL necesario para acceder a los datos, se centra justamente en estos y en como se accede a ellos en la base de datos y genera el codigo necesario para poder usarlos desde la aplicacion. De esta forma, se puede diseñar a mano codigo SQL optimizado para la aplicacion en concreto teniendo un control total sobre los datos sin tener que escribir todo el glue code necesario para poder usarlo ya que de esto ya se encarga Norm, y ademas genera una API especifica para la aplicacion muy sencilla de usar. Si a esto le añadimos que ademas el codigo SQL no esta embebido dentro del codigo del programa principal como se ha hecho hasta ahora cuando se necesitaba este tipo de optimizaciones sino que se guarda en archivos independientes faciles de mantener y de actualizar sin tocar el codigo del programa principal, no me extraña que al final de la presentacion que hice ayer en las oficinas de Tuenti para Python-Madrid la gente mostrara tanto interes e incluso me diesen ideas para mejorarlo o quisieran colaborar en su desarrollo... :-)
¿Sera posible que por primera vez haya hecho algo que realmente sea util para la gente? ¿Al final sera capaz PirannaFS de sacarme de pobre? :-P
martes, 20 de diciembre de 2011
PirannaFS reloaded...
6 meses han pasado ya desde mi ultima entrada... y con razón. Los examenes me tuvieron al borde de un suspiro, y gracias al proyecto de Gameloft he sabido lo que es un trabajo de verano de 60 horas a la semana (y pensar que yo queria ser un pirata con sus 96 horas...). Luego llego el nuevo curso con un primer cuatrimestre supercargado y faltandome horas por todas partes, asi que dije BASTA: decidi centrarme en los estudios y luego ya veria que haria.
Eso es lo que decidi hacer... otra cosa es que eso fuese lo que hiciese :-D Que no tuviese tiempo para publicar nada no significa que no hiciese avances, y si hice: MUCHOS.
Eso es lo que decidi hacer... otra cosa es que eso fuese lo que hiciese :-D Que no tuviese tiempo para publicar nada no significa que no hiciese avances, y si hice: MUCHOS.
- Para empezar consegui mezclar el codigo de las ramas de PyFilesystem con la de FUSE, con lo que ahora mismo ya tenemos (¡al fin! :-D ) un unico codigo base para las dos. Bien es cierto que la predominante es la de PyFilesystem, pero su orientacion a objetos es mucho mas potente y flexible. Aparte, tambien me va a servir de base para desarrollar las herramientas externas :-)
- Por otra parte, tambien he conseguido avances para convertir los archivos y los directorios en plugins externos, aunque por alguna razon unittest no me funciona con Louie, el motor de eventos, por lo que tendre que mirarlo con mas calma.
- No obstante, este paron forzoso me vino bien para darle vueltas al tema de hacer PirannaFS un sistema de archivos autocontenido, y creo que gracias los VFS de SQLite (y en concreto usando como base este ejemplo para funcionar directamente sin sistema de ficheros) voy a tener la papeleta resuelta, aunque probablemente tendria que sustituir el modulo pysqlite por APSW. APSW tiene la ventaja de que es un wrapper muy fino, siendo las funciones directas con las de SQLite con lo que es mucho mas rapido y ademas obtiene mas rapido todas las mejoras y nuevas funcionalidades de SQLite (incluido el soporte para VFSs) a diferencia de pysqlite, que intenta pythonizarlas. Aparte tambien esta el echo de que APSW no sigue el DB-API 2.0 (aunque su API si es muy parecida), pero al parecer el "anti-ORM" que me he desarrollado con PirannaFS puede resolver la papeleta (a la gente le encanta mi idea de desarrollar funciones y objetos Python a partir de codigo SQL :-D ) y probablemente hasta lo limpie y lo saque como modulo aparte. Luego estaria el tema de como hacer para poder acceder a los plugins, pero eso es otra historia...
- Y aparte, tambien se me han ocurrido otras novedades como son las "extensiones", que basicamente son como los plugins pero a diferencia de estos, estan orientados a "extender" funcionalidad ya existente (en lugar de añadir nueva) y por lo tanto no necesitan tablas propias sino que modifican directamente las ya existentes, por lo que su acceso es mucho mas rapido (me ahorro hacer un join... :-D ).
martes, 19 de abril de 2011
Las gallinas que entran por las que salen
El viernes pasado fue la final de Madrid del concurso, al igual que el jueves tuve el examen de Fundamentos de los Computadores, y dejando de lado que ya se que no tengo perdon de FSM por tardar tanto en comentar el resultado del partido, lo cierto es que he estado bastante liado/agobiado estos dias.
Las noticias buenas, primero que creo que al final despues de 5 años me he quitado al fin la famosa asignatura :-D No se porque razon, pero la electronica se me atraganto sobremanera, y eso teniendo en cuenta que me meti en informatica por culpa de que la electronica se me quedaba pequeña... Y la segunda... Piranna wins!!! :-D Contra todo pronostico y en especial el mio, ¡resulta que PirannaFS ha ganado! :-D Empece el proyecto por hobbie, nada especial, y ademas era muy "friki" y especifico cuando habia otros que estaban mas orientados a la comunidad. Aparte, de los que estuvimos en la final realmente yo habria apostado por los de los demas (cORMoran me parecio bastante practico, e InfantView yo ya le saque alguna que otra utilidad practica...), asi que normal que todos me miraran con cara rara cuando me entro la risa floja cuando me entere que habia ganado porque todavia no me lo creia :-P Pero bueno, no deja de ser ironico que no me cogiese la promocion de la tablet del ABC aprovechando que trabajaba alli y que ahora tenga una Galaxy Tab para sustituir a mi pobre Spica... :-D
En cualquier caso las dos proximas semanas el proyecto va a estar parado debido a que voy a estar estudiando Java para el examen de Orientacion a Objetos (si, a la vejez viruelas, quien lo diria...), y como no puedo estar haciendo una sola cosa, pues voy a aprovechar para aprender Android y desarrollar el cliente en Java de UnHosted todo a la vez. Como dijo el pirata, "la vida es corta pero ancha"... :-D
Ahora las malas, y es que a pesar de ser "un tecnico extraordinario" (palabras literales) me despidieron del trabajo porque no buscaban un perfil tan tecnico sino "alguien mas de gestion o administracion capaz de atender al cliente". En resumen, yo preocupandome siempre de que mi codigo hablara por mi y ahora resulta que lo que hay que hacer si quieres seguir ascendiendo es saber colocar correctamente un lazo rosa para que no se vean las grietas ni se desmorone el invento. Pues mira, ellos se pierden el tener un campeon entre sus tropas. Al final cuando hasta en el trabajo te dicen directa o indirectamente que si quieres desarrollar una carrera puramente tecnica te tienes que ir a Estados Unidos, agua lleva.
Esta claro, no podian pasarme tantas cosas buenas en una semana sin riesgo de provocar un desequilibrio en la constante espacio-tiempo. Maldito karma...
Las noticias buenas, primero que creo que al final despues de 5 años me he quitado al fin la famosa asignatura :-D No se porque razon, pero la electronica se me atraganto sobremanera, y eso teniendo en cuenta que me meti en informatica por culpa de que la electronica se me quedaba pequeña... Y la segunda... Piranna wins!!! :-D Contra todo pronostico y en especial el mio, ¡resulta que PirannaFS ha ganado! :-D Empece el proyecto por hobbie, nada especial, y ademas era muy "friki" y especifico cuando habia otros que estaban mas orientados a la comunidad. Aparte, de los que estuvimos en la final realmente yo habria apostado por los de los demas (cORMoran me parecio bastante practico, e InfantView yo ya le saque alguna que otra utilidad practica...), asi que normal que todos me miraran con cara rara cuando me entro la risa floja cuando me entere que habia ganado porque todavia no me lo creia :-P Pero bueno, no deja de ser ironico que no me cogiese la promocion de la tablet del ABC aprovechando que trabajaba alli y que ahora tenga una Galaxy Tab para sustituir a mi pobre Spica... :-D
En cualquier caso las dos proximas semanas el proyecto va a estar parado debido a que voy a estar estudiando Java para el examen de Orientacion a Objetos (si, a la vejez viruelas, quien lo diria...), y como no puedo estar haciendo una sola cosa, pues voy a aprovechar para aprender Android y desarrollar el cliente en Java de UnHosted todo a la vez. Como dijo el pirata, "la vida es corta pero ancha"... :-D
Ahora las malas, y es que a pesar de ser "un tecnico extraordinario" (palabras literales) me despidieron del trabajo porque no buscaban un perfil tan tecnico sino "alguien mas de gestion o administracion capaz de atender al cliente". En resumen, yo preocupandome siempre de que mi codigo hablara por mi y ahora resulta que lo que hay que hacer si quieres seguir ascendiendo es saber colocar correctamente un lazo rosa para que no se vean las grietas ni se desmorone el invento. Pues mira, ellos se pierden el tener un campeon entre sus tropas. Al final cuando hasta en el trabajo te dicen directa o indirectamente que si quieres desarrollar una carrera puramente tecnica te tienes que ir a Estados Unidos, agua lleva.
Esta claro, no podian pasarme tantas cosas buenas en una semana sin riesgo de provocar un desequilibrio en la constante espacio-tiempo. Maldito karma...
miércoles, 6 de abril de 2011
Fahrenheit 1832
Semanita de aupa llevo, y semanita de aupa me espera. Semanita llevo, porque he "intentado" (no existe una palabra mejor...) mezclar las dos ramas de PirannaFS (FUSE y PyFilesystem) y el repositorio ha acabado como era previsible: apocalipsis post-nuclear y terminar metiendo los archivos a mano de nuevo (con esto ya si que me paso definitivamente a GIT), al hacerlo me he encontrado bugs al prepararlo todo para la integracion (y aqui me veis, un dia antes de terminado el plazo haciendo todavia la memoria) y encima al empezar a hacer las pruebas directamente sobre el disco he descubierto que SQLite es mucho mas lento de lo que pensaba por pura paranoia y voy a tener que configurarlo y optimizarlo muchisimo antes de tener algo usable. Semanita me espera, porque el jueves tengo examen de Fundamentos de los Computadores (y no he estudiado...), el viernes tengo la presentacion del proyecto (y todavia no la he preparado...) y encima me he comprometido a hacer la version Java-Android de UnHosted en lugar de las aburridas, inutiles y nada practicas practicas de POO para el examen de dentro de 3 semanas. Me encanta vivir al limite... :-D
Pero bueno, no todo son buenas noticias, tambien he conseguido sacar tiempo para hacer la memoria del proyecto, y la teneis en la pagina de documentacion. Tambien estoy aprovechando a desarrollar toda la documentacion del proyecto para tenerlo centralizado en algun sitio y que sea usable por otras personas, y una de las cosas mas importantes es la estructura de clases, la cual ademas me ha permitido ver algunos detallitos y hacer algunas optimizaciones (siempre se me ha dado bien la memoria espacial... :-D ).
Vamos a explicar las partes. En primer lugar vemos un conjunto de clases fuera del paquete de PirannaFS a la derecha de este. Son el conjunto de clases encargadas del sistema de plugins, junto con los plugins encargados de los checksums, el log y los links simbolicos (obviamente, todos ellos en la carpeta de plugins... :-D ). Ya dentro de PirannaFS vemos un par de paquetes para las interfaces de FUSE y de PyFilesystem. Obviamente las clases de FUSE estan vacias porque tengo que adaptarlas a la nueva estructura, asi que nos centraremos en la de PyFilesystem. Ahi vemos tres clases: Filesystem, Dir y File, que heredan de sus correspondientes dentro del core, las cuales tienen sus referencias a la base de datos y al dispositivo. Ahora mismo tienen casi toda su funcionalidad dentro a la espera de que se vayan "destilando" al core a medida que reintegre la interfaz de FUSE. Como se ve la estructura por capas es realmente sencilla puesto que he desarrollado el codigo alrededor de las funciones correspondientes a las interfaces (de ahi que casi todo el codigo este ahora mismo dentro de los paquetes FUSE y PyFilesystem) y porque todo el trabajo duro se lo esta llevando la base de datos (de ahi que sea tan lenta...). Luego cuando convierta Dir y File en plugins propios ya veremos que pasa con todo esto... :-P
Y bueno, aparte de eso, tambien estoy pensando si en lugar de acceder a la base de datos directamente no hacerme un controlador independiente... Eso me permitiria varias ventajas, como el poder serializarlo todo para que tenga soporte multihilo (se le lanzan peticiones y ya se encargara de resolverlas cuando pueda), cachear las peticiones para que funcione mas rapido el sistema (si solo accede el al sistema no deberia haber problema de que esten desactualizados) o incluso simplificar el proceso de sacar el codigo SQL a archivos externos y cargarlos al principio incluso por parte de los plugins... Pura poesia... :-D
PD: Fahrenheit 1832 es la temperatura a la que arde el silicio en contacto con el aire, convirtiendose en SiO2. Nunca maldigo mi suerteeeeee, porque yo friki naciiiii... :-P
Pero bueno, no todo son buenas noticias, tambien he conseguido sacar tiempo para hacer la memoria del proyecto, y la teneis en la pagina de documentacion. Tambien estoy aprovechando a desarrollar toda la documentacion del proyecto para tenerlo centralizado en algun sitio y que sea usable por otras personas, y una de las cosas mas importantes es la estructura de clases, la cual ademas me ha permitido ver algunos detallitos y hacer algunas optimizaciones (siempre se me ha dado bien la memoria espacial... :-D ).
Vamos a explicar las partes. En primer lugar vemos un conjunto de clases fuera del paquete de PirannaFS a la derecha de este. Son el conjunto de clases encargadas del sistema de plugins, junto con los plugins encargados de los checksums, el log y los links simbolicos (obviamente, todos ellos en la carpeta de plugins... :-D ). Ya dentro de PirannaFS vemos un par de paquetes para las interfaces de FUSE y de PyFilesystem. Obviamente las clases de FUSE estan vacias porque tengo que adaptarlas a la nueva estructura, asi que nos centraremos en la de PyFilesystem. Ahi vemos tres clases: Filesystem, Dir y File, que heredan de sus correspondientes dentro del core, las cuales tienen sus referencias a la base de datos y al dispositivo. Ahora mismo tienen casi toda su funcionalidad dentro a la espera de que se vayan "destilando" al core a medida que reintegre la interfaz de FUSE. Como se ve la estructura por capas es realmente sencilla puesto que he desarrollado el codigo alrededor de las funciones correspondientes a las interfaces (de ahi que casi todo el codigo este ahora mismo dentro de los paquetes FUSE y PyFilesystem) y porque todo el trabajo duro se lo esta llevando la base de datos (de ahi que sea tan lenta...). Luego cuando convierta Dir y File en plugins propios ya veremos que pasa con todo esto... :-P
Y bueno, aparte de eso, tambien estoy pensando si en lugar de acceder a la base de datos directamente no hacerme un controlador independiente... Eso me permitiria varias ventajas, como el poder serializarlo todo para que tenga soporte multihilo (se le lanzan peticiones y ya se encargara de resolverlas cuando pueda), cachear las peticiones para que funcione mas rapido el sistema (si solo accede el al sistema no deberia haber problema de que esten desactualizados) o incluso simplificar el proceso de sacar el codigo SQL a archivos externos y cargarlos al principio incluso por parte de los plugins... Pura poesia... :-D
PD: Fahrenheit 1832 es la temperatura a la que arde el silicio en contacto con el aire, convirtiendose en SiO2. Nunca maldigo mi suerteeeeee, porque yo friki naciiiii... :-P
miércoles, 30 de marzo de 2011
Minority Report
Pequeña nota aprovechando un pequeño descanso en el curro mientras se configura el Ubuntu que acabo de instalarle: solo decir que debido a lo caotico que se me presenta el mes de abril entre examenes (¿¿¿quien ha sido el que me ha puesto el examen de Fundamentos de los Computadores justo UN DÍA ANTES de la presentación de PirannaFS???), trabajo, presentaciones y memorias, me voy a centrar durante las dos proximas semanas (aparte de a estudiar) a documentar el proyecto tanto rellenando los DocStrings de las funciones como creando diagramas, haciendo la memoria del proyecto y preparando la presentación que tendre en la final de Madrid del dia 15 de Abril. No tengo nada planeado al respecto, asi que debido a la falta de tiempo de hacer algo mas especifico aprovechare a desarrollar toda la documentacion de forma que me valga para todos los frentes que se me han presentado abiertos. Es por eso que de momento la documentacion se encontrara en la forja de Red Iris, donde podreis encontrar absolutamente todo el material relaccionado con PirannaFS (excepto lo publicado en este blog, que se encargan de guardarmelo muy amablemente los chicos de Google... :-D ).
lunes, 21 de marzo de 2011
PirannaFS Reloaded
Dos meses y medio, el ritmo decrece... :-P Lo cierto es que como bien predije este cuatrimestre iba a ser de aupa, y lo ha sido: jornadas de 12 horas, mudanza y media hora mas de transporte... y trabajo para casa los fines de semana. Por suerte hace dos semanas se hizo la presentación de los trenes y no solo la señora Cristina Fernández de Kirchner (para que veais como cotiza el niño... :-D ), sino que encima antes de que se terminara el proyecto conseguí trabajo en Vocento, y tiro oca porque me toca: estoy en todo el centro, tardo la mitad en llegar, el horario es flexible, las horas son ajustadas, el ambiente es agradable, el trabajo es tranquilo... y me pagan un 33% mas. Vamos, que me ha tocado la primitiva :-D Es por eso que despues de varios meses de estress y no dormir no solo vuelvo a tener fuerzas para estudiar en el tren sino que mucho mas importante, vuelvo a tener TIEMPO, y es por eso por lo que en las dos ultimas semanas le he pegado un chute bien fuerte a PirannaFS :-D
Para empezar, finalmente pude probar como seria el sistema usando PyFilesystem, y no hay lugar a dudas: me ha convencido. Dejando de lado que por su filosofia tan pythonica se queda a bastante alto nivel de lo que seria un sistema de archivos normal (el acceso a los sectores no se hace directamente sino a nivel de archivos...) lo cierto es que su uso de excepciones hasta la estenuación lo hace realmente potente y sencillo de programar: adios a comprobar continuamente valores de retorno que no nos atañen, si no nos interesa una excepcion ya habra otro que se encargue. Relax... y una limpieza de codigo y un estilo Zen minimalista increible. ¡Si hasta en algunos casos los comentarios de cabecera ocupan mas que el codigo! :-P
Ademas, este reinicio cual ave Phoenix me ha permitido el encontrar algunos fallos ciertamente molestos y solventar algunas idiosincrasias como el hecho de que la longitud de los chunks empezara en 1 para apuntar siempre al siempre simplemente por ahorrar algunas sumas de vez en cuando, aparte de poder limpiar codigo y encontrar soluciones mas optimas a algunos problemas, lo cual me ha llevado a pensar que al tener ahora un nucleo mas limpio, quizas si sea buena idea el tener tambien una version Python-FUSE del sistema de archivos saltandome algunas capas de abstraccion de PyFilesystem. Al fin y al cabo, el usar excepciones en lugar de retornar valores de error era el paso logico a dar para tener un codigo en condiciones, hoy dia el hacer las cosas al "estilo C", por muy simple, portable y optimo que pudiese ser, es un sin sentido teniendo opciones mas potentes (mismamente C++).
Ahora bien, despues de haberme metido en faena, efectivamente PyFilesystem no es la panacea: todavia esta muy verde e inmaduro, y no esta pensado para desarrollar sistemas de archivos nativos... ni parece que tengan intencion de hacerlo. Al igual que FUSE era famoso porque aparecieron multitud de sistemas de archivos "de juguete" (los sistemas de archivos para acceder a sistemas online son legion) esa filosofia es mucho mas real en PyFilesystem, lo cual tampoco es malo si lo que se pretende es que sea mas facil el desarrollo de sistemas de archivos. Sin embargo esta facilidad lleva implicita cierta abstraccion como es el hecho de acceder a nivel de ficheros (al menos, al ser "file-like objects", la integracion y uso de estos directamente en codigo python externo es directo), y tambien hay algunas decisiones como la ausencia directorio actual y el que los directorios realmente sean sub-sistemas de archivos (logico desde un punto de vista jerarquico-recursivo...) lo hace un poco extraño y dificil de manejar, aparte de que no hay definidas clases neutras desde las que poder heredar de _nada_. Al menos he intentado solucionar estos fallos en mi implementacion de PirannaFS sobre PyFilesystem, asi que cuando lo tenga mas fino y estable los adaptare a la libreria y enviare los parches correspondientes a ver que pasa :-)
Y recuerden niños: no olvidensupervitaminarse y supermineralizarse hacer unidades de test para todo: no veais el subidon de adrenalina que da despues de haber hecho una metamorfosis completa del codigo el no saber por donde empezar a comprobar que todo esta bien, encontrarse perdido dentro del codigo de PyFilesystem unas unidades de test basicas, ver como te dicen exactamente donde estan los fallos (incluso algunos que ni siquiera suponias que podrias llegar a tener, como es la corrupcion de archivos de gran tamaño) e ir resolviendolos uno a uno (a veces mas ;-) ) poquito a poco y pasar de no superar ninguno de los 49 a que solo queden 10 y la mayoria relaccionados con los hilos... :-D
Para empezar, finalmente pude probar como seria el sistema usando PyFilesystem, y no hay lugar a dudas: me ha convencido. Dejando de lado que por su filosofia tan pythonica se queda a bastante alto nivel de lo que seria un sistema de archivos normal (el acceso a los sectores no se hace directamente sino a nivel de archivos...) lo cierto es que su uso de excepciones hasta la estenuación lo hace realmente potente y sencillo de programar: adios a comprobar continuamente valores de retorno que no nos atañen, si no nos interesa una excepcion ya habra otro que se encargue. Relax... y una limpieza de codigo y un estilo Zen minimalista increible. ¡Si hasta en algunos casos los comentarios de cabecera ocupan mas que el codigo! :-P
Ademas, este reinicio cual ave Phoenix me ha permitido el encontrar algunos fallos ciertamente molestos y solventar algunas idiosincrasias como el hecho de que la longitud de los chunks empezara en 1 para apuntar siempre al siempre simplemente por ahorrar algunas sumas de vez en cuando, aparte de poder limpiar codigo y encontrar soluciones mas optimas a algunos problemas, lo cual me ha llevado a pensar que al tener ahora un nucleo mas limpio, quizas si sea buena idea el tener tambien una version Python-FUSE del sistema de archivos saltandome algunas capas de abstraccion de PyFilesystem. Al fin y al cabo, el usar excepciones en lugar de retornar valores de error era el paso logico a dar para tener un codigo en condiciones, hoy dia el hacer las cosas al "estilo C", por muy simple, portable y optimo que pudiese ser, es un sin sentido teniendo opciones mas potentes (mismamente C++).
Ahora bien, despues de haberme metido en faena, efectivamente PyFilesystem no es la panacea: todavia esta muy verde e inmaduro, y no esta pensado para desarrollar sistemas de archivos nativos... ni parece que tengan intencion de hacerlo. Al igual que FUSE era famoso porque aparecieron multitud de sistemas de archivos "de juguete" (los sistemas de archivos para acceder a sistemas online son legion) esa filosofia es mucho mas real en PyFilesystem, lo cual tampoco es malo si lo que se pretende es que sea mas facil el desarrollo de sistemas de archivos. Sin embargo esta facilidad lleva implicita cierta abstraccion como es el hecho de acceder a nivel de ficheros (al menos, al ser "file-like objects", la integracion y uso de estos directamente en codigo python externo es directo), y tambien hay algunas decisiones como la ausencia directorio actual y el que los directorios realmente sean sub-sistemas de archivos (logico desde un punto de vista jerarquico-recursivo...) lo hace un poco extraño y dificil de manejar, aparte de que no hay definidas clases neutras desde las que poder heredar de _nada_. Al menos he intentado solucionar estos fallos en mi implementacion de PirannaFS sobre PyFilesystem, asi que cuando lo tenga mas fino y estable los adaptare a la libreria y enviare los parches correspondientes a ver que pasa :-)
Y recuerden niños: no olviden
domingo, 2 de enero de 2011
Volver a empezar
Casi dos meses hace desde la ultima entrada, pero lo cierto es que han sido dos meses de aupa: presentación en el trabajo, vencimiento de fechas, jornadas maratonianas (entre el miercoles 22 a las 10 de la mañana -tarde, como siempre- y sale el viernes 24 a las 5 de la madrugada...), examenes... y encima, para colmo un antiguo compañero de trabajo ha empezado UnHosted, un proyecto muy interesante y aparte de colaborar con el he participado en el concurso que ha organizado para ponerlo a prueba, asi que el tiempo que le he podido dedicar a PirannaFS ha tendido a 0.
Sin embargo no me he olvidado del proyecto y de hecho ha sido uno de mis propositos de año nuevo (otro de ellos era ganar el concurso de UnHosted... :-D ), asi que aqui estoy intentando retomarlo, y una de las primeras que voy a hacer va a ser olvidarme un poco de la obsesion que coji con las unidades de test. Eso lo hice por estabilizar el codigo y poder publicarlo, pero si por dedicarle tiempo dejo de dedicarselo al proyecto, a perder la ilusion de hacer algo y, lo mas importante, dejo de divertirme, entonces ya no merece la pena.
Precisamente por eso voy a retomar el desarrollo puro y duro, y debido a lo potente que he visto en estos dos meses que es PyFilesystem (que no haya programado no significa que no me haya documentado, y el estar inscrito a su lista de correo ayuda... :-D ) lo primero que voy a hacer va a ser modificar PirannaFS para que sea una libreria que pueda servir como base para crear una interfaz python-FUSE como hasta ahora y otra nueva interfaz PyFilesystem. Asi, aparte de ser compatible tanto con un sistema que ya es funcional como con otro bastante prometedor pero todavia en desarrollo, me permitira luego desarrollar las utilidades de apoyo sin necesidad de lidiar directamente con el sistema de archivos.
Asi que dejando de lado estresses varios y que se presenta un cuatrimestre movidito, dejemos que de comienzo la magia... :-D
Sin embargo no me he olvidado del proyecto y de hecho ha sido uno de mis propositos de año nuevo (otro de ellos era ganar el concurso de UnHosted... :-D ), asi que aqui estoy intentando retomarlo, y una de las primeras que voy a hacer va a ser olvidarme un poco de la obsesion que coji con las unidades de test. Eso lo hice por estabilizar el codigo y poder publicarlo, pero si por dedicarle tiempo dejo de dedicarselo al proyecto, a perder la ilusion de hacer algo y, lo mas importante, dejo de divertirme, entonces ya no merece la pena.
Precisamente por eso voy a retomar el desarrollo puro y duro, y debido a lo potente que he visto en estos dos meses que es PyFilesystem (que no haya programado no significa que no me haya documentado, y el estar inscrito a su lista de correo ayuda... :-D ) lo primero que voy a hacer va a ser modificar PirannaFS para que sea una libreria que pueda servir como base para crear una interfaz python-FUSE como hasta ahora y otra nueva interfaz PyFilesystem. Asi, aparte de ser compatible tanto con un sistema que ya es funcional como con otro bastante prometedor pero todavia en desarrollo, me permitira luego desarrollar las utilidades de apoyo sin necesidad de lidiar directamente con el sistema de archivos.
Asi que dejando de lado estresses varios y que se presenta un cuatrimestre movidito, dejemos que de comienzo la magia... :-D
jueves, 4 de noviembre de 2010
Horror, espanto, pavor (2ª parte... y media)
Si antes me quejo de lo malo que es Python-FUSE para depurarlo y para hacer unidades de test, antes me encuentro con otro con el mismo problema :-P
Bindings de FUSE para python hay varios (eso ya lo sabia) y escogí Python-FUSE aparte de por ser el mas famoso y el "oficial" (o al menos es del unico que hay documentación en la pagina de FUSE) porque ya habia paquetes en Ubuntu. Lo que yo no sabia es que otra de las alternativas (fusePy) tenia paquetes dentro de la CheeseShop (si, asi se llamaba hasta hace poco el repositorio de paquetes oficial de Python antes de "profesionalizarse"), y por lo que parece esta alternativa no solo es mas "pythonica" que Python-FUSE sino que ademas es mas completa respecto a funcionalidad de bajo nivel, y para muestra un boton:
Si con esto no es mas facil el hacer las unidades de test sin necesidad de hackeos que baje FSM y lo vea. El problema viene entonces de tener que rehacer PirannaFS usando como base estos nuevos bindings o si hacer PirannaFS compatible con los dos, asi que quizas lo mejor sea estudiar previamente si realmente sera rentable o no, y leyendose el codigo no creo que baste. No se, otra alternativa podria ser el hacerme algun otro sistema de archivos (¿otro mas?), pero FullFAT no tiene bindings en Python (aparte de que queria usar la libreria para "entrenarme" para el paso a C++ de PirannaFS) y no he encontrado nada de bindings de Ext3 en Python, aunque sin lugar a dudas estaria interesante el hacerse una implementacion completa de Ext3 en Python (para chulo, yo :-P ). ¿Vosotros que opinais? ¿Reciclaje? ¿Reimplementación? ¿Mirar para otro lado y hacer como que no he visto esto? :-P
Al menos, de regalo me he encuentrado que CUSE, el hermano pequeño y marginado de FUSE para desarrollar drivers de dispositivo en espacio de usuario (el tio que lo desarrolló se dio cuenta que solo hacia falta añadir dos IOCTLs a FUSE para tener soporte para poder escribir drivers genericos fuera del kernel...) y del cual a casi nadie parece importarle (o al menos no he visto ningun proyecto importante o ni siquiera una pagina con documentacion)... ¡¡¡me encuentro con que han desarrollado unos bindings para Python!!! :-D
Quizas empezase PirannaFS porque CaOS (mi propio sistema operativo que llevo diseñando desde que tenia 10 años) se me hacia muy grande, pero parece que todo el universo se esta conspirando en que lo saque adelante... :-)
Bindings de FUSE para python hay varios (eso ya lo sabia) y escogí Python-FUSE aparte de por ser el mas famoso y el "oficial" (o al menos es del unico que hay documentación en la pagina de FUSE) porque ya habia paquetes en Ubuntu. Lo que yo no sabia es que otra de las alternativas (fusePy) tenia paquetes dentro de la CheeseShop (si, asi se llamaba hasta hace poco el repositorio de paquetes oficial de Python antes de "profesionalizarse"), y por lo que parece esta alternativa no solo es mas "pythonica" que Python-FUSE sino que ademas es mas completa respecto a funcionalidad de bajo nivel, y para muestra un boton:
>>> from fs.memoryfs import MemoryFS
>>> from fs.expose import fuse
>>> fs = MemoryFS()
>>> mp = fuse.mount(fs,"/mnt/my-memory-fs")
>>> mp.path
'/mnt/my-memory-fs'
>>> mp.unmount()Si con esto no es mas facil el hacer las unidades de test sin necesidad de hackeos que baje FSM y lo vea. El problema viene entonces de tener que rehacer PirannaFS usando como base estos nuevos bindings o si hacer PirannaFS compatible con los dos, asi que quizas lo mejor sea estudiar previamente si realmente sera rentable o no, y leyendose el codigo no creo que baste. No se, otra alternativa podria ser el hacerme algun otro sistema de archivos (¿otro mas?), pero FullFAT no tiene bindings en Python (aparte de que queria usar la libreria para "entrenarme" para el paso a C++ de PirannaFS) y no he encontrado nada de bindings de Ext3 en Python, aunque sin lugar a dudas estaria interesante el hacerse una implementacion completa de Ext3 en Python (para chulo, yo :-P ). ¿Vosotros que opinais? ¿Reciclaje? ¿Reimplementación? ¿Mirar para otro lado y hacer como que no he visto esto? :-P
Al menos, de regalo me he encuentrado que CUSE, el hermano pequeño y marginado de FUSE para desarrollar drivers de dispositivo en espacio de usuario (el tio que lo desarrolló se dio cuenta que solo hacia falta añadir dos IOCTLs a FUSE para tener soporte para poder escribir drivers genericos fuera del kernel...) y del cual a casi nadie parece importarle (o al menos no he visto ningun proyecto importante o ni siquiera una pagina con documentacion)... ¡¡¡me encuentro con que han desarrollado unos bindings para Python!!! :-D
Quizas empezase PirannaFS porque CaOS (mi propio sistema operativo que llevo diseñando desde que tenia 10 años) se me hacia muy grande, pero parece que todo el universo se esta conspirando en que lo saque adelante... :-)
Horror, espanto, pavor (2ª parte)
Nota mental: plantearme hacer de proyecto para el año que viene o una maquina del tiempo o un replicador de cuerpos o diseñar una droga que permita alterar la percepcion del tiempo sin los efectos secundarios de la cocaina y que pegue mas fuerte por las mañanas que un cutrebull del Lidl... la falta de tiempo es acuciante, y ahora que se acercan los examenes creo que la mejor opcion va a ser dedicarme a la meditacion tibetana, a ver si asi consigo concentrarme...
Quejas varias aparte, pequeño resumen de en lo que he estadoperdiendo el tiempo ocupado las ultimas semanas:
Para empezar, como ya puse en mi anterior post he empezado a realizar baterias de test para el sistema de archivos. Por un lado me hacia falta aprender a hacerlas, porque es algo que siempre he estado dejando de lado, y aunque no ha sido pan comido lo cierto es que no ha sido tan dificil como pensaba, pero la razon mas importante para hacerlo era el tema de difundir el proyecto, porque siendo un proyecto tan complejo y "delicado" (nadie quiere poner sus datos en peligro, y bastante ya me esta dando por [autocensurado] el Ext4 en el Ubuntu del trabajo poniendose en modo solo lectura cuando le doy un poco de caña por un error del kernel respecto a los timeout en discos lentos y antiguos... ¬¬) se necesitaba algun metodo para controlar la evolucion del proyecto y sobretodo para evitar regresiones. Y si, tengo que reconocer una cosa: funcionan, y mucho mejor de lo que pensaba. Tuve bastantes problemas a la hora de realizarlo por la forma en que esta diseñado python-fuse (no se si seria mejor arreglarlo o rehacerlo de cero...) pero lo cierto es que consegui que funcionara, y cuando despues de arreglar unos pequeños fallos que me encontre en la implementacion vi esto
realmente se me puso una sonrisa de oreja a oreja :-D
Pero mas interesante que esto fue cuando leyendome las especificaciones del OpenGroup vi algo que me dejo totalmente desconcertado: en readdir especifica que los famosos . y .. solo deben ser mostrados si el sistema de archivos en cuestion tiene referencias explicitas a ellos, cosa que no es el caso (y de hecho siempre me ha parecido una tonteria si ya sabemos tanto cual es el directorio actual como cual es el padre). Sin embargo en todos los ejemplos y documentacion que he visto los ponian explicitamente a mano. ¿Que hacer, saltarse el estandar, o seguirlo fielmente a pesar de que luego al listar el directorio se vea raro? Al final, como no sabia si la lista de correo del concurso podria servir para esto (apenas acababa de comenzar a usarse y esto era una pregunta muy especifica y hasta cierto punto yo entendia que seria cierta ventaja si alguien me ayudaba) asi que pregunte a mis colegas de AlcorconWireless, y como suele suceder en estas cosas mi amigo Dani (que al final le voy a tener que meter en los titulos de credito por toda la ayuda que me esta dando :-P ) dio con la mejor solucion:
Esa es la diferencia entre un ingeniero y uno que presume de serlo teniendo apenas la mitad de los creditos aprobados. Simplemente brillante.
En fin, la cuestion es que aunque apenas tengo tiempo sigo sacando las cosas adelante, solo espero que con el trajin que llevo no termine implosionando por el estress :-P Espero a ver si para el proximo post ya tengo terminados las unidades de test, porque iba a haber hecho una release especial para Halloween y lo cierto al final ha sido que hacia una semana que no encendia el PC de casa... :-P
Quejas varias aparte, pequeño resumen de en lo que he estado
Para empezar, como ya puse en mi anterior post he empezado a realizar baterias de test para el sistema de archivos. Por un lado me hacia falta aprender a hacerlas, porque es algo que siempre he estado dejando de lado, y aunque no ha sido pan comido lo cierto es que no ha sido tan dificil como pensaba, pero la razon mas importante para hacerlo era el tema de difundir el proyecto, porque siendo un proyecto tan complejo y "delicado" (nadie quiere poner sus datos en peligro, y bastante ya me esta dando por [autocensurado] el Ext4 en el Ubuntu del trabajo poniendose en modo solo lectura cuando le doy un poco de caña por un error del kernel respecto a los timeout en discos lentos y antiguos... ¬¬) se necesitaba algun metodo para controlar la evolucion del proyecto y sobretodo para evitar regresiones. Y si, tengo que reconocer una cosa: funcionan, y mucho mejor de lo que pensaba. Tuve bastantes problemas a la hora de realizarlo por la forma en que esta diseñado python-fuse (no se si seria mejor arreglarlo o rehacerlo de cero...) pero lo cierto es que consegui que funcionara, y cuando despues de arreglar unos pequeños fallos que me encontre en la implementacion vi esto
[piranna@Tontodelculo:~/Proyectos/FUSE/PirannaFS/src]
> cat ../test/error.log
...............
----------------------------------------------------------------------
Ran 15 tests in 4.176s
OKrealmente se me puso una sonrisa de oreja a oreja :-D
Pero mas interesante que esto fue cuando leyendome las especificaciones del OpenGroup vi algo que me dejo totalmente desconcertado: en readdir especifica que los famosos . y .. solo deben ser mostrados si el sistema de archivos en cuestion tiene referencias explicitas a ellos, cosa que no es el caso (y de hecho siempre me ha parecido una tonteria si ya sabemos tanto cual es el directorio actual como cual es el padre). Sin embargo en todos los ejemplos y documentacion que he visto los ponian explicitamente a mano. ¿Que hacer, saltarse el estandar, o seguirlo fielmente a pesar de que luego al listar el directorio se vea raro? Al final, como no sabia si la lista de correo del concurso podria servir para esto (apenas acababa de comenzar a usarse y esto era una pregunta muy especifica y hasta cierto punto yo entendia que seria cierta ventaja si alguien me ayudaba) asi que pregunte a mis colegas de AlcorconWireless, y como suele suceder en estas cosas mi amigo Dani (que al final le voy a tener que meter en los titulos de credito por toda la ayuda que me esta dando :-P ) dio con la mejor solucion:
mas friki.. activa una opción para verlos o para no verlos.. jajajaaja
Esa es la diferencia entre un ingeniero y uno que presume de serlo teniendo apenas la mitad de los creditos aprobados. Simplemente brillante.
En fin, la cuestion es que aunque apenas tengo tiempo sigo sacando las cosas adelante, solo espero que con el trajin que llevo no termine implosionando por el estress :-P Espero a ver si para el proximo post ya tengo terminados las unidades de test, porque iba a haber hecho una release especial para Halloween y lo cierto al final ha sido que hacia una semana que no encendia el PC de casa... :-P
martes, 19 de octubre de 2010
Horror, espanto, pavor
Acabo de darme cuenta de porque casi nadie hace baterías de test de casi nada, y no es porque no lo enseñan en la universidad... Acabo de hacerme la batería de test de la función ftruncate (es en la que mas modificaciones he hecho ultimamente con las optimizaciones. Ademas, por algun sitio tenia que empezar...) siguiendo las indicaciones de funcionalidad y errores de OpenGroup y me ocupa 254 lineas... y eso que solo he comentado lo que hace cada test, que ahora me toca programarlo :-/ Ahora bien, con la paliza que me voy a pegar, ¿que deberia hacer, acceder a las funciones a bajo nivel, o hacerlo rollo shell script y que ya que me pego la paliza con los test al menos que sirva para que otros no tengan que implementarselos tambien?
Y en plan recursivo... ¿deberia hacer una bateria de test para la bateria de test para testear que la bateria de test testea correctamente? X-D
Y en plan recursivo... ¿deberia hacer una bateria de test para la bateria de test para testear que la bateria de test testea correctamente? X-D
domingo, 17 de octubre de 2010
[0.2.3] Checksums de Octubre
Casi 20 dias despues... nueva release :-D
Este mes ha sido de aúpa, entre el trabajo y la demostración de este miércoles (que FSM nos coja confesaos...), los estudios (de los cuales todavía no tengo todos los apuntes), los compromisos sociales (aunque algunos han merecido la pena... aunque podrian haberlo merecido mas :-P ) y que los [auto-censurado] checksums se me habian atragantado no he parado quieto, pero bueno, tal y como dijo Mao "una revolución a la vez" al final esta saliendo todo adelante :-D
En primer lugar estaba el tema de los plugins. Los checksums no aportaban simplemente funcionalidad no existente como pasaba con los symlinks sino que trabajaban directamente con los datos, por lo que ya no se podia usar un simple mapeo como antes sino que habia que empezar a desarrollar el sistema de plugins, y a ser posible de una forma un poco mas consistente que como lo habia hecho antes. Por suerte fue facil y ademas el codigo ha quedado bastante limpio, pero tengo la sospecha de que en el futuro voy a tener que hacerle profundos cambios para darle mas potencia y versatilidad (conflictos entre modulos es lo primero que se me viene a la cabeza, luego vereis porque).
Pero el principal problema que tenia con los checksums (y que no identifique hasta hace poco) no estaba relaccionado directamente con ellos, sino que mas bien era un pequeño fallo de diseño (mas bien de falta de planificación) que tuve cuando desarrolle el codigo de escritura y modificación de los archivos (el cual en su momento ya me dio bastante guerra hasta el punto de tener que modificar el diseño de la base de datos tres veces...). Este fallo consistia por un lado que accedia desde distintos puntos del codigo directamente a las funciones DB.Split_Chunks y a LL.Write, con lo que a la hora de generar los eventos para los plugins tendria que generarlos desde multitud de sitios distintos. Sin embargo su funcionalidad era muy parecida y de hecho el codigo era casi el mismo en muchos sitios (como ya indique en mi anterior post entre DB.truncate y DB.Split_Chunks), asi que finalmente he conseguido encarrilar a todo el ganado a través de una nueva función (File.__Split_Chunks) que se encarga efectivamente de llamar a DB.Split_Chunks y de generar el evento correspondiente en caso de que haya producido alguna división.
Al menos todo este follón me ha servido para varias cosas: en primer lugar, una revisión a fondo del código de los archivos, de la base de datos y del acceso a bajo nivel (este al fin es una clase y es instanciada en FileSystem, con lo que ya no abrirá y cerrara el dispositivo en cada llamada. La ventaja es que el acceso es mucho mas rápido, el inconveniente que usara los buffers de archivo del sistema y no escribirá los datos directamente a disco y todavía no estoy usando las transacciones, que es justo una de las razones por las que decidí usar un motor de bases de datos, para aprovechar las que ya tiene... :-/ ). Esta revisión me ha permitido aplicarle muchas mejoras menores y reutilizar mucho código duplicado, con lo que ahora el tamaño y las posibilidades de error son menores, pero sobretodo he quitado "inteligencia" a la base de datos (ahora solo ejecuta sentencias SQL, apenas toma decisiones por si misma aunque lo cierto es que se podría "estupidizar" aun mas) y he eliminado la notificación de eventos desde la base de datos y el acceso a bajo nivel, con lo que por un lado permite mayor control de quien envía realmente los eventos (todo se esta perfilando a que la comunicación entre los plugins va a ser realmente sencilla... :-) ) y también permite mayor portabilidad en el futuro a otros motores de bases de datos o sistemas de almacenamiento o incluso a sacar el código SQL a archivos externos y que los parsee en el arranque en lugar de estar directamente dentro del código Python (esta idea la tengo desde hace tiempo, pero aunque permitiría un mejor mantenimiento al poder tenerlo aislado y que sea mas fácil procesarlo con un editor de texto con coloreado de sintaxis -me encantan :-D - todavía no me he planteado en serio el realizarlo porque consumiría mas memoria y seria un poco mas lento... :-/ )
Ademas todos estos cambios me han hecho replantearme en serio la necesidad de hacer modulos de prueba, por lo que voy a empezar a usar PyUnit, que es el estandar en Python. Nunca he desarrollado ninguno y ademas siempre he sido reaccio a hacerlos (si funciona, ¿para que comprobarlo?) pero un proyecto tan complejo como este lo necesita. Por suerte hace tiempo cuando estaba buscando los codigos de error de los sistemas de archivos tratando de averiguar porque fallaba me encontre con esta pagina que contiene la definición de todas las funciones UNIX con sus parametros, errores y limitaciones, con lo que me vendra de perlas para desarrollar los modulos de test (espero que no me pidan comprar una licencia de POSIX o que Linux Tordvalds me preste la suya... :-D ). Tambien aprovechare a documentar todo el codigo con vistas a liberar publicamente la version 0.3 a ver si se apunta alguien a echarme una mano, y tambien aprovechare a cambiar la filosofia de la API, ya que hasta hace poco (bendito trabajo que tambien lo estoy haciendo en Python y me permite aprender de forma intensiva... :-D ) no entendia correctamente uno de los aspectos mas extraños del lenguaje: en Python no hay metodos o atributos privados, todo es publico. Sin embargo por convenio los atributos y metodos que empiezan con un guión bajo (_) no se muestran en el completado de sintaxis, aunque se sigue podiendo acceder normalmente a ellos. Aparte tambien estan los que empiezan por dos guiones bajos (__) que aqui si el lenguaje los considera como atributos especiales y su firma es distinta, haciendo por tanto que sea mucho mas dificil acceder a ellos. Hasta ahora solo usaba este ultimo metodo para emular los atributos privados, pero realmente era un engorro cuando me encontraba con que queria acceder a algo que habia ocultado demasiado hasta que descubri en que se basaba esta diferencia: la filosofia en Python es la confianza en el programador, por lo tanto no tiene sentido pensar en atributos publicos, protegidos y privados, sino en mostrar (normal), no mostrar (_) y ocultar (__), teniendo en cuenta por ambas partes que si quieres acceder a algun sitio siempre vas a poder pero que necesitas tener buenas razones para ello (por ejemplo, en los debuggers). Despues de tanto tiempo con C++ cuesta acostumbrarse, pero la posibilidad de ver el codigo de los demas para ver que es lo que esta haciendo realmente es de gran ayuda... :-D
Y bueno, ese es el toston de hoy. Espero que cuando este aprendiendo a usar las unidades de test y documentando el codigo no me encuentre con demasiados problemas como hasta ahora, porque entonces esto va a parecer la biblia... :-P Por el momento para mi desgracia acabo de descubrir que ZFS si tiene bloques de tamaño variable (lo que yo creia que era una feature exclusivamente mia... ¬¬) pero por otro lado tambien he descubierto que su algoritmo de compresion tiene una implementación en Python, asi que no hay mal que por bien no venga... :-D
Este mes ha sido de aúpa, entre el trabajo y la demostración de este miércoles (que FSM nos coja confesaos...), los estudios (de los cuales todavía no tengo todos los apuntes), los compromisos sociales (aunque algunos han merecido la pena... aunque podrian haberlo merecido mas :-P ) y que los [auto-censurado] checksums se me habian atragantado no he parado quieto, pero bueno, tal y como dijo Mao "una revolución a la vez" al final esta saliendo todo adelante :-D
En primer lugar estaba el tema de los plugins. Los checksums no aportaban simplemente funcionalidad no existente como pasaba con los symlinks sino que trabajaban directamente con los datos, por lo que ya no se podia usar un simple mapeo como antes sino que habia que empezar a desarrollar el sistema de plugins, y a ser posible de una forma un poco mas consistente que como lo habia hecho antes. Por suerte fue facil y ademas el codigo ha quedado bastante limpio, pero tengo la sospecha de que en el futuro voy a tener que hacerle profundos cambios para darle mas potencia y versatilidad (conflictos entre modulos es lo primero que se me viene a la cabeza, luego vereis porque).
Pero el principal problema que tenia con los checksums (y que no identifique hasta hace poco) no estaba relaccionado directamente con ellos, sino que mas bien era un pequeño fallo de diseño (mas bien de falta de planificación) que tuve cuando desarrolle el codigo de escritura y modificación de los archivos (el cual en su momento ya me dio bastante guerra hasta el punto de tener que modificar el diseño de la base de datos tres veces...). Este fallo consistia por un lado que accedia desde distintos puntos del codigo directamente a las funciones DB.Split_Chunks y a LL.Write, con lo que a la hora de generar los eventos para los plugins tendria que generarlos desde multitud de sitios distintos. Sin embargo su funcionalidad era muy parecida y de hecho el codigo era casi el mismo en muchos sitios (como ya indique en mi anterior post entre DB.truncate y DB.Split_Chunks), asi que finalmente he conseguido encarrilar a todo el ganado a través de una nueva función (File.__Split_Chunks) que se encarga efectivamente de llamar a DB.Split_Chunks y de generar el evento correspondiente en caso de que haya producido alguna división.
Al menos todo este follón me ha servido para varias cosas: en primer lugar, una revisión a fondo del código de los archivos, de la base de datos y del acceso a bajo nivel (este al fin es una clase y es instanciada en FileSystem, con lo que ya no abrirá y cerrara el dispositivo en cada llamada. La ventaja es que el acceso es mucho mas rápido, el inconveniente que usara los buffers de archivo del sistema y no escribirá los datos directamente a disco y todavía no estoy usando las transacciones, que es justo una de las razones por las que decidí usar un motor de bases de datos, para aprovechar las que ya tiene... :-/ ). Esta revisión me ha permitido aplicarle muchas mejoras menores y reutilizar mucho código duplicado, con lo que ahora el tamaño y las posibilidades de error son menores, pero sobretodo he quitado "inteligencia" a la base de datos (ahora solo ejecuta sentencias SQL, apenas toma decisiones por si misma aunque lo cierto es que se podría "estupidizar" aun mas) y he eliminado la notificación de eventos desde la base de datos y el acceso a bajo nivel, con lo que por un lado permite mayor control de quien envía realmente los eventos (todo se esta perfilando a que la comunicación entre los plugins va a ser realmente sencilla... :-) ) y también permite mayor portabilidad en el futuro a otros motores de bases de datos o sistemas de almacenamiento o incluso a sacar el código SQL a archivos externos y que los parsee en el arranque en lugar de estar directamente dentro del código Python (esta idea la tengo desde hace tiempo, pero aunque permitiría un mejor mantenimiento al poder tenerlo aislado y que sea mas fácil procesarlo con un editor de texto con coloreado de sintaxis -me encantan :-D - todavía no me he planteado en serio el realizarlo porque consumiría mas memoria y seria un poco mas lento... :-/ )
Ademas todos estos cambios me han hecho replantearme en serio la necesidad de hacer modulos de prueba, por lo que voy a empezar a usar PyUnit, que es el estandar en Python. Nunca he desarrollado ninguno y ademas siempre he sido reaccio a hacerlos (si funciona, ¿para que comprobarlo?) pero un proyecto tan complejo como este lo necesita. Por suerte hace tiempo cuando estaba buscando los codigos de error de los sistemas de archivos tratando de averiguar porque fallaba me encontre con esta pagina que contiene la definición de todas las funciones UNIX con sus parametros, errores y limitaciones, con lo que me vendra de perlas para desarrollar los modulos de test (espero que no me pidan comprar una licencia de POSIX o que Linux Tordvalds me preste la suya... :-D ). Tambien aprovechare a documentar todo el codigo con vistas a liberar publicamente la version 0.3 a ver si se apunta alguien a echarme una mano, y tambien aprovechare a cambiar la filosofia de la API, ya que hasta hace poco (bendito trabajo que tambien lo estoy haciendo en Python y me permite aprender de forma intensiva... :-D ) no entendia correctamente uno de los aspectos mas extraños del lenguaje: en Python no hay metodos o atributos privados, todo es publico. Sin embargo por convenio los atributos y metodos que empiezan con un guión bajo (_) no se muestran en el completado de sintaxis, aunque se sigue podiendo acceder normalmente a ellos. Aparte tambien estan los que empiezan por dos guiones bajos (__) que aqui si el lenguaje los considera como atributos especiales y su firma es distinta, haciendo por tanto que sea mucho mas dificil acceder a ellos. Hasta ahora solo usaba este ultimo metodo para emular los atributos privados, pero realmente era un engorro cuando me encontraba con que queria acceder a algo que habia ocultado demasiado hasta que descubri en que se basaba esta diferencia: la filosofia en Python es la confianza en el programador, por lo tanto no tiene sentido pensar en atributos publicos, protegidos y privados, sino en mostrar (normal), no mostrar (_) y ocultar (__), teniendo en cuenta por ambas partes que si quieres acceder a algun sitio siempre vas a poder pero que necesitas tener buenas razones para ello (por ejemplo, en los debuggers). Despues de tanto tiempo con C++ cuesta acostumbrarse, pero la posibilidad de ver el codigo de los demas para ver que es lo que esta haciendo realmente es de gran ayuda... :-D
Y bueno, ese es el toston de hoy. Espero que cuando este aprendiendo a usar las unidades de test y documentando el codigo no me encuentre con demasiados problemas como hasta ahora, porque entonces esto va a parecer la biblia... :-P Por el momento para mi desgracia acabo de descubrir que ZFS si tiene bloques de tamaño variable (lo que yo creia que era una feature exclusivamente mia... ¬¬) pero por otro lado tambien he descubierto que su algoritmo de compresion tiene una implementación en Python, asi que no hay mal que por bien no venga... :-D
Published with Blogger-droid v1.6.2
domingo, 3 de octubre de 2010
Proyecto Brainstorm
Como habréis podido ver hace días que no escribo por aquí y sin embargo en el svn ha habido muchos cambios... Esto es debido por un lado a que las modificaciones en el core para que acepte el lanzamiento de eventos para los plugins esta siendo mas complicado de lo que parecía debido a que hay que pensar en como aislar correctamente cada una de las partes (hasta ahora no tenia problemas, pero el plugin de checksums funciona a muy bajo nivel y además recibe eventos de distintas partes del código). Sin embargo estos replanteamientos están permitiendo una mayor independencia entre cada una de las partes y además me esta permitiendo el optimizar y documentar código bastante antiguo (en concreto estoy rompiéndome la cabeza para que DB.truncate utilice por debajo a DB.Split_Chunks), así que estoy matando tres pájaros de un tiro :-)
Pero por otro lado también he estado aprovechando el tiempo, y el sistema de plugins ya esta bastante maduro. El sistema me ha quedado bastante escueto y portable, por lo que se podría utilizar en otros sistemas que precisen de un sistema de plugins, pero aunque ya haya otros sistemas de plugins para python (y algunos ya se me han adelantado en la idea de convertirlos en sistema "oficial") lo cierto es que no he visto ninguno que tenga algún mecanismo de control de dependencias entre plugins, y aunque creía que iba a ser mas complicado lo cierto es que al final ha sido casi obvio: al cargar el modulo obtenemos las clases de los plugins y vemos cuales son sus dependencias. Si no están todas disponibles dejamos el plugin pendiente, y si lo están entonces lo cargamos y comprobamos entre los pendientes si para alguno de ellos ha cambiado la situación. Simple, fácil y para toda la familia :-D
Es por esto por lo que todavía no le estoy dando mucha popularidad al sistema ya que quiero tenerlo bien fino antes de abrirlo al publico (sobretodo por el tema de los plugins que se meten muy adentro del funcionamiento del sistema), pero probablemente para la versión 0.3 ya haga un llamamiento publico buscando ideas y colaboradores (y si, prometo que intentare poner al día y en la web cuales son los checkpoints para cada versión...). Sin embargo precisamente por esto he estado actualizando (y limpiando) el diagrama de la estructura de tablas mas acorde a como se esta perfilando el sistema ahora que empiezan a funcionar los plugins (mi idea era implementarlo después de la versión 1.0, pero con motivo del concurso y de la "participación de la comunidad" he tenido que cambiar las fechas para hacerlo mas accesible) y este es el resultado:
Como podéis ver, arriba a la izquierda tenemos el core, ya implementado. He agrupado lo que correspondería al plugin de directorios y al de archivos porque aunque por el momento no tenga pensado implementarlos como modulos externos, lo cierto es que cada vez me esta tentando mas la idea (¡Mama mama, sin directorios! ¡Mama mama, sin archivos! ¡Mama mama, sin datos! X-D). Luego en el siguiente nivel tenemos los modulos de implementación que como dije anteriormente son dependientes de los elementos del core, y por ultimo tenemos los de valor añadido, en los cuales he puesto el ACL y el log (antes los tenia como de implementación) debido a que no son dependientes directos del core. También tengo aquí a un nuevo vecino en el barrio, xattrs (atributos extendidos), que aunque si es dependiente del core lo cierto es que no depende de sus claves únicas. Además, realmente voy a implementar los atributos extendidos para completar la funcionalidad del sistema de archivos y porque va a ser igual de sencillo que los symlinks (al igual que estos, se podría hacer con un mapeo directo de funciones) ya que a titulo personal, me parece una solución mucho mejor el usar algún tipo de estructura como las tablas id3 y exif, no un simple clave-valor que no da ninguna idea de cuales datos faltan por rellenar (lo admito, estoy obsesionado con los tags de los mp3s en el iTunes hasta el punto de que no solo relleno todos los campos de autor/album/disco/pista/titulo para tenerlos bien organizados sino que le meto dentro a los archivos todas las imágenes del album e incluso la letra de las canciones... :-P). Sin embargo también tengo que reconocer que aunque no son muy usados (al menos son unos completos desconocidos para el usuario medio, y para mi hasta hace poco), realmente pueden ser muy potentes y en un sistema de archivos "tradicional" puede ser usado para implementar un ACL y aumentar el nivel de seguridad, por ejemplo. En cualquier caso, para todo lo que se pueden usar los atributos extendidos un sistema dedicado puede cumplir su tarea mucho mejor, pero las estructuras en los sistemas de archivos tradicionales son demasiado fijas como para añadir este tipo de funcionalidades. Por eso la flexibilidad que ofrecen las bases de datos en estos casos es justo una de las razones que me impulsaron a usar una como base para diseñar el sistema de archivos.
Pero este pequeño by-pass con replanteamiento de puntos de vista incluido también me esta permitiendo el tener tiempo para pensar sobre nuevos modulos, plugins y funciones que añadir al sistema, y parte del merito se lo tengo que dar a mi buena amiga Jennifer, una completa n00b para estas cosas (bastante que la conseguí sacar del lado oscuro y que empezara a usar Linux... :-P) pero que sin embargo su punto de vista como usuario raso me ha sido bastante útil (¡gracias! :-D ).
Una de las ideas que me dio fue el implementar algún sistema de búsqueda avanzada en situaciones limite, del estilo "he buscado la foto del garito aquel en la playa en que estuve desfasando con mis amigas en la que salia guapísima, pero no me acuerdo si es de este año o del anterior y no se si las he borrado o que porque no las encuentro" (nota: aunque no haya dicho nada, casi desde que empecé el proyecto en el diagrama arriba a la derecha hay un modulito muy majo llamado "unlinks"... Si, he pensado en todo, también en otro llamado "purge" que no sale ;-) ). "Además, no quiero que salgan las fotos del tío con el que me enrolle esa noche no sea que entre mi novia en un momento inoportuno cuando este buscando la foto" (a esto ultimo lo llamo yo "ganas de fastidiarme", solo que no con estas palabras...). Al leer esto algunos pensaran que eso es imposible, y otros pensaran que quizás SpotLight o Beagle ya lo hacen (realmente esta idea suya les correspondería mas a unas aplicaciones de alto nivel como ellos que a un sistema de archivos, pero un poco de ayuda por debajo les facilitaría mucho la tarea al igual de lo que podría ocurrir si combinásemos ZFS con TimeMachine... :-) ). Lo cierto es que SpotLight es buenísimo (Beagle nunca lo he usado porque siempre lo desinstalaba ya que mis maquinas con Linux nunca han sido lo suficientemente potentes como para encima tener un proceso accediendo al disco todo el rato...) pero nunca he visto que llegara a un nivel de precisión quirúrgica tan avanzado (quizás lanzandolo desde linea de comandos y procesando una consulta muy elaborada, pero si fuera así de fácil habría un montón de artículos escritos en internet al respecto y lo cierto es que no he oído nada). Yo tengo que ser sincero: es muy complicado, pero no imposible. Aquí el mayor problema depende de la adquisición de los metadatos (día-noche, fechas contextualizadas, reconocimiento de caras...) pero si se tienen y están bien organizados, el problema se reduciría a una simple búsqueda en la base de datos. No diré que lo vaya a implementar... pero si que lo tendré en cuenta para orientar posibles mejoras futuras.
Otras ideas que surgieron entre los dos fueron la eliminación segura de archivos (que ya lo tenia pensado antes pero me gusto ver que no soy el único preocupado :-) ) o la compactación de los archivos (quizás para mas adelante, ya hay suficiente lío con la escritura de los chunks como para encima meter esto). Sin embargo al ver todo lo que esta creciendo el sistema me esta entrando una pequeña duda: ¿y si SQLite no es lo suficientemente potente como para moverlo todo? SQLite es un motor de bases de datos muy optimizado, pero tiene el inconveniente de que cuando se accede a el bloque la base de datos entera, y con tanta funcionalidad añadida a falta de pruebas de rendimiento un sistema que ponga a funcionar muchos modulos podría tener problemas... Una solución bastante practica podría ser el que los modulos en lugar de crear sus tablas en la base de datos principal las creen en bases de datos secundarias, con lo que aparte de aumentar la modularización permitirá el acceder en paralelo a las distintas tablas (sobretodo con equipos multicore como los que se venden hoy día) y además se evitaría el meter "mierda" en la base de datos principal y la desinstalación de modulos seria mas sencilla, sin embargo la adaptación a un sistema autocontenido se complicaría sobremanera. Bien es cierto que todavía queda mucho para entonces, pero siempre es bueno planear tus actos con dos o tres pasos de antelación... :-D Por el momento lo dejo aquí anotado como recordatorio para el futuro ;-)
Pero por otro lado también he estado aprovechando el tiempo, y el sistema de plugins ya esta bastante maduro. El sistema me ha quedado bastante escueto y portable, por lo que se podría utilizar en otros sistemas que precisen de un sistema de plugins, pero aunque ya haya otros sistemas de plugins para python (y algunos ya se me han adelantado en la idea de convertirlos en sistema "oficial") lo cierto es que no he visto ninguno que tenga algún mecanismo de control de dependencias entre plugins, y aunque creía que iba a ser mas complicado lo cierto es que al final ha sido casi obvio: al cargar el modulo obtenemos las clases de los plugins y vemos cuales son sus dependencias. Si no están todas disponibles dejamos el plugin pendiente, y si lo están entonces lo cargamos y comprobamos entre los pendientes si para alguno de ellos ha cambiado la situación. Simple, fácil y para toda la familia :-D
Es por esto por lo que todavía no le estoy dando mucha popularidad al sistema ya que quiero tenerlo bien fino antes de abrirlo al publico (sobretodo por el tema de los plugins que se meten muy adentro del funcionamiento del sistema), pero probablemente para la versión 0.3 ya haga un llamamiento publico buscando ideas y colaboradores (y si, prometo que intentare poner al día y en la web cuales son los checkpoints para cada versión...). Sin embargo precisamente por esto he estado actualizando (y limpiando) el diagrama de la estructura de tablas mas acorde a como se esta perfilando el sistema ahora que empiezan a funcionar los plugins (mi idea era implementarlo después de la versión 1.0, pero con motivo del concurso y de la "participación de la comunidad" he tenido que cambiar las fechas para hacerlo mas accesible) y este es el resultado:
 |
| (Los colorines son para indicar la dificultad de implementar cada uno de los modulos según cuanto haya que modificar el código: blanco=implementado, verde=directo o casi directo, amarillo=alguna modificación, naranja=reimplementación en parte, rojo=reimplementación de gran parte y turquesa=implementado pero necesita mejoras. Obviamente, con los checksums me equivoque...) |
Como podéis ver, arriba a la izquierda tenemos el core, ya implementado. He agrupado lo que correspondería al plugin de directorios y al de archivos porque aunque por el momento no tenga pensado implementarlos como modulos externos, lo cierto es que cada vez me esta tentando mas la idea (¡Mama mama, sin directorios! ¡Mama mama, sin archivos! ¡Mama mama, sin datos! X-D). Luego en el siguiente nivel tenemos los modulos de implementación que como dije anteriormente son dependientes de los elementos del core, y por ultimo tenemos los de valor añadido, en los cuales he puesto el ACL y el log (antes los tenia como de implementación) debido a que no son dependientes directos del core. También tengo aquí a un nuevo vecino en el barrio, xattrs (atributos extendidos), que aunque si es dependiente del core lo cierto es que no depende de sus claves únicas. Además, realmente voy a implementar los atributos extendidos para completar la funcionalidad del sistema de archivos y porque va a ser igual de sencillo que los symlinks (al igual que estos, se podría hacer con un mapeo directo de funciones) ya que a titulo personal, me parece una solución mucho mejor el usar algún tipo de estructura como las tablas id3 y exif, no un simple clave-valor que no da ninguna idea de cuales datos faltan por rellenar (lo admito, estoy obsesionado con los tags de los mp3s en el iTunes hasta el punto de que no solo relleno todos los campos de autor/album/disco/pista/titulo para tenerlos bien organizados sino que le meto dentro a los archivos todas las imágenes del album e incluso la letra de las canciones... :-P). Sin embargo también tengo que reconocer que aunque no son muy usados (al menos son unos completos desconocidos para el usuario medio, y para mi hasta hace poco), realmente pueden ser muy potentes y en un sistema de archivos "tradicional" puede ser usado para implementar un ACL y aumentar el nivel de seguridad, por ejemplo. En cualquier caso, para todo lo que se pueden usar los atributos extendidos un sistema dedicado puede cumplir su tarea mucho mejor, pero las estructuras en los sistemas de archivos tradicionales son demasiado fijas como para añadir este tipo de funcionalidades. Por eso la flexibilidad que ofrecen las bases de datos en estos casos es justo una de las razones que me impulsaron a usar una como base para diseñar el sistema de archivos.
Pero este pequeño by-pass con replanteamiento de puntos de vista incluido también me esta permitiendo el tener tiempo para pensar sobre nuevos modulos, plugins y funciones que añadir al sistema, y parte del merito se lo tengo que dar a mi buena amiga Jennifer, una completa n00b para estas cosas (bastante que la conseguí sacar del lado oscuro y que empezara a usar Linux... :-P) pero que sin embargo su punto de vista como usuario raso me ha sido bastante útil (¡gracias! :-D ).
Una de las ideas que me dio fue el implementar algún sistema de búsqueda avanzada en situaciones limite, del estilo "he buscado la foto del garito aquel en la playa en que estuve desfasando con mis amigas en la que salia guapísima, pero no me acuerdo si es de este año o del anterior y no se si las he borrado o que porque no las encuentro" (nota: aunque no haya dicho nada, casi desde que empecé el proyecto en el diagrama arriba a la derecha hay un modulito muy majo llamado "unlinks"... Si, he pensado en todo, también en otro llamado "purge" que no sale ;-) ). "Además, no quiero que salgan las fotos del tío con el que me enrolle esa noche no sea que entre mi novia en un momento inoportuno cuando este buscando la foto" (a esto ultimo lo llamo yo "ganas de fastidiarme", solo que no con estas palabras...). Al leer esto algunos pensaran que eso es imposible, y otros pensaran que quizás SpotLight o Beagle ya lo hacen (realmente esta idea suya les correspondería mas a unas aplicaciones de alto nivel como ellos que a un sistema de archivos, pero un poco de ayuda por debajo les facilitaría mucho la tarea al igual de lo que podría ocurrir si combinásemos ZFS con TimeMachine... :-) ). Lo cierto es que SpotLight es buenísimo (Beagle nunca lo he usado porque siempre lo desinstalaba ya que mis maquinas con Linux nunca han sido lo suficientemente potentes como para encima tener un proceso accediendo al disco todo el rato...) pero nunca he visto que llegara a un nivel de precisión quirúrgica tan avanzado (quizás lanzandolo desde linea de comandos y procesando una consulta muy elaborada, pero si fuera así de fácil habría un montón de artículos escritos en internet al respecto y lo cierto es que no he oído nada). Yo tengo que ser sincero: es muy complicado, pero no imposible. Aquí el mayor problema depende de la adquisición de los metadatos (día-noche, fechas contextualizadas, reconocimiento de caras...) pero si se tienen y están bien organizados, el problema se reduciría a una simple búsqueda en la base de datos. No diré que lo vaya a implementar... pero si que lo tendré en cuenta para orientar posibles mejoras futuras.
Otras ideas que surgieron entre los dos fueron la eliminación segura de archivos (que ya lo tenia pensado antes pero me gusto ver que no soy el único preocupado :-) ) o la compactación de los archivos (quizás para mas adelante, ya hay suficiente lío con la escritura de los chunks como para encima meter esto). Sin embargo al ver todo lo que esta creciendo el sistema me esta entrando una pequeña duda: ¿y si SQLite no es lo suficientemente potente como para moverlo todo? SQLite es un motor de bases de datos muy optimizado, pero tiene el inconveniente de que cuando se accede a el bloque la base de datos entera, y con tanta funcionalidad añadida a falta de pruebas de rendimiento un sistema que ponga a funcionar muchos modulos podría tener problemas... Una solución bastante practica podría ser el que los modulos en lugar de crear sus tablas en la base de datos principal las creen en bases de datos secundarias, con lo que aparte de aumentar la modularización permitirá el acceder en paralelo a las distintas tablas (sobretodo con equipos multicore como los que se venden hoy día) y además se evitaría el meter "mierda" en la base de datos principal y la desinstalación de modulos seria mas sencilla, sin embargo la adaptación a un sistema autocontenido se complicaría sobremanera. Bien es cierto que todavía queda mucho para entonces, pero siempre es bueno planear tus actos con dos o tres pasos de antelación... :-D Por el momento lo dejo aquí anotado como recordatorio para el futuro ;-)
miércoles, 29 de septiembre de 2010
[0.2.2] El log de Schindler
Hoy debido a la huelga he decidido quedarme en casa, no por apoyarla y no ir a trabajar, sino que ayer me hice una copia de seguridad y he trabajado desde aquí debido al miedo que tenia a los piquetes (no estoy de acuerdo con las reformas, pero tampoco con los sindicatos como la mayoría de la población).
Al final ha sido mas ruido que otra cosa y podría haber ido sin problemas, pero el caso es que como he terminado pronto me he puesto a darle un empujón al sistema de archivos y bueno... hemos alcanzado otro checkpoint :-D Ahora modulo de log esta operativo, he limpiado el modulo de symlinks (ya no hay funciones mapeadas, todas son lanzadas por eventos gracias a louie :-) ) y empieza a discernirse un borrador de como implementar el sistema de plugins. Esto ultimo es debido a que en el modulo de log no tenia manera de tener una referencia para acceder a la base de datos, ya que antes accedía a través del objeto del sistema de archivos (como se puede ver en symlinks, aunque lo voy a cambiar en breve para unificarlo) y ahora al tener el objeto otra estructura perdía toda referencia a ella, y guardarlo en una variable global me decía el bicho que nanai. ¿Como hacerlo? Pues construyendo una clase. Era reacio a hacerlo a pesar de mi gusto por la orientación a objetos porque entonces ya no bastaría con cargar el modulo para tenerlo habilitado, sino que ademas tendría que meterme dentro, leer la clase y crear un objeto, y eso ya es mucho engorro. Por el momento lo he solucionado con la chapuza de crear una instancia del objeto al final del modulo (niños, no miréis :-P ) pero la ventaja de usar orientación a objetos es que mi idea de en un futuro implementar un sistema de dependencias entre plugins (inspirado en APT para mas señas... ;-) ) va a ser mucho mas sencillo :-)
En fin, en cualquier caso el modulo de logs ya esta listo, aunque tendré que diseñar algún método para agrupar los eventos y así poder discernir cuales son validos para loggear y cuales no, porque cuando ya estaba operativo con solo hacer un ls me ha salido todo esto...
Si, efectivamente, FUSE hace muchas llamadas al sistema... ;-)
P.D.: entrada libre de faltas de "hortográfia" ;-) dedicada a Pau y su muy buen consejo :-)
Al final ha sido mas ruido que otra cosa y podría haber ido sin problemas, pero el caso es que como he terminado pronto me he puesto a darle un empujón al sistema de archivos y bueno... hemos alcanzado otro checkpoint :-D Ahora modulo de log esta operativo, he limpiado el modulo de symlinks (ya no hay funciones mapeadas, todas son lanzadas por eventos gracias a louie :-) ) y empieza a discernirse un borrador de como implementar el sistema de plugins. Esto ultimo es debido a que en el modulo de log no tenia manera de tener una referencia para acceder a la base de datos, ya que antes accedía a través del objeto del sistema de archivos (como se puede ver en symlinks, aunque lo voy a cambiar en breve para unificarlo) y ahora al tener el objeto otra estructura perdía toda referencia a ella, y guardarlo en una variable global me decía el bicho que nanai. ¿Como hacerlo? Pues construyendo una clase. Era reacio a hacerlo a pesar de mi gusto por la orientación a objetos porque entonces ya no bastaría con cargar el modulo para tenerlo habilitado, sino que ademas tendría que meterme dentro, leer la clase y crear un objeto, y eso ya es mucho engorro. Por el momento lo he solucionado con la chapuza de crear una instancia del objeto al final del modulo (niños, no miréis :-P ) pero la ventaja de usar orientación a objetos es que mi idea de en un futuro implementar un sistema de dependencias entre plugins (inspirado en APT para mas señas... ;-) ) va a ser mucho mas sencillo :-)
En fin, en cualquier caso el modulo de logs ya esta listo, aunque tendré que diseñar algún método para agrupar los eventos y así poder discernir cuales son validos para loggear y cuales no, porque cuando ya estaba operativo con solo hacer un ls me ha salido todo esto...
[piranna@Tontodelculo:~/Proyectos/FUSE/PirannaFS/test]
> sqlite3 db.sqlite
SQLite version 3.6.22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * from log;
|__init__|DB|2010-09-29 18:34:31||{'self': , 'db_name': '../test/db.sqlite'}||
|readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:39||{'path': '/nano_link.txt', 'self': }||
sqlite> Si, efectivamente, FUSE hace muchas llamadas al sistema... ;-)
P.D.: entrada libre de faltas de "hortográfia" ;-) dedicada a Pau y su muy buen consejo :-)
Suscribirse a:
Entradas (Atom)