las actas de las jornadas - Gcubo

Asociación para la Difusión y el Avance del Software Libre de Andalucı́a (ADALA) Grupo de Usuarios de GNU/Linux de Granada (GCUBO) Actas de las III Jornadas Andaluzas de Software Libre Granada, 14 y 15 de noviembre de 2003 Organizadas por: ADALA GCUBO Con la colaboración de: Escuela Técnica Superior de Ingenierı́a Informática de la Universidad de Granada Editores: Alfonso Cepeda Caballos Antonio Arauzo Azofra Antonio Luque Estepa http://jornadas.adala.org Los textos que aparecen en el presente volumen constituyen las contribuciones presentadas en las III Jornadas Andaluzas de Software Libre. Reflejan la opinión de sus autores y se publican tal y como ellos las presentaron. Esta publicación no significa que ADALA, GCUBO, ni los editores, compartan o apoyen las opiniones expresadas en dichos textos. Las contribuciones fueron propuestas por sus autores y pasaron un proceso de selección, durante el cual fueron revisadas por un comité de programa. Por favor, use el siguiente formato para citar material de este libro: Autor(es), “Tı́tulo del artı́culo”, en Actas de las III Jornadas Andaluzas de Software Libre, A. Cepeda, A. Arauzo, A. Luque, Editores, números de página (2003). ISBN: 84-88783-66-3 Publicado por: ADALA, Asociación para la Difusión y el Avance del Software Libre de Andalucı́a http://www.adala.org GCUBO, Grupo de Usuarios de GNU/Linux de Granada http://www.gcubo.org Biblioteca de la Escuela Superior de Ingenieros de Sevilla http://www.esi.us.es/BIB Copyright c 2003, ADALA y GCUBO Copyright c 2003, Los autores de cada contribución Se otorga permiso para copiar y distribuir este documento bajo los términos de la Licencia de Documentación Libre GNU, publicada por la Free Software Foundation, cubriendo las secciones invariantes el documento completo. Impreso en España. Tanto los trabajos individuales como las actas completas se pueden descargar en la página web http://www.adala.org/jasl3/. 2 Índice General Comité de programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Artı́culos presentados El kernel linux 2.6: Presente y futuro Alejandro Sánchez Acosta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Cherokee Web server Álvaro López Ortega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Reciclaje y Software Libre: Una Solución para la Enseñanza Juan Pablo Sánchez Beltrán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Espiral de valores: técnicas avanzadas de programación PHP Diego Arranz y Javier Linares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Legislación europea y el Open Source / Free Software José M. Fidel Santiago Luque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 La Intranet Educativa Municipal del Ayuntamiento de La Coruña Enrique Ocaña González . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 PROPIEDAD, S.L.: Propiedad y software libre José J. Grimaldos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact. Francis Brosnan Blázquez, David Marı́n Carreño y Marcos Olmos Domı́nguez . . . . . . . . . . . . . . . . . . . . . . . . 64 Gentoo Linux: filosofı́a e introducción José Alberto Suárez López . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Plone - Taller y experiencia docente Gregorio Robles y Jesús M. González Barahona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3 4 Comité de programa Antonio Buiza Calero, Adala Alfonso Cepeda Caballos, Universidad de Sevilla Antonio Luque Estepa, Universidad de Sevilla Rafael Martı́n de Agar Tirado, Emergya, S.L. Juan J. Merelo, Universidad de Granada Daniel Molina, GCubo 5 6 Presentación En el presente volumen se recogen las contribuciones presentadas a las III Jornadas Andaluzas de Software Libre, JASL3, celebradas en Granada durante los dı́as 14 y 15 de noviembre de 2003. El software libre son todos los programas o aplicaciones para ordenadores u otros dispositivos electrónicos que nos permiten hacer uso de las tres famosas libertades: -Libertad de usarlo sin ninguna restricción, ni económica ni de ningún otro tipo de discriminación social. -Libertad para ver como esta hecho, aprender de él y modificarlo. -Libertad de poder distribuirlo, tanto en su versión original como las posibles versiones modificadas. Como todo aquello que permite aumentar la libertad, el software libre es un desarrollo muy interesante para la sociedad. Ası́ parece que esta empezando a percibirse por un número de personas cada vez mayor. El software libre ya no sólo se conoce dentro del ámbito técnico de la informática, al que se encontraba reducido hasta hace pocos años, sino que está empezando a ser usado ampliamente en proyectos educativos, en las administraciones públicas de muchos lugares del mundo y en numerosas empresas. Esta tercera edición de las Jornadas Andaluzas de Software Libre se celebra en un ambiente muy positivo, en el que todos los que nos consideramos pertenecientes a la comunidad del software libre nos alegramos por gran la expansión que el software libre está experimentando. Podemos mencionar especialmente la iniciativa Guadalinex de la Junta de Andalucı́a, que a semejanza con el proyecto de la Junta de Extremadura (Linex), pretende equipar los centros docentes con nuevas tecnologı́as eligiendo al software libre como protagonista. Esta sabia elección, además de conseguir numerosas ventajas en ahorro de costes, igualdad, y libertad en el uso de las nuevas tecnolog?as, puede suponer un apoyo muy fuerte al avance del software libre. Un avance esperamos que se produzca, tanto por el impulso de nuevos proyectos de desarrollo, como por la difusión de las ideas y el propio software masivamente. Todo esto redundará sin duda en ventajas todavı́a mayores para la sociedad, cerrando de esta manera un beneficioso circulo virtuoso. Considerando la idoneidad del software libre para ser aplicado en tareas de educación, y la importancia del desarrollo del proyecto Guadalinex, el tema elegido para las jornadas ha sido “El software libre y la educación”. Entre las comunicaciones presentadas en esta publicación, todas ellas con un alto grado de calidad, encontramos algunas relacionadas directamente con la educación y otras con los últimos desarrollos técnicos y cuestiones sociales relacionadas con el mundo del software libre. Esperamos que las ponencias os resulten interesantes y que todos disfrutemos con los actos organizados en estas Jornadas. Finalmente nos gustarı́a agradecer su apoyo a todas las entidades y personas que han colaborado en el desarrollo de las JASL3, y especialmente a los autores que han enviado sus trabajos. Antonio Arauzo Azofra Lorenzo Gil Sánchez Comité organizador de las III JASL 7 El pasado de 27 de septiembre se cumplieron 20 años desde el anuncio oficial del proyecto GNU. Cuando en 1983 Richard Stallman mandó aquél famoso correo electrónico a los grupos de noticias nadie, seguro que ni siquiera él, imaginaba las repercusiones que tendrı́a. Su original idea trajo al apasionante mundo del desarrollo de software una libertad muy necesaria que, por otro lado, ya existı́a en otras áreas del conocimiento humano y que desgraciadamente se sigue echando en falta en otras. Su proyecto se resume, nada más y nada menos, en crear una nueva implementación del sistema operativo Unix que tenga los siguientes requisitos: (0) libertad de usar un programa con cualquier propósito (1) libertad de estudiar cómo funciona un programa y adaptarlo a tus necesidades (el acceso al código fuente es una condición previa) (2) libertad de distribuir copias y ası́ ayudar a tu vecino (3) libertad de mejorar el programa y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie. En estos 20 años son muchas cosas las que han sucedido, pero quizás haya una que las resume a todas: se ha diseñado una nueva forma de desarrollar programas; ha nacido y madurado el software libre. Puede que no sea el único modelo válido, ni siquiera el mejor, pero es el que nos define, nos divierte y por el que apostamos. Muchas son sus particularidades, y una de las más importantes ha sido la de crear una comunidad dinámica, dispuesta a mejorarse y a mejorar su entorno. Y ese espı́ritu, precisamente ese, fue el que gobernó, gobierna y gobernará las Jornadas Andaluzas de Software Libre que, este año, se han celebrado en Granada prestando especial interés a la ı́ntima relación que creemos existe entre el software libre y la educación. Confiamos, por tanto, que estas ponencias fruto de las mencionadas Jornadas y aquı́ publicadas sean de su interés. Por último, agradecer sinceramente la labor realizada por los numerosos voluntarios de la organización, a los ponentes por participar con sus trabajos y a los organismos públicos y privados por la colaboración prestada. Antonio M. Zugaldı́a Rodrı́qued-Campra Presidente de GCubo 8 Probablemente, 2003 haya marcado un punto de inflexión en la relación de Andalucı́a con el software libre. Tras el Decreto 72/2003, de 18 de marzo, de Medidas de Impulso de la Sociedad del Conocimiento en Andalucı́a, la apuesta de la Junta de Andalucı́a por el uso del software libre en la administración autonómica nos ha situado en el punto de mira de la comunidad. Las medidas promovidas por este decreto ya se han dejado notar, especialmente en el ámbito educativo, donde la incorporación de más de 20.000 PCs equipados con GNU/Linux para los alumnos y profesores de 100 centros de enseñanza ha supuesto el comienzo de la iniciativa Guadalinex, destinada a promocionar el uso de software libre por parte de todos los ciudadanos andaluces. Por ello, las III Jornadas Andaluzas de Software Libre están dedicadas al empleo de software libre en la enseñanza, como vehı́culo para facilitar la incorporación de nuestro sistema educativo al tren de las nuevas tecnologı́as. En esta coyuntura, las Jornadas han despertado un nivel de expectación superior al de ediciones anteriores. Los apoyos institucionales y empresariales, el nivel de los trabajos presentados y las previsiones de asistencia de público hacen suponer el éxito de unas Jornadas llamadas a convertirse en el punto de encuentro de la comunidad del software libre en Andalucı́a, de acuerdo al espı́ritu con el que nacieron y que, este año, se ve reflejado en la impagable colaboración de GCubo en la organización del evento en Granada. Daniel Carrión Reinoso Presidente de ADALA 9 El kernel linux 2.6: Presente y futuro. Alejandro Sánchez Acosta kernelnewbies-es [email protected] 1. Introduccion al kernel 2.5.x. El kernel 2.5.x nos trae numerosas mejoras que harán del kernel 2.6 que los usuarios notemos notables diferencias ya que son muchas las mejoras que nos trae, entre ellas un nuevo planificador de procesos, mejora de escalabilidad, soporte para máquinas NUMA, una completa CryptoAPI, un nuevo sistema de configuración, soporte para hilos, así entre muchas más que iremos viendo a continuación. En este articulo se intentará hacer una visión global de cada una de las nuevas características que nos provee la rama 2.5.x para lo que vendrá a ser el kernel 2.6, planificada su primera versión para finales de Octubre en fechas de Halloween según el propio Linus Torvalds. 2. Nuevo planificador de Ingo Molnar O(1) Así que voy a empezar por el Scheduler de Ingo Molnar (Desarrollador de Redhat): (Basándome en parte en la informacion disponible en Documentation/sched-design.txt y en las fuentes del kernel.) Como todos sabemos cuando el número de procesos es mayor que el número de procesadores, es necesario alternar entre los diferentes procesos, de manera de que a cada proceso le parezca que se esta ejecutando continuamente y al mismo tiempo. El scheduler o planificador del actual 2.4.x tenía problemas, principalmente de escalabilidad. Consta de una lista global de procesos de la que ahí, el scheduler escoge el que cree mas adecuado según los algoritmos que utilicee. EL problema de tener una lista global, es que para accederla hay que usar mecanismos de bloqueo, esto implica que cuando una CPU queda libre y llama al scheduler para buscar una nueva tarea para hacer, no puede hacerlo si hay otra cpu en ese mismo instante haciendolo, tendrá que esperar a que termine antes de empezar ella. Por supuesto, a mayor número de CPUs mayor contención se crea, las CPUs se quedan esperando a que el bloqueo se libere, y mientras tanto no pueden ejecutar ningún proceso. Aparte, el algoritmo que deduce que proceso es el más adecuado para ejecutar, tampoco es escalable con respecto al número de procesos. Para decidir que proceso se ha de ejecutar se tiene que recorrer _toda_ la lista de procesos. Esto está muy bien si sólo hay, pongamos, 10 procesos pero si hay 10000, significa que tiene que recorrer la lista de 10000 procesos y esto consume mucha CPU, más según aumenta el número de procesos por lo que esto es un algoritmo no-óptimo. La solución de Ingo Molnar arregla estos dos problemas: En el scheduler de Ingo Molnar, no hay una lista global de procesos, sino una lista de procesos por cada CPU, esto significa que no hay un bloqueo global y por lo tanto que cada CPU puede terminar un proceso, decidir que proceso será el siguiente a ejecutar, ejecutarle, expedirlo cuando haya pasado su cuanto de tiempo (time slice), individualmente, sin intervernir para nada con el resto de las listas de procesos de las otras CPUs por lo que esto hace que la escalabilidad en SMP sea "perfecta". Esto ISBN 84-88783-66-3 ©2003 10 El kernel linux 2.6: Presente y futuro. podría hacer que en una CPU se terminaran todos los procesos y en otra no, para ello existe un hilo del kernel en cada CPU que periodicamente se encarga de balancear los procesos entre las CPUs que haya en dado sistema. La solución al otro problema es un algoritmo completamente O(1). Ya no se necesita recorrer toda la lista de procesos. Existe una máscara de bits sobre cada array (más detalles en Documentation/sched-design.txt), por lo que encontrar el proceso a ejecutar es cuestión de una simple operación de bits (dos instrucciones de CPU en x86 segun el documento referido anteriormente). Es decir, aunque el numero de procesos sea 100000, cuesta muy poco encontrar el siguiente proceso a ejecutar por lo que nos encontramos con un algoritmo altamente eficiente de una complejidad lineal O(1). Otra cosa que nos trae este scheduler es una nueva política de planificación conocida como "batch scheduling". Cuando una tarea está en "batch scheduling" (SCHED_BATH), significa que esta tarea no se ejecutará hasta que todos los procesos hayan agotado sus "timeslices" (el tiempo durante el cual un proceso tiene oportunidad de ejecutarse). Es decir, en el scheduler hay prioridades (nice), pero siempre hay alguna oportunidad de que un proceso con nice 0 se ejecute aunque haya procesos con nice -12 por ejemplo (si no lo hiciera, ese scheduler no estaría funcionando correctamente). Con el batch scheduling, se asegura de que una tarea no interfiera en absoluto con el resto del sistema. 3. Inversión de prioridades El batch scheduling trae algunos efectos negativos que cabe resaltar, como es la inversion de prioridades, algo que NO esta solucionado en linux (si en otros sistemas operativos, como NT). Haré una descripción corta de lo que hace la inversión de prioridades para ver como esto puede afectar negativamente en algunos casos. Pongamos que tenemos tres procesos: A, B y C. El proceso A es una tarea que se ejecuta con prioridad alta, la B con una normal (nice 0), y la C como SCHED_BATCH (muy baja). Pongamos que esta tarea C adquiere un bloqueo, que necesita ser liberado para que A se ejecute. Ahora pongamos que la tarea B necesita ejecutarse: como la tarea C no se ejecutará hasta que la B termine, el resultado es que la tarea B se ejecuta y la A no; es decir, la tarea B acaba ejecutándose como si tuviera la prioridad de A (de ahi "inversion de prioridades"). La solucion a esto es la "herencia de prioridades": Si quieres que la tarea A se ejecute, lo que necesitas es dar la prioridad de A a C. Si, se invierten las prioridades predefinidas; pero el hecho es que la única manera de que se ejecute A es que C termine lo mas rápido posible y esto que parece tan simple así, no es tan fácil de implementar. Aparte, hay gente a la que esta solucion no le parece la más adecuada. Aparte de todo esto, los algoritmos que se han diseñado de nuevo en muchos casos consiguen asegurar una buena interactividad, que no haya "casos esquina", ,por lo que se consigue una mayor eficiencia en la mayoría de los problemas que venían dándose en kernels 2.4.x consiguiendo una buena planificación de los procesos del sistema. También ha habido muchos, muchos cambios en el soporte threads por Ingo Molnar, estos cambios han venido dados dentro de la libc consiguiendose hilos en espacio de kernel en relación 1:1 al igual que recientemente se ha añadido lo que se conoce como TLS o Thread Local Storage para el uso de segmentos distintos en el uso de threads teniendo secciones dedicadas a cada hilo como .tbss, pero en el tema de hilos se comentará más adelante. 4. Conceptos sobre la antigua planificación. Bien, como principal ventaja se observa que se mejora notablemente la escabilidad debido a que se añaden listas para el manejo de procesos en cada una de las CPU’s. En caso de sistemas uniprocesador lo que se hacía antes era directamente recurrir a la lista de procesos en ejecución run_task_list y a la run_task_queue list, la cual se recorría cada uno de los procesos y se miraba si el proceso era adecuado para pasar a CPU, esto se hacía por un medio de un algoritmo que decía si era optimo por medio de la función goodness() que realizaba el propio planificador en la llamada a shedule(). 11 El kernel linux 2.6: Presente y futuro. Luego para realizar la planificación lo que se hacía era directamente llamar a la rutina shedule() que lo que hacía era realizar la planificación de los procesos y era provocada tanto indirectamente como de una manera provocada (current->need_resched=1) para que se llamase a este. De forma indirecta se hacía cuando se realizaba un ret_from_intr() y se hacía directamente llamando al propio shedule() una vez habiendo puesto current al state TASK_INTERRUMPIBLE o TASK_UNINTERRUMPIBLE. En cuanto al cambio de procesos, el cambio se realiza mediante la rutina __switch_to() que está definida en arch/tipo_arch/process.c. Me imagino que estará dentro de las policies como venía antes dentro de task_struct, yo que recuerde unicamente he visto SHED_RR, SHED_FIFO, SHED_OTHER y SHED_YIELD. Como se ha visto se introduce SHED_BATCH que irá a tratar una planificación con procesos que no necesitan la interaccion del usuario tales como puede ser la compilación de un programa o de un proceso que esté realizando una búsqueda o cualquier cosa similar, en su caso previamente se ha abarcado introduciendo el nuevo planificador. 5. Mejora del algoritmo de asignación de PID’s Abundando un poco sobre el mismo tema de la escalabilidad, pero en este caso recurriendo sólo a mi memoria y no a un enlace donde se sustente lo que digo a continuación, parece que otra de las mejoras ha sido modificar el algoritmo para encontrar el PID para el siguiente proceso que se cree. Según parece la complejidad del algoritmo que daba un PID para asignarlo al siguiente proceso que crear era de complejidad cuadrática O(n^2) y lo que hacía era que cuantos más procesos había en la máquina más costoso en tiempo fuera obtener un PID libre. Evidentemente no es habitual (por ahora) tener en la máquina tantos procesos como para que se note la merma del rendimiento sólo para encontrar el siguiente PID, pero con los recientes avances en el soporte multihebra del núcleo (principalmente la NPTL de la gente de libc e Ingo Molnar) y con sus pruebas de decenas de miles de threads simultáneos (que mapearían a igual número de procesos del núcleo, pues si no recuerdo mal NPTL es un modelo 1:1, el algoritmo mencionado era subóptimo). 6. Preemptividad Mucha gente ya ha probado los parches de preempt para el 2.4 (al igual que los del scheduler). Cuando se habla de preempt, se quiere decir que un proceso pueda interrumpirse y que se pueda pasar a ejecutar otro. Esto ya existía en linux, pero sólo en espacio de usuario: EL kernel puede interrumpir un proceso para atender a un evento externo y dar la ejecucion a otro programa. Sin embargo, en el momento en el que un proceso ejecuta una llamada al sistema y pasa a ejecutar codigo del kernel, hasta que no vuelva al espacio de usuario no se puede interrumpir. Me explico: Si una aplicacion hace un read(), el kernel ejecutara todo la llamada del sistema desde la llamada hasta la peticion a disco; y devolvera el valor a quien lo llamo. En todo ese transito por el kernel, el propio kernel no puede ser interrumpido. Con Preempt, es posible que durante esa llamada, el propio kernel se interrumpa así mismo y pase a ejecutar otra operación totalmente distinta. 7. Parches de preemptividad y baja latencia. Algo de lo que me parece muy interesante son los parches de preemptivo y baja latencia, probándolos ambos se demostraba que el tiempo de latencia se disminuía considerablemente. Por ejemplo, se decía que al aplicar el parche de baja latencia se conseguía una latencia de 1.2 milisegundos, pero si se dejaba durante 24 horas el sistema encencido aumentaba considerablemente a cantidades de cerca de los 250 milisegundos, sin embargo con el uso 12 El kernel linux 2.6: Presente y futuro. del parche preemptivo junto con el de baja latencia se conseguían unas latencias de 1.5 milesegundos después de bastante tiempo, por lo que se adoptó la solución de la unión de ambos para conseguir soluciones con latencias mínimas. En cuanto al tipo de latencia es al que se considera latencia de planificación, el cual se entiende como el tiempo entre que un proceso tarda en despertar. Por ejemplo, cuando tenemos un proceso en un estado TASK_INTERRUMPIBLE se tiene que pasar al estado de listo TASK_RUNNING mediante sleep_on() o rutinas similares que se encargan de cambiar el estado del proceso para que esté listo para ejecutarse por la CPU, pues el tiempo entre el que se le manda una señal para que ese proceso despierte y responda se entiende por latencia de planificación. Que un proceso despierte puede ser causado tanto por una interrupción software como una interrupción hardware, recordad que la unica forma de retomar un proceso en TASK_UNINTERRUMPIBLE es a través de que se produzca una interrupción hardware que lo despierte. Luego entre otros tipos también se encuentra la latencia de interrupciones que es la cantidad de tiempo que pasa entre que se produce una interrupción y se llama a la rutina de atención a interrupción (RAI). Siempre que se produce una interrupción cuando vuelve del manejador de interrupciones lo que se hace es fijar a "1" need_resched por lo que se llama de nuevo al planificador (schedule()). Según Ingo Molnar es que este tiempo de latencia de interrupciones suele ser de 10 microsegundos frente a los pocos que se realizan en la latencia de planificación. En definitiva, lo que se suele decir es que principalmente afecta el tener una gran latencia en que el kernel no responde rapidamente a eventos producidos por E/S, esto se nota considerablemente en cuando estais reproduciendo un video ya que se accede considerablemente a disco. La solución que se adopta es la de hacer uso del planificador más regularmente pero esto se trata de un problema porque se van a necesitar gastar ciclos de reloj de CPU para que periodicamente se llame al planificador de forma más frecuente, así que como solución que se adopta es que el planificador se ejecute cuando se produzca un evento, tal como una interrupción. En sistemas de tiempo real se consigue considerablemente bajar el tiempo de latencia, pero el kernel linux al no ser preemptivo (ahora sí) se tiene que estar pendiente constantemente de los procesos o hilos (kernel_thread) y seguir las políticas de planificación para ello establecidas (SCHED_FIFO, SCHED_RR o SCHED_OTHER), por ello lo que se adopta es un planificador en tiempo real al igual que un parche para que se consiga preemptividad y se puedan expulsar del procesador procesos/hilos en espacio de kernel. Esta solución vino dada por una compañia de sistemas empotrados conocida como Montavista que introdujeron tanto un planificador en tiempo de real como un parche de preemtividad que actualmente están mantenidos por Robert M. Love. En cuanto lo que hacen los parches de preempt lo que hacen es modificar las macros de spinlocks y el retorno de interrupción de forma que sea segura (mediante el uso de exclusión mutua) poder expedir el proceso actual y replanificarlo luego cuando se necesario. Luego hay una API para asegurarnos si el hilo o proceso ha sido expedido o no , esto se sabe mediante funciones como preempt_enable() y preempt_disable() que modifican el valor preempt_count que nos indica si ha sido expedido o no, en caso de ser el valor 0 se llama al planificador mediante preempt_schedule(). Luego para tanto el uso de enable como disable se utilizan spin_lock() y spin_unlock() para la modificación de dicho contador. Con esto lo que se consigue es bajar notablemente la latencia por medio de la expedición de procesos, pero también queda comentar el parche de baja latencia que fue introducido por Ingo Molnar y ahora está mantenido por uno de los antiguos desarrolladores del core de OpenBSD, Andrew Morton. La idea de esto es buscar partes de código donde se produzcan largas iteraciones de tiempo y mientras se pueda hacer una llamada al planificador. Para ello lo que se hace es buscar zonas/bloques de código donde se pueda llamar a schedule(), esto se hace por una herramienta de Andrew Morton llamada rtc-debug que lo que modifica es el rtc timer que busca tiempos en el que las latencias son mayores que un determinado valor generando un syslog o log del sistema. Luego en este fichero se mira entre las rutinas indicadas que mayor latencia tienen e inserta lo que se llama un punto de preemptividad. Un ejemplo está en la parte que se hace de busqueda de una disk caché que se hacen largas iteraciones (función prune_dcache() en la que se pone un contador DEFINE_RESCHED_COUNT que se incrementa en cada bucle sobre el que itera hasta que llega a un determinado valor y se realiza una planificación incondicional: 13 El kernel linux 2.6: Presente y futuro. if (TEST_RESCHED_COUNT(100)) { RESET_RESCHED_COUNT(); if (conditional_schedule_needed()) { spin_unlock(&dcache_lock); unconditional_schedule(); goto redo; } } El redo unicamente salta otra vez al principio donde se estaba iterando para seguir por donde iba después de haberse realizado una planificación incondicional. Y nada esto son los dos parches, luego pruebas que se suelen hacer para probar los parches son como scripts que continuamente compilan el kernel X veces, programas que mandan/reciben constantemente grandes bloques de paquetes por el dispositivo loopback, operaciones con números largos con matrices o escrituras/lecturas con ficheros grandes para ver sus tiempos de latencia. 8. Parches para VM rmap RMAP: Otro delos famosos parches para 2.4, que ha sido llevado al 2.5, este parche conocido como RMAP viene del nombre anglosajón "reverse mapping". El esquema del kernel 2.4.x es el siguiente: Los procesos ven direcciones virtuales de la memoria. Es decir, un programa puede ver la dirección X, y otro ver la misma direccion X y ser en realidad direcciones completamente distintas fisicamente. Los procesos tienen tablas de paginas (PTEs), donde se guarda la correspondencia linear>fisica de cada proceso. Asi, si un proceso quiere acceder a la direccion FOO de memoria, el kernel consulta esa tabla y ve que es la direccion BAR de memoria fisica. Realmente este esquema es algo más complejo de explicar pero con estas nociones se puede llegar a entender basicamente que es lo que se hace, por ejemplo también se hace uso de TLB’s para guardar las traducciones de direcciones lineales a direcciones físicas, recordar unicamente que estamos en un sistema con segmentación paginada y mediante segmentación se hace la traducción a direcciones lineales y por medio de paginación a direcciones físicas mediante la consulta de tablas diferenciandose de si estamos trabajando en modo extendido o no y variando el tamaño de página entre estas, en este caso no habrá que complicarnos porque linux utiliza tamaño de páginas de 4kb’s. Continuando con lo de antes, los procesos pueden compartir memoria. Es decir, la dirección X de un proceso y la Y de otro pueden ser la direccion física Z. El problema viene cuando el kernel necesita liberar memoria física RAM y decide liberar la página Z porque no se usa, tiene que marcar esas direcciones en cada tabla y por medio del bit Present se indica si está en memoria o swap. Posteriormente entonces, se tienen que recorrer _TODAS_ las tablas de paginas de procesos, para encontrar que procesos tienen mapeadas esa memoria Z. Esto esta muy bien si hay 2 procesos, pero imaginemos 1000 procesos compartiendo 1 GB de memoria, la sobrecarga de CPU que esto implica es sencillamente inmensa, produciendo sobrecargas de O(2^n) en algunos casos. Con rmap, lo que se hace es conservar una tabla de paginas fisicas->lineares. Es decir, cuando el kernel quiera liberar la pagina Z; rmap le contestará que los procesos a, b y c lo estan usando, con lo cual la sobrecarga de CPU en esos casos de los que hablabamos se reduce enormemente. Esto tiene sus costes, como todo, y es que las tablas de páginas ocupan un tamaño. Sin embargo, este esquema no sólo permite reducir la carga de CPU en esos raros casos, sino que permite hacer decisiones más avanzadas a la hora de decidir si una página hay que llevarsela a swap o no, si se ha utilizado recientemente, la edad de la página, etcétera. Esta es la parte del parche de rmap que se ha incluido en 2.5.x de Rik van Riel junto con otras optimizaciones que conforme nuevas versiones del 2.5.x van saliendo se van incorporando. 14 El kernel linux 2.6: Presente y futuro. 9. Nuevas implementaciones de hilos en espacio de kernel. Al respecto del soporte de multithreading, aparte de la aparición "nocturna, alevosa y por sorpresa" de NPTL, tenemos NGPT (la implementación de threads M:N de IBM), que en su reciente versión 2.2 parece que recupera el terreno perdido con respecto a NPTL en el campo de la velocidad de ejecución. Ahora mismo en 2.5.x parece haber soporte para dos tipos de hilos. A principios de 2.5.4 se integró una versión "antigua" de NGPT (http://oss.software.ibm.com/developerworks/opensource/pthreads/), de IBM, con modelo M:N. Posteriormente en 2.5.32 se integró una versión preliminar de NPTL, la implementación de threads 1:1 de Ingo Molnar y los desarrolladores de libc. En aquel momento se publicaron tests donde supuestamente NPTL era lo mejor desde el pan en rodajas (sliced-bread que dicen ellos ;-), pero hace pocas semanas IBM publicaba la versión 2.2.0 de NGPT donde afirman que han recuperado la diferencia de rendimiento con respecto a NPTL. Vaya usted a saber qué implementación es mejor o más conveniente, eso lo tendrán que decir los que sepan de eso, pero lo bueno es que la competencia mejora ambos proyectos y para dentro de unos meses Linux tendrá buen soporte de threads, que tantas veces la gente ha echado de menos (ahora las aplicaciones en Java irán como un tiro, salvo que la gente se crea las opiniones de la propia SUN acerca de "qué bueno" es el Java y "cuánto" lo recomiendan). 10. Trabajo en la vm y capa de buffers por Andrew Morton. Andrew Morton (de mano de Digeo, www.digeo.com) ha trabajado mucho esta parte del kernel. Sin duda, va a a tener buena parte de la culpa de que el 2.5 se "sienta" mucho mejor de cara a lo usuarios (junto con preempt). Este hombre ha reescrito gran parte de la capa de buffers, gestión de memoria, y ha dedicado gran parte del tiempo a muchas notables mejoras. El resultado es sencillamente, impresionante. Pegaré aquí el extracto de un post suyo a la lista del kernel como ejemplo: "Most of the VM gains involve situations where there are large amounts of dirty data in the machine. This has always been a big problem for Linux, and I think we’ve largely got it under control now. There are still a few issues in the page reclaim code wrt this, but they’re fairly obscure (I’m the only person who has noticed them ;)) (La mayor parte de las ganancias en la VM son bajo situaciones donde hay muchos datos "sucios" en la maquina. Esto siempre ha sido un gran problema, y creo que lo tenemos bastante bajo control ahora. Hay unos pequeños problemas en el codigo de recuperacion de paginas mientras escribo esto. Son muy oscuras (de hecho soy el unico que las ha notado ;)) There are some things which people simply have not yet noticed. (Hay algunas cosas que la gente simplemente no ha notado) Andrea’s kernel is the fastest which 2.4 has to offer; let’s tickle its weak spots: (El kernel de Andrea (Arcangeli) es lo más rápido que 2.4 tiene para ofrecer, vamos a mirar uno de sus puntos débiles) Run mke2fs against six disks at the same time, mem=1G: (Ejecutar mk2fs contra seis discos a la vez, memoria 1GB) 2.4.20-rc1aa1: 0.04s user 13.16s 0.05s user 31.53s 0.05s user 29.04s 0.05s user 31.07s 0.06s user 29.80s system system system system system 51% 63% 58% 62% 58% cpu cpu cpu cpu cpu 25.782 49.542 49.544 50.017 50.983 total total total total total 15 El kernel linux 2.6: Presente y futuro. 0.06s user 23.30s system 43% cpu 53.214 total 2.5.47-mm2: 0.04s user 2.94s 0.04s user 2.89s 0.05s user 3.00s 0.06s user 4.33s 0.06s user 4.35s 0.04s user 4.32s system system system system system system 48% 39% 37% 43% 42% 32% cpu cpu cpu cpu cpu cpu 6.168 total 7.473 total 8.152 total 9.992 total 10.484 total 13.415 total Write six 4G files to six disks in parallel, mem=1G: (Escribir seis archivos de 4GB a seis discos en paralelo, memoria 1 GB) 2.4.20-rc1aa1: 0.01s user 63.17s 0.05s user 63.43s 0.03s user 65.94s 0.01s user 66.29s 0.08s user 63.79s 0.09s user 65.22s system system system system system system 7% 7% 7% 7% 7% 7% 2.5.47-mm2: 0.03s user 53.95s 0.03s user 58.11s 0.02s user 57.43s 0.03s user 54.73s 0.03s user 54.72s 0.03s user 46.14s system system system system system system 39% 30% 30% 23% 23% 14% cpu cpu cpu cpu cpu cpu 13:53.26 14:07.17 14:36.25 14:38.01 14:45.09 14:46.95 cpu cpu cpu cpu cpu cpu 2:18.27 3:08.23 3:08.47 3:52.43 3:53.22 5:29.71 total total total total total total total total total total total total Compile a kernel while running ‘while true;do;./dbench 32;done’ against the same disk. mem=128m: (Compilar un kernel mientras se ejecuta ‘while true;do;./dbench 32;done’ contra el mismo disco. Memoria=128m) 2.4.20-rc1aa1: Throughput 17.7491 MB/sec (NB=22.1863 MB/sec 177.491 MBit/sec) Throughput 16.6311 MB/sec (NB=20.7888 MB/sec 166.311 MBit/sec) Throughput 17.0409 MB/sec (NB=21.3012 MB/sec 170.409 MBit/sec) Throughput 17.4876 MB/sec (NB=21.8595 MB/sec 174.876 MBit/sec) Throughput 15.3017 MB/sec (NB=19.1271 MB/sec 153.017 MBit/sec) Throughput 18.0726 MB/sec (NB=22.5907 MB/sec 180.726 MBit/sec) Throughput 18.2769 MB/sec (NB=22.8461 MB/sec 182.769 MBit/sec) Throughput 19.152 MB/sec (NB=23.94 MB/sec 191.52 MBit/sec) Throughput 14.2632 MB/sec (NB=17.8291 MB/sec 142.632 MBit/sec) Throughput 20.5007 MB/sec (NB=25.6258 MB/sec 205.007 MBit/sec) Throughput 24.9471 MB/sec (NB=31.1838 MB/sec 249.471 MBit/sec) Throughput 20.36 MB/sec (NB=25.45 MB/sec 203.6 MBit/sec) make -j4 bzImage 412.28s user 36.90s system 15% cpu 47:11.14 total 2.5.46: Throughput 19.3907 MB/sec (NB=24.2383 MB/sec 193.907 MBit/sec) Throughput 16.6765 MB/sec (NB=20.8456 MB/sec 166.765 MBit/sec) make -j4 bzImage 412.16s user 36.92s system 83% cpu 8:55.74 total 16 El kernel linux 2.6: Presente y futuro. 2.5.47-mm2: Throughput 15.0539 MB/sec (NB=18.8174 MB/sec 150.539 MBit/sec) Throughput 21.6388 MB/sec (NB=27.0485 MB/sec 216.388 MBit/sec) make -j4 bzImage 413.88s user 35.90s system 94% cpu 7:56.68 total - fifo_batch strikes again It’s the "doing multiple things at the same time" which gets better; the straightline throughput of "one thing at a time" won’t change much at all. (Es el "Haciendo muchas cosas al mismo tiempo" lo que mejora; la linea de rendimiento de "una cosa a la vez" no cambiara mucho) A pesar de que parezca que para máquinas de escritorio normales los cambios no afectan, no teneis más que probar el 2.5 para comprobar que no es así. No olvidemos que el "hacer muchas cosas a la vez" implica threads; simplemente haced un recuento de procesos en GNOME para ver que ya estamos haciendo muchas cosas al mismo tiempo. El kernel 2.5 se comporta mucho mejor que el 2.4 en todo lo referente a VM/disco; se nota mucho más desahogado, más rápido. Siempre se dijo que la gestión de memoria del sistema GNU/Linux era de un nivel "medio". Mi opinion es que a partir del 2.6 la cosa va a cambiar. Tambien hay que resaltar otro párrafo de Andrew Morton en ese mismo mensaje: For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. Quite a lot of work has gone into "fairness" issues: allowing tasks to make equal progress when the machine is under load. Not stalling tasks for unreasonable amounts of time, etc. (Para uniprocesadores y pequeños servidores, habra ganancias significantes en algunos casos esquina. Y algunas pérdidas. Bastante del trabajo ha ido en problemas de "limpieza": Permitir a tareas hacer igual trabajo cuando la maquina esta bajo carga. No "parar" las tareas por espacios de tiempos irrazonables) Y en esto se incluye el scheduler de Ingo Molnar: el 2.5 se asegura de ser más justo con los procesos. En el 2.4, un proceso se le permitiría hacer algo (por ejemplo escribir al disco) más de lo que debería cuando hay otros procesos, etcétera. Siendo así dicho proceso es más rapido, pero más "sucio". Hay que dar iguales oportunidades a todos los procesos, y esto si que beneficia muchas veces. Por ejemplo, dos procesos leyendo simultaneamente, si a uno se le deja leer demasiado, el otro podria quedarse esperando. Mientras que si se les da a ambos mas igualdad, los dos procesos podran hacer trabajo, en vez de estar uno trabajando y otro haciendo nada. Aun asi, la sensacion en cuanto a gestion de memoria/disco en 2.5 es significantemente mejor. Las ventanas no tardan tanto en redibujarse muchas veces; porque se asegura que todos los procesos (incluidos los de las ventanas) se lleven su porción de recursos correctamente. 11. Cambio del sistema de configuración a CML2. Otros de los cambios importantes en el kernel 2.5.x ha sido la reescritura de todo el sistema de configuración conocido de la rama kbuild adaptando lo que previamente era conocido como CML1 a CML2, esta parte ha sido escrita por Eric S. Raymond y Keith Owens y supone de cara al usuario un avance muy importante. Con este cambio el usuario no se va a tener la necesidad de tener que escribir multiples comandos al compilar el kernel, con un make install será suficiente para compilar nuevos kernels debido al nuevo sistema de configuración recientemente añadido. Además otros de los cambios al sistema de configuración ha sido en la interfaz gráfica, ahora en vez de make xconfig y tener una interfaz gráfica en XLib podemos mediante gconfig y kconfig tener una interfaz gráfica más integrada tanto para GNOME con gtk+ como con KDE con las librerias QT. 17 El kernel linux 2.6: Presente y futuro. 12. Soporte Hiperthreading Una de las características que también se han añadido en el kernel 2.5, es el soporte hiperthreading para aquellas máquinas que lo soporten, especificamente en ordenadores personales más de cara al usuario como podría ser el Pentium Xeon. Para entender bien lo que es hiperthreading habría que entender a su antecesor, se tata de superthreading que se basa en lo que es la multitearea o multitasking. Como muchos sabréis un procesador da la impresión de que todo lo analiza secuencialmente, pero en realidad lo que hace el procesador es una replanificación de las instrucciones, es a lo que se llama hacer una ejecución fuera de orden (OOE) que es la que usan la mayoría de las arquitecturas cuando compilamos un programa y lo ejecutamos de forma que se usen al máximo los recursos del procesador. De cara al programador no se sabe como se ejecutarán internamente todas las instrucciones, se suele decir que se trata de una caja negra para tanto el programador como el usuario. Lo mismo ocurre cuando ejecutamos varios programas, sólo uno se puede ejecutar por el procesador, ahí es donde entra en juego lo que se llama la multitarea que nos hace pensar que varios programas se están ejecutando en la CPU, sin embargo como ya sabreis se le asigna un cuanto de tiempo que hace que en determinado momento se expida el proceso de la CPU, en espacio de kernel ahora posible gracias al parche preempt del kernel, con esto sólo aclarar el concepto de multitarea sin entrar en detalles. El cuanto de tiempo es posible llevarlo a cabo por el sistema operativo, pero internamente la CPU tiene un «time slice» definido. 13. CryptoAPI En 2.5.x se ha introducido lo que se conoce como CryptoAPI, este proyecto nació a partir de lo que era el proyecto kerneli que trataba de encriptar sistemas de ficheros mediante el dispositivo loop por medio de AES, el archiconocido algoritmo Rhijndael. Posteriormente a raiz de este proyecto lo que se hizo fue implementar un amplio número de algoritmos criptográficos dentro de espacio de kernel en la que mediante una API sencilla se pudiese cifrar y descifrar por medio de distintos algoritmos como DES, RSA, RC, SHA, MD5 entre otros. Como consecuencia esto facilitará labores como el cifrado de sistemas de ficheros, implementación de tarjetas criptografícas y la propia de implementación de VPN’s por medio de IPsec sin la necesidad de usar freeswan y utilizando directamente lo que es la propia CryptoAPI. 14. Linux Security Modules (LSM) Este proyecto surgió en la Linux Kernel Summit a raiz de que en marzo del 2001 la agencia de seguridad nacional dio una charla dando a conocer lo importante que sería la seguridad dentro del kernel linux, a raiz de esto surgieron varios proyectos que acabaron juntandose y dandose a conocer como LSM, ya que en si formaban un conjunto de módulos que se adaptaban dentro del kernel de la misma forma que lo hacían los LKM’s o modulos del kernel de Linux. Estos módulos de lo que se encargaban era de introducir una serie de ganchos o hooks dentro del kernel para que se realizase de forma totalmente segura determinadas operaciones en el kernel relativas a operaciones con ficheros, inodos, gestión de I/O filtrado de paquetes en netfilter y así un largo etcétera, todo esto llevado por medio de lo que era una syscall llamada security (sys_security()) y lo que eran las operaciones de seguridad conocidas como security_operations. Este proyecto fue liderado por Wirex, incluyendo todos los proyectos previamente ya hechos como eran Inmunix, SELinux, SGI y Janus por medio de desarrolladores como Greg HG (mantenedor de USB) y James Morris (desarrollador de la CryptoAPI) y finalmente en 2.5 Linus los incluyó dentro de la rama oficial del kernel. 18 El kernel linux 2.6: Presente y futuro. Otras de las características importantes es que se ha movido todas las capabilities dentro de LSM, estas son las encargadas de que se realicen de forma segura ciertas operaciones, por ejemplo, para poder cargar un módulo u otra operación relacionada necesitamos que esté activado CAP_SYS_MODULE, al igual que esto hay una gran rama de capabilities dentro de security/capability.c. 15. Soporte Bluetooth La tecnología bluetooth para la interconexión entre dispositivos vino dada por dos proyectos conocidos como Blues y OpenBT, el primero previamente añadido dentro de la rama estable del kernel 2.4.x soportando los tres tipos de pila bluetooth disponibles junto a todos sus servicios. El proyecto OpenBT se está planteando añadir dentro de la rama del kernel, es totalmente portable a numerosas arquitecturas al igual que añade mejoras sobre la pila implementada en 2.4 con el proyecto Blues. Así que en cuanto a comentar de la tecnología Bluetooth es el añadido de nuevos drivers al igual que la escritura de la capa que venía dada en 2.4 por el proyecto Blues consiguiendo un mayor soporte para la interconexión de dispositivos por medio de esta tecnología sin cables conocida como Bluetooth. 16. Otras características del kernel 2.5.x Son muchas las mejoras que nos ofrece el kernel 2.5.x y todas muy extensas de tratar, por lo que aquí comentaré brevemente otras de las funcionalidades que se le han añadido. Así características añadidas son el soporte para dispositivos que usen USB 2.0 que nos permite unas tasas mayores de transferencias gracias a la implementación de esta nueva especificación, el soporte para AGP 3.0, la inclusión de ACPI en sustitución de lo que venía siendo APM, una mejora en el soporte de sonido gracias a ALSA en sustitución de OSS, reescritura de la API de framebuffer, el uso de la Linux Console con soporte para todo tipos de fuentes, fribidi, reescritura de la capa de tty’s . el nuevo planificador de I/O añadido conocido como anticipatory scheduller que mejora la escritura/lectura haciendo que se consigan tiempos de latencia muy pequeños al igual que el deadline scheduller por Andrew Morton. Luego también comentar la inclusión de otros sistemas de ficheros como XFS, ReiserFS, JFS, reescritura de la capa IDE, soporte para arquitecturas de 64 bits como Opteron, Hammer, PPC64, mejora en algunos sistemas de ficheros como smbfs para Samba, hotplugging de CPU, uso de futuxes y soporte para TLS. 17. Conclusiones del kernel 2.5 En definitiva, esta es la primera ronda de novedades que nos trae el 2.5. Supongo (y no me equivoco) que hay gente todavia que no ha probado el 2.5. La mayoria de las veces es miedo a que algo no funcione, a que haya corrupcion o que exista un problema relacionado por pensar que al ser una rama inestable va a ocasionar problemas. Decir lo siguiente: 1. Yo personalmente utilizo 2.5 en esta máquina; y lleva casi 12 horas, y así hace todos los días, no negare que de vez en cuando se me ha colgado, pero lo que hacia colgarlo ultimamente ha desaparecido. Ahora mismo sin ningún tipo de problema tiene un uptime de 15 días con 2.5.64. 2. Un oops no hace daño a nadie, simplemente es un oops. 3. Si encuentras un bug, oops, REPORTALO. Es la mejor manera de que entre todos mejoremos el kernel. 19 El kernel linux 2.6: Presente y futuro. 4. Corrupción de disco: A pesar de los cambios que ha habido en todo este campo, (todo lo relacionado a vm, disco, sistemas de ficheros (recordar el htree orlov allocator y ACLs, nuevos juguetes para el ext3), los desarrolladores han sabido llevarlo maravillosamente bien, y no ha habido grandes bugs que hayan comido disco misteriosamente. A mi personalmente nunca me ha pasado nada, pero también porque he tenido un poco de precaución, cuando sale un nuevo kernel, espero un tiempo prudencial en espera de que aparezcan bugs, Si lo hubiera, me enteraría y no lo pondría, aparte no olvidemos que ahora Linus utiliza bitkeeper y que (a pesar de lo que Stallman y puristas puedan decir al respecto) ahora la gente prueba snapshots del árbol de Linus actualizados cada noche (se encuentran en kernel.org, en el subdirectorio snapshots; por no decir que los de bitkeeper parece ser que planean poner un cvs para que los "puristas" puedan estar al dia con su cvs). Aparte, practicamente todos los parches relacionados con este tema, pasan previamente a traves del patchset de Andrew Morton (el famoso -mm), que mucha gente prueba y donde se detectaría primero cualquier problema. En definitiva que si os sentis animados, echeis un vistazo al 2.5 y a todo lo nuevo que trae. Asi, podreis ayudar si econtrais algun bug. Como requerimientos no tiene anda especial; si recalcar que ahora hay nuevas utilidades de modulos, y que las viejas no funcionaran. Hay para debian sid un paquete; module-init-tools, en http://www.kernel.org/pub/linux/kernel/people/rusty/modules/ hay fuentes y rpms tambien. Un magnifico documento ( y ampliacion de este en muchos aspectos) si sabeis ingles es http://www.codemonkey.org.uk/post-halloween-2.5.txt , una especie de Guia de transicion al 2.5 (que cosas nuevas hay de cara al usuario, etc) de mano de Dave Jons (de suse). Mas documentos sobre el 2.5 estan en www.kernelnewbies.org/status, pagina de un proyecto que deberia estar en todos los bookmarks de aquellos que se manejen con el ingles ;) Entre otras cosas interesantes comentar el deadline io-scheduler, todas las novedades en drivers, apis, la ya no necesidad ide-scsi para grabar cds, UML, sysfs, oprofile y así un largo etcétera. Luego comentar que se ha formado una comunidad de hispanohablantes referente al desarrollo del kernel de linux, podeis visitar la página web en http://es.kernelnewbies.org, apuntaros a la lista de correo o bien visitar el canal #kernelnewbies-es de la red de irc openprojects. 18. Referencias. http://www.kernelnewbies.org: Proyecto kernelnewbies. http://es.kernelnewbies.org: Proyecto kernelnewbies en castellano. http://www.kerneljanitors.org: Proyecto kerneljanitors. http://www.kerneltrap.org. Foro de noticias. http://www.lwn.org. Noticias semanales acerca de GNU Linux. http://www.kernelnewbies.org/status. Estado actual del kernel. http://www.kernelnewbies.org/mailinglists: Listas de correo. http://listas.hispalinux.es: Lista nucleo-desarrollo correspondiente a kernelnewbies-es. 20 Cherokee Web server Alvaro López Ortega Madrid España [email protected] Cherokee es un proyecto que implementa una librería para poder dotar a toda clase de aplicaciones de servicios web de una forma fácil y rápida. En su desarrollo se realiza un esfuezo especial en mantener un core reducido - de forma que se pueda utilizar en sistemas empotrados - e implementar todas las funcionalidades como módulos cargables en tiempo de ejecución. De igual forma, la alta eficiencia y una arquitectura lo suficientemente flexible como para poder escalar a servidores SMP son características de Cherokee que pueden suponer un paso adelante respecto a los servidores web libres existentes. 1. Introducción Desde hace años, la tecnología que rodea la web tiene una importancia grandísima. Alrededor de esta tecnología se han producido grandes batallas; en unos casos por pura y sana competencia con productos que implementan una funcionalidad similar y en otros por el interés de romper los estándares. Sin ninguna duda, el vencedor indiscutible de esta batalla es Apache, un servidor web libre, que a día de hoy utiliza casi el 65% de los servidores en Internet. Cherokee es otro servidor web. Se trata de un proyecto que desarrolla una nueva implementación de este tipo de aplicación, con una serie de características y funcionalidades concretas. El fin último del proyecto no es clonar ni imitar las funcionalidades de Apache, trabajo que sería sumamente complejo e innecesario, sino hacer un servidor con unas características de las que Apache carece debido a su diseño original. Las funcionalidades de Apache son muchas y a estas hay que sumarle las que aportan los módulos y extensiones. El resultado es el que conocemos, Apache es un servidor web que puede hacer casi cualquier cosa con una flexibilidad y velocidad razonables. Ahora bien, todas estas caracteristicas positivas tienen un coste: que en algunos casos se trata de un servidor lento, que no fue diseñado como un servidor para ser empotrado, etc. En el diseño de Cherokee se han tenido en cuenta todos estos puntos en los que creíamos que Apache flaqueaba. Se ha puesto especial interés en los tres puntos siguientes: velocidad, flexibilidad y capacidad de ser empotrado. La velocidad es un punto básico en Cherokee. En el último benchmark realizado hasta el momento (http://www.alobbs.com/news/104), Cherokee fue cinco veces más rápido que Apache. Este es un punto importante a tener en cuenta para la elección del software de un sitio web con mucho tráfico (por ejemplo, un servidor de banners). Posiblemente, gracias al cambio de software, se aplace la necesidad de actualización del hardware del servidor. El segundo de los puntos en los que se ha hecho especial énfasis en el diseño de Cherokee es la flexibilidad. En este respecto Cherokee dispone de un sistema para la carga dinámica de módulos (como el soporte mod_* de Apache) ISBN 84-88783-66-3 ©2003 21 Cherokee Web server tanto para handlers como encoders y sistema de logging. Siempre que se han añadido nuevas funcionalidades, se ha hecho de la forma más modular posible: a día de hoy, prácticamente cualquier nueva característica será implementada como un módulo cargable que Cherokee utilizará o no dependiendo de la configuración de este. La última característica que se cuida con gran interés en el desarrollo de Cherokee es la capacidad para ser empotrado dentro de otras aplicaciones. Todo el código con la lógica del servidor se encuentra en una librería dinámica que puede utilizar cualquier aplicación. El API de esta librería es muy sencillo; básicamente permite crear, configurar y ejecutar de diferentes formas objetos "servidor". Existe una aplicación (http://freshmeat.net/projects/gnome-cheroke) para GNOME2 que implementa un servidor web personal (http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gnome-network) basándose en la librería de Cherokee. 2. Cherokee para los usuarios A día de hoy, Cherokee tiene tanto ventajas como inconvenientes para los usuarios. Hay que tener en cuenta que se trata de un software que actualmente sigue en desarrollo y que hay funcionalidades no terminadas sobre las que se continua trabajando. Por otro lado, se trata de un proyecto con más de dos años de vida y presenta algunas grandes ventajas sobre otras opciones. El principal inconveniente que tiene Cherokee hoy en día desde el punto de vista de un usuario final es la necesidad de un par de módulos importantes para servir contenidos dinámicos: PHP y Python. Nota: Este artículo está escrito en Septiembre del 2003, en estos momentos ya hay trabajo realizado en la implementación de ambos módulos. Es probable que para la fecha de la celebración del congreso al que va dirigido el paper (III Jornadas Andaluzas de Software Libre) ambos módulos estén terminados, probados y funcionando. Por otro lado, también existen ventajas para los usuarios finales. La velocidad para servir las páginas se plantea como la principal de ellas; crea menos carga en máquinas pequeñas o desde otro punto de vista, admite más peticiones por segundo en máquinas que funcionen al limite. Otra ventaja a tener en cuenta es que al tratarse de un servidor pensado para ser empotrado, es posible desarrollar sencillas interfaces gráficas con las que recubrirlo para que el usuario final trabaje con una herramienta mucho más amigable y no con ficheros de texto con muchas sentencias que es posible que no entienda. GNOME-Network utiliza actualmente libcherokee para implementar su aplicación de servidor web personal. Por último, Cherokee al igual que Apache, pero al contrario que al gran mayoria de servidores web libres, escala a servidor SMP y máquinas con hyperthreading. La implementación del servidor tiene una visión doble: por una parte realiza servicio de peticiones mediante time-slices, pero por la otra es capaz de manejar más de un thread y en cada uno de ellos, de nuevo, volver a procesar conexiones mediante compartición de tiempo. De esta forma Cherokee escala a máquinas con más de un procesador y al mismo tiempo mantiene el rendimiento de los servidores basados en select() o poll(). Respecto a la implementación de time-slice de Cherokee, soporta poll(), epoll() (GNU/Linux 2.6.0 o superior) y emulación de poll() mediante select() para los sistemas en los que no existe función poll() en el sistema (MacOS X, por ejemplo). 22 Cherokee Web server Figura 1. Benchmark, Cherokee 0.4.3 3. Características principales La librería de cherokee, libcherokee, implementa las características básicas de un servidor web, permitiendo cargar desde módulos muchas otras. Esta arquitectura modular ha sido elegida para permitir cargar y ejecutar únicamente las partes y funcionalidades que sean necesarias en cada caso concreto. De esta forma, se ahorran recursos, se aumenta la seguridad (menos código en ejecución implica menos posibilidad de existir un bug en él) y se disminuye ligeramente la carga del servidor web. Hay tres grandes grupos de módulos cargables: handlers, encoders, validators. Los handlers son manejadores de peticiones. Cuando el servidor procesa una petición, decide que clase de manajedor debe de utilizar para responder a dicha petición. Dependiendo de el módulo, la respuesta será una u otra. Cherokee incorpora el concepto de asociación de manejadores a directorios, de forma que el usuario puede definir que manejador desea utilizar en cada uno de los directorios servidos por web. Actualmente, se distribuyen los siguientes manejadores dentro del paquete principal de Cherokee: 1. file: Sirve ficheros al cliente 2. dirlist: Construye una página con lista de los ficheros contenidos en un directorio 3. redir: Redirecciona peticiones 4. nn: Basado en el algoritmo de "Near Neighbors" atiende las peticiones recibidas con una respuesta simple positiva 5. gnomevfs: Utiliza las librería de GNOME-VFS para atender las peticiones, de forma que es posible que sea el servidor web el que exporte ficheros localizados en ubicaciones accesibles bajo otros protocolos: NNTP, 23 Cherokee Web server FTP, HTTP (en este caso trabajaría de proxy), etc. Los encoders por su parte, son módulos que implementan una funcionalidad de conversión de la información que se va a enviar a los clientes. Actualmente, el encoder más útil es el de GZip. Este módulo comprime la información que se sirve antes de enviarla a los clientes, ahorrando ancho de banda y acelerando la transmisión. Los validadores son los módulos que implementan posibles formas de validar a los usuarios. En el momento de escribir este artículo (Septiembre 2003) se encuentran en desarrollo. Cherokee implementa módulos para validar con LDAP, PAM y htpasswd. Todos los módulos son configurables en tiempo de ejecución, normalmente mediante cadenas de texto que procesa libcherokee. 4. Cherokee para el desarrollador Desde el punto de vista de un desarrollador, Cherokee proporciona la librería (libcherokee.so) con la que dotar de las aplicaciones de servicios web. Para que un programa proporcione esta clase de servicios, lo único que tiene que hacer es linkar junto con esta librería y añadir un par de fragmentos de código adicionales. 1. La instanciación de un nuevo objeto servidor y la configuración de este. 2. El manejador (handler) o pasarela para que la aplicación exporte los datos que desee por medio de la interface web. La implementación de un nuevo manejador de peticiones no es una tarea larga; simplemente hay que implementar 5 métodos virtuales (Aunque Cherokee está escrito por completo en C, utilizamos conceptos de programación orientada a objetos ya que existe un grandísimo parecido entre estos conceptos y la implementación en Cherokee): new(), init(), free(), step() y add_headers(). De igual forma, es posible implementar nuevos encoders y validadores implementando otro pequeño número de métodos. Para consultar los nombres y los parámetros de estos métodos, se puede consultar la documentación de libcherokee o directamente los ficheros de cabezeras en el código fuente: handler.h, encoder.h o validator.h. 5. Rodmap Existe un roadmap (http://www.alobbs.com/news/124) publicado con los hitos cercanos en el desarrollo de cherokee. Al margen del desarrollo del core de Cherokee se está realizando la implementación de dos manejadores de especial importancia en el proyecto: 1. PHP4: De forma que todo el software disponible escrito en PHP se pueda utilizar bajo Cherokee. 2. Python: El objetivo de este manejador es en un primer momento, la implementación de server scripting basado en Python, y en un segundo paso la implementación de un conector para WebWare (http://webware.sourceforge.net). 6. Conclusiones Cherokee tiene dos facetas. En primer lugar la de servidor web, en la que se centra en la eficiencia y la flexibilidad; implementa las funcionalidades deseables en un servidor web moderno (http 1.1, gran modularización, compresión gzip, etc). 24 Cherokee Web server En su segundo enfoque proporciona un framework con el que dotar de funcionalidades web a las aplicaciones de una forma rápida y sencilla, de forma que cualquier aplicación pueda incorporar servicios Web. 25 Reciclaje y Software Libre: Una Solución para la Enseñanza Juan Pablo Sánchez Beltrán Presidente de TeSo, Telecomunicaciones Solidarias Las Tecnologías de la Información y de la Comunicación (TIC) proporcionan un conjunto de herramientas básicas para la sociedad actual. Su uso mejora la calidad de vida, la cohesión social, facilita el desarrollo, etc. pero exigen disponer de: • Información: que son y para que sirven. • Formación (reglada y no reglada): conocer cómo funcionan, se usan, se mantienen y se desarrollan. • Medios: hardware, software y enlaces de comunicación. • Contenidos: servicios útiles para el usuario. Para disponer de estos cuatro elementos es necesario realizar unas inversiones iniciales para la adquisición de los medios, etc. que permitan iniciar el uso de las TIC y posteriormente, y de forma periódica, realizar inversiones para mantener actualizados los conocimientos y los medios. 1. La Brecha Digital En España el parque de ordenadores personales en 2003 está alrededor de los 15 millones de unidades y se compran 1,5 millones más anualmente. Entre el 30 y el 50% de las compras se destinan a la sustitución de ordenadores obsoletos, mientras que en Estados Unidos se destinan a este fin el 75% de las nuevas adquisiciones. Por otra parte en España el número de ordenadores personales por cada 100 habitantes es de unos 37, porcentaje que es casi la mitad del existente en Estados Unidos, o visto de otra forma, estamos en los niveles que tenía Estados Unidos en 1995. España desde el año 1995 figura entre los tres países de la Comunidad Europea (CE) con menor uso de las TIC ( Ordenadores Personales, Internet, etc.) junto a Grecia y Portugal 1 Las altas inversiones necesarias para alcanzar los índices de uso de las TIC, de las que disfruta países como los Estados Unidos son prohibitivas para los países menos desarrollados, y un esfuerzo muy grande y prolongado para el resto de los países. Hay que tener en cuenta que si bien las TIC son un elemento importante, no es imprescindible, pues no es un bien de primera necesidad. Este hecho hace que sean precisamente los países ricos los únicos que disponen de recursos para invertir en TIC que a su vez le permitirán una mayor productividad y riqueza. Esta situación de desigualdad creciente en TIC entre países o grupos sociales se conoce como brecha digital. Además el desarrollo de las TIC está en manos de los países más ricos, por lo que además se crea una dependencia creciente de los países menos ricos al depender su desarrollo tecnológico de las importaciones de bienes del exterior. El problema de las pobrezas endémicas ha sido objeto de múltiples estudios y las soluciones propuestas pueden resumirse en: 1. http://europa.eu.int/information_society/eeurope/benchmarking/index_en.htm ISBN 84-88783-66-3 ©2003 26 Reciclaje y Software Libre: Una Solución para la Enseñanza • La implantación de modelos de desarrollos propios. • La financiación de los mismos a bajo coste o coste nulo. • El reaprovechamiento de los bienes y servicios. 2. Soluciones generales Los ordenadores son máquinas de propósito general por lo que un modelo puede servir para muchos fines, por ello la producción de un modelo único supone que los precios bajen a medida que aumenta la producción, siempre que el mercado no tenga imperfecciones. Esto se cumple en la práctica con el hardware, en el que incluso no valorando el efecto de la inflación, los precios disminuyen tanto de forma absoluta como relativa, pero no ocurre así con el software. Podemos encontrar cuatro tipos de soluciones que permiten la informatización: • • Modelo propietario de propósito general: Es el modelo más extendido en la actualidad. Se basa en el uso de una plataforma de propósito general denominada WINTEL compuesta por software basado en el Sistema Operativo Windows de Microsoft y hardware basado en los procesadores x86 de Intel y compatibles. La vida útil de este tipo de solución es de 4 años; con algún mantenimiento es posible alargarla hasta 8. El coste es de unos 600 a 1.800 ¤ para el Hardware (Pentium IV a 2,8 GHz, etc.) y de unos 900 ¤ para el software (Windows XP + Office XP), lo cual nos da un precio total que va de 1.500 a 2.700 ¤ por PC. Modelo propietario de propósito específico: En esta solución se elige un software específico 2 para el uso que se le va a dar al ordenador, por lo que los requisitos del hardware son menores. Con esta solución el recorte en el precio del hardware puede dividirse por 2 y del software por 6. El precio por unidad de este tipo de soluciones está sobre los 720 ¤. • Modelo abierto de propósito general: En este caso se usa software de código abierto y libre como por ejemplo LINUX y Open office. El coste del hardware es similar pero el del software puede dividirse por más de 20. El precio por unidad será menor a 660 ¤. • Modelo abierto de propósito específico: En el caso de hacer uso de una arquitectura adaptada a las necesidades3,el coste del hardware puede dividirse por más de 2 y el software por más de 20. Por lo que cada puesto de trabajo puede tener un coste menor a los 300 ¤. El software de código abierto y libre no requiere menos recursos que el software propietario, lo que si es cierto que únicamente evoluciona por necesidades técnicas y no comerciales, es decir no está presionado de forma artificial, por lo que los sistemas duran más. Duplicar la vida media es reducir a la mitad el coste de nuevas tecnologías. Por otra parte no es necesariamente gratuito pero facilita la creación de un mercado competitivo perfecto, por lo que los precios resultantes tiende a ser el precio del soporte físico, al ser una producción en serie. El uso de modelos abiertos, tanto de propósito general como específico, es una estrategia que están adoptando tanto gobiernos nacionales como regionales. 2. Ensembre Desktop de Breadbox (www.breadbox.com) es un software completo orientado a la educación que tiene un coste de 120 ¤ y usa DRDOS 7.2, un ordenador Audrey (www.audreyupgrade.com) viene a salir por unos 500 ¤. 3. Por ejemplo el ordenador Simputer (www.simputer.org) sale por menos de 300 ¤ la unidad y en un servidor LTSP (www.ltsp.org) puede facilitar puestos de trabajo por unos 60 ¤, etc. 27 Reciclaje y Software Libre: Una Solución para la Enseñanza 3. Soluciones en educación: ordenador reciclado + código abierto Hemos visto que las soluciones basadas en modelos abiertos de propósito específico son las más baratas, además estas soluciones en la enseñanza tienen una serie de valores añadidos que las hacen todavía más interesantes. La soluciones adoptadas hasta la fecha se han basado en modelos propietarios de propósito general, y con ellas los resultados han sido insatisfactorios4. Esto es debido a que con dicho modelo existe un margen muy estrecho para buscar soluciones: conseguir descuentos de los fabricantes, aumentar la inversión, optar por el renting frente a la compra para evitar la inversión inicial, implicar a la iniciativa privada 5, compartir el uso de los medios, etc. Reciclar ordenadores es por una parte alargar la vida del material informático que disponen los centros docentes, por otra resolver problemas medioambientales, pero también es el mejor final para los ordenadores obsoletos procedentes de otras instituciones, empresas y particulares6, dado que en España el mercado de segunda mano es escaso y el reciclaje es una actividad económica poco o nada rentable, por la cantidad mano de obra que necesita, aunque si es social o educativamente rentable. Además el reciclaje de ordenadores despierta un gran interés para los alumnos que disponen de ordenadores en casa y que ven en ello una aplicación inmediata, permite asentar la enseñanza teórica de la física (electricidad, magnetismo, óptica, etc.), es una actividad formativa técnica y una capacitación profesional que va acompañado de valores demás de llevara asociados valores ecológicos, trabajo en grupo, etc. El mejor complemento para un equipo reciclado es sin duda alguna el software libre por su coste prácticamente nulo, por la oferta tan amplia que existe y el gran número de soluciones que proporciona. Así podemos trabajar con LINUX en modo LIVE, compartiendo un equipo con otros sistemas opertivos o no, en modo autónomo o en modo cliente-servidor, en entorno de texto o en entorno gráfico con distintos niveles de requerimientos. Las soluciones basadas en software de código abierto son las más ventajosas económicamente, pero además tienen en la enseñanza valores adicionales como animar a la curiosidad, fomentar las vocaciones, capacitar profesionalmente, mantener los bienes públicos, etc. El software de código abierto/libre dispone de documentación completa que puede adaptarse libremente a las necesidades. Permite además participar en su mantenimiento y creación y conocer su funcionamiento además de llevar asociado valores como la cooperación, el trabajo en equipo, etc. Existen un gran número de asociaciones de usuarios de software libre en las que se pueden integrar alumnos y profesores. 4. Experiencias La UNESCO ha realizado este año un congreso precisamente sobre el uso de ordendores reciclados para la enseñanza7 y mantiene un portal en Internet dedicado al software abierto8. Las experiencias de reciclaje de ordenadores y software libre en educación son escasas en España, y todas ellas de los últimos años, algunas referencias sobre las mismas: • 4. 5. 6. 7. 8. Software abierto: Pequelin es una distribución LINUX LIVE orientada a los la educación de los más pequeños (www.espartakus.org ), Pedro Reina mantiene una WEB con abundante material para la enseñanza de la Informática en Secundaria (pedroreina.org/ ), Plan de la Junta de Extremadura (www.linex.org ), Decreto de la Junta de Andalucia (www.guadalinex.org ). Declaración de intenciones de la Generalitat Valenciana. 7,3 PCs/100 alumnos a tiempo parcial, con solamente el 43% de las conexiones con banda ancha. www.elmundo.es/navegante/2003/09/01/empresas/1063204763.html www.intel.com/education/recycling_computers/recycling.htm portal.unesco.org/es/ev.php@URL_ID=10325&URL_DO=DO_TOPIC&URL_SECTION=201.html www.unesco.org/webworld/portal_freesoft/index.shtml 28 Reciclaje y Software Libre: Una Solución para la Enseñanza • • Software abierto y reciclaje: Hay que destacar los trabajos de Antonio Quesada en la puesta en marcha de aulas LTSP en Canarias y Palencia9. A nivel institucional hay que destacar el proyecto desarrollado por la Universidad de Cadiz10 y el Decreto del Parlamento Andaluz11. Reciclaje: TeSo12 en Valencia (IES de Ondara y IES S. Vicent Ferrer de Algemesí) Sin embargo las experiencias en el extranjero son abundantes, y muchas de ellas se remontan al principio de los 90. 4.1. Software abierto LINUX • www.linuxforkids.org • www.seul.org/edu/ • www.riverdale.k12.or.us/linux/k12ltsp.html • www.bluelinux.org • www.debian.org/devel/debian-jr/ • www.canopener.ca (Canadian Open Source Education & Reseacrh) • www.linuxeduquebec.org 4.2. Escuelas con software libre • garneau.csdm.qc.ca/ • fleclerc.csdm.qc.ca/stagiaires/document.html 4.3. Escuelas con software libre y equipos reciclados • www.agers.cfwb.be (Ministerio de la Comunidad Francófona Belga) • www.hispalinux.net/casos.ntml?id=26 (IES Maria de la Guia-Canarias, Escuela infantil Corazón de MariaPalencia) 4.4. LTSP • www.ltsp.org • www.k12ltsp.org 9. 10. 11. 12. www.gulic.org www.uca.es/grup-invest/cit/ Decreto de Medidas de Impulso de la Sociedad del Conocimiento en Andalucía BOJA no 55 21-3-2003. www.renuevate.com/teso/ 29 Reciclaje y Software Libre: Una Solución para la Enseñanza 4.5. Recursos varios • www.schoolforge.net • www.ofset.org/freeduc/ • www.freshmeat.net/ 4.6. Reciclaje para la educación • www.opeq.qc.ca/ (Canada) • www.besanet.org.uk/ (Reino Unido) • www.crc.org (Computer Recycling Center - Estados Unidos, desde 1991) • www.c4kfoundation.org (Estados Unidos) • www.computers.fed.gov (CFL Computers For learning) • www.computer-aid.org (Reino Unido) • www.computerecycleforeduc.com/ (Estados Unidos) • www.emsc.nysed.gov/workforce/create/home.html (Estados Unidos - Nueva York) • www.microweb.com/pepsite/Recycle/India.html (India) • www.computersforschoolsontario.com (Canada-Ontario) 5. Conclusiones El modelo actual deinformatización WINTEL de los centros de enseñanzas ha mostrado sus limitaciones y carencias debido a los pocos recursos que se asignan en relación a los costes tanto iniciales como recurrentes. El uso del software libre es una opción estratégica básica en la enseñanza. El aprovechamiento de ordenadores reciclados es una opción barata y didáctica que permite disponer de una forma inmediata de sistemas informáticos para la enseñanza. Otra opción más valiente y a medio plazo pasa por la creación de todo el material didáctico en soporte digital y bajo licencia de contenidos abiertos13 y convertir el gasto en texto escolares que se aproxima a unos 200 ¤ anuales por alumno en la adquisición de ordenadores portátiles que quedarán en posesión de los alumnos y de sus familias14. 13. www.opencontent.org 14. www.landesinteractives.net 30 espiral de valores: técnicas avanzadas de programación PHP Diego Arranz Interactors Madrid España [email protected] Javier Linares Interactors Sevilla España [email protected] espiral de valores (http://espiraldevalores.org) es un lugar en Internet donde se debaten de forma organizada y colaborativa posicionamientos ante problemáticas sociales, políticas, medioambientales, etc. Cada uno de estos posicionamientos se denomina “valor”, y consiste en un texto con el planteamiento de un problema concreto y una propuesta de solución. El presente artículo explica las ideas y procesos colaborativos que hay detrás de esta web e introduce las metodologías y los correspondientes paquetes de software libre utilizados en el desarrollo. También se esbozan algunas futuras líneas de desarrollo que ampliarían en gran medida las posibles aplicaciones de la herramienta. 1. Introducción Internet está llena de foros de debate sobre sociedad, política, religión, etc. Millones de lugares virtuales donde tienen lugar trillones de debates y discusiones. Se trata sin duda de una de las mejores aplicaciones a nivel social de Internet. Sin embargo, detrás de la espiral de valores está la convicción de que es necesario dar un paso más allá de este tipo de foros. Al fin y al cabo, un foro virtual no es más que una gran cantidad de datos, argumentos y opiniones en un formato que hace prácticamente imposible la consulta de algo determinado pasado un tiempo. La espiral de valores es un esfuerzo que pretende dar con un modo más productivo de canalizar todas esas energías desparramadas a lo largo de tanto debate y discusión prácticamente estéril. Se trata de un piso más, edificado sobre un foro virtual. Aporta un proceso de debate orientado hacia la consecución de consensos, y una herramienta que permite referenciar, organizar y reutilizar los resultados de los debates, ya sean definitivos o parciales. ISBN 84-88783-66-3 ©2003 31 espiral de valores: técnicas avanzadas de programación PHP 1.1. Un poco de historia espiral (http://lawebespiral.org) nace en mayo de 2001 con el objetivo de introducirse legalmente en entornos políticos, mediáticos y corporativos promocionando posibles futuros más sostenibles y humanos. Se trata de una organización abierta, transparente y descentralizada, que utiliza Internet como herramienta principal de comunicación. espiral de valores surge en abril de 2002 como proyecto de espiral, tomando como inspiración el proyecto Open Directory Project (http://dmoz.org), directorio de páginas de Internet descentralizado, mantenido por voluntarios. La idea inicial era crear un directorio de posicionamientos, a la vez que un espacio participativo de reflexión y diálogo, y así afrontar mejor los debates teóricos sobre un futurible programa electoral del partido espiral, ya reconocido legalmente por aquellas fechas. 1.2. Objetivos Aunque no contemplados desde el principio, con el tiempo se fueron haciendo evidentes una serie de objetivos que podía intentar cumplir el proyecto: 1. Servir de ayuda a los debates y acciones de personas y colectivos dentro y fuera de espiral. 2. Ofrecer una visión condensada y organizada de los muchos esfuerzos que llevan a cabo multitud de personas y organizaciones en pos de un mundo mejor. 3. Proveer de una base teórica al desarrollo de denuncios, es decir, anuncios que no venden nada sino que denuncian un determinado problema. 4. Ofrecer a la comunidad de software libre una herramienta que puede servir como base para proyectos software más ambiciosos en campos como la gestión de contenido o la democracia participativa. 5. Demostrar que el compromiso social o el uso de software libre no son incompatibles con el uso de avanzadas metodologías y herramientas software. 2. Valores y debates Los valores son las unidades de información básicas. Son como los ladrillos que forman un edificio. Cada valor debe contener en su texto el planteamiento de un problema más o menos concreto y una propuesta de solución. Todos los valores son el resultado de un proceso de debate abierto que tiene lugar en un foro virtual enlazado con la web. 2.1. Composición y organización de los valores Formalmente, cada valor se compone de un título, una descripción de uno o dos párrafos y una ampliación más detallada con argumentos a favor, puntos a profundizar, argumentaciones típicas en contra de la propuesta, etc. Es recomendable que incluya también enlaces con información adicional, organizaciones relacionadas con el valor, etc. Lo normal es que todo lo anterior se pueda imprimir en una sóla hoja de papel. A modo de ejemplo, algunos títulos de valores que pueden encontrarse en la web son: “Los ciudadanos tienen derecho a decidir a qué se destinan sus impuestos”, “Vidas sencillas” o “La ciencia y la tecnología están en nuestras manos”. Los valores se organizan por categorías y subcategorías y también según unos niveles de importancia. Cualquier persona puede participar en los debates que conducen a estos valores, así como proponer nuevos debates de 32 espiral de valores: técnicas avanzadas de programación PHP valores. La gestión y actualización del contenido se realiza de forma descentralizada, por medio de una serie de editores que, conectándose a la web mediante una clave, se ocupan de mantener la categoría que libremente han elegido. 2.2. El proceso de debate Aunque cualquiera puede participar en los debates de la forma que desee, hay unas normas en lo que se refiere a la presentación, discusión y aprobación de los valores. Este proceso está inspirado en la motivación principal que guía este proyecto: intentar siempre que sea posible llegar a consensos, no dejar los debates a medias. De forma resumida el proceso es el siguiente: Una vez formulado el valor cualquiera puede criticar, apoyar, corregir o añadir los aspectos que considere oportunos. El valor se debate el tiempo que sea necesario hasta llegar a un consenso. Para que sea oficialmente aprobado, cuatro o más participantes deben dar su apoyo explícito a la redacción del valor. Más adelante, es posible reabrir el debate y modificar el texto si alguien lo cree necesario. Cada editor es el responsable de dinamizar la categoría que eligió, presentando valores a debate, procurando que los propuestos por otras personas lleguen a buen puerto y actualizando la información de la web en consecuencia. 3. Metodología Modelo-Vista-Controlador Las aplicaciones web se programan según algún lenguaje de programación para servidor, por ejemplo PHP, JSP o ASP. Estos lenguajes permiten mezclar en cada fichero código de presentación (normalmente HTML) y código de programación de cualquier tipo (construcciones simples, uso de objetos, comunicación de bases de datos), de forma sencilla y flexible. Sin embargo, cuando las aplicaciones adquieren un tamaño considerable, si no se ha seguido alguna metodología de desarrollo puede resultar una pesadilla revisar el código para solucionar errores o añadir nuevas funcionalidades. Lo que requieren la mayoría de aplicaciones web es una forma correcta de organizar el código en componentes que tengan funciones claras, como alternativa al habitual código “spaghetti” en el que todo está mezclado. La idea en la que se basa la metodología MVC (http://www.ulpgc.es/otros/tutoriales/java/Apendice/arq_mvc.html) es que los aspectos visuales de un sistema deberían estar aislados del funcionamiento interno, que a su vez debería estar separado del mecanismo de coordinación global de la aplicación. A continuación se expone la arquitectura de componentes, con un esquema de esta metodología y una explicación de cada parte, y más adelante se hace un recorrido por el código, siguiendo el flujo del programa. 33 espiral de valores: técnicas avanzadas de programación PHP 3.1. Arquitectura de componentes Figura 1. Esquema metodología MVC 34 espiral de valores: técnicas avanzadas de programación PHP 3.1.1. El modelo Es el código que administra el estado interno del sistema. Se compone de una serie de clases o funciones que gestionan por una parte la lógica de proceso (o reglas de negocio) y por otra el acceso a la base de datos. Es recomendable que ambos aspectos estén en módulos separados. El modelo no contiene ningún componente visual. Funciona como un interfaz de programación (API) que encapsula los detalles internos del sistema. 3.1.2. Las vistas Constituyen la capa de presentación del sistema, la parte visible de cara al usuario. No deben acceder directamente a bases de datos ni contener lógica de proceso (quizá si un poco de lógica para la presentación). Cualquier dato que necesiten mostrar al usuario se recupera mediante llamadas a la API que ofrece el modelo. 3.1.3. El controlador Es el componente que coordina el funcionamiento global de la aplicación. Toda acción realizada por el usuario es gestionada por él. En función de la vista actual, la acción concreta y el estado del modelo: Manipula el modelo invocando la API de éste y selecciona la siguiente vista a mostrar. 3.2. Plantillas El mecanismo de plantillas sirve para separar el código de presentación del resto del código de una aplicación web. Consiste en codificar todo lo que tenga que ver con la presentación en una serie de plantillas de código HTML (u otro lenguaje de presentación), con expresiones sencillas intercaladas para comunicarse con el resto de la aplicación y poder mostrar datos dinámicos. Un motor de plantillas es el que se encarga de hacer la traducción a HTML. Este mecanismo es independiente de la metodología MVC y puede utilizarse sin ella, pero combinando las dos cosas se consigue una estructura de código muy organizada y elegante. De esta forma, las vistas simplemente se ocupan de extraer la información necesaria del modelo y comunicársela a las plantillas, y estas simplemente de dar un formato visual a esa información, añadiendo la información estática pertinente. Aunque así se complica algo la construcción del sistema al introducir un nuevo nivel, en las plantillas el código de presentación queda mucho mejor aislado que en las vistas de una aplicación MVC clásica (sin plantillas), de forma que se facilita la tarea de los diseñadores web. 35 espiral de valores: técnicas avanzadas de programación PHP 3.3. Un recorrido por el código Figura 2. Ejemplo de flujo 36 espiral de valores: técnicas avanzadas de programación PHP A continuación explicamos cómo funciona la arquitectura MVC mediante un recorrido por los distintos componentes que colaboran para resolver una acción concreta del usuario sobre la aplicación, ilustrando el ejemplo con algo de código representativo de cada componente. El número de los pasos se corresponde con los pasos del esquema de flujo. Paso 1: Partimos de la plantilla que muestra un formulario a través del cual se pueden cambiar los datos de un valor. Los datos introducidos se envían al controlador junto con el código propio de esta acción. <form action="{$control}" method="post"> <input type="text" name="titulo" size="50" value="{$titulo}"> <input type="radio" name="nivel" value="2" {if $nivel==2}checked{/if}>Esencial <input type="radio" name="nivel" value="1" {if $nivel==1}checked{/if}>De categoría <input type="radio" name="nivel" value="0" {if $nivel==0}checked{/if}>Normal <input type="hidden" name="action" value="{$accion}"/> </form> Paso 2: Los datos del formulario son validados por un componente específico para tal fin. function validate() { if (!$this->get(’titulo’)) { trigger_error(’Introduzca título’); $isValid = FALSE; } else if (!$this->get(’descripcion’)) { trigger_error(’Introduzca descripción’); $isValid = FALSE; } ... return $isValid; } Pasos 3 y 4: El controlador consulta en la tabla de acciones qué componente debe atender la acción y le delega el control. ’CambiarValor’ => array( _TYPE => ’CambiarValor’, _NAME => ’FormValor’, _INPUT => ’index.php?view=views/cambiovalor.php’, _VALIDATE => 1, _ACTION_FORWARDS => array( ’OK’ => array( _PATH => ’index.php?view=views/valor.php’, _REDIRECT => 0 ), ’Error’ => array( _PATH => ’index.php?view=views/cambiovalor.php’, _REDIRECT => 0 ) ) ), Pasos 5 y 6: La acción realiza las modificaciones oportunas en el modelo invocando las funciones adecuadas de la API del mismo. if (($_SESSION[_ERRORS])) { $actionForward = $actionMapping->get(’Error’); } 37 espiral de valores: técnicas avanzadas de programación PHP else { bd_cambiarValor ($valorid, $titulo, $nivel, $estado, $temaforo, $descripcion, $ampliacion); //fechas bd_guardarFechaAprob($valorid, $diaapr, $mesapr, $anyoapr); bd_guardarFechaInicio($valorid, $diaini, $mesini, $anyoini); ... $actionForward = $actionMapping->get(’OK’); } return $actionForward; Pasos 7 y 8: La acción consulta qué vista se debe mostrar a continuación y le pasa el control (ver mappings.php). Paso 9: La vista obtiene a través del modelo los datos necesarios del valor y se los envía a la plantilla correspondiente. $titulo = bd_extraerTituloValor($valorid); $nivel = bd_extraerNivelValor($valorid); $estado = bd_extraerEstadoValor($valorid); $s->assign(’titulo’, $titulo); $s->assign(’nivel’, $nivel); $s->assign(’estado’, $estado); $s->display(’valor.tpl’); Paso 10: La plantilla es quien finalmente muestra los datos del valor al usuario de la aplicación. <h1>{$titulo} {if $nivel == 2} - Esencial {elseif $nivel == 1} - De categoría {/if} </h1> <p class="dates">{if $estado==1}Aprobado: {$fechaaprob} - {/if}Iniciado: {$fechainicio}</p> <h3>Descripción</h3> <p>{$descripcion}</p> <h3>Ampliación</h3> <p>{$ampliacion}</pC> 3.4. Software Libre El compromiso de la espiral de valores con el software libre es triple: 1. La herramienta está escrita en el lenguaje PHP y utiliza MySQL como servidor de base de datos, ambos libres. Además se utilizan como código base dos paquetes de software libre, Phrame y Smarty. 2. Todo el código de la herramienta se ofrece como software libre a cualquier particular, organización o empresa interesada en realizar de él cualquier uso recogido en la licencia GPL. 3. Aunque no es un requisito general para la herramienta, la instalación realizada en espiraldevalores.org está soportada por el software de servidor Apache, ejecutándose en un sistema GNU/Linux, concretamente la distribución Debian GNU/Linux 3.0. 38 espiral de valores: técnicas avanzadas de programación PHP 3.4.1. Software básico de servidor Los programas que se ejecutan en el servidor, y que en definitiva componen esta aplicación web, están escritos en el lenguaje PHP, desarrollado por una gran comunidad de personas a través de Internet, a lo largo de casi diez años, de forma similar a como se desarrolló Linux, o el sistema operativo Debian. En cuanto a las principales ventajas de PHP frente a otros lenguajes de servidor, son las siguientes: 1. Su rapidez de ejecución. 2. Es un lenguaje específicamente diseñado para realizar aplicaciones web, mientras que otros lenguajes son adaptaciones de lenguajes preexistentes, no pensados para la web. 3. El software necesario para ejecutar aplicaciones es software libre. Los datos con los que trabaja la espiral de valores se almacenan utilizando MySQL, un sistema de gestión de bases de datos relacional licenciado como software libre. Se trata del gestor más usado en el mundo del software libre, debido a su gran rapidez, facilidad de instalación y de uso, y a que existen infinidad de librerías y otras herramientas que permiten utilizarlo desde gran cantidad de lenguajes de programación. Enumeramos brevemente los puntos fuertes de este gestor: 1. La velocidad a la hora de realizar operaciones, manteniendo un bajo consumo de recursos de máquina. 2. La proliferación y facilidad de uso de las utilidades de administración. 3. Gran seguridad, muy poca probabilidad de corromper los datos. 3.4.2. Software para MVC y plantillas Además de PHP y MySQL, se han utilizado los siguientes paquetes de software libre, como base para el desarrollo de la espiral de valores, según las técnicas explicadas: 1. Phrame (http://phrame.sourceforge.net/): Software que proporciona un marco de trabajo para la metodología MVC. Contiene un componente controlador, a completar con el código de las distintas acciones que tengan lugar en la aplicación web. Permite trabajar con múltiples lenguajes de presentación (HTML, XSLT, etc.). Ofrece otras utilidades, como por ejemplo la posibilidad de separar el código de validación de formularios hacia ficheros específicos para ese fin. 2. Smarty (http://smarty.php.net/): Software que proporciona un motor de plantillas. Internamente trabaja con una caché que reduce al mínimo la pérdida de eficiencia que todo mecanismo de traducción introduce. Ofrece un lenguaje para construir expresiones complejas, lógica condicional y de iteración, funciones predefinidas, etc. Por supuesto existen otras herramientas dentro del mundo del PHP que permiten trabajar con las técnicas expuestas. Hay ya un considerable número de motores de plantillas libres. No hay muchos paquetes libres para trabajar con MVC en PHP, quizá porque PHP ha sido considerado como un lenguaje sencillo de desarrollo rápido y no se ha prestado la suficiente atención a una buena organización del código de las aplicaciones. Pero poco a poco aparecen desarrollos en este sentido, como por ejemplo php.MVC (http://phpmvc.net). El lenguaje PHP todavía queda lejos en estas materias de otros lenguajes, como Java, en el que hablar de MVC es hablar de Struts (http://jakarta.apache.org/struts/index.html), prácticamente un “estándar de facto”, un software maduro que sirve como base para desarrollar aplicaciones web según la metodología MVC. Incluso existen herramientas visuales que facilitan dichos desarrollos. A modo de curiosidad, decir que Phrame es prácticamente una copia de Struts para PHP. 39 espiral de valores: técnicas avanzadas de programación PHP 4. Desarrollos futuros La espiral de valores es una herramienta completa y funcional que ha resuelto un problema de una organización, y que con ligeras modificaciones puede servir para otros propósitos similares. Sin embargo existen algunas posibles líneas de desarrollo que podrían llegar a una herramienta verdaderamente potente, útil para gran variedad de fines distintos. Una primera posibilidad es elevar el nivel de abstracción de la herramienta y llegar a obtener una metaherramienta que sirva como base para crear webs de conocimiento organizado, sin necesidad de modificar el código, simplemente especificando las características particulares de la web que queremos construir por medio de un interfaz de usuario. A partir de dicha metaherramienta podríamos obtener fácilmente una espiral de valores, pero también una web de recopilación y debate de obras de cultura, o de textos con procedimientos operativos de una empresa. Con características de participación como comentarios y puntuaciones, y un sistema de edición descentralizado (aspectos éstos ya implementados en la actual web). Otra posibilidad es orientar el desarrollo futuro hacia una herramienta de democracia participativa orientada al consenso, integrando y automatizando todo lo relacionado con las votaciones, plazos, histórico de propuestas, etc., con flexibilidad para adaptar las normas de debate según las peculiaridades y deseos de una organización en cuestión. Dicha herramienta podría resultar muy útil a todo tipo de empresas, organismos públicos y asociaciones con necesidades de organizar distintos debates organizados por temas y de poder elaborar y posteriormente acceder a consensos parciales o definitivos. Es difícil saber a ciencia cierta hacia dónde se dirigirá el desarrollo de la herramienta. Lo único seguro es que el seguimiento de unas técnicas orientadas a conseguir una buena organización del código hará más sencilla cualquier futura evolución que si la aplicación consistiera en una serie de ficheros PHP de tipo “spaghetti”. 5. Conclusión En este trabajo hemos presentado una herramienta de software libre construida para resolver las necesidades de organización y participación de un colectivo concreto. También se ha esbozado cómo elevando el nivel abstraccion o automatizando una serie de cuestiones, la herramienta podría ser útil para muchos más colectivos. Se han introducido las distintas metodologías utilizadas en el desarrollo, que tienen como fin potenciar la organización, la facilidad de ampliación y mantenimiento, una separación clara de papeles en el equipo de trabajo, etc. Quizá la única desventaja a mencionar es la complejidad asociada a un desarrollo tan modular y con tantos niveles, pero esto realmente sólo es una desventaja para aplicaciones sencillas sin requisitos especiales de mantenimiento ni posibles ampliaciones en previsión. En casos así, es posible que no valga la pena complicarse tanto, pero en los demás casos (que son clara mayoría) esta complejidad inicial se rentabiliza con creces según pasa el tiempo de desarrollo y mantenimiento. 40 Legislación europea y el Open Source / Free Software José M. Fidel Santiago Luque Network-sec.com 1. Introducción Quizá la legislación más importante que puede afectar al sofware libre es la que se refiere a la propiedad intelectual y a las patentes. Ambas son formas legales de "protegerlo". Analizaremos las dos en este artículo. Desde el punto de vista de la propiedad intelectual el software se considera un trabajo literario y se le aplica la legislación correspondiente. Las patentes no protegen el software en si mismo sino la idea nueva e innovadora que hay detrás del desarrollo del mismo. La propiedad intelectual se aplica por igual a software propietario y a software OS/FS. Ambos tienen licencias basadas en los derechos de autor y la legislación acorde. La aplicación es totalmente distinta, evidentemente, pero basada en los mismos principios legales. El software propietario hace uso y abuso de la legislación sobre patentes para proteger y ganar dinero con la investigación que se realiza. Sin embargo, el concepto de patente es incompatible con el espíritu del movimiento OS/FS. La idea de compartir el conocimiento es totalmente contraria al concepto de patente. Estas vías legales no son incompatibles, al contrario, son complementarias. Mientras que una de ellas, la propiedad intelectual protege la expresión concreta que representa el software, las patentes protegen y defienden la idea, el diseño último, del que el software es la implementación. El desarrollador de software puede jugar con ambas para conseguir la protección deseada. 2. Propiedad intelectual 2.1. Introducción El mercado de los contenidos es más y más importante cada día. Su importancia va pareja a su íntima relación con la incipiente sociedad de la información. La digitalización de los contenidos permite su reproducción exacta, sin perdida de calidad alguna. Podemos copiar y distribuir los contenidos digitales allá donde queramos. Una consecuencia, ¿no deseada?, de este desarrollo tecnológico ha sido el increíble desarrollo de la piratería de contenidos. La Comisión Europea, consciente de la importancia y la necesidad de un mercado de los contenidos correctamente legislado, ha desarrollado una serie de directivas destinadas a la protección y el desarrollo de este mercado. Gracias a la asimilación que se hace del software a una obra literaria, protegible mediante la propiedad intelectual, toda la legislación europea que se hace sobre propiedad intelectual lo afecta de una forma u otra. ISBN 84-88783-66-3 ©2003 41 Legislación europea y el Open Source / Free Software 2.2. La directiva 2001/29/EC. Sobre la armonización de ciertos aspectos del copyright y derechos relacionados en la sociedad de la información. Esta es la última directiva de la UE sobre propiedad intelectual. Armoniza las diferentes legislaciones, nacionales o europeas, sobre el copyright y la propiedad intelectual. El nacimiento de esta directiva ha sido realmente difícil. El 10 de Diciembre de 1997 la Comisión presentó su propuesta. El 10 de Febrero de 1999, un año y dos meses más tarde, el Parlamento Europeo pidió a la Comisión ciertas modificaciones. La Comisión hizo su trabajo rápidamente y la nueva propuesta estaba lista el 21 de Mayo. El 28 de Septiembre, el Consejo no aceptó todas las enmiendas presentadas por el Parlamento y la directiva tuvo que ser revisada de nuevo. La Comisión se encontraba más cerca del Consejo que del Parlamento. El 14 de Febrero de 2001 el Parlamento, en segunda lectura, aprobó nueve enmiendas a la propuesta. La Comisión, otra vez, tuvo que modificar la propuesta. El 9 de Abril el Consejo le dio el visto bueno a las modificaciones y finalmente, el 22 de Mayo de 2001 la directiva fue finalmente aprobada por el Consejo y el Parlamento. Un claro ejemplo de la agilidad con que se gesta la legislación europea. El software queda específicamente excluido de esta directiva, exactamente en el artículo 1 de la misma. El software se seguirá regulando por la directiva 91/250/CEE. 2.3. Directiva 91/250/CEE. Sobre la protección legal de los programas de ordenador. 2.3.1. Introducción Esta directiva regula los derechos de autor para los programas de ordenador. Asimila un programa de ordenador a una obra literaria acorde a la Convención de Berna. Las patentes se encuentran cubiertas en esta directiva, exactamente, en el artículo 9. Este artículo es totalmente claro: los derechos de autor y las patentes son compatibles. Es una legislación retroactiva, se aplica al software escrito antes de la fecha de adopción con lo cual abarca a todo el software realizado en la UE. La directiva 93/98/ECC modifica esta en cuanto a la fecha de expiración de los derechos de autor. Extiende la duración de cincuenta a setenta años. ¿Habrá algún programa tan longevo? Y, de existir, ¿aún será útil? 2.3.2. Análisis Los programas de ordenador se protegen según los derechos de autor tratando a los mismos como si fueran una obra literaria según se define en la Convención de Berna. Esto incluye la documentación previa a la creación del programa. El programa de ordenador se protege en tanto y cuanto es una creación original en el sentido de que es una creación intelectual de su autor. Nada más. El autor de un programa será la persona natural o grupo de personas naturales que lo han creado, o, cuando los Estados Miembros lo permitan, una persona legal puede tener el derecho de creación. Los derechos derivados de un trabajo serán compartidos por todo los creadores si son personas naturales. Si un empleado crea un programa como parte de su trabajo, el dueño de los derechos económicos, y sólo estos, del programa en cuestión será le empresa a no ser que se decida otra cosa por contrato. El propietario del software tiene el derecho para hacer o autorizar: la reproducción o la modificación del programa y cualquier forma de distribución del mismo. 42 Legislación europea y el Open Source / Free Software No se necesitará la autorización para la reproducción o la modificación del software cuando sea necesaria para el uso del mismo por el comprador legal. Tampoco se podrá prohibir la realización de las copias de seguridad por parte del usuario legal. Este, también podrá estudiar un programa para averiguar las ideas subyacentes al mismo. La decompilación y la modificación del software se permite para conseguir la interoperatibilidad de programas independientes. La información obtenida no se usará para otros fines que el mencionado y no se le dará a otras de no ser necesario para conseguir la deseada interoperatibilidad. Los Estados Miembros proveerán de las herramientas legales necesarias para perseguir a aquellos que infrinjan esta legislación. Especialmente: (a) la puesta en circulación de copias ilegales de un programa, (b) la posesión de copias ilegales con propósito comercial, (c) la puesta en circulación o la posesión por motivos comerciales, de medios para eliminar y obviar la protección de un programa. La protección legal dura toda la vida del autor y cincuenta años después de su muerte o la muerte del último autor superviviente. Si el autor es una persona legal el término de la protección será de cincuenta años desde que el programa se encuentra legalmente disponible al público. Este artículo, el ocho, se actualiza en la directiva 93/98/ECC cambiando la duración de la protección de cincuenta a setenta años. Esta directiva también se aplica a software creado antes de su aplicación. 2.3.3. Comentarios El principal motivo de esta directiva, como de tantas otras, es uniformar la legislación sobre la protección de los programas de ordenador. Legislación que, increíblemente, estaba ausente de algunos países de la UE. Trata de proteger la inversión económica realiza en la investigación de nuevas programas de ordenador. Crea un marco legal para el desarrollo y la explotación de los programas de ordenador en la UE. Pero esta directiva no solo protege los autores, sino que también protege los derechos de los usuarios. Concede a los usuarios varios derechos para poder ejecutar el software de forma segura y asegurar su interoperatibilidad con el resto del sistema. Esta directiva es, esencialmente, compatible con el desarrollo OS/FS. Reconoce la figura de autor y los derechos necesarios para construir una licencia OS/FS. Es gracias a esta legislación que se pueden crear las licencias OS/FS que luego se usan para proteger y "abrir" el código de este software e impedir que se "cierre". 2.4. GPL 2.4.1. Introducción Esta es la licencia más extendida en el mundo OS/FS hoy. Es la más restrictiva, también. Aunque no es la única si que es la más importante y el mejor ejemplo de una licencia OS/FS y perfectamente relacionado con la legislación sobre propiedad intelectual. 2.4.2. Análisis Esta licencia comienza con un preámbulo en el que se explica la filosofía del software OS/FS. Después del preámbulo va la licencia propiamente dicha. Esta licencia se aplica a "programas" y solo implica los derechos de copia, distribución y modificación. Los más importantes, por otra parte. 43 Legislación europea y el Open Source / Free Software Se concede permiso para copiar y distribuir copias exactas del código fuente del programa siempre que cada copia del fuente tiene el copyright apropiado, una declaración de ausencia de garantía y una referencia a la licencia. Claramente permite el cobro por la copia física del código fuente. Se pude modificar el programa siempre que: (a) el programa lleve un mensaje anunciando que esta es una versión modificada, (b) la modificación también debe llevar esta licencia, y (c) el programa debe informar sobre la licencia. Se puede integrar software GPL dentro de un sistema propietario siempre que la separación entre ambos sea suficiente para identificar cada uno y poder cumplir esta licencia por completo. Así, podríamos usar una base de datos GPL junto con un ERP propietario sin violar la GPL. Se puede distribuir un programa en forma binaria, o ejecutable. Aparte de cumplir las condiciones aplicadas al código fuente hay que acompañar el ejecutable con el código fuente. La infracción de la licencia finaliza los derechos del propietario del software bajo esta licencia. Otros que hubieran obtenido el software del infractor conservan sus derechos aunque este los haya perdido. Los creadores de esta licencia, conscientes del problema de las patentes, las tratan de forma clara: si hay patentes que entran en conflicto con esta licencia esta licencia no deja de aplicarse. Si la distribución bajo esta licencia y la patente en cuestión es imposible entonces es la distribución la que se acaba, no dejan de tener efecto ni la licencia, ni las patentes. El uso de partes de software GPL dentro de otros programas licenciados libres pero no GPL se permite siempre que se escriba al autor para pedir permiso. El mensaje de no garantía aparece al final de la licencia. No es diferente de otros mensajes iguales en el software propietario. El software no tiene ninguna garantía y el autor no es responsable por ningún daño que el mismo pueda causar. 2.5. Conclusiones La legislación europea sobre propiedad intelectual es estándar y común a las legislaciones nacionales preexistentes y a la que se puede tener en otros países fuera del espacio UE. Su acomodo a las licencias OS/FS existentes es total puesto que estas ya se hicieron basándose en legislaciones equivalentes. No solo no representa un freno al desarrollo del movimiento OS/FS sino que constituye la base jurídica sobre la que poder apoyar las licencias del mismo y sobre la que defender los derechos de los autores de software OS/FS sobre sus programas. 3. Patentes Las patentes son la segunda forma de protección de los programas de ordenador. Junto con la propiedad intelectual completan los mecanismos legales para controlar y proteger el desarrollo y la distribución de software. Una patente es el derecho exclusivo sobre una invención. Una invención es el producto o proceso que ofrece una nueva forma de hacer algo o una nueva solución técnica a un problema. Una patente protege la invención por un periodo de tiempo limitado, veinte años es lo normal. Así, una invención no puede ser fabricada, usada, distribuida o vendida sin el consentimiento del titular de la patente. Estos derechos puede ser vendidos a un nuevo titular. 3.1. Patentes en Europa La patentes en la UE están basados en dos sistemas: la patente nacional y la europea. Ninguna de las dos tiene una legislación comunitaria detrás. 44 Legislación europea y el Open Source / Free Software Las patentes nacionales fueron las primeras que aparecieron. Estas patentes han sido armonizadas "de facto" en todos los países de la unión: todos los miembros de la UE han firmado la Convención de París para la protección de la propiedad industrial (20 de Marzo de 1883) y el acuerdo TRIPS (Trade-Related aspects of Intellectual Property rightS) (aspectos comerciales de los derechos de propiedad industrial) el 15 de Abril de 1994. La patente europea se basa en la Convención sobre Patente Europea, "La Convención de Munich" de 1977. La CPE concede derechos en tantos países como lo desee el solicitante. Esto dota de una gran flexibilidad. La CPE no proporciona un tribunal a nivel europea sino que los tribunales nacionales son los que han de resolver los problemas que surjan. Nada impide a diferentes tribunales dirimir las solicitudes que se les hagan de diferente forma. La CPE estableció la Oficina Europea de Patentes (OEP) para gestionar las patentes europeas. El 24 de Julio de 1997 la Comisión presentó un Libro Verde sobre la patente comunitaria y el sistema de patentes en Europa (COM(97) 314 final). Como resultado del debate iniciado por este papel la comisión desarrolló una comunicación (COM(99) 42 final) para el Consejo, el Parlamento y el Comité Económico y Social sobre este Libro Verde. En esta comunicación la Comisión propuso diferentes iniciativas y legislación sobre la patente comunitaria. El 5 de Julio de 2000 la Comisión presentó una propuesta para una regulación del consejo sobre la patente comunitaria (COM(2000) 412 final). El Consejo desea que esta propuesta se apruebe lo antes posible pero no parece fácil. 3.1.1. La patente comunitaria El sistema de patente comunitaria propuesta por la Comisión debe convivir con los sistemas en uso (los sistemas nacionales y el CPE). La coherencia entre estos sistemas se consigue gracias a la adhesión de la UE a la Convención de Munich. La OEP será la organización que se encargue de examinar las patentes y conceder la patente comunitaria. La OEP seguiría haciendo el mismo trabajo de siempre. Las principales características de la patente comunitaria son: unidad y autonomía. Solo se pueden conceder, trasmitir, revocar o expirar para toda la comunidad y solo puede ser sujetas a la legislación propuesta y al derecho general de la UE. CPE regulará el sistema de patentes de esta patente comunitaria. Esta patente es, en definitiva, una patente europea en el sentido del Convenio de Munich en la que el área de aplicación es la comunidad al completo. A día de hoy, el coste medio de una patente europea (para ocho países) es, aproximadamente, EUR 30.000. El coste de las traducción se lleva sobre el 39% del total. La propuesta de la comisión trata de reducir el coste de la patente reduciendo el coste de la traducción y del procedimiento. Para reducir el coste de la traducción la propuesta requiere la traducción de toda la petición de patente a una sola lengua de las de trabajo del OEP y dos traducciones adicionales de las reivindicaciones a las otras dos. Así, traducir una patente completo a todos los idiomas comunitarios costaría unos EUR 17.000, a las tres lenguas de la OEP, EUR 5.100, y, según la propuesta de la comisión, EUR 2.200. Está claro que es mucho más barato. Otra propuesta de la comisión es igualar el coste de los procedimientos con los de los principales socios comerciales. La patente europea es tres veces más cara que la japonesa y casi cinco veces más cara que la americana. Como es la OEP quien examina las patentes y sus tarifas vienen fijadas por el Convenio de Munich la Comisión no puede cambiarlas. Pero si que puede modificar los costes de renovación y lo hace acercando la patente europea a la japonesa y la americana. Para resolver los problemas legales que surjan alrededor de las patentes la Comisión propone la creación de un Tribunal Comunitario sobre Propiedad Intelectual. De esta forma se conseguiría la uniformidad en la legislación y la jurisprudencia. El nacimiento de la patente comunitaria está siendo muy difícil. Un asunto tan importante como es la propiedad industrial no es fácilmente dejado de lado por los estados miembros. Aunque la Comisión está trabajando duro para conseguir la aprobación de la propuesta, aún no se ha conseguido. 45 Legislación europea y el Open Source / Free Software 3.2. Patentes y programas de ordenador 3.2.1. Introducción Las patentes son importantes en este trabajo a causa de la nueva propuesta de la Comisión sobre las patentes para los programas de ordenador. Este no es un punto fácil y hay dos opiniones enfrentadas acerca de él: las patentes ayudarán a desarrollar la industria europea del software y las patentes impedirán su desarrollo. La tercera opción: mejor dejamos las cosas como están, también está siendo defendida por algunas empresas del sector como IBM. De un lado la Comisión, la BSA e importante empresas del software (europeas y, mayormente, no europeas). Del otro lado la comunidad OS/FS representada, fundamentalmente por Eurolinux y las principales PYMES europeas del mundo de la informática. No es una legislación trivial. Las patentes pueden cambiar totalmente las reglas del juego para el desarrollo del software y, especialmente, el desarrollo del software OS/FS. Si Europa, y la Comisión, van a apostar por el software OS/FS tiene que pensar detenidamente la legislación sobre patentes. 3.2.2. Legislación Los principios legales básicos sobre la patentabilidad de los programas de ordenador son dos: Los programas de ordenadores "como tales" no son patentables siguiendo el artículo 52 de la CPE. Las leyes nacionales reproducen de una forma u otra este artículo. Las patentes se conceden a invenciones que son nuevas, proporcionan un avance tecnológico y tienen una aplicación industrial. Basados en estos principios, diferentes tribunales europeos han resuelto que una invención técnica que usa un programa de ordenador es patentable. El primero y más importante de estos ejemplos viene de dos decisiones del Comité Técnico de Apelación, ambas involucrando a IBM. El Comité llegó a la siguiente importante conclusión: "Según este Comité, un programa de ordenador "como tal" no es excluido de patentabilidad si el programa, cuando es ejecutado o cargado en un ordenador, produce, o es capaz de producir, un efecto técnico que va más allá de las interacciones físicas normales entre el programa y el ordenador en que el que se ejecuta." A día de hoy, en Europa, hay alrededor de 15.000 patentes para programas de ordenador y aproximadamente el 75% de ellas corresponden a grandes empresas de software no europeas. 3.2.3. Revisión de la situación La Comisión y el Parlamento Europea están de acuerdo en la patentabilidad de los programas de ordenador si el producto es "nuevo" y es la aplicación industrial de una innovación técnica. La Comisión ha propuesta dos acciones: una directiva para armonizar las legislaciones nacionales sobre la patentabilidad de los programas de ordenador y la modificación del Artículo 52(.2.c) del CPE para eliminar los programas de ordenador de la lista de exclusión de patentes. El 20 de Febrero de 2002, la Comisión presentó una propuesta de directiva (COM(2002) 92 final). El 19 de Octubre de 2000 la Comisión comenzó una consulta oficial acerca del impacto social y económico de la patentabilidad de los programas de ordenador. Como resultado de esta consulta se creó el estudio "The economic impact of patentability of computer programs". 3.2.4. Propuesta de directiva de la Comisión El objetivo de esta propuesta es armonizar las legislaciones nacionales sobre las patentes de programas de ordenador y clarificar las condiciones de patentabilidad. 46 Legislación europea y el Open Source / Free Software En el artículo 1 se concreta el alcance: la patentabilidad de las invenciones implementadas en ordenador. El artículo 2 engloba las definiciones: "Invención implementada en un ordenador": cualquier invención que conlleva el uso de un ordenador y que tiene una o más características novedosas las cuales se llevan a cabo gracias al uso del ordenador. "Contribución técnica": una contribución al "estado del arte" de un campo técnico que no es obvia para alguien competente en semejante campo. El artículo 3 especifica que cualquier invención que involucra un ordenador pertenece a un campo técnico. El artículo 4 define las condiciones para la patentabilidad: 1. La invención tiene que tener una aplicación industrial, ser nueva, y conllevar un salvo inventivo. 2. La invención debe hacer una contribución técnica. 3. El total de la invención debe ser evaluado para determinar la contribución técnica al "estado del arte" Artículo 5: una invención implementada en ordenador puede ser implementada a través de un ordenador a o de cualquier apartado programable con el programa dentro. El artículo 6 es muy importante. Relaciona la propiedad intelectual con esta directiva. Ambas son de aplicación. El artículo 7 comprenda la obligación de la Comisión de monitorizar el impacto de esta directiva. El artículo 8 está relacionado con el anterior. Después de la monitorización, la Comisión tiene que informar: sobre el impacto de esta directiva, si aún es valida, y, si han surgido patentes "erróneas", de que manera resolver esto. Los artículo 9, 10, 11 son artículos administrativos sobre la aplicación de la directiva, su entrada en efecto, etc. 3.3. Conclusiones En mi opinión el actual estado de las patentes de programas de ordenador ha de ser revisado. Si los programas de ordenador no pueden ser patentados es increíble que se hayan concedido más de 15.000 patentes sobre los mismos. Está claro que hace falta una legislación a nivel europeo que unifique los criterios necesarios para poder patentar un programa de ordenador. Me inclino por la propuesta de EuroLinux más que por la de la Comisión Europea. En la propuesta de EuroLinux se hace hincapié en el uso de los programas de ordenador a nivel industrial y siempre conducentes a "la modificación de la materia" como objetivo del mismo. De este modo las patentes de ordenador estarían más cercanas al espíritu inicial de las patentes que es la defensa de la innovación "industrial". 4. Conclusiones La UE dispone a día de hoy de una legislación, la de propiedad intelectual, y una propuesta de legislación, sobre la patentabilidad de los programas de ordenador, que afectan al desarrollo del software OS/FS. La legislación sobre propiedad intelectual, más que beneficiosa, es el marco legal sobre el que basar la propiedad del software OS/FS, algo reconocido por la comunidad, y el que provee de los derechos necesarios para poder "abrir" el software e impedir un uso fraudulento del mismo. La propuesta de la Comisión sobre las patentes de software puede perjudicar el desarrollo del software OS/FS. Como ya plantean diversos documentos, las patentes no sólo pueden representar un freno al desarrollo de la tecnología de las telecomunicaciones y la informática en general, afectan de forma especial al software OS/FS debido a sus especiales características. Confiemos en que entre el Parlamento Europeo y el Consejo consigan rehacer la propuesta de la comisión y conseguir un sistema de patentes comunitario que apoye y desarrolle el movimiento OS/FS. 47 Legislación europea y el Open Source / Free Software Bibliografía Comisión Europea , COM(1994) 347 final, Europa en marcha hacia la sociedad de la información . Comisión Europea , COM(1995) 382 final, Derechos de autor y derechos afines de la sociedad de la información . Comisión Europea , COM(1996) 568 final, Seguimiento del Libro Verde sobre derechos de autor y derechos afines de la sociedad de la información . Comisión Europea , Directiva 2001/29/CE, Relativa a la armonización de derechos de autor y derechos afines en la sociedad de la información . Comisión Europea , Directiva 91/250/CEE, sobre la protección jurídica de programas de ordenador . Comisión Europea , Directiva 93/98/CEE, relativa a la armonización del plazo de protección del derecho de autor y de determinados derechos afines . Convenio de Munich sobre la Patente Europea (CPE) , 1973 . Convenio de Luxemburgo sobre la patente comunitaria (CPC) , 1975 . Acuerdo en materia de patentes comunitarias (APIC) , 1989 . Comisión Europea , COM(97) 314 final, Libro Verde sobre la patente comunitaria y el sistema europeo de patentes . Comisión Europea , COM(99) 42 final, Comunicación al Consejo, al Parlamento Europeo y al Consejo Económico y Social sobre el seguimiento que debe darse al Libro Verde sobre la patente comunitaria y el sistema europeo de patentes . Comisión Europea , COM(2000) 412 final, propuesta de Reglamento del Consejo sobre la patente comunitaria . Comisión Europea , COM(2002) 92 final, propuesta de Directiva del Parlamento Europeo y del Consejo sobre la patentabilidad de las invenciones implementadas en ordenador. . Gretel (COIT) , Gretel 2002, Nuevo diseño europeo de las Telecomunicaciones, el Audiovisual e Internet . Free Software Foundation , GNU GPL (www.gnu.org) . Robert Hart y John Reid , The Economic Impact of Patentability of Computer Programs . IBM , Role of national patent offices, the European Patent Office, as well as the Japanese and US patent offices in promoting the patent system Final report to the European Commission Almere , 2003 . PbT Consultants , The results of the European commission consultation exercise on the patentability of computer implemented inventions . IBM , Europe Response to the Services of the Directorate General for the Internal Market The Patentability of Computer-Implemented Inventions Consultation Paper of 19.10.2000 . James Bessen y Eric Maskin , Sequential innovation, patents and imitation . Jesús González-Barahona , EU Consultation on Software Patents Contribution , December 2000 . EuroLinux Alliance , DGIM Consultation on Software Patents , 2000 . 48 Legislación europea y el Open Source / Free Software BSA , Comments to the European Commission Consultation Paper on the Patentability of Computer-Implemented Inventions . 49 La Intranet Educativa Municipal del Ayuntamiento de La Coruña Enrique Ocaña González Igalia, S.L. Departamento de Servicios A Coruña España [email protected] En este artículo se presentan brevemente los orígenes, presente y futuro de la intranet educativa municipal que el Ayuntamiento de La Coruña ha implantado en los centros educativos de la ciudad. Se comentarán las principales dificultades para mantener el nivel de funcionalidad de la red a lo largo del tiempo y cómo el software libre permite alargar la vida útil de los equipos. Por último se establecerán una serie de conclusiones acerca del uso de la informática y el software libre en la educación. 1. Los comienzos de la intranet educativa La intranet educativa del Ayuntamiento de La Coruña nació en el año 1999 como un proyecto pionero para poner las tecnologías de la información y las comunicaciones a disposición de más de 60 centros educativos no universitarios de la ciudad. Inicialmente el ayuntamiento contó con la colaboración del departamento de computación de la universidad de La Coruña, que llevó a cabo un estudio preliminar de la tecnología (véase WePrj). Aunque se barajaron otras alternativas, se tomó la decisión de emplear IBM NetworkStation 1000 contra un servidor central Windows NT con Citrix Metaframe en cada aula. Los NS1000 están basados en NCOS, variante de NetBSD, sobre arquitectura PowerPC. No llevan disco, ya que acceden a los datos mediante NFS a través de la red. Incorporan Netscape 4.7 como navegador local, así como un cliente ICA para conectarse al servidor Metaframe. El sistema operativo de estos clientes ligeros es propietario y cerrado, y no incorpora un compilador C ni ficheros de cabeceras para permitir nuevos desarrollos. Los motivos para emplear clientes ligeros fueron los siguientes: • Bajo coste de mantenimiento software: Al carecer de disco y obtener el sistema operativo de un servidor central de aula, simplemente hay que mantener 60 servidores en lugar de 60 x 15 equipos. • Baja probabilidad de fallo: Al no tener disco duro ni ventilador, la probabilidad de fallo se reduce drásticamente. • Baja obsolescencia: Los clientes ligeros están pensados como clientes para sesiones remotas, no para proceso local. De este modo quien se queda obsoleto es el servidor, no el terminal. ISBN 84-88783-66-3 ©2003 50 La Intranet Educativa Municipal del Ayuntamiento de La Coruña Finalmente se implantó la infraestructura de red que se muestra en Figura 1 con diversos servicios que se explicarán a continuación. Figura 1. Esquema de la intranet educativa municipal SERVICIOS CENTRALES Internet Intranet CENTRO EDUCATIVO nc1 ... nc15 Servidor de aula 1.1. Aula educativa (una por centro) En el aula, como se ha dicho, un servidor con Metaframe con escáner e impresora y entre 13 y 15 terminales NetworkStation 1000. Existe un sistema de cuentas de usuario públicas (cualquiera puede utilizarlas) y privadas (de uso personal para alumnos y profesores). Por supuesto, aplicaciones educativas y un proxy local en el servidor para acelerar la navegación por internet. Todas las aulas están conectadas a la red central del ayuntamiento por medio de una red privada contratada con un proveedor de cable regional. 1.2. Servicios centrales Se establecen también una serie de servicios centrales ofrecidos desde el ayuntamiento: • Web educativa municipal (véase Webedu) • FTP • Correo electrónico • Listas de correo • News • IRC • LDAP • Proxy central + filtro La web educativa municipal era inicialmente muy simple, pero fue evolucionando hasta incorporar un sistema de gestión centralizada de usuarios, noticias educativas, buscador, correo web, aula virtual, pensar en educación, enrédate y webs de centros escolares. El "aula virtual" es una zona donde los profesores que lo deseen pueden publicar los contenidos web que ellos mismos desarrollan. 51 La Intranet Educativa Municipal del Ayuntamiento de La Coruña En la sección "pensar en educación" tienen cabida materias transversales, como educación para la paz, igualdad interracial, derechos de la mujer... La sección "enrédate" es una recopilación de enlaces y recursos educativos interesantes en internet. El servicio de FTP (file transfer protocol, protocolo de transferencia de archivos) permite publicar contenidos a los profesores y centros que lo deseen. El correo electrónico, las listas de correo y las news constituyen el medio de comunicación de los usuarios de la intranet con el exterior. Cada cuenta privada dispone de una dirección de correo asociada automáticamente de la forma [email protected]. Un servidor LDAP (lightweight directory access protocol, protocolo ligero de acceso a directorio) mantiene de forma centralizada una base de datos de los usuarios de la red, con sus respectivas contraseñas y direcciones de email asociadas. Hay que aclarar que la red central del ayuntamiento está aislada de internet. Es necesario un proxy central para proveer de acceso web al resto de los proxys de aula de la intranet, actuando de filtro web al mismo tiempo. El filtro web es necesario para evitar que los menores accedan a contenidos inadecuados en la red. 1.3. Equipo de gestión y mantenimiento hardware y software Velan por el buen funcionamiento de la red y el desarrollo de la página web educativa. En la actualidad hay tres ingenieros encargados del mantenimiento y resolución de incidencias software y un psicopedagogo encargado del desarrollo de la web. Una empresa de mantenimiento hardware y el operador de cable que suministra la conexión entre los centros y el ayuntamiento se ocupan de los problemas de equipos y red. 2. La actualidad de la intranet educativa Por nuestra experiencia en software libre y conocimiento de la tecnología empleada en la intranet, Igalia es escogida en Junio de 2002 para tomar el relevo a la universidad en las tareas de mantenimiento de la red. Nuestra actividad abarca mucho más que la resolución de incidencias diaria. Hemos puesto en marcha nuevos servicios y aplicaciones: • Aplicaciones basadas en software libre, personalizadas para soportar la configuración de nuestra red: mozilla firebird (navegador), openoffice (ofimática), gimp (retoque fotográfico), logo, dev-c++ y gnu pascal (programación), filezilla (FTP), 7zip (compresor), dia (diagramas), VNC (pizarra virtual) y otras aplicaciones GNU (véase GNUWin)... • Servicios centralizados, tanto de uso público como para el apoyo a la gestión interna: squirrelmail (webmail), drupal (foro), claroline (teleformación), bugzilla (gestión de incidencias), irm (inventario de software)... • Desarrollo propio de aplicaciones de gestión administrativa: inscripción a actividades educativas "aprender en Coruña", reserva online de entradas de teatro, consulta del estado de incidencias, gestión de actas de consejos escolares, sugerencia de enlaces y páginas del filtro. La tecnología no es nada sin una formación adecuada. Por eso Igalia organiza visitas personalizadas a los centros y cursillos de formación específica para que los profesores aprendan a sacarle el máximo partido a los recursos que la intranet les ofrece. Estos cursos sirven, además, para obtener el feedback necesario y conocer de primera mano la opinión y necesidades de los docentes. 52 La Intranet Educativa Municipal del Ayuntamiento de La Coruña 3. El futuro de la intranet educativa 3.1. La evolución del cliente ligero En el mundo de las tecnologías de la información el ritmo de evolución de la tecnología es extremadamente acelerado. Generalmente dicha evolución no suele ser asfixiante en un entorno empresarial cerrado, donde las tareas a realizar se mantienen constantes. Sin embargo, en el entorno de la intranet educativa, donde una de las prioridades esenciales es el uso de internet como herramienta educativa, el problema de la obsolescencia se hace patente y es necesario incrementar las funcionalidades del sistema. La navegación de 15 usuarios simultáneos satura el servidor, pero no es posible navegar en los terminales porque el Netscape 4.7 de los clientes se ha quedado anticuado. Es necesario otro navegador en el cliente. ¿Qué hacer si no existen herramientas de desarrollo para estos clientes ligeros y el fabricante ha dejado de soportarlos? ¡Usar Linux como sistema operativo! Nunca antes se había conseguido ejecutar Linux en estos aparatos. No se conocían las especificaciones de la máquina y fue necesario coordinar un equipo de desarrollo internacional (véase NS1000) para hacer los cambios necesarios en el kernel. No obstante, siguen existiendo problemas debido a la necesidad de incorporar software de compañías que no han portado sus productos a plataforma Linux PowerPC, como es el caso del plugin de Flash. Finalmente, se configuró adecuadamente una distribución Debian (véase Deb) hasta conseguir un producto adecuado para implantar de modo experimental en las escuelas infantiles de la ciudad. Se ha bautizado a esta adaptación con el nombre de Corunix. Estas escuelas poseen un servidor Windows NT, 4 terminales y un servidor Linux. El servidor Linux elimina muchos de los problemas técnicos, pero por el momento esta configuración no es aplicable al resto de los centros de la intranet, ya que sólo disponen de servidores Windows NT. El no disponer de un servidor Linux plantea ciertos problemas técnicos para simular un sistema de ficheros NFS con usuarios, permisos, enlaces simbólicos y acceso concurrente. Por el momento estamos investigando la solución a esos problemas empleando CygWin. A la hora de decidir qué software se iba a incluir en Corunix, se hizo un estudio del software libre disponible en Debian y se hicieron pruebas de qué paquetes funcionaban correctamente en los terminales. 3.2. La evolución de los servicios centrales En estos momentos se está trabajando en un nuevo sistema mejorado de gestión centralizada de usuarios vía web. El nuevo sistema permitirá que un mismo usuario pueda pertenecer a más de un colegio, contempla la figura del profesor administrador, purga los usuarios cada año y permite mantener la cuenta de correo aún cuando el usuario ya no pertenezca a ningún centro. Otra tarea pendiente en la red educativa es la implantación de una clave única para todos los servicios web, ya que por el momento el usuario tiene que registrarse de forma independiente para la red educativa/correo electrónico, el foro y la plataforma de teleformación. 4. De la experiencia se aprende A lo largo de todo este tiempo ha cambiado el contexto que hacía válida la solución inicial basada en clientes ligeros. De todos estos cambios se pueden extraer algunas conclusiones: 53 La Intranet Educativa Municipal del Ayuntamiento de La Coruña El proceso centralizado en un servidor (de aula) con ventanas exportadas presenta problemas al ejecutar aplicaciones que exigen un rendimiento gráfico elevado. Es preferible realizar las tareas multimedia en los clientes, con lo cual el uso de thin clients debería descartarse en favor de equipos con mayor potencia. La obsolescencia de los equipos es difícilmente predecible cuando se destinan a un entorno abierto y de rápida evolución como Internet. A la hora de diseñar una red siempre hay que preguntarse ¿dónde estaremos dentro de 3 años?. Es un error confiar en una plataforma cerrada o poco común, en nuetro caso NCOS sobre PowerPC. Si el fabricante decide dejar de dar soporte se pone en peligro la mantenibilidad del proyecto. En nuestro caso no fue posible aumentar la funcionalidad del software original de los thin client para minimizar la dependencia del servidor. Apostando por una plataforma libre se evita este problema. Necesidad de formación y concienciación del profesorado en el uso de las TIC a su alcance. La única forma de hacer que los profesores valoren el software libre es enseñándoles a sacarle partido. Es interesante consensuar entre profesores y técnicos una lista de programas educativos libres que cubran las necesidades curriculares de 0 a 18 años. Si se utiliza software libre en la escuela, también se utilizará en casa y al final todos salimos ganando. Referencias [WePrj] Proyecto: Red educativa de La Coruña. http://www.edu.aytolacoruna.es/proyecto [Webedu] Web Educativa del Ayuntamiento de La Coruña. http://www.edu.aytolacoruna.es/ [GNUWin] GNUWin. http://gnuwin.epfl.ch/es/index.html [NS1000] Linux on the IBM NetworkStation 1000. http://sourceforge.net/projects/networkstation/ [Deb] Debian GNU/Linux - The Universal Operating System. http://www.debian.org 54 PROPIEDAD, S.L.: Propiedad y software libre Un enfoque educativo José J. Grimaldos Profesor de Matemáticas IES Cura Valera. (http://www.iescuravalera.org) Huércal-Overa (Almería) [email protected] Resulta ya tópico decir "los tiempos están cambiando", "cada día surgen nuevos retos",... pero, tal vez como ocurre con la mayoría de tópicos, algo tienen de verdad. En el caso del propósito de estas reflexiones, qué duda cabe, cualquier observador curioso debe sentirse intrigado ante el devenir del fenómeno asociado al software libre. No pretendemos, en absoluto, una tarea de divulgación de esta ¿filosofía?,tampoco es nuestra meta el proselitismo, ni tan siquiera la formulación de unas tesis de contenido político, económico, jurídico o social; sólo pretendemos acercarnos con cierta curiosidad a este movimiento y plantear algunas reflexiones acerca de sus implicaciones en el pensamiento actual, los valores educativos que encierra, en definitiva, más dudas que certezas. Para ello, huiremos de los profundos, y desconocidos para el autor, análisis académicos o técnicos donde el software libre está siendo objeto de análisis, estudios, ensayos y... hasta simulaciones iterativas usando modelos matemáticos inspirados en la "Teoría de Juegos" y trataremos de enfocar el tema en los valores educativos que encierra el software libre en sí mismo, desde las necesarias precisiones sobre el concepto de propiedad que situen con claridad el carácter de libre. 1. Clarificando el lenguaje En principio, hemos de aclarar ciertos vocablos, la mayoría heredados o adaptados del idioma inglés, dado el carácter tecnológico del tema, a fin de que la semántica no sea un problema añadido, y con objeto, además, que la persona no muy familiarizada con la informática y su particular jerga tenga la posibilidad de acceder sin dificultad a las ideas que se exponen. Tal vez, desde principios de siglo, la información ha alcanzado tal dimensión que el exceso de la misma requiere de herramientas auxiliares para ser procesada. En este sentido, las técnicas de computación han auxiliado al hombre en esta tarea hasta el punto de convertirse casi en imprescindibles hoy día. Bien es cierto que, en honor a la verdad, no son condición necesaria ni, por supuesto, suficiente para que un estudioso, investigador o un simple ciudadano, sin más pretensiones, acceda al conocimiento que desee, necesite o busque. En cambio, sí es habitual que la mayoría de personas, en mayor o menor medida, acudan a los ordenadores cotidianamente para aliviar parte de su actividad. ISBN 84-88783-66-3 ©2003 55 PROPIEDAD, S.L.: Propiedad y software libre Un ordenador es, simplemente, un conjunto de piezas ensambladas en torno a un procesador con una gran capacidad operativa, aritmética y lógica. Sin embargo, todos estos componentes, convenientemente concectados, son incapaces de realizar tarea alguna por sí mismos, necesitan un soporte lógico que les dote de cohesión y les haga funcionar coordinadamente con algún propósito específico. Es necesario además que el ser humano tenga la posibilidad de comunicarse con él, por una parte para demandarle el tipo de procesamiento deseado y por otra, para recibir el resultado del proceso. Básicamente necesitamos dos tipos de programas: Uno específico que sea capaz de realizar la tarea concreta que pueda demandar un usuario (procesar texto, gestionar una base de datos,...) y otro genérico que cohesione los diferentes elementos físicos del ordenador y, a su vez, se entienda con el programa específico utilizado por el usuario. Este último tipo de programa se conoce con el nombre de sistema operativo y a los primeros se les llama aplicaciones. Ambos se construyen generalmente sobre una secuencia de comandos en un determinado idioma 1 que constituyen el código fuente de cada programa. 1.1. El código fuente Sobre este código fuente gira toda la controversia. Las personas con los conocimientos necesarios para escribirlo son conocidas como hackers o programadores y, es conveniente distinguirlos de los crackers pues éstos últimos son también programadores de grandes conocimientos, pero con intenciones maliciosas o dañinas que a los primeros no se les suponen. El código fuente de un programa es, por tanto, un simple texto que contiene las instrucciones para que el procesador, junto a los periféricos, realicen una determinada tarea, sea ésta simple o de gran complejidad. Sin embargo, para que las órdenes que contiene sean comprendidas por la máquina es necesario traducirlo (compilarlo) a un lenguaje denominado genéricamente código máquina que es propio de la estructura interna que ésta posea; una vez realizado este paso, el texto que inicialmente contenía el código fuente deja de ser legible para el humano y pasa a ser accesible sólo para la máquina. Además, este código fuente permite ser cifrado y, por tanto, ocultado ante lectores no deseados. Es lo que ocurre con los programas comerciales, donde únicamente el propietario posee el código fuente de éste y sólo a él le está permitido hacer modificaciones en el comportamiento de su programa. 2. Un poco de historia Pese a que en la actualidad, el fenómeno del software libre está generando un eco y una repercusión considerables, lo cierto es que su génesis podría datarse casi en los inicios de la computación moderna. No es fácil señalar una fecha ni un lugar concretos, como es lógico, raras veces las ideas, las tendencias o los movimientos sociales vienen acompañadas de partidas de nacimiento en toda regla y este caso no es una excepción. El primer sistema operativo digno de recibir ese nombre, tal y como lo concebimos hoy, nace en los laboratorios Bell fruto de la curiosidad investigadora del ser humano. Nació libre y fue bautizado con el nombre de Unix, al poco tiempo pasó a ser comercial puesto que fue patentado, registrado y distribuido por una considerable cantidad de dinero, sólo al alcance las las grandes firmas comerciales. Aún quedaba muy lejos el PC doméstico. Por aquel entonces los computadores estaban recluidos en los centros de cálculo e investigación, en los departamentos contables de las grandes organizaciones comerciales y centros similares. La informática era, pues, una disciplina científica de aplicación, todavía, lejos del gran público, lejos de la sociedad y oficiada por una privilegiada élite de investigadores capaces de instruir al computador. 1. Lo que conocemos como "lenguaje de programación". 56 PROPIEDAD, S.L.: Propiedad y software libre 2.1. El movimiento GNU Un grupo de hackers, abanderados por Richard Stallman (RMS) (http://www.stallman.org) se rebelaron ante esta situación porque defendían que el software era conocimiento científico y como tal no debía ser patentado ni comercializado, sino todo lo contrario, difundido como motor del avance del progreso. Se consideraban, ante todo, investigadores, y como tales, frecuentaban el libre intercambio de información entre la comunidad científica. Con este objetivo crearon la Fundación para el Software Libre (FSF) (http://www.fsf.org) con el objeto de recaudar fondos que permitieran la creación y distribución de programas de código abierto. 2 Así nacieron distintas aplicaciones de software libre (como Emacs, gcc,...) que aún hoy día gozan de gran difusión. Para ajustarse al marco legal vigente e impedir que sus productos fueran patentados y comercializados por alguna empresa que se apropiase de su código libre, la FSF los protegió bajo la Licencia Pública General (GPL) (http://www.fsf.org/licenses/gpl.html), una ingeniosa fórmula de copyright expansivo, conocido como copyleft, en contraposición a las restricciones de las licencias de copia habituales. Las condiciones de esta licencia, calificada también como contagiosa, se aseguran que un producto amparado por ella no evolucionará a versiones propietarias o restrictivas, pues hereda las características de la licencia original. Esta astuta forma de proteger sus creaciones ha convertido a la FSF en el foco más significativo de la comunidad del software libre durante varios años, sobre todo, en la década de los 80 y principios de los 90, llegando a crear lo que muchos han calificado de ideología hacker. 2.2. Linux entra en escena Paralelamente, Linus Torvald, un estudiante de informática finlandés, escribía, a principios de los años 90, un sistema operativo compatible con Unix con el objeto de poder practicar en su ordenador doméstico. Este rudimentario sistema se llamó Linux y su creador difundió el código fuente en la red Internet para que fuese probado y mejorado. Este hecho causó una revolución sin precedentes en el ámbito informático, propiciando que muchísimos hackers se entusiasmaran con el proyecto hasta el punto que sobre el año 93, Linux era ya un sistema operativo casi tan potente y robusto como su inspirador Unix y superaba holgadamente en muchos aspectos a la mayoría de sistemas comerciales. No sería esa la única expansión que sufriría. A finales de los años 90, con la integración de los entornos gráficos de escritorio más avanzados (fundamentalmente GNOME y KDE) Linux abandonó los círculos propios de hackers para extenderse al usuario final, convirtiéndose así en una seria amenaza para los intereses comerciales de los fabricantes de programas de código cerrado, siendo en este momento cuando la polémica salta también a las tribunas de la sociedad. 3. Sobre la propiedad El fenómeno del software libre está poniendo en cuestión numerosos conceptos normalmente asumidos, unas veces de manera natural, otras, no tanto, en la sociedad occidental actual. El primero en tambalearse visiblemente es el de propiedad, en el sentido genuino del término y, como efectos colaterales, los derechos de copia, propiedad intelectual, libertad de información, así como otras cuestiones menores como libertad de mercado, monopolios, etc. Siempre que usamos el concepto de propiedad, en general, tendemos a la identificación de un bien material o inmaterial pero asociado a la exclusividad, es decir "poseemos algo", bien sea total o parcialmente; de modo que tenemos plena capacidad y absoluto dominio del bien poseido. 2. Los programas de código abierto son aquellos que se distribuyen junto al su código fuente para que cualquiera pueda mejorarlo y adaptarlo a sus necesidades 57 PROPIEDAD, S.L.: Propiedad y software libre 3.1. Propiedad posesiva Si adquirimos un refresco, podemos consumirlo, compartirlo o regalarlo, pero debemos fijar nuestra atención en unos rasgos fundamentales que acompañan a esta idea de propiedad. En primer lugar, el producto adquirido no ve alteradas sus características esenciales dependiendo del precio pagado, incluso si nos lo han regalado tenemos pleno dominio sobre nuestra posesión y nada condiciona nuestra decisión acerca del destino posterior del refresco. Cuando compramos software propietario este dominio no es absoluto y se nos cercena la posibilidad de adaptar, mejorar, copiar y/o compartir el producto. En segundo lugar, si ejercemos el derecho de decisión sobre el refresco, en cualquier sentido, perdemos todo o parte de nuestro dominio, tanto si lo consumimos, lo compartimos o lo regalamos. La idea de posesión lleva implícita, pues, la idea de renuncia. No ocurre así con el software. Si poseemos un programa informático, podemos cederlo y/o compartirlo sin que perdamos ni un ápice de nuestra primitiva capacidad de dominio sobre la posesión. Esta característica, por sí misma, justificaría al menos una profunda reflexión sobre el peligro de extender la noción de propiedad -y por tanto el derecho sobre ella- alegremente a este terreno. Una observación detallada y reflexiva de esta cuestión bajo el prima educativo puede llevarnos, sin mucha dificultad, a la idea que instruir en este ambiente y con estos planteamientos puede fomentar el egoismo innato en el ser humano, alentando el hecho de poseer en sí mismo, sin importar la legitimidad o el reconocimiento general y, sobre todo, sin margen para el intercambio tan necesario y enriquecedor en el ámbito del conocimiento. La propiedad en el contexto de la comunidad del software libre tiene, y así debe tenerlo, un significado totalmente distinto al sentido de propiedad convencional. El propietario de un proyecto es aquél que tiene la capacidad exclusiva de redistribuir versiones modificadas del mismo. También ésto se origina dada la estructura organizativa y de trabajo que posee la comunidad hacker productora de software libre. Cuando surge un proyecto de programa o se aborda uno existente el grupo de hackers participantes se coordinan trabajando cooperativamente, en primer lugar, para evitar redundancias innecesarias como que varios escriban la misma parte del código y, en segundo lugar, para repartirse las tareas y sumar los talentos individuales. Cuando el resto de la comunidad acepta a ese grupo como responsable del proyecto, son los únicos autorizados para modificar y certificar las variantes de código introducidas, no por una cuestión reglamentaria, sino para evitar la muerte del proyecto por dispersión. Mientras tanto, cualquier usuario, hacker o no, es libre de usar o modificar la aplicación. Consideramos que es un proceder consecuente. Esta forma de entender la propiedad consagra un principio de legitimidad, es decir, el propietario lo es no por una cuestión meramente legal, sino porque la comunidad reconoce en él unos rasgos que le acreditan y son moralmente aceptables para todos. 3.2. Propiedad abierta Por lo tanto, para la comunidad hacker de software libre no existe el concepto de propiedad convencional, de hecho toda su producción está amparada por la Open Source Definition (OSD (http://www.opensource.org/docs/definition.php)) que, al menos en teoría, permite a cualquiera tomar el código fuente de una aplicación, duplicarlo y evolucionarlo en cualquier sentido. No obstante, los usos y costumbres de los programadores de software libre hacen que su configuración y funcionamiento, tanto a nivel individual (Los proyectos también los puede mantener una sola persona) como a nivel de grupo "propietario" de un proyecto, les confieren unas características muy particulares. Según Eric S. Raymond (http://www.tuxedo.org/~esr/), en un ensayo sobre el comportamiento de estos hackers llamado "Cultivando la noosfera" (http://www.tuxedo.org/~esr/writings/homesteading/homesteading/) pone de manifiesto la contradicción entre la teoría de la propiedad asumida por la comunidad del software libre y la práctica tan diferente que resulta de sus formas de proceder, ateniéndose a unas costumbres, a menudo, con matices heredados del mundo del "software propietario". Concretamente defiende que el modelo generativo de 58 PROPIEDAD, S.L.: Propiedad y software libre software libre es homólogo a la teoría de Locke sobre posesión de tierras, para ello destaca tres formas en las que un hacker puede adquirir la propiedad de un proyecto para crear un programa libre. En primer lugar, fundando el proyecto. Lógicamente en este caso la "propiedad" no es discutida. En segundo lugar, heredándolo de su anterior propietario. Finalmente, proponerse como propietario de un cierto proyecto si éste necesita atención porque el propietario haya desaparecido o se encuentre abandonado. En este caso el protocolo requiere un anuncio previo a la comunidad, la espera prudencial antes de repetir su ofrecimiento y si no hay objeción a su propuesta, puede adueñarse del proyecto, aunque no será reconocido completamente mientras no aporte una innovación sustancial. En cualquier caso, en todos los supuestos está presente una idea legitimadora que evita el sentimiento únicamente egoísta y propicia el esfuerzo a la búsqueda del mérito. Sin duda, un valor formativo nada desdeñable. 3.3. Estructura de la propiedad libre Esta forma de proceder, según Raymond, es totalmente lockeana y recuerda la ley común anglo-americana sobre tenencia de tierras, sistematizada y racionalizada por el filósofo inglés John Locke a principios de la era moderna. Hay otras consideraciones acerca del proceder de la comunidad del software libre como Faré Rideau (http://fare.tunes.org/) quien sostiene que el hacker no ejerce su dominio en el territorio de las ideas puras, sino en los proyectos de programación, incluyendo por tanto, una labor material que lleva asociada elementos como la confianza, reputación, etc. para él sería pues, más preciso, situar sus dominios en el terreno de la ergosfera o esfera del trabajo, si bien esta matización no perturba demasiado el concepto de propiedad mismo que se manifiesta en este ambiente. Este modelo de propiedad es el que podríamos denominar, de un modo no exento de paradoja, "propiedad libre" porque en él no son fundamentales los conceptos de heredad o perpetuidad, sino que el control sobre lo poseído está, por la propia dinámica del sistema, siempre en cuestión. Un "propietario" que se negara a liberar nuevo código, que se mostrara reticente a la incorporación de mejoras, que su obstinación rebasara lo razonable o que la intransigencia pertinaz fuese una rémora para el progreso del proyecto, sería finalmente cuestionado por el resto de la comunidad y relegado de sus funciones, o bien, otro hacker asumiría el proyecto virando en la dirección adecuada y condenando, de paso, al ostracismo al líder dictatorial. Por tanto la propiedad se fundamenta en el respeto, en el prestigio, en la actitud y en la aptitud, siendo así fruto del consenso general. Cuestiones totalmente al margen del concepto de propiedad convencional. Como ocurre en la mayoría de casos, para avanzar, es necesario mirar atrás. El concepto de propiedad surge como un acuerdo para evitar las luchas fraticidas por el control de bienes escasos. La sociedad se dota de este instrumento regulador como escudo protector ante los desastres ocasionados por la disputa de elementos vitales, no suficientes para colmar las necesidades o aspiraciones de todos los miembros de la comunidad. En su génesis, la propiedad se ejercía sobre un, llamémosle así, "objeto" público, las tierras, el agua, los refugios donde cobijarse. Más tarde, fue extendiendo su ámbito para acoger las creaciones individuales o colectivas: las cosechas, las rudimentarias armas,... En definitiva, como todos los consensos humanos, es fruto de la necesidad, del "mal menor", del "beneficio"... del beneficio social. Toda sociedad acota sus libertades individuales con el único objetivo de protegerse o beneficiarse colectivamente. Llegado este extremo, cabe preguntarse, ¿estas consideraciones son de aplicación al software?, ¿qué debe proteger la sociedad, al creador de software o al comercializador?, ¿es el software un bien escaso susceptible de ser protegido?, si un programa se copia, se divulga, ¿se impide o se limita que el resto de personas puedan crear nuevas aplicaciones?, ¿qué es más beneficioso socialmente, el software comercial o el software libre? Desde luego, sería paradójico que la sociedad adoptase un marco regulador que le perjudicase a sí misma. No tendría mucho sentido y, por supuesto, estaría en contra de la finalidad primitiva de las estrategias normativas, incluso de las más evolucionadas, como afirma Jean-Jacques Rousseau en "El contrato social": Encontrar una forma de asociación que defienda y proteja de toda fuerza común a la persona y a los bienes de cada asociado, y gracias a la cual cada uno, en unión de todos los demás, solamente se obedezca a sí mismo y quede tan libre como antes. 59 PROPIEDAD, S.L.: Propiedad y software libre Es evidente que el software no presenta las características de un bien poseible en el sentido primigenio del término, más bien, nos debemos aproximar al concepto de "acción apropiativa" fruto del trabajo, 3tal y como convergen las tesis liberales y socialistas. Sin embargo hay muchas opiniones que sostienen la inapropiabilidad del software, abanderadas por Stallman y la FSF. 4. ¿Software? libre, por favor Pese a todo lo expuesto, hay determinados factores que intervienen, tal vez, para añadir mayor confusión y margen de controversia o, tal vez, para contextualizar el fenómeno del software y presentarlo junto a su genuino marco de gestación, desarrollo y distribución. Entre estos factores es indudable que destaca el fenómeno de la Internet, tanto su aparición,4 como, y sobre todo, su expansión hasta el nivel que conocemos. Aunque todavía carezcamos, quizás, de perspectiva o lejanía histórica suficiente para calibrar en su justa medida. Otro factor a tener en cuenta es la propia estructura de los programas, compuestos de algoritmos, subrutinas, bibliotecas,... no necesariamente genuinas, sino que es la combinación de una serie de elementos, en un cierto orden, lo que proporciona cohesión y funcionalidad a una aplicación informática, pero fundamentalmente, las tecnologías de distribución, edición y copia han evolucionado hasta unas cotas y con una velocidad, sin precedentes, ocasionando un fuerte desconcierto entre una sociedad organizada en unas estructuras jurídicas sorprendidas ante este voraz crecimiento. Todo este cambio tecnológico se ha ido produciendo en las últimas décadas bajo el paraguas normativo de las leyes de propiedadad intelectual, copyright y patentes, por supuesto generadas en una época diferente y con unos objetivos también diferentes. Tan sólo en algunos países se han producido cambios, modificaciones o nuevas normativas que recogían aspectos relacionados con el software, las nuevas tecnologías o el comercio electrónico, pero, bajo la referencia del actual contexto jurídico, es decir, sin afrontar un marco legislativo nuevo, acorde con las peculiaridades del tema y los intereses de la sociedad. Es ciertamente interesante conocer la posición del movimiento por el software libre en relación con la regulación normativa existente y su evolución. En primer lugar, como hemos avanzado, se defiende la idea que el software no es patentable. Para ello se fundamentan el los principios básicos que generaron la adopción del concepto de propiedad en que se sustenta la teoría del liberalismo, incluso, la propia antropología: ante unos bienes materiales escasos, constituye la única salida civilizada al control de los recursos disponibles esquivando las luchas permanentes entre los miembros del colectivo, en cambio, el software no comparte esta característica, no forma parte de los bienes físicos o materiales sino que se encuadra en el ámbito de las ideas, constituyendo un tipo particular de éstas, más cercanas al conocimiento intelectual o, si se prefiere, a la aplicación práctica de éste. En consecuencia, la escasez o no de ideas no está relacionada con que éstas sean propietarias o libres, puesto que es posible generar conocimiento simultáneamente, es decir, si dos personas tienen una idea, no impiden que la tenga también un tercero. 4.1. La sociedad contra sí misma Es el momento de plantearse, ¿por qué la sociedad ha llegado a ver con naturalidad el comercio de software?, ¿por qué se permiten las patentes sobre el conocimiento humano, e incluso se protegen jurídicamente?, ¿qué beneficio obtiene la sociedad con estas prácticas? Indudablemente, son muchos los factores que intervienen para explicar la situación actual. En primer lugar, la propia naturaleza práctica del software 5hace que vaya unido a la comercialización de servicios, a recursos físicos y a la realización de tareas que sí tienen mucho que ver con la economía de la sociedad. No es de 3. 4. 5. Incluso aquí hay margen para la disidencia: la creación de software, ¿es sólo un trabajo? El fenómeno de la Internet, por sí mismo, justificaría varias tesis y varios ensayos. No en vano, la mayoría de programas informáticos son conocidos como aplicaciones 60 PROPIEDAD, S.L.: Propiedad y software libre extrañar, entonces, que, interesadamente, las empresas hayan tratado, y conseguido, llegar a confundir producto con servicio y comercializar todo un conjunto incluyendo el software en el lote. En segundo lugar, se ha utilizado equívocamente la llamada propiedad intelectual y todo su marco legal relativo a derechos de copia y patentes, para colocar al software libre bajo su cobertura, cuando en realidad, ni por cuestiones históricas, prácticas, ni por interés social se justifica este hecho. Los derechos de copia surgen, y tienen su sentido, con la aparición de la imprenta que posibilitaba la producción en serie de libros, antes, ni existían, ni fueron necesarios, de hecho, era natural que los libros ser copiasen a mano sin despertar recelo social. Sin embargo, cuando la copia en serie se convirtió en realidad, la sociedad estimó la adopción de un instrumento que regulara esta nueva situación, naciendo así los derechos de copia. Es claro que la normativa restringía tan sólo a las imprentas, por lo tanto, a la sociedad en general 6no se le cercenaba ningún derecho fundamental que le fuese propio y, en un principio, constituyó una normativa fácil de vigilar en su cumplimiento pues bastaba con controlar a las industrias de impresión. Sin embargo, a partir de la aparición de la fotocopiadora, pero sobre todo, con el tremendo desarrollo de la tecnología de autoedición y copia, este marco normativo está gravemente obsoleto pues para su control se están proponiendo y ejecutando una serie de medidas que colisionan frontalmente con derechos fundamentales de la libertad individual,7 síntoma claro de la no adecuación del ámbito jurídico a la necesidad social. Otro tanto ocurre con la propiedad intelectual o "derechos de autor" que no constituyen un derecho fundamental, de hecho, en la Constitución de los Estados Unidos está claramente recogido que la protección al autor sobre sus derechos intelectuales debe ser por un tiempo limitado, en su origen diez años, pero con el único fin de favorecer el progreso, es decir, la sociedad protege al autor pero con el objetivo "egoísta" de beneficiarse a sí misma. No ocurre así en la situación actual, en que los derechos de autor se esgrimen por las grandes corporaciones, para justificar sus propios intereses, no los de los autores ni los de la sociedad en su conjunto. En la época en la que surge la legislación sobre los derechos de copia, ningún ciudadano miembro de la socidad renunciaba, de hecho, a ningún tipo de libertad "ejercible" pues no disponía de industria de reproducción, hoy día, esta renuncia sí es significativa. El desarrollo tecnológico ha hecho posible que una gran mayoría de ciudadanos tengan la posibilidad de acceder y copiar información de cualquier tipo, por lo tanto, parece necesario, un replanteamiento de la situación, a nivel político y jurídico. Richard Stallman, en una conferencia pronunciada en la Universidad de Burdeos, el 7 de julio de 2000, pone un ejemplo bastante ilustrativo. Viene a decir que, si en las circunstancias actuales, a un ciudadano le pagan por firmar un documento en el que renuncia a realizar viajes interestelares, sería un trato ventajoso para él ya que, de momento, no limitaría nada su libertad de actuación, sin embargo, puede que dentro de unos años, el mismo trato tenga unas connotaciones distintas y, entonces, sí suponga una merma sensible para sus derechos y libertades básicos, debiendo ser abordado desde otra posición. Por otra parte, desde los tiempos de la FSF el software libre ha tenido que justificarse continuamente y tratar de argumentar sus ventajas sociales, tanto desde el punto de vista ético, filosófico, moral, económico o de capacitación técnica. Es necesario también que nos detengamos a reflexionar sobre las mejoras que representan para la colectividad los programas comerciales y demandemos a las empresas de software propietario las explicaciones pertinentes. Hasta ahora, todas las manifestaciones e informes en este sentido han carecido de argumentación sólida y de rigor científico. Se han basado en verdades a medias e hipótesis usadas como argumentos irrefutables para establecer unas conclusiones totalmente interesadas y alejadas de toda objetividad. Sirva como ejemplo el informe elaborado por la empresa norteamericana NERA (National Economic Research Associates) (http://www.neramicrosoft.com), conocido como Informe NERA, analizado por Ricardo Galli Granada (http://mnm.uib.es/~gallir/), profesor de la Universidad de las Islas Baleares, en un artículo aparecido en Bulma (http://bulmalug.net/body.phtml?nIdNoticia=1889), donde se pone de manifiesto la parcialidad y ausencia de rigor de este tipo de documentos elaborados al dictado de los grandes intereses comerciales. 6. La mayoría de ciudadanos no poseía una imprenta, claro. 7. Software para espiar el uso de los programas de ordenadores, para rastrear las páginas visitadas en la Internet, el chip numerado y registrado con que la empresa Intel equipó a sus procesadores, se propone, el cánon de la Sociedad General de Autores para gravar la compra de CD’s vírgenes, por si fueran usados para realizar copias musicales, aunque se destinen en realidad para realizar copias de seguridad de tus datos,... 61 PROPIEDAD, S.L.: Propiedad y software libre 5. El software libre como herramienta educativa Pocos ponen en duda que, hoy día, el software tiene un protagonismo esencial en todos los ámbitos de la sociedad, especialmente en el educativo. Constituye un instrumento básico para todas las tareas relacionadas con la generación, transmisión, recuperación y almacenamiento de información. Este fenómeno que muchos califican de Tercera Revolución Industrial y que hemos dado en denominar como Tecnologías de la Información y la Comunicación (TIC), descansa, en buena medida sobre los dominios del software. El manejo de aplicaciones, ya básicas, como el correo electrónico o el procesador de textos son un requisito para la mayoría de la población contemporánea. Nuestos escolares no pueden abandonar el colegio sin conocer, más aún, sin dominar estas destrezas. Ahora bien, ¿qué se necesita para conseguir este objetivo? En general, muchas y muy variadas condiciones. Algunas pueden resultar polémicas y controvertidas, sin embargo otras parecen diáfanas y concitan bastantes acuerdos, sobre todo desde el sentido común. Cada persona, cada educador puede tener, y probablemente tendrá, una visión muy particular de esta cuestión. Puede discrepar en la edad de iniciación apropiada, puede cuestionar los métodos y los procesos de enseñanza-aprendizaje, puede acentuar en mayor o menor grado el aspecto tecnológico-científico del software o el aspecto instrumental del mismo, sin embargo, resulta evidente que algunas cuestiones están al margen de la discusión. En primer lugar, para poder adiestrar en las TIC y convertirlas en un vehículo eficaz de transmisión de conocimientos junto a una herramienta formativa y útil, es necesario acercarlas a los centros educativos, de modo que el alumno crezca y se desarrolle junto a ellas, con ellas y, por qué no, por ellas. El esfuerzo necesario para este acercamiento que debe acometer la entidad competente no es baladí. El software libre se perfila como un aliado idóneo para esta tarea, aunque sólo seamos capaces de apreciar, obtusamente, el ahorro económico en el coste de licencias. Por otra parte la educación debe tener un carácter igualitario y ser un factor esencial en la corrección de desequilibrios sociales. No parece, pues adecuado, formar en unos sistemas propietarios y comerciales alejados, en muchos casos, de las posibilidades económicas de una gran parte de la población, sino que debemos procurar la formación en entornos abiertos que garanticen el principio de igualdad de oportunidades. Básicamente y de una forma general podemos considerar como necesidades sociales primarias en relación con las TIC, la posibilidad de generar información en diferentes soportes y formatos, la capacidad de transmitirla y compartirlas con nuestros semejantes, la recuperación, consulta y almacenamiento de la misma, en resumen, herramientas de gestión total del conocimiento disponible y/o generado. Puede quedar un resquicio para la polémica si cuestionamos las capacidades reales del software libre para estas tareas, sin embargo, no resulta demasiado convincente esta objeción en los tiempos actuales, donde numerosas aplicaciones libres han demostrado con creces, no ya su idoneidad para el objetivo de su diseño sino, en muchas ocasiones, un nivel de prestaciones muy por encima de otras soluciones comerciales del mismo propósito. 6. El carácter educativo del software libre Si dejamos a un lado las obvias capacidades del software para ser usado como una herramienta eficaz en los entornos educativos y nos centramos en sus valores intrínsecos o, incluso en su estructura generativa, aproximándonos a sus formas de organización y de relación, podremos observar una serie de rasgos con un tremendo valor pedagógico y formativo. La educación, hoy día, no se concibe únicamente como un mero sistema transmisor de conocimientos preocupado por la alta cualificación y especialización de los individuos sino que también procura no desdeñar los aspectos formativos que rodean todo el proceso de enseñanza-aprendizaje acentuando los valores, actitudes y principios como ejes transversales de este proceso con la finalidad de conseguir individuos plenamente integrados, responsables, solidarios, en definitiva, una sociedad más rica y humana. 62 PROPIEDAD, S.L.: Propiedad y software libre Con carácter general, los entornos de generación de software libre aportan tipologías muy aprovechables en este campo. El esfuerzo cooperativo, el trabajo en equipo, donde cada miembro de un grupo siente la responsabilidad y, a la vez, la consideración de la importancia de su tarea para la consecución de un objetivo común es, en muchas ocasiones, un acicate y un elemento motivador amén de un magnífico instrumento de mejora de la autoestima. El planteamiento de metas comunes y la labor personal necesaria para llevarlas a cabo fomentan la generosidad y mantienen a raya el, a veces, excesivo individualismo propio del ser humano. El respeto surgido del consenso y no de la imposición supone un magnífico aliado para potenciar la cultura del esfuerzo y el afán de superación personal como medio para lograr el reconocimiento legítimo. La revisión y transparencia del trabajo personal invitan claramente a la adquisición de las dosis necesarias de humildad propicias para el progreso y la formación individual, lejos de posturas intransigentes y sectarias propias de otros ambientes más oscurantistas. La toma de decisiones basadas en la transparencia y en datos objetivos constatables constituyen un fuerte inhibidor de las tentaciones autoritarias y fomentan unos valores democráticos genuinos sustentados en la información y en la responsabilidad. La igualdad y, a la vez, la diversidad está naturalmente aceptada, potenciada, respetada y convenientemente valorada. Nadie debe sentirse inferior ni superior a nadie. Cada persona tiene sus propias destrezas que se le respetan y reconocen de modo que se canalizan adecuadamente para que el proyecto, en su conjunto, resulte beneficiado. El conocimiento circula libre. Es cuestionado, adquirido, mejorado y difundido en un esfuerzo conjunto imprescindible, para el progreso de la sociedad. Todos estos rasgos se encuentran presentes en el movimiento del software libre. Son inherentes a él y constituyen unos pilares básicos que pueden ayudarnos a entender su vertiginoso desarrollo. Tal vez ha llegado el momento de preguntarnos si la sociedad actual puede permitirse desdeñarlos. 63 Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact. Francis Brosnan Blázquez David Marín Carreño Marcos Olmos Domínguez En esta ponencia se hablará de la Arquitectura AF: una arquitectura que se propone para la implementación de sistemas de gestión empresarial, así como del proyecto a partir del cual esta arquitectura surgió: ASPL Fact. 1. Introducción A lo largo de los últimos años, se han iniciado varios proyectos de desarrollo de aplicaciones para gestión empresarial. Muchos de ellos fueron abandonados tras la etapa inicial del proyecto. Algunos otros continúan su desarrollo, pero el aprovechamiento del código existente en los mismos para su uso en otros proyectos es prácticamente nulo debido a su implementación “monolítica”. A finales de 2002, Advanced Software Production Line comenzó el desarrollo de ASPL Fact con el objetivo de crear una aplicación de facturación para Gnome, pero de modo que estuviera desarrollada bajo un modelo de componentes distribuidos altamente especializados. De este modo, a través de los primeros hitos de desarrollo de ASPL Fact, se ha ido definiendo una arquitectura de componentes distribuidos de fácil implantación e instalación, que da soporte a llamadas de procedimiento remotas y proporciona servicios de mantenimiento de sesiones, usuarios, y permisos: la Arquitectura AF. Advanced Software Production Line propone esta arquitectura como un estándar para el desarrollo de aplicaciones de gestión empresarial dentro del marco de desarrolladores de software libre. 2. La Arquitectura AF 2.1. ¿Qué es? La Arquitectura AF consiste en un conjunto de librerías de soporte para el desarrollo de aplicaciones de gestión empresarial. Lo que se pretende es establecer un entorno de desarrollo en el cual, no solo estén estandarizados el mayor número de mecanismos posibles, sino que el desarrollador se dedique a la programación de sus aplicaciones de una manera muy general, evitando detalles como la comunicación, la sincronización y el acceso a bases de datos por citar algunos. ISBN 84-88783-66-3 ©2003 64 Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact. El modelo de programación propuesto consiste es un sistema cliente-servidor TCP basado en el paso de mensajes en formato XML. Lo interesante de la arquitectura es que permite al programador usar los servicios de la arquitectura de una manera muy limpia, en concreto: • El desarrollador no tendrá que programar una sola línea de threads pues la comunicación con los servidores se realizar de manera abstracta a través de una api escrita en c que es completamente asíncrona. • El desarrollador no tendrá que escribir código para crear sockets de conexión, gestionar buffers, mensajes, etc. Todo es realizado de manera abstracta, como si tratásemos directamente con estructuras de datos. • La arquitectura está diseñada para que los componentes servidores sean independientes de la interfaz utilizada, además, éstos componentes también tienen mucho código de soporte dentro de la arquitectura para ser desarrollados rápidamente. • La arquitectura está diseñada para que los componentes servidores sean independientes de la interfaz utilizada, además, éstos componentes también tienen mucho código de soporte dentro de la arquitectura para ser desarrollados rápidamente. • Se ha estandarizado la api utilizada por las aplicaciones clientes (libafdal) para comunicarse con los servidores, así, la utilización de nuevos servidores a través de sus interfaces de aplicación es común y homogénea. • Al realizar la comunicación con los servidores de manera abstracta, a través de estructuras de datos, se evita que aparezca código SQL por toda la aplicación, consiguiendo esto último que la aplicación desarrollada no sea mantenible a través de los cambios. • La arquitectura, además, proporciona numerosos servicios que simplifican los clientes y los servidores. Algunos de estos: gestión de sesiones, permisos y mecanismos de seguridad (aun no están implementado, pero será implementado de manera transparente). • La gestión de sesiones permitirá a los clientes autenticarse una sola vez en el sistema, en concreto al servidor central, y tener acceso al resto de servidores, siguiendo un modelo de seguridad similar al de kerberos. Por otra parte, los servidores son programados de manera que la arquitectura se encarga de determinar la corrección de las sesiones sobre las que son establecidas las peticiones. • Finalmente, la gestión de usuario está centralizada, permitiendo que nuevos servidores no tengan que tener noción ninguna sobre los usuarios que existen, como gestionarlos y el nivel de acceso de que disponen. 2.2. Implementación actual Toda la arquitectura, en la actualidad, está implementada en el lenguaje C, utilizando la librería glib. Esto haría muy sencilla la construcción de bindings a otros lenguajes como C++ o Python. En la actualidad, la arquitectura AF está compuesta por varios componentes: Roadrunner Librería de comunicaciones desarrollada por la empresa sueca CodeFactory. Es una implementación asíncrona del protocolo de intercambio de mensajes sobre TCP BEEP. Esta librería abstrae completamente del interfaz de sockets de Berkeley, y proporciona todas las ventajas del protocolo BEEP, como la posibilidad de establecer varios canales de comunicación independientes por conexión, etc. 65 Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact. Coyote Esta librería, desarrollada ya dentro de la arquitectura por Advanced Software Production Line, está íntimamente relacionada con Roadrunner. Implementa los perfiles que la arquitectura AF empleará para las comunicaciones, así como todas las funciones auxiliares necesarias para el análisis léxico y sintáctico de los mensajes. AfDal Esta librería es el corazón de la arquitectura. Todos los componentes de la misma emplearán sus servicios, ya que incorpora, entre otras, los mecanismos de: • Gestión de sesión y de llaves. La arquitectura emplea mecanismos de sesión y de llaves para la transmisión de las capacidades de los usuarios desde el servidor central hasta cada uno de los servidores proveedores de servicios. • Gestión asíncrona de peticiones y procesado de respuestas. Librerías libafdal* Estas librerías, que en la actualidad se generan manualmente (aunque a medio plazo se generarán de manera automática) incluyen todas las interfaces de solicitudes de servicios para cada uno de los servidores de la arquitectura, así como los tipos que representan cada uno de los objetos de negocio con los que se trabajará. libafgs Esta librería implementa la parte común de todos los servidores de la arquitectura, de modo que la realización de un servidor se convierte en un mecanismo completamente trivial, debiéndose codificar sólo una variable que define los servicios que implementa el servidor, así como las funciones a las que se llamará cuando un cliente solicite estos servicios. af-kernel Este es el servidor central de la arquitectura. Se encarga de la gestión de usuarios y permisos, así como de la generación y mantenimiento de sesiones y llaves. Estos componentes son los que definen las capas que forman la arquitectura AF. Para implementar una aplicación que la utilice, sólo es necesario realizar un servidor que proporcione servicios que accede a la base de datos, genera sus registros log mediante la librería afgs. Tras esto, hay que implementar la capa libafdal* correspondiente al servidor, que será la librería llamada por el programa cliente para acceder a los servicios implementados. 2.3. Estado del proyecto y evolución futura. En la actualidad (septiembre de 2003), la primera versión de la arquitectura AF, tras la liberación del tercer hito, y poco antes de la liberación del cuarto hito de desarrollo de ASPL Fact, se encuentra definida en su mayor parte. La arquitectura congelará su API en el lanzamiento de la versión 0.1 de ASPL Fact, prevista para Diciembre del presente año. Esta congelación se realizará para construir la primera versión estable del sistema de facturación, aunque el desarrollo en la arquitectura no se detendrá. De hecho, existen dentro de Advanced Software Production Line varios proyectos que implicarán mejoras importantes dentro de la presente arquitectura: • AF-Gen: consiste en la construcción de un generador automático de código a partir de un lenguaje de definición de objetos de negocio. De este modo, desde una descripción de un objeto de negocio en un formato similar a IDL o a XDR, se tendrán, dependiendo de los casos, los esqueletos o el código completo de las funciones que 66 Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact. realicen los servicios relacionados con dichos objetos de negocio, tanto en la capa de servidor, como en la capa libafdal*, llegando incluso a la generación automática de formularios para interfaces de usuario. • AF-Sec: este proyecto está orientado al análisis de vulnerabilidades en el protocolo de intercambio de mensajes empleado, de modo que se consiga un aumento en la seguridad del mismo. Así mismo, también incorporará la implementación de varios niveles de seguridad para el acceso a los servicios (en la actualidad, existe un único nivel de seguridad al que se accede con un par usuario/contraseña). • En un futuro se ha previsto el soporte de scripting en el lado del servidor. De este modo, por ejemplo, la solicitud del servicio de "creación de factura" podría hacer, mediante un script creado por el administrador, que el servidor de facturación se comportara como cliente del servidor de contabilidad para insertar un apunte contable. 3. ASPL Fact 3.1. ¿Qué es? ASPL Fact era, inicialmente, un proyecto para hacer un programa de facturación bajo GNU/Linux sobre el entorno Gnome. A día de hoy, ASPL Fact es un paquete software formado por 4 servidores para la Arquitectura AF (a saber: servidor para gestión de clientes/contactos, servidor para gestión de artículos, servidor para gestión de impuestos y servidor para la gestión de facturación) y por un programa cliente (el propio programa \asplfact). Todos estos programas proporcionarán las características de un programa de facturación, pero... • En un futuro, cualquiera de estos servidores pueden emplearse para otra aplicación, ya sea de contabilidad, de control de almacenes, o de control de pedidos... • La aplicación cliente ASPL Fact es completamente independiente de la base de datos. la estructura de ésta puede cambiar, pero el código del cliente ASPL Fact se mantendrá igual: la aplicación está completamente abstraída de la base de datos. 4. ¿Por qué utilizar la Arquitectura AF? Hemos enumerado antes las ventajas de utilizar la Arquitectura AF a nivel técnico y haciendo referencia directa a problemas existentes en el desarrollo de aplicaciones de gestión comercial, pero no hemos hablado aún de las ventajas generales de esta propuesta. Tal y como está definida la arquitectura, obliga a los desarrolladores a programar en un modelo basado en capas, donde cada una se dedica a algo más específico que la anterior. Por lo tanto, cada una de las capas de comunica con la siguiente de manera abstracta hasta que la petición se resuelve finalmente. Esta idea es la misma que el estandar OSI para comunicaciones. El otro modelo posible de programación es el de una sola capa. Este tipo de aplicaciones tienen concentrada en un mismo nivel el acceso a datos (SQL), la lógica para manipular estos datos y la interfaz de usuario. Las ventajas del modelo basado en una sola capa es que es más facil de programar inicialmente y más rápido en el acceso a la base de datos frente al modelo basado en varias capas. 67 Una arquitectura para el desarrollo de sistemas de gestión empresarial. La Arquitectura AF y ASPL Fact. Pero, las desventajas que ofrece el modelo basado en una capa son: • Obliga a realizar la programación de manera muy dependiente al interfaz que se esté utilizando. Esto es un problema a la hora de compartir código con otros proyectos, pues todo el código está fuertemente acoplado a la interfaz. • En un modelo basado en varias capas, existe una parte, que es la que gestiona las peticiones a los datos, que es completamente independiente del interfaz. • Impide que se pueda construir un modelo real cliente servidor que permita una existencia independiente entre el servidor y el cliente. Esto ocasiona que no se pueda realizar proceso en los datos a no ser que el cliente esté arrancado, o se programen demonios add-hoc que realicen ese proceso. En un modelo basado en varias capas es posible la existencia de procesos de ejecución independiente a las interfaces haciendo posible el proceso en background. • Dificulta el mantenimiento del software. La característica esencial de las aplicaciones de gestión empresarial es que todas, de un modo u otro, están apoyadas sobre una base de datos. Pues bien, el acceso directo a los resultados de las sentencias SQL hace que cualquier cambio en el esquema de la base de datos signifique revisar las sentencias que ya existienses y que guardasen relación. En un modelo basado en varias capas, el acceso a los datos se realizar de una manera abstracta, es decir, la interfaz de usuario no tiene conocimiento alguno sobre cómo está implementada la base de datos, los campos que posee y las relaciones existentes. El código hecho así, no hay que revisarlo debido a cambios en el esquema de datos. 5. Referencias e información relacionada Toda la documentación actual acerca del proyecto puede obtenerse de su página web: http://fact.aspl.es Acerca de la librería Roadrunner puede encontrarse información en: http://roadrunner.codefactory.se (http://roadrunner.codefactory.se) 68 Gentoo Linux: filosofía e introducción José Alberto Suárez López Gentoo Linux [email protected] Gentoo Linux (http://www.gentoo.org) es una Meta-Distribución que ha destacado en el mundo del Software Libre gracias a seguir una filosofía o camino completamente distinto al del resto de distribuciones más conocidas y usadas como puedan ser RedHat, Debian, etc. Esta pretende ser una introducción esta distribución y a un uso básico de esta. 1. Introducción Gentoo (http://www.gentoo.org) Linux nació desde el principio con la idea de la flexibilidad y la optimización, por ello como el creador de Gentoo Linux (Daniel Robbins (mailto:[email protected])), deja muy claro en el documento de introducción (http://www.gentoo.org/main/en/about.xml) de Gentoo Linux, Gentoo Linux es una Meta-Distribución. Gentoo Linux fue concebida desde un principio para dar un gran rango de flexibilidad desde el mismo momento que se procede a instalarla. Gentoo Linux es un "sabor" especial de Linux que puede ser automáticamente optimizada y adaptada para el uso que necesitemos. El gran rendimiento y flexibilidad son marcas de la casa de esta distribución. Gracias a una tecnología llamada "Portage", Gentoo Linux puede ser un servidor seguro, una estación de desarrollo, un escritorio profesional, un sistema para juegos, una solución empotrada o cualquier otra cosa, esta adaptabilidad es lo que hace que Gentoo Linux sea una Meta-Distribución." 2. Diferencia con el resto La gran diferencia de Gentoo Linux con el resto de distribuciones actuales consiste en facilitar el trabajo, al igual que las otras, pero sin olvidar que hay usuarios más avanzados que requieren un mayor nivel de complejidad, flexibilidad, y por que no, de divertimento. Todo esto se consigue basando Gentoo Linux en LFS (Linux from scratch (http://www.linuxfromscratch.org)) añadiéndole herramientas y tecnologías que facilitan su administración, mantenimiento y uso. Esta diferencia hace que aquellos usuarios avanzados o con ganas de adentrarse aún más en el mundo de Linux (también llamados Geeks) prefieran está distribución, ya que permite hacerte tu propia distribución adaptándola a tus necesidades y de una manera más simple que empezando desde cero. Y siguiendo su estupenda documentación (http://www.gentoo.org/docs) se aprende realmente lo que se esta haciendo, no simplemente se hace (aunque también existe esta posibilidad). Gentoo Linux fue por este camino en lugar de seguir el camino de las interfaces gráficas, e instalaciones preconfiguradas que restan flexibilidad y en algunos casos entorpecen ciertas tareas. Esto no quiere decir que no pueda existir un instalador gráfico para Gentoo Linux, de hecho existe, así como otros proyectos de interfaces gráficas pero son de un uso minoritario y totalmente opcional. También existe un proyecto para la creación de un script (http://glis.sourceforge.net) que ayuda a dar todos los pasos necesarios en la instalación de Gentoo Linux. Así mismo también existen proyectos de creación ISBN 84-88783-66-3 ©2003 68 Gentoo Linux: filosofía e introducción de frontends para ciertas características del sistema, como por ejemplo el fantástico "etc-update" que permite una manejo simple y flexible de los archivos de configuración actualizados de Gentoo Linux. Además Gentoo Linux, tiene muy claro que sus características, tanto presentes como futuras, son las que los usuarios piden. La lista de desarrollo (mailto:[email protected]) esta abierta para que cualquier usuario pueda sugerir, o implementar nuevas características, que si son de buen agrado para la comunidad y no perjudican al funcionamiento de Gentoo Linux serán incorporadas a su debido tiempo. Cómo toda distribución Gentoo Linux tiene cientos de fallos o bugs de distintas categorías conocidos, y otros tantos no conocidos, pero siempre a disposición del usuario en el sistema bugzilla de Gentoo (http://bugs.gentoo.org). Desde este sistema se puede acceder a toda la información sobre fallos, no solo en el sistema, ni en paquetes concretos, sino también sobre la documentación o la agregación de nuevas características. Además todo el software desarrollado o modificado por Gentoo Linux se encuentra accesible a través del cvs de Gentoo (http://cvs.gentoo.org) para poder descargar o consultar sus códigos fuentes. La comunidad es uno de los puntos fuertes de Gentoo y el crecimiento de esta ha sido espectacular. Prueba de ello es el hecho de la tremenda base de datos que se ha originado en los foros (http://forums.gentoo.org) de Gentoo con casí medio millón de entradas con una media desde que se crearon de casi 1000 al día, y con casi 30.000 usuarios y más de 2 Gb de información. 3. ¿Qué es "Portage"? "Portage" (http://www.gentoo.org/doc/es/portage-user.xml) es el corazón de Gentoo Linux, y se encarga de muchas funciones claves. En primer lugar "Portage" es el sistema de distribución de Software de Gentoo Linux. Para obtener el último software para Gentoo Linux, solo es necesario ejecutar un comando: ’emerge sync’. Este comando le pide a "Portage" que actualize la copia local del "Árbol de Portage" desde internet. La copia local del árbol de Portage contiene una gran colección de "scripts" que pueden ser usados por Portage para crear e instalar los últimos paquetes de Gentoo. Actualmente Gentoo Linux tiene: • (comando ejecutado el 22 de Junio del 2003) minime Number Number Unique • root # gentool-package-count of categories : 76 of ebuilds : 9106 packages : 4540 (comando ejecutado el 6 de Septiembre del 2003) asuka root # gentool-package-count Number of categories : 85 Number of ebuilds : 10904 Unique packages : 5272 Es decir, casi 5300 paquetes únicos y cerca de 11000 si contamos los paquetes con varias versiones disponibles, en un total de 85 categorías. Y nuevos paquetes son añadidos continuamente al árbol de Portage para el deleite de los usuarios de Gentoo Linux. Portage es también un sistema de creación e instalación de paquetes. Cuando quieres instalar un paquete solo necesitar hacer : emerge nombre_paquete 69 Gentoo Linux: filosofía e introducción Y Portage automáticamente descargará y creará una versión adaptada del paquete para tus especificaciones exactas, optimizándolo para el hardware que sea necesario y asegurándote que las características extras del paquetes que necesites serán también instaladas y por supuesto las que no necesites no serán instaladas. ¿Por què instalar el soporte para arts en zinf si prefieres usas esd? Portage además es capaz de mantener tu sistema completamente actualizado. Escribiendo: emerge --update world Te asegura que todos los paquetes que se engloban en "world" serán automáticamente actualizados. Gracias a Portage mantener el sistema es mucho más amenos y sencillo. Además Portage usa una tecnología denominada "sandbox" que hace que un paquete no sea realmente instalado en el sistema si no puede ser instalado correctamente. Complementando a esto los archivos importantes de los paquetes (osea los archivos de configuración) no serán sobreescritos sino almacenados a la espera de una decisión del administrador por cada uno de ellos. Así como otra que permite tener varias versiones de un mismo software trabajando juntas sin conflictos y de una forma transparente al usuario. Esto es los llamados "slots". Con los "slots" podemos tener instalado simultáneamente y funcionando, por ejemplo las librerías qt-2.x y las librerías qt-3.x y a la vez distintas versiones de programas que utilizan estas librerías, usando una u otra según hallamos especificado en el USE (que se verá más adelante) o lo requiera el programa. Portage es capaz de usar otras tecnologías como "ccache" (http://www.gentoo.org/dyn/pkgs/dev-util/ccache.xml) que permite rebajar tremendamente el tiempo de compilación. Y "distcc" (http://www.gentoo.org/dyn/pkgs/sysdevel/distcc.xml) (ver documentación (http://www.gentoo.org/doc/es/distcc.xml)) que permite distribuir una compilación a través de una red para que el trabajo de compilación sea hecho por varios procesadores simultáneamente por lo que el tiempo de compilación puede llegar a ser realmente reducido. Portage también es capaz de gestionar dependencias intrínsecas y a distintos niveles, así como de diferenciar entre dependencias necesarias para la creación del paquete y dependencias necesarias para su ejecución. Y por supuesto es capaz de elegir que dependencia necesita un paquete en función del tipo de sistema y de las características de este. Portage ha bebido de muchos otros sistemas similares tomando lo mejor de ellos, y añadiéndoles nuevas características y capacidades. Así como posee la facilidad y la robustez del comando ’apt-get’ también toma algunas de sus características del sistema de paquetes de FreeBSD, y como no del sistema de paquetes de RedHat. Además cualquier usuario familiarizado con alguno de ellos se encontrará cómodo con el comando "emerge" de Portage o en su defecto con su símil del "rpm" el "epm" (http://www.gentoo.org/dyn/pkgs/app-portage/epm.xml). Con lo que la migración de estos sistemas a Portage es realmente cómoda e intuitiva. Para más información acerca de Portage se puede leer el manual (http://www.gentoo.org/doc/es/portagemanual.xml), además de la guía rápida (http://www.gentoo.org/doc/es/portage-user.xml). 4. Edge Bleding (al filo) Gracias a las peculiaridades de Gentoo Linux, los usuarios son capaces de mantener un sistema realmente muy actualizado. Gentoo Linux poseía paquetes para la versión 2 de GNOME a los 5 minutos de esta ser liberada. Así como de kde 3.1 u otras piezas de software. Pero Gentoo Linux no necesita tener varios repositorios con distintos paquetes de software para conseguir un sistema estable y flexible a al vez. En un mismo árbol de portage se encuentran TODAS las ramas necesarias desde la inestable hasta la estable para procesadores x86 (intel) hasta para Mac o sparc. Una simple configuración permite usar mezcla y separar estas ramas sin ningún tipo de problema. 70 Gentoo Linux: filosofía e introducción 5. Optimización Gracias a la flexibilidad de Gentoo y de la configuración centralizada del Portage (make.conf). Somos capaces de construir un paquete para las características exactas de nuestro sistema y de nuestras necesidades. Este es el llamado sistema de "FLAGS" y de "USE". 5.1. USE El sistema de "USE" (http://www.gentoo.org/doc/es/use-howto.xml) nos permite especificar cuales son nuestras necesidades, desde si preferimos usar gnome a kde hasta si no queremos tener soporte para gis en el sistema. Gracias a esto se puede construir el mozilla contra las librerías gtk2 y tan solo el navegador, por lo que esta aplicación en concreto estará adaptada a nuestras necesidades y optimizada para nuestro uso que será claramente perceptible. Gracias al sistema USE somos capaces de especificar una gran cantidad de características configurables por paquete, siempre adaptado al sistema que deseemos tener y tan solo con lo que necesitemos usar. Esto facilita en mucho la administración y mantenimiento del sistema y su flexibilidad a la hora de dedicar un sistema para una tarea en concreto. • Ejemplo de uso de varias características de Portage y del USE entre ellas USE="x gnome" emerge --pretend -v bitchx Calculating dependencies ...done! [ebuild N ] media-libs/audiofile-0.2.3-r1 [ebuild N ] media-sound/esound-0.2.29 +tcpd -alsa [ebuild N ] gnome-base/ORBit-0.5.17 +nls [ebuild N ] dev-util/intltool-0.25 [ebuild U ] media-libs/freetype-2.1.4 [1.3.1-r3] +doc +zlib -prebuilt [ebuild N ] x11-misc/ttmkfdir-3.0.9 [ebuild N ] x11-base/opengl-update-1.5 [ebuild N ] media-libs/fontconfig-2.2.0-r2 +doc [ebuild N ] app-arch/cabextract-0.6 [ebuild N ] x11-base/xfree-4.3.0-r2 -3dfx -sse +mmx -3dnow +xml +truetype +nls -cjk +doc [ebuild N ] x11-libs/gtk+-1.2.10-r10 +nls [ebuild N ] media-libs/giflib-4.1.0-r3 -X +gif [ebuild N ] media-libs/imlib-1.9.14-r1 [ebuild N ] app-text/docbook-sgml-1.0 [ebuild N ] gnome-base/gnome-libs-1.4.2 +doc +nls -kde [ebuild R ] net-irc/bitchx-1.0.19-r5 +ssl -esd +gnome -xmms +ncurses -ipv6 -gtk -cjk USE="-x" emerge --pretend -v bitchx [ebuild R ] net-irc/bitchx-1.0.19-r5 +ssl -esd +gnome -xmms +ncurses -ipv6 -gtk -cjk Como se observa en el ejemplo hay una gran diferencia que consiste en que uso le vayamos a dar al sistema. Esto no es una simple resolución de dependencias, sino que con un solo paquete (bitchx en este caso) podemos tener varias posibilidades. En el primer comando se usa el USE por defecto, por lo que al intentar instalar BitchX (cliente IRC de consola) intenta instalar librerías gráficas, ¿Por qué? muy simple, existe una versión de BitchX que usa las librerías gráficas "gtk" y esta depende de otras tantas. Simplemente especificando en el "USE" que no queremos usar las opciones gráficas (USE="-x") estamos delimitando que se compilará, y no solo esto, sino que también su comportamiento y relación entre si. Un ejemplo más caro puede ser el uso de la variable "java" en el "USE" al compilar mozilla. al incluir tal variable (USE="java"), se incluirá una nueva dependencia en mozilla, que es la máquina virtual java. Esto descargará e instalara la máquina virtual java, no solo eso, sino que hará lo que necesite para que mozilla tenga el soporte java. La variable "USE" (así como cualquier otra variable), puede definirse de una manera global en el archivo principal de configuración (/etc/make.conf) o en la propia línea de 71 Gentoo Linux: filosofía e introducción comandos. Se puede obtener un gran nivel de afinamiento gracias al USE y de configuración de características, no solo de ciertos paquetes sino también del propio sistema. Aquí otro ejemplo de cuan configurable puede llegar a ser un paquete tan "básico" como un editor: emerge vim -pv [ebuild R ] app-editors/vim-6.1-r21 -gnome +gpm -gtk -gtk2 +ncurses +nls +perl +python -ruby Existen varias utilidades de Gentoo que nos permiten un control más intuitivo de las variables USE. Como por ejemplo ufed (http://www.gentoo.org/dyn/pkgs/app-portage/ufed.xml) un buen gui que nos permite seleccionar los USE a introducir en el make.conf con una descripción de cada uno. Así mismo existen dos tipo de variables USE. Las que se pueden aplicar a todos los ebuilds, o las que son especificas de un ebuild. Por lo que el nivel de configuración puede ser tan profundo como se desee. 5.2. Flags (variables de compilación) Así como el USE, en Gentoo Linux es muy fácil especificar que variables debe usar nuestro compilador para crear un paquete, y esto esta integrado totalmente con el sistema Portage. Gracias al uso de compiladores y librerías de ultima generación como el gcc-3.x o las glibc-2.3.x el sistema es capaz de optimizarse para un tipo de hardware muy concreto y así sacar el mayor rendimiento de este. Esto se hace de una forma muy simple, tan solo hay que usar la variable CFLAGS="" la cual es pasada al gcc (o al compilador elegido como por ejemplo icc). Un ejemplo de esta configuración sería: CFLAGS="-mcpu=pentiumpro -O3 -pipe" Lo cual aprovecha todas las instrucciones y tecnologías de este procesador en concreto rompiendo la compatibilidad del binario generado con otros procesadores. Hay un gran número de opciones, pero no son específicas de Gentoo, dependen del compilador (en este caso gcc). Para más información acerca de esto visitar la web de opciones de gcc (http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcc/Optimize-Options.html#Optimize%20Options) o de una forma más clara está referencia (http://www.freehackers.org/gentoo/gccflags) en freehackers. Para facilitar esta tarea existe una pequeña utilidad en Gentoo llamada genflag (http://www.gentoo.org/dyn/pkgs/sys-apps/genflags.xml) la cual consta de una seria de comandos que nos ayudan a configurar el sistema: asuka root # info2flags CHOST="i686-unknown-gnu-linux" CFLAGS="-march=athlon -O3 -pipe" CXXFLAGS="-march=athlon -O3 -pipe" asuka root # info2host MAINARCH="x86" SUBARCH="duron" 5.3. Prelink Básicamente el prelink (http://www.gentoo.org/doc/en/prelink-howto.xml) modifica los ejecutables consiguiendo que se inicien hasta un 50% más rápido. ¿Magia? no. Para que prelink funcione debemos tener un sistema con una versión de glibc mayor o igual a la 2.3.1. Mandrake Linux usa esta tecnología de serie. Prelink funciona especialmente bien en aplicaciones hechas en c++ (léase KDE). Prelink modifica el ejecutable deseado añadiéndole el linkado de librerías que antes necesitaba hacer exteriormente. Aunque tiene cierto parecido, no es lo mismo que un ejecutable estático. Además Prelink es completamente reversible y seguro para el sistema. Tanto Mandrake como RedHat confían en el para acelerar sus sistemas de escritorio. 72 Gentoo Linux: filosofía e introducción 6. Conlcusión Con Gentoo Linux nos creamos un sistema completamente adaptado a nuestras necesidades y a las características de nuestro hardware. Consiguiendo una gran flexibilidad y optimización de paso. Gracias a Portage nuestro sistema es tremendamente sencillo de administrar y automatizar. Sin perder un ápice de flexibilidad. Pero aunque nuestro sistema este muy optimizado y compilado desde cero la mejora de velocidad no tiene porque notarse ni ser obvia, pero el rendimiento del sistema será tremendamente aumentado. No hace mucho fue publicado una comparativa de velocidad (usando el comando time) entre Debian, Gentoo y Mandrake. En esta comparativa se ejecutaron varas aplicaciones y se medio el tiempo en cada una por separado. En esta comparativa Mandrake conseguía las mejores marcas de velocidad (algo que no extraña teniendo en cuenta que en la comparativa fue la única que uso prelink), ademas la Gentoo que se uso no fue compilada desde cero. Entre Debian y Gentoo el resultado fue reñido, obteniendo resultados equivalentes, demostrando que no es factible hacer una instalación de Gentoo Linux ya que no se consigue una velocidad superior a una distribución ordinaria. Pues bien aprovechando el paso de un usuario de RedHat desde tiempos inmemoriales a Gentoo hicimos nuestra propia prueba. En un mismo ordenador con una Mandrake 9.1 muy bien configurada se ejecutaron una serie de aplicaciones y se midieron con el comando time. Más tarde se hizo una instalación de Gentoo Linux 1.4 GRP (una versión de Gentoo Linux totalmente binaria exceptuando el kernel) y se ejecutaron los mismo comandos. Y por último se aplico el prelink a esas aplicaciones (no a todo el sistema) y se volvió a medir. Cabe destacar que la persona que realizo estas prueba es un recién llegado a Gentoo por lo que el sistema seguramente se podría haber optimizado mucho más, Además el sistema Gentoo usado no fue compilado desde cero para obtener el máximo rendimiento. Aquí están los resultados: • Características de la máquina: Pentium III (Coppermine) 733 Mhz 256 Kb de Caché. 1461 bogomips 128 Mb de RAM • • • Mandrake 9.1 (prelink de serie): Mozilla 5,34 5,45 5,32 NetBeans 38,37 14,58 20,43 Kmail 0,42 0,42 0,46 Gentoo 1.4 GRP Pentium3 : Mozilla 2,88 2,82 2,88 NetBeans 18,98 18,35 18,51 Kmail 0,39 0,97 0,33 Gentoo 1,4 GRP Pentium3 (prelink selectivo) : Mozilla 2,8 2,78 NetBeans (no aplicable) 2,82 73 Gentoo Linux: filosofía e introducción Kmail 0,03 0,02 0,01 En definitiva, los resultados hablan por si solos. Si en la comparativa anteriormente mencionada, Mandrake se situaba por encima de Debian y una Gentoo un tanto malograda, al superar en esta comparativa una Gentoo básica a Mandrake, también supera a Debian ;) Nota: no, lo del 0,03 no es una errata. Gracias a Juán Jesús Prieto (mailto:jjprieto@eneotecnología.com) de Eneo tecnología por la comparativa objetiva. En palabras de Daniel Robbins: [22:15] <BaSS > ok i’ll send to u and seemant the talk and the this lil benchmark [22:16] [drobbins] ok cool [22:16] [drobbins] a good thing is to say "we don’t do any magic, we just get the latest impro 7. Bibliografía http://www.gentoo.org - Web principal http://www.gentoo.org/doc/es/gentoo-x86-install.xml - Guía de instalación de x86 http://www.gentoo.org/doc/en/gentoo-ppc-install.xml - Guía de instalación de PPC http://www.gentoo.org/doc - Documentación en varios idiomas http://forums.gentoo.org - Foros de Gentoo en varios idiomas http://www.gentoo.org/main/en/about.xml - Acerca de Gentoo http://www.linuxfromscratch.org - Linux from scratch http://glis.sourceforge.net - Script ayuda instalación http://www.gentoo.org/main/en/lists.xml - Listas de correo http://bugs.gentoo.org - bugzilla de Gentoo http://www.gentoo.org/doc/es/portage-user.xml - Guía de usuario de Portage http://www.gentoo.org/doc/es/portage-manual.xml - Manual de portage http://www.gentoo.org/doc/es/use-howto.xml - Guía de USE http://www.gentoo.org/doc/es/distcc.xml - Guía de Distcc http://www.gentoo.org/main/en/contract.xml - Contrato social de Gentoo http://www.gentoo.org/news/en/gwn/gwn.xml - Boletín semanal de Gentoo 74 Plone - Taller y experiencia docente Gregorio Robles Grupo de Sistemas y Comunicaciones - Universidad Rey Juan Carlos [email protected] Jesús M. González Barahona Grupo de Sistemas y Comunicaciones - Universidad Rey Juan Carlos [email protected] [email protected] Esta ponencia pretende ser a la vez taller y presentación de una experiencia docente de Plone, una herramienta libre de generación de portales web. Plone se fundamenta sobre la sólida base del servidor de aplicaciones Zope y se adecúa muy bien como portal comunitario, ya que tanto la gestión de los contenidos como de la apariencia se pueden realizar de manera sencilla a través de un interfaz web. Los autores de esta ponencia han utilizado estas herramientas para la consecución de objetivos docentes en una asignatura orientada a alumnos de carreras no técnicas. Los resultados de esta experiencia han sido muy satisfactorios. 1. Introducción Plone [PloneWeb] es un generador de portales web construido sobre la sólida base de Zope. Plone permite la creación, personalización y gestión de un sitio web de manera rápida y fácil. Todas las acciones que se han de realizar para la gestión de Plone se pueden realizar a través de un interfaz web una vez instalados Zope y Plone, lo que facilita el trabajo colaborativo y distribuido. Plone es un proyecto desarrollado por una amplia comunidad y su licencia es [GPL]. Se puede probar Plone sin necesidad de instalarlo en el sitio creado por el propio proyecto Plone para pruebas [PloneWeb]. ISBN 84-88783-66-3 ©2003 75 Plone - Taller y experiencia docente Figura 1. Página principal del GSyC realizada con Plone Zope [ZopeWeb] es un servidor de aplicaciones totalmente orientado a objetos escrito en Python. Es el proyecto estrella de la compañía Zope Corporation, que lo publica bajo los términos de la licencia Zope Public License [ZPL], una licencia de software libre. Zope ofrece una infraestructura general sobre la que se pueden construir aplicaciones web. De esta manera, muchos conceptos y funcionalidades pueden ser reutilizadas. Así, por ejemplo, la herramienta de generación de portales se basa en con módulos de gestión de usuarios, de seguridad o de sesiones ofrecidos por la arquitectura Zope. En realidad, sobre Zope se ha construido una capa intermedia llamada CMF (Content Management Framework, plataforma de gestión de contenidos) que ofrece funcionalidades de interés para gestores de contenidos como es el caso de Plone y de otras aplicaciones web. Si Zope es una plataforma genérica, CMF se basa en ella y es más concreta. Plone es un producto final que se basa en CMF (y, por tanto, en Zope). Desde octubre de 2003, el portal principal de Zope utiliza la terna Zope/CMF/Plone. La estructura de este documento es la siguiente: En primer lugar se van a presentar los diferentes contenidos (objetos) de los que consta Plone y que permitirán al lector hacerse una idea de lo que se puede incluir en su portal Plone. En segundo lugar, introduciremos los roles por defecto que existen en Plone y los permisos que tienen. A continuación, se verán dos conceptos muy importantes para un entorno corporativo en el que se haga uso de Plone: los estados de los objetos y el flujo de trabajo (workflow). En el siguiente apartado, se presentará la interfaz de gestión de contenidos que ofrece Plone y se hará un breve ejercicio práctico para que el lector pueda familiarizándose con los conceptos presentados con anterioridad y su uso en Plone. El siguiente punto incluye la interfaz de gestión de Zope que posibilita realizar acciones más allá de la gestión de contenidos como cambiar la apariencia, gestionar permisos, añadir nuevas funcionalides, etc. Finalmente se indicará la existencia de otros 76 Plone - Taller y experiencia docente productos integrables en Plone y se describirá la experiencia docente que los autores han tenido en un curso universitario en el que esta herramienta constituía uno de los pilares básicos del programa. 2. Objetos Todos los contenidos que pueden ser introducidos en el portal Plone son conceptualizados como objetos. De esta forma, cada objeto cuenta con unas características propias y unas acciones asociadas, mientras que otras son comunes a todos. Así, una imagen tiene características de tamaño en píxeles que no suele tener un texto, pero ambos -como objetos- tienen nombre (a partir del cual podrán ser referenciados por una URL única) y pueden ser copiados y/o borrados de idéntica manera. Plone cuenta con una serie de objetos, de los cuales los más importantes son las carpetas, los documentos y las imágenes. Sin embargo, no son los únicos. A continuación se ofrece una breve descripción de cada objeto: • Las carpetas son en sí contenedores o clasificadores de otros objetos. Por eso, como veremos más adelante no cuentan con vista de objeto (mostrará en su caso el documento por defecto, index_html) y en su vista de contenidos muestran precisamente lo que contienen. Por defecto, las carpetas publicadas y las visibles que haya creado el propio usuario aparecen en la caja de navegación lateral. • Los documentos son la parte esencial de un portal y están compuesto por texto. El texto que contienen puede ser texto estructurado (texto plano con unas pocas marcas para darle estructura), HTML o texto plano. Tanto en texto estructurado como en HTML existe la posibilidad de introducir imágenes, tablas, enlaces, etc. • Se pueden subir objetos imagen a Plone que posteriormente pueden ser referenciados desde los documentos HTML. Las imágenes para el logotipo, los iconos y los demás elementos de configuración no incluidos en la parte dedicada a los contenidos no se pueden subir mediante Plone, sino que han de hacerse a través de la interfaz de gestión de Zope (conocida por sus siglas en inglés, ZMI). • Los eventos permiten indicar, entre otras cosas, entradas en el calendario del portal. • Las noticias son documentos de texto con ciertas peculiaridades. En primer lugar, cuando se publican, aparecen en una página especial dedicada a las noticias. Asimismo, existe una caja lateral “de fábrica” que las indexa. • Los enlaces permiten almacenar un enlace URL. • Los temas son elementos interesantes para facilitar las búsquedas dentro del propio sitio web. 3. Roles dentro de Plone (y Zope) Plone cuenta con una serie de roles por defecto que suelen ser los comunes en un portal web. Los roles tienen asociados una serie de permisos que permiten realizar acciones. Tanto los roles como las acciones pueden ser modificadas por el usuario (a través del interfaz ZMI), aunque esto no suele ser necesario. Los roles son: • El rol de miembro es el equivalente al de usuario registrado en muchos sitios web. El miembro sólo tiene acceso a la interfaz de Plone y no a la ZMI, por lo que puede gestionar contenidos. Los contenidos que puede gestionar un miembro han de encontrarse dentro de su carpeta personal, que se encuentra bajo la carpeta Miembros (Members). Todos los objetos que cree un miembro le pertenecerán, por lo que podrá modificarlos como quisiere, así como cambiarlos de estado: publicarlos para que los vea todo el mundo, hacerlos privado para que no los vea nadie más, retirarlos si están publicados, etc. Para hacerse miembro, sólo hace falta rellenar un formulario de alta. • Los revisores son miembros de Plone con una serie de permisos adicionales, ya que tiene la potestad de validar o no las noticias que todo el mundo envía. Por defecto, existe una caja lateral que avisa a un revisor de noticias 77 Plone - Taller y experiencia docente pendientes de validar en caso de que éstas existieran. Al igual que los miembros, el revisor no tiene acceso al ZMI. • El gestor tiene permisos de acceso tanto para Plone como para la ZMI, por lo que es el encargado de la configuración de la apariencia de Plone. El gestor también tiene entre sus tareas la de gestionar los usuarios y los roles y, por tanto, será el que deba asignar los roles necesarios. Así, a través del ZMI en acl_users puede asignar o quitar permisos de revisor a un usuario ya miembro. 4. Estados y workflow Todos los objetos tienen asociada la característica de estado a partir de la cual se puede ver lo “publicable” que se consideran. La razón por la cual existen diferentes estados la podemos entender fácilmente si nos imaginamos un entorno profesional donde trabajan de manera simultánea muchas personas. En un entorno así, existirán personas que creen contenidos y otras que los revisarán y darán el visto bueno (o no) para su publicación definitiva. A continuación, se muestra un ejemplo muy simple de un posible flujo de trabajo (workflow en inglés), que puede complicarse notablemente dependiendo de los objetivos que se persigan. Los estados existentes por defecto en Plone son: • Visible (por defecto): los contenidos (objetos) que tienen este estado pueden ser vistos por cualquiera en Internet mediante la inserción de la URL en el navegador, pero no aparecerán indexados para búsquedas ni en la página de noticias en el caso de que fuera una noticia. Esto quiere decir -a efectos prácticos- que son accesibles, pero más bien difíciles de encontrar. • Publicado: además de accesible por URL, los contenidos en este estado son indexados, por lo que pueden aparecer en búsquedas dentro del sitio, en la caja lateral que sirve de barra de navegación o como noticia en la página de noticias. • Privado: solamente el autor (y el gestor del sitio) puede acceder a este contenido. Todo acceso por parte de terceros será rechazado. El flujo de trabajo normal suele ser el siguiente: primero se crea un nuevo documento (que aparecerá en estado visible). Para cuando el documento esté presentable, se cambiará su estado a publicado para que todo el mundo lo pueda ver y esté indexado. Si se quieren realizar modificaciones a un documento publicado, primero se ha de retirar. Entonces se podrá editar, se guardarán las modificaciones y se podrá volver a publicar. En el caso de que no se desee que se vea, siempre se podrá hacer privado . El siguiente diagrama de estados muestra el flujo de trabajo de manera gráfica. 78 Plone - Taller y experiencia docente Figura 2. Algunos objetos (como documentos, eventos o noticias) ofrecen la posibilidad de especificar las fechas de publicación, por lo que una vez que cumpla el plazo el objeto se retirará de manera automática. Un ejemplo muy simple de esto es una noticia con las ofertas de la semana. Este documento tiene sentido la semana de la oferta, incluso en las anteriores, pero una vez que la oferta caduca no tiene ningún sentido que siga publicado. 5. La interfaz de gestión de contenidos La gestión de los contenidos web en Plone se realiza a través de la propia interfaz que ofrece Plone. Esto supone que Plone sirve tanto para ver los contenidos (como portal web) como para gestionarlos (como gestor de contenidos). Para poder diferenciar entre una y otra actividad, se han ideado dos vistas: • La vista de contenidos muestra los contenidos de una carpeta. Esto permite ver el tipo de objetos que contiene, su estado, su tamaño, la fecha, así como gestionar su ubicación (seleccionarlo para copiarlo, cortarlo, pegarlo, borrarlo o cambiarle el estado). Figura 3. La vista de contenidos en Plone. En este caso, estamos viendo lo que contiene la carpeta 79 Plone - Taller y experiencia docente Campus • La vista de objetos por otro lado muestra el objeto en sí. En el caso de la mayoría de los objetos esta acción es evidente: si el objeto es una imagen, en la vista de objetos se verá la imagen. La única excepción a esta regla la proporcionan las carpetas, que en vista de objetos mostrarán el objeto por defecto (generalmente un documento) que siempre ha de tener el nombre “index_html”. Hay que tener cuidado con no llamar a otros objetos -carpetas, imágenes, etc.- “index_html”, ya que en ese caso mostrará sus contenidos y no el documento que nosotros deseamos. A modo de ejemplo, vamos a crear una carpeta nueva con un documento que a su vez ha de contener una imagen. Para realizar las acciones que se van a describir a continuación, el lector ha de ser miembro registrado en el portal. Todos los miembros cuentan con una carpeta personal que cuelga de la carpeta Miembros. Los pasos a seguir son los siguientes. 1. Nos situamos en la carpeta raíz - generalmente la carpeta raíz es la que contiene la página principal y es de donde nace el árbol de carpetas. Si no estamos en la carpeta raíz, podemos utilizar la caja lateral de navegación para llegar a ella. Apretando sobre la entrada superior, llegaremos a la carpeta raíz. Una vez en la carpeta raíz, cambiamos a vista de contenidos para ver los contenidos de la carpeta. Veremos que, por ahora, lo que hay es un documento de nombre “index_html”, que es -como sabemos ya- el documento por defecto que se muestra al dar la dirección de la carpeta (en otras palabras, la página que vemos cuando estamos en vista de objetos en la carpeta raíz). Figura 4. La caja de navegación lateral 80 Plone - Taller y experiencia docente 2. Lo siguiente que queremos hacer es crear una subcarpeta, que será donde incluyamos nuestro documento. Para eso, seleccionaremos “Carpeta” del menú desplegable (que por defecto muestra la entrada “Seleccione”) y pulsaremos sobre el botón “añadir un nuevo objeto”. Aparecerá un formulario donde podremos introducir una serie de parámetros: nombre (que será un nombre interno utilizado por Plone mediante el cual se generarán las URLs; aunque Plone dé uno por defecto, nuestro consejo es que se ponga en este campo lo mismo que en el título), título y descripción. Introduciremos los parámetros deseados y pulsaremos sobre “guardar” al final del formulario para que se cree. Una vez hecho esto, veremos la vista de contenidos de la nueva carpeta, que como es lógico se encuentra vacía. Recomendamos al lector que cambie a vista de objetos; lo que podrá ver es que al tratarse de una carpeta y ante la ausencia de un documento por defecto (el “index_html”), se muestre la descripción de la carpeta y se invite a crear un documento por defecto. Siguiendo el enlace de "Edit" podríamos editar ahora el documento por defecto, cosa que haremos un poco más adelante. Volvamos antes a la vista de contenidos, porque primero añadiremos la imagen. 3. Seleccionemos “imagen” del menú desplegable para crear una imagen. El formulario que nos aparecerá es idéntico al de la carpeta que ya conocemos de crear una nueva carpeta, con la salvedad de que hay un campo para seleccionar la imagen de nuestro disco duro. Rellenemos el formulario y seleccionemos “guardar”. Una vez hecho esto, nos aparecerá la vista de objeto de la imagen, o sea, la propia imagen. Si vamos a la vista de contenidos lo que veremos es que la carpeta que creamos con anterioridad tiene un objeto: la imagen. 4. El siguiente paso va a consistir en crear el documento, que además será el documento por defecto de la carpeta. Para ello procederemos de forma idéntica a la creación de la imagen con la salvedad de que ahora en vez de seleccionar “imagen”, seleccionaremos “documento”. Para que sea el documento por defecto de la subcarpeta, su nombre ha de ser "index_html", mientras que el título lo podremos elegir libremente. La descripción debe ser un breve resumen de lo que va a incluir el documento, mientras que el campo del formulario dedicado al texto es el que contendrá el contenido documento en sí. El texto del documento puede estar en varios formatos: texto estructurado (que es texto plano más unas pocas marcas que le dan cierta forma - similar a lo que se utiliza en los wiki), HTML o texto plano. Una vez que hayamos rellenado todos los campos, pulsamos sobre “guardar”. Figura 5. Formulario de edición de un documento 81 Plone - Taller y experiencia docente 5. Ahora que tenemos el documento, deseamos añadir la imagen. Para eso, le damos a la pestaña de “Editar” e introducimos en el campo de texto el siguiente código HTML: <img src="nombre_imagen"> . Guardamos las modificaciones y ¡voilà!, la imagen aparece en nuestro documento. 6. El último paso consiste en cambiar el estado de la subcarpeta. Para ello se accede a la vista de contenidos, se pulsa sobre la pestaña de estado y se publica la imagen seleccionando Publicar. 6. Interfaz de gestión de Zope Mientras que con la interfaz de Plone podemos gestionar todo lo relativo a los contenidos, la interfaz de Zope nos brinda la oportunidad de modificar la apariencia y las acciones. Esto se realiza mediante la interfaz de gestión de Zope (ZMI - “Zope Management Interface” en inglés). La interfaz ZMI ofrece muchas más posibilidades que la de Plone y también es mucho más compleja. Por eso se recomienda la utilización de recetas tal y como se pueden encontrar en [MalditosProfes] para la consecución de objetivos puntuales que en la gran mayoría de los casos serán suficientes. Figura 6. Aspecto de la interfaz de gestión de Zope Para el manejo de Zope, es importante tener en cuenta que debido a su implementación en Python, sigue el paradigma de orientación a objetos. Esto quiere decir que todos los elementos que gestiona Zope son objetos, con características y acciones asociadas. La interfaz de gestión de Zope está organizada en carpetas de manera que 82 Plone - Taller y experiencia docente ofrece un sistema de navegación a través de los objetos similar al del Explorador de Windows. A continuación se va a describir de manera breve las posibilidades que ofrece el ZMI para la gestión de la apariencia de Plone: • Existen apariencias (skins) de fábrica que permiten definir la apariencia visual del portal de manera rápida. Los skins suelen tener asociada una hoja de estilo donde vienen especificados los colores a utilizar. Se pueden inspeccionar los skins y los elementos que los componen en la subcarpeta portal_skins. Como se puede observar, las subcarpetas dentro de portal_skins tienen superpuesto un candado al símbolo de carpeta convencional. Eso quiere decir que los elementos contenidos en ella son de sólo lectura. Para personalizar la apariencia (por ejemplo la hoja de estilo), se tiene que apretar sobre el botón Customize, que lo que hace es llevar el objeto a la subcarpeta custom, que es la única subcarpeta dentro de portal_skins sin candado. Esta carpeta sí contiene elementos de lectura y escritura, por lo que el usuario podrá personalizar allí tanto hojas de estilo como los demás elementos. Plone busca primero en la subcarpeta custom y si no lo encuentra, mira en la del skin elegido, por lo que situar en custom una imagen llamada logo.jpg supone de hecho cambiar el logo del portal. Lo mismo ocurre con el resto de iconos y la cabecera y pie de página. El lector interesado puede mirar las recetas en [MalditosProfes] para mayor información. • Desde la ZMI también se pueden gestionar las cajas laterales y las pestañas. Para ello se ha de ir desde la carpeta raíz de la ZMI a la pestaña Properties, donde aparecerá un listado de pestañas y cajas laterales y sus parámetros de configuración. Se pueden añadir y quitar pestañas de manera muy sencilla. En la pestaña Properties situada en la parte superior del frame de la derecha es donde se ha de especificar en qué columna (slot) ha de aparecer la pestaña. Se puede encontrar más información en [MalditosProfes]. • La gestión de usuarios (y de los roles que tienen) se realiza en la subcarpeta acl_users. Si se entra en ella, se puede ver un listado de los usuarios registrados en el portal. Pulsando sobre un usuario se puede ver su rol y modificarlo de manera sencilla. Por causas que los autores de esta ponencia todavía no entienden, se recomienda que todos los usuarios utilicen el formulario de creación de cuenta en Plone que ofrece la propia interfaz Plone en vez de ser incluídos mediante el ZMI. Parece ser que lo primero incluye una serie de acciones añadidas que no se hacen en lo segundo y, por eso los usuarios que han sido creados directamente a través del ZMI suelen encontrar algunos problemas al hacer uso del portal. Figura 7. Vista de la carpeta de usuarios acl_users • La gestión de seguridad está basada en la división de las diferentes acciones que se pueden llevar a cabo y en el concpeto de adquisición. Lo primero viene a significar que cada acción tiene asociado un permiso. Para poder llevarla a cabo, se ha de tener ese permiso. Generalmente los permisos se dan a ciertos roles. Por otro 83 Plone - Taller y experiencia docente lado, la adquisición se puede tratar de manera similar a la herencia: carpetas de niveles inferiores tendrán la configuración de seguridad de la carpeta superior si no se ha especificado lo contrario. De esta forma, el superusuario de Plone, lo es de todas las subcarpetas dentro de Plone a menos de que se especifique lo contrario. Cabe mencionar que la gestión de seguridad es una tarea bastante compleja y que para el caso general la que viene por defecto es más que suficiente. Figura 8. Ejemplo de asignación de permisos en la ZMI 7. Integración de otros productos CMF-Zope Existen muchos productos que pueden ser integrados en Plone y que aportan funcionalidades y posibilidades añadidas a las que obtenemos al instalar un Plone desnudo. Es más, debido a la naturaleza orientada a objetos de Zope, muchos de los productos de Zope se pueden integrar sin más o con pocas modificaciones directamente en Plone. Estos productos ofrecen funcionalidades añadidas que pueden ser interesantes para el portal. Como la descripción pormenorizada y completa de los productos existentes en Plone excede lo que pretendemos abarcar en en esta ponencia, sólo se describirán los más comunes, dejando al lector que busque por su cuenta si necesita más información en [Collective], un proyecto que pretende aglutinar todos los productos Zope/Plone bajo un mismo paraguas. • Uno de los productos más interesantes es Localizer, que permite la localización del portal. Existe otro producto con idénticos objetivos llamado I18NLayer. Las capturas de pantalla que han sido mostradas en esta ponencia hacen uso de Localizer, de forma que los mensajes de interfaz de usuario están en español en lugar de en inglés. • Existen varios productos de edición. Los más conocidos son: CMFVisualEditor, CMFOODocument y ExternalEditor, aunque no son los únicos. • Para la sindicación existe un producto llamado CMFSin. • Se pueden integrar encuestas mediante el producto MPoll. • Se puede añadir un wiki al portal con el producto Zwiki para Plone. Por ejemplo, el sitio web de Plone utiliza este producto para ofrecer documentación tipo chuletas para los usuarios [PloneHowTo]. 84 Plone - Taller y experiencia docente 8. Experiencia docente Los autores de esta ponencia han tenido la suerte de poder utilizar Zope, ZWiki, Squishdot y Plone en una asignatura de libre elección ofertada a alumnos de la Facultad de Ciencias de la Comunicación. Esta experiencia docente es, por tanto, una experiencia con alumnos de carreras universitarias no técnicas y que han elegido la asignatura para completar su currículo. Los conocimientos mínimos exigidos para cursar la asignatura eran los que se habían adquirido en una asignatura troncal que se imparte en el primer curso y que introduce al alumno en los entornos ofimáticos y de navegación en Internet. La composición del alumnado era bastante heterogénea, ya que muchos contaban con experiencia y soltura superior a la de sus compañeros en cuanto al uso de sistemas informáticos. Aún así, de una encuesta que se hizo en la primera clase pudimos observar que, en general, no contaban con conocimientos de creación de páginas web y, salvo contadas excepciones, desconcocían el lenguaje HTML. 8.1. Programa de la asignatura La secuencia de contenidos elegida para la asignatura fue la siguiente: • Presentación de la asignatura (2 horas) • Introducción a Internet (4 horas) • Introducción al lenguaje HTML: uso de Mozilla Composer (8 horas) • Foros en Internet: uso de Squishdot (4 horas) • Elaboración de documentos colaborativos: uso de ZWiki (4 horas) • Introducción teórica a Zope y Plone (2 horas) • Gestión de contenidos en Plone (6 horas) • Práctica: creación de un entorno web por grupos de 4 a 6 personas utilizando las herramientas utilizadas durante el curso (20 horas) • Presentación pública del práctica (4 horas) En general, todas las clases -salvo las eminentemente teóricas- contaban con alrededor de 30 minutos de teoría al principio y una hora de trabajo práctico en el laboratorio docente con las herramientas que se habían presentado con anterioridad. La parte práctica cuenta con un guión que los alumnos han de seguir. Algunas prácticas se hacían a nivel individual, aunque también se programaron actividades por grupos para que los alumnos pudieran asimilar los conceptos de intercambio y generación de información de manera colaborativa de una forma más fácil. Por ejemplo, tras ver que los alumnos no conseguían asimilar los conceptos y la utilidad de un sistema wiki, se ideó una actividad para que comprendieran las posibilidades que ofrece esta herramienta para el trabajo colaborativo con resultados inmediatos. Para ello, durante una hora de prácticas se elaboró una historia colaborativa, que consistía en ofrecer una poco de trama de la historia (con unos párrafos bastaba) en una página wiki y a continuación una serie de posibilidades para seguir la historia, que consistían en enlaces a otras páginas wiki. Otra persona debía seguir la historia según las posibilidades ofrecidas en otra página wiki y ofrecer al final de la misma varias posibilidades para que a su vez otros compañeros suyos pudieran aportar. Así, a partir de un comienzo común, la historia se va ramificando con las colaboraciones de los alumnos. 8.2. Problemas encontrados El principal problema con el que nos hemos encontrado es que la documentación existente sobre Plone es bastante escasa. Este hecho se agudiza más aún al no existir prácticamente material en nuestra lengua. Sobre todo en las primeras semanas de uso de Plone, los alumnos se sentían “indefensos” ante la imposibilidad de acudir a un 85 Plone - Taller y experiencia docente manual de referencia completo y conciso que explicara la herramienta y su uso. Cabe decir que se está trabajando en este aspecto y que en un futuro no muy lejano esto dejará de ser un problema. La reciente creación del sitio [HispaZope] es una clara muestra de ello. De la encuesta final que se hizo a los alumnos se ha podido observar que los alumnos han salido satisfechos de la asignatura y con los conocimientos adquiridos. También han valorado positivamente la secuencia de las clases y algunas de las actividades realizadas. Son más críticos, sin embargo, con las herramientas elegidas y sospechan que conocer su uso no les va a servir en su futuro profesional. Por otro lado, hemos podido observar cómo una serie de conceptos han sido difíciles de asimilar por los alumnos. A continuación se citan los más importantes, por lo que se recomienda que en futuras experiencias docentes donde se utilicen estas herramientas se haga especial énfasis en que estos conceptos queden claros: • Diferenciación entre la interfaz de gestión de apariencia (en el ZMI) y la interfaz de gestión de contenidos. • Diferenciación entre la vista de contenidos y la vista de objetos. • Creación de las páginas por defecto (index_html). • Asimilación del concepto de “workflow” (flujo de trabajo). • Uso de los roles: ningún grupo utilizó en sus prácticas especiales ninguna política de asignación de roles más allá del que todos tuvieran todos los permisos. 9. Conclusiones En esta ponencia se ha presentado brevemente la plataforma Zope y más ampliamente su herramienta de generación de portales Plone. Se ha mostrado cómo Plone se basa en el uso de roles de usuario, varios estados para los contenidos, una amplia gama de objetos en los que se puede encuadrar los contenidos y un flujo de trabajo bien definido. Asimismo, hemos podido ver la interfaz de gestión de contenidos de Plone, con seguridad lo más utilizado, así como la interfaz que se utiliza para gestionar la visualización y las acciones. Esto se hace mediante la interfaz de gestión de Zope (ZMI) y su uso es mucho menos frecuente que la de gestión de contenidos en Plone. Para terminar, se ha ofrecido una experiencia docente que los autores de este artículo han tenido en la que las herramientas presentadas han sido utilizadas por alumnos universitarios de carreras no técnicas. La experiencia ha sido muy provechosa, tanto para los profesores como para los alumnos. Bibliografía [Collective] Projects in the Collective, http://plone.org/collective/Document.2003-07-24.1856 . [GPL] GNU General Public License (GPL) Version 2.0, http://www.gnu.org/copyleft/gpl.html . [HispaZope] HispaZope, http://www.hispazope.org . [MalditosProfes] MalditosProfes.com - Portal de apoyo de los Profesores de la Asignatura Servicios de Información en Internet. Curso 2002-2003., http://barba.dat.escet.urjc.es:9080/cccom-serv-infoinet/PracticasEspeciales/MalditosProfes.com/ . [PloneBook] Andy McKay, The Plone Book, http://plone.org/documentation/book/ . 86 Plone - Taller y experiencia docente [PloneBook-es] Andy McKay, Plone Book (en español), http://www.neuroomante.com/Members/pedro/libro_plone . [PloneDemo] Demo Plone Web Site, http://demo.plone.org . [PloneHowTo] Tutorial and How-to section of plone.org, http://plone.org/documentation/howto/ . [PloneWeb] Plone Project Web Site, http://www.plone.org . [ZopeBook] Amos Latteier y Michel Pelletier, The Zope Book, http://www.zope.org/Documentation/Books/ZopeBook/ . [ZopeWeb] Zope Project Web Site, http://www.zope.org . [ZPL] Zope Public License (ZPL) Version 2.0, http://www.zope.org/Resources/ZPL . 87

las actas de las jornadas - Gcubo

Documentos relacionados

Productos

Apoyo

las actas de las jornadas - Gcubo

Documentos relacionados

Añadir este documento a la recogida (s)

Añadir a este documento guardado

Sugiéranos cómo mejorar StudyLib