Monthly Archive for Marzo, 2005

Page 2 of 2

V Concurso de Programación Obfuscada

A pesar de encontrarme a 6623 kilometros de la Universidad de Deusto (más o menos), este año vuelvo a organizar el Concurso de Programación Obfuscada en el marco de la Semana ESIDE 2005. Este ya es el quinto año que organizo el concurso, y animo a los frikis deustenses a que hagan gala de sus habilidades obfuscadoras. Para los que no esteis en Deusto, el concurso también está abierto a no-deustenses, aunque no optan a premio (sólo a un bonito diploma). De todas maneras, en este concurso uno no se mete por los premios, ¡sino para ganar frikipuntos e infinite bragging rights!

Pues eso. Aunque no vayais a concursar, echadle un vistazo a web del concurso, donde podreis encontrar los programas ganadores de años pasados (algunos de ellos, verdaderas joyas).

Mi kernel

Bueno, para los más frikis, aquí lo teneis para vuestro disfrute y deleite: el kernel que he programado como parte de la asignatura de Sistemas Operativos aquí en la Universidad de Chicago. ¡Ojo! Como el kernel podría ser de gran utilidad para alumnos que hagan la asignatura el año que viene, hace falta nombre de usuario y contraseña para acceder a la URL donde está colgado el kernel. Como me imagino que principalmente interesará a los frikis de ESIDE, la contraseña la podrá deducir facilmente cualquier persona que haya estudiado en ESIDE. Si no has estudiado en ESIDE, mandame un mail y te mando la contraseña.

Nombre de usuario: borjanet
Contraseña: “Número del aula de programación” (3 dígitos) + “Nombre de cierta profesora de programación con risa muy contagiosa” (en minúsculas) + “Piso de los profesores” (un dígito)

En cuanto al kernel, lo primero que tengo que decir es que no lo he programado yo solito, sino en colaboración con Mike Rainey, estimado compañero y excepcional friki. Luego, en vez de cascar un rollo macabeo sobre el kernel, me parece que lo mejor es dar un pequeño resumen y si alguien se pone a mirar el codigo fuente y no entiende algo, que lo plantee en los comentarios.

El kernel está escrito para una arquitectura simplificada llamada Yalnix. Hace falta un emulador para ejecutar el kernel, y por mucho que busco y rebusco, no lo encuentro por ningún lado en la web. Podría pasaros el binario que hemos utilizado nosotros, pero sólo funciona bajo Solaris… En fin, la arquitectura Yalnix es parecida a la que podriamos encontrarnos en un dispositivo movil tipo PDA (de hecho, el emulador de Yalnix te muestra una pantalla tipo PDA e incluye un dispositivo “lapiz” como el que tienen los PDAs). Por lo tanto, implementar un kernel resulta bastante más sencillo que en una arquitectura i386, aunque no por ello deja de ser complicado. A saber, nuestro kernel implementa la siguiente funcionalidad:

  • Gestión de la memoria física (utilizando un algoritmo First-Fit).
  • Gestión de memoria virtual (First-Fit) pero sin swapping al disco. El malloc interno del kernel utiliza un Buddy algorithm (que resulta que es un algoritmo pesimo para reservas de bloques pequeños de memoria, pero que es bastante rapido, y por lo tanto adecuado para una PDA)
  • Gestión de procesos (exec, fork, wait, getpid, delay, yield, …). El scheduler utiliza un algoritmo round robin.

Debo enfatizar que todo esto funciona. Es decir, cuando ejecutamos el kernel en el emulador podemos cargar programas, crear nuevos procesos, y ver como interactuan y se pelean por la CPU. No os podeis imaginar la cara de felicidad que se me puso cuando conseguí que el “Proceso A” y el “Proceso B” conmutasen sin problemas… Trabajar en este proyecto ha sido sinceramente muy revelador. Una cosa es estudiar el funcionamiento de (por ejemplo) la memoria virtual sobre el papel, y otra cosa muy distinta es pelearte tu mismo con la implementación desde cero de un gestor de memoria virtual donde el más mínimo fallo provoca un kernel panic.

En la segunda parte del proyecto (la que entregamos este viernes), tenemos que añadir lo siguiente al kernel:

  • Gestión de E/S a bajo nivel (llamadas del sistema para interactuar directamente con los dispositivos fisicos). Esto supone escribir código bastante obfuscado para gestionar (entre otras cosas) un puerto serie.
  • Gestión de E/S a alto nivel, tipo UNIX. Es decir, interactuar con los dispositivos de bajo nivel a través de ficheros como “/dev/serial”, “/dev/display”, etc. y con las llamadas típicas de UNIX (open, close, read, write, pipe, etc.)
  • Exclusión mutua mediante semáforos.

La segunda parte ya la tenemos 99.9% terminada (hemos llegado al punto en que nuestra principal preocupación es conseguir que los comentarios queden bonitos…). De la segunda parte me ha encantado implementar todo el sistema de pipes. Escribir el caracter de la barra vertical en la shell nunca volverá a ser lo mismo…

En fin, ahi lo teneis. Si os sentís especialmente frikis hoy, bajaros el kernel y echadle un vistazo (os sugiero que empeceis por kernel.c). Si teneis preguntas, planteadlas en los comentarios. ¡Ah! E intentaré colgar el segundo kernel la semana que viene.

P.D.- El kernel incluye varios comentarios en plan de cachondeo. A ver si podeis encontrarlos todos…

Llegando a la linea de meta…

Hoy ha sido el último día de clase del trimestre de invierno. Después de duras batallas en Algoritmos y en Sistemas Operativos, ya sólo queda semana y media para que esto termine definitivamente. Este viernes entregamos el segundo proyecto de SO, y el 18 de marzo tenemos el examen final de Algoritmos. Me siento como si estuviese corriendo un maratón, y estuviese a punto de entrar al estadio para la vuelta final…

De momento parece que todo va viento en popa. El lunes tuvimos el segundo parcial de Algoritmos y hoy nos han dado las notas. Afortunadamente, me sigo manteniendo a flote en el “cuartil superior” (top 25% de la clase). Debo enfatizar que aquí lo importante no es tu nota sino dónde te situas con respecto a tus compañeros, porque la nota final se hace mediante campanazo de Gauss. Para que os hagais una idea del nivel de exigencia de la asignatura, yo estoy en el cuartil superior a pesar de que mi nota media (sin ajustes) es un 6 :-O

Hoy, además, nos han dado las notas del primer proyecto de SO (el kernel que implementamos). Me agrada poder anunciar que mi kernel ha sacado la segunda nota más alta de la clase (después de unos megafrikis que al parecer se pegaron atracones de 72 horas seguidas de programación -sin dormir- para currarse un kernel acojonante… lo siento, pero yo por eso ya no paso). En fin, que he dejado en buen lugar la honra Deustense… Que se enteren estos zafios yankis que dónde esté un ingeniero de Deusto, que se quite el resto (lo digo con un ligero tono de coña… así que si alguien está pensando en dejar un comentario tipo “¡Eres un pretencioso soplapollas!” que por favor se abstenga :-P)

Y hablando del proyecto de SO, no, no me he olvidado de que tengo que colgarlo. De hecho, hoy mismo lo colgaré por fin.

Ah, y aunque no haya escrito sobre el tema (como han hecho muchos otros blogs Deustenses, como el de Lady Pain y Paradise City), que sepais que sí he seguido con sumo interes el progresivo agilipollamiento del Consejo Europeo en lo referente a las patentes del software. No sé por qué, yo me imaginaba que aquí en Europa tendriamos un nivel de trapicheo menor, por lo menos por el simple hecho de que hay que alcanzar un consenso entre tantos paises. Pero parece que no… incluso en Europa nos la pueden meter doblada porque se le pone en la punta de las narices a una minoría interesada. No voy a repetir aquí en mi blog todos los argumentos en contra de la patentabilidad del software. Sí diré que estos argumentos a mi, por lo menos, me parecen muy solidos, tanto en el fondo de la cuestión como en lo referente en la forma en la que se ha aprobado la directiva Europea (pasandose los procedimientos y cauces legales for el arco del triunfo). Os refiero para más detalles a la web del GHOST: http://www.e-ghost.deusto.es/patentesfuera.

Ser ingeniero mooola

Como ya he comentado alguna vez en el blog, el hecho de que soy ingeniero me convierte en una especie de bicho raro en el Departamento de Ciencias de la Computación. Por raro que le parezca a alguien de ESIDE, la mayoría de las personas que deambulan por el departamento…

  • … consideran que C/C++ y Java son unos lenguajes que hay que evitar a toda costa. Por eso mucha gente se pega un batacazo considerable en la asignatura de Sistemas Operativos (no, no me he olvidado de que tengo que colgar mi kernel algún día de estos…)
  • … no saben que el desarrollo del software se divide en análisis, diseño, implementación, pruebas, y mantenimiento. Tampoco saben que la fase de implementación es la que menos tiempo debería consumir. De hecho…
  • … no saben nada de Ingeniería del Software (ni DFDs, ni UML, ni ná de ná)
  • … no han visto un circuito, una protoboard, o un microPIC en su vida.
  • … saben lo que es una red, pero no tienen ni idea de cómo funciona.
  • … etc.

Evidentemente, las generalizaciones son peligrosas, pero a lo que voy es que aquí la gente tiene una concepción mucho más teorica, y menos prágmatica, de la informática. Evidentemente, muchos de mis compañeros podrían decir lo contrario de mi: que si no sé nada de maquinas de Turing, que si no tengo ni idea de lenguajes funcionales de programación, que si nunca he implementado un compilador en mi vida, etc. De hecho, cuando algunos de mis compañeros hablan de lenguajes de programación me pierden por completo (al parecer, el estudio de los lenguajes de programación por estos lares gira en torno a demostrar formalmente propiedades de los lenguajes de programación… ¿y quién tiene tiempo para programar cuando tienes que realizar demostraciones formales sobre el lenguaje?).

Pero bueno, a pesar de ser el patito feo, hoy mi caracter ingeniero ha cosechado un importante triunfo. Para cumplir los requisitos del doctorado, el cuatrimestre que viene tengo que hacer una asignatura de “Redes y Sistemas Distribuidos”, lo que (tras consultar el temario) aquí significa “Vamos a explicaros lo que es TCP e IP y vamos a programar un servidor web ultrabásico con sockets”. Y a mi, por supuesto, me dio una sensación de déjà vu tremenda. Más concretamente: Redes de Ordenadores de 4º de ESIDE (TCP e IP) y Sistemas de Transmisión de Datos de 4º de ESIDE (protocolos de la capa de aplicación y programación con sockets). Así que hablé con las personas pertinentes, y resulta que como soy ingeniero, pues que no tengo que hacer esa asignatura. Que me la puedo saltar directamente. De hecho, es posible que el año que viene pueda saltarme la asignatura de Arquitectura de Computadores (para algo me tiene que haber servido pasar en 2001 las peores navidades de mi vida).

¡Mola, mola, mooooola! Después de esta noticia, el trimestre de primavera promete ser un paseo por la playa comparado con el trimestre de invierno :-D