actas de las iii jornadas andaluzas de software...

Asociacion para la Difusion y el Avance del Software Libre de Andalucıa (ADALA)Grupo de Usuarios de GNU/Linux de Granada (GCUBO)

Actas de lasIII Jornadas Andaluzas de Software Libre

Granada, 14 y 15 de noviembre de 2003

Organizadas por:ADALAGCUBOCon la colaboracion de:Escuela Tecnica Superior de Ingenierıa Informatica de la Universidad de Granada

Editores:Alfonso Cepeda CaballosAntonio Arauzo AzofraAntonio Luque Estepa

http://jornadas.adala.org

Los textos que aparecen en el presente volumen constituyen las contribuciones presentadas en las III JornadasAndaluzas de Software Libre. Reflejan la opinion de sus autores y se publican tal y como ellos las presen-taron. Esta publicacion no significa que ADALA, GCUBO, ni los editores, compartan o apoyen las opinionesexpresadas en dichos textos. Las contribuciones fueron propuestas por sus autores y pasaron un proceso deseleccion, 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, numeros de pagina (2003).

ISBN: 84-88783-66-3

Publicado por:ADALA, Asociacion para la Difusion y el Avance del Software Libre de Andalucıahttp://www.adala.orgGCUBO, Grupo de Usuarios de GNU/Linux de Granadahttp://www.gcubo.orgBiblioteca de la Escuela Superior de Ingenieros de Sevilla http://www.esi.us.es/BIBCopyright c

�2003, ADALA y GCUBO

Copyright c�

2003, Los autores de cada contribucion

Se otorga permiso para copiar y distribuir este documento bajo los terminos de la Licencia deDocumentacion Libre GNU, publicada por la Free Software Foundation, cubriendo las secciones invariantesel documento completo.

Impreso en Espana.

Tanto los trabajos individuales como las actas completas se pueden descargar en la pagina webhttp://www.adala.org/jasl3/.

2

Indice General

Comite de programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Artıculos presentadosEl kernel linux 2.6: Presente y futuroAlejandro Sanchez Acosta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Cherokee Web serverAlvaro Lopez Ortega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Reciclaje y Software Libre: Una Solucion para la EnsenanzaJuan Pablo Sanchez Beltran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Espiral de valores: tecnicas avanzadas de programacion PHPDiego Arranz y Javier Linares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Legislacion europea y el Open Source / Free SoftwareJose M. Fidel Santiago Luque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

La Intranet Educativa Municipal del Ayuntamiento de La CorunaEnrique Ocana Gonzalez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

PROPIEDAD, S.L.: Propiedad y software libreJose J. Grimaldos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Una arquitectura para el desarrollo de sistemas de gestion empresarial. La Arquitectura AF y ASPLFact.Francis Brosnan Blazquez, David Marın Carreno y Marcos Olmos Domınguez . . . . . . . . . . . . . . . . . . . . . . . . 64

Gentoo Linux: filosofıa e introduccionJose Alberto Suarez Lopez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Plone - Taller y experiencia docenteGregorio Robles y Jesus M. Gonzalez Barahona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3

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

Presentacion

En el presente volumen se recogen las contribuciones presentadas a las III Jornadas Andaluzas de SoftwareLibre, 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 electronicosque nos permiten hacer uso de las tres famosas libertades:

-Libertad de usarlo sin ninguna restriccion, ni economica ni de ningun otro tipo de discriminacion social.

-Libertad para ver como esta hecho, aprender de el y modificarlo.

-Libertad de poder distribuirlo, tanto en su version original como las posibles versiones modificadas.

Como todo aquello que permite aumentar la libertad, el software libre es un desarrollo muy interesante parala sociedad. Ası parece que esta empezando a percibirse por un numero de personas cada vez mayor. Elsoftware libre ya no solo se conoce dentro del ambito tecnico de la informatica, al que se encontraba reducidohasta hace pocos anos, sino que esta empezando a ser usado ampliamente en proyectos educativos, en lasadministraciones publicas de muchos lugares del mundo y en numerosas empresas.

Esta tercera edicion de las Jornadas Andaluzas de Software Libre se celebra en un ambiente muy positivo, enel que todos los que nos consideramos pertenecientes a la comunidad del software libre nos alegramos porgran la expansion que el software libre esta experimentando.

Podemos mencionar especialmente la iniciativa Guadalinex de la Junta de Andalucıa, que a semejanza con elproyecto de la Junta de Extremadura (Linex), pretende equipar los centros docentes con nuevas tecnologıaseligiendo al software libre como protagonista. Esta sabia eleccion, ademas de conseguir numerosas ventajasen ahorro de costes, igualdad, y libertad en el uso de las nuevas tecnolog?as, puede suponer un apoyo muyfuerte al avance del software libre. Un avance esperamos que se produzca, tanto por el impulso de nuevosproyectos de desarrollo, como por la difusion de las ideas y el propio software masivamente. Todo estoredundara sin duda en ventajas todavıa mayores para la sociedad, cerrando de esta manera un beneficiosocirculo virtuoso.

Considerando la idoneidad del software libre para ser aplicado en tareas de educacion, y la importancia deldesarrollo del proyecto Guadalinex, el tema elegido para las jornadas ha sido “El software libre y la edu-cacion”. Entre las comunicaciones presentadas en esta publicacion, todas ellas con un alto grado de calidad,encontramos algunas relacionadas directamente con la educacion y otras con los ultimos desarrollos tecnicosy cuestiones sociales relacionadas con el mundo del software libre.

Esperamos que las ponencias os resulten interesantes y que todos disfrutemos con los actos organizadosen estas Jornadas. Finalmente nos gustarıa agradecer su apoyo a todas las entidades y personas que hancolaborado en el desarrollo de las JASL3, y especialmente a los autores que han enviado sus trabajos.

Antonio Arauzo AzofraLorenzo Gil Sanchez

Comite organizador de las III JASL

7

El pasado de 27 de septiembre se cumplieron 20 anos desde el anuncio oficial del proyecto GNU. Cuando en1983 Richard Stallman mando aquel famoso correo electronico a los grupos de noticias nadie, seguro que nisiquiera el, imaginaba las repercusiones que tendrıa. Su original idea trajo al apasionante mundo del desarrollode software una libertad muy necesaria que, por otro lado, ya existıa en otras areas del conocimiento humanoy que desgraciadamente se sigue echando en falta en otras.

Su proyecto se resume, nada mas y nada menos, en crear una nueva implementacion del sistema operativoUnix que tenga los siguientes requisitos:

(0) libertad de usar un programa con cualquier proposito

(1) libertad de estudiar como funciona un programa y adaptarlo a tus necesidades (el acceso al codigofuente es una condicion previa)

(2) libertad de distribuir copias y ası ayudar a tu vecino

(3) libertad de mejorar el programa y hacer publicas las mejoras a los demas, de modo que toda lacomunidad se beneficie.

En estos 20 anos son muchas cosas las que han sucedido, pero quizas haya una que las resume a todas: se hadisenado una nueva forma de desarrollar programas; ha nacido y madurado el software libre. Puede que nosea el unico modelo valido, 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 mas importantes ha sido la de crear una comunidad dinamica,dispuesta a mejorarse y a mejorar su entorno. Y ese espıritu, precisamente ese, fue el que goberno, gobiernay gobernara las Jornadas Andaluzas de Software Libre que, este ano, se han celebrado en Granada prestandoespecial interes a la ıntima relacion que creemos existe entre el software libre y la educacion.

Confiamos, por tanto, que estas ponencias fruto de las mencionadas Jornadas y aquı publicadas sean de su in-teres. Por ultimo, agradecer sinceramente la labor realizada por los numerosos voluntarios de la organizacion,a los ponentes por participar con sus trabajos y a los organismos publicos y privados por la colaboracionprestada.

Antonio M. Zugaldıa Rodrıqued-CampraPresidente de GCubo

8

Probablemente, 2003 haya marcado un punto de inflexion en la relacion 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 enAndalucıa, la apuesta de la Junta de Andalucıa por el uso del software libre en la administracion autonomicanos ha situado en el punto de mira de la comunidad.

Las medidas promovidas por este decreto ya se han dejado notar, especialmente en el ambito educativo,donde la incorporacion de mas de 20.000 PCs equipados con GNU/Linux para los alumnos y profesores de100 centros de ensenanza ha supuesto el comienzo de la iniciativa Guadalinex, destinada a promocionar eluso de software libre por parte de todos los ciudadanos andaluces. Por ello, las III Jornadas Andaluzas deSoftware Libre estan dedicadas al empleo de software libre en la ensenanza, como vehıculo para facilitar laincorporacion de nuestro sistema educativo al tren de las nuevas tecnologıas.

En esta coyuntura, las Jornadas han despertado un nivel de expectacion superior al de ediciones anteriores.Los apoyos institucionales y empresariales, el nivel de los trabajos presentados y las previsiones de asistenciade publico hacen suponer el exito de unas Jornadas llamadas a convertirse en el punto de encuentro de lacomunidad del software libre en Andalucıa, de acuerdo al espıritu con el que nacieron y que, este ano, se vereflejado en la impagable colaboracion de GCubo en la organizacion del evento en Granada.

Daniel Carrion ReinosoPresidente de ADALA

9

ISBN 84-88783-66-3 ©2003

El kernel linux 2.6: Presente y futuro.

Alejandro Sánchez Acostakernelnewbies-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

10


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


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 uni-

camente 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


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 reprodu-

ciendo 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 expe-

dido 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


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


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 ver-

sión "antigua" de NGPT (http://oss.software.ibm.com/developerworks/opensource/pthreads/), de IBM, con mo-

delo 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 system 51% cpu 25.782 total





15



2.5.47-mm2:







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 system 7% cpu 13:53.26 total






2.5.47-mm2:







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)












make -j4 bzImage 412.28s user 36.90s system 15% cpu 47:11.14 total

2.5.46:



make -j4 bzImage 412.16s user 36.92s system 83% cpu 8:55.74 total

16


2.5.47-mm2:



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


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 Inmu-

nix, 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


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


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 ayu-

dar si econtrais algun bug. Como requerimientos no tiene anda especial; si recalcar que ahora hay nuevas uti-

lidades 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

ISBN 84-88783-66-3 ©2003

Cherokee Web server

Alvaro López Ortega

MadridEspañ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 flexi-

bilidad 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)

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 che-

rokee. 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 flexi-

bilidad; 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

ISBN 84-88783-66-3 ©2003

Reciclaje y Software Libre: Una Solución

para la Enseñanza

Juan Pablo Sánchez BeltránPresidente 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 Portugal1

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

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ífico2 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 necesida-

des3,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


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 privada5, 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 profesional-

mente, 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:

• 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 Infor-

má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.

4. 7,3 PCs/100 alumnos a tiempo parcial, con solamente el 43% de las conexiones con banda ancha.5. www.elmundo.es/navegante/2003/09/01/empresas/1063204763.html6. www.intel.com/education/recycling_computers/recycling.htm7. portal.unesco.org/es/ev.php@URL_ID=10325&URL_DO=DO_TOPIC&URL_SECTION=201.html8. www.unesco.org/webworld/portal_freesoft/index.shtml

28


• 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 Maria-

Palencia)

4.4. LTSP

• www.ltsp.org

• www.k12ltsp.org

9. www.gulic.org10. www.uca.es/grup-invest/cit/11. Decreto de Medidas de Impulso de la Sociedad del Conocimiento en Andalucía BOJA no55 21-3-2003.12. www.renuevate.com/teso/

29


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 caren-

cias 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.org14. www.landesinteractives.net

30

ISBN 84-88783-66-3 ©2003

espiral de valores: técnicas avanzadas de

programación PHP

Diego ArranzInteractors

MadridEspaña

[email protected]

Javier LinaresInteractors

SevillaEspaña

[email protected]

espiral de valores (http://espiraldevalores.org) es un lugar en Internet donde se debaten de forma orga-

nizada 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.

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 comuni-

cació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


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 oportu-

nos. 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


3.1. Arquitectura de componentes

Figura 1. Esquema metodología MVC

34


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


3.3. Un recorrido por el código

Figura 2. Ejemplo de flujo

36


A continuación explicamos cómo funciona la arquitectura MVC mediante un recorrido por los distintos com-

ponentes 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


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 correspon-

diente.

$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


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 expues-

tas. 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 herra-

mientas visuales que facilitan dichos desarrollos. A modo de curiosidad, decir que Phrame es prácticamente una

copia de Struts para PHP.

39


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, simple-

mente 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 asociacio-

nes 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óny 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 orga-

nizació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 mante-

nimiento 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

ISBN 84-88783-66-3 ©2003

Legislación europea y el Open Source /

Free Software

José M. Fidel Santiago LuqueNetwork-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 conse-

cuencia, ¿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.

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


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


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


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


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 Con-

venció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 comer-

ciales. 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


3.2. Patentes y programas de ordenador


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 aplica-

ció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 Octu-

bre 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 orde-

nador y clarificar las condiciones de patentabilidad.

46


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


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


BSA , Comments to the European Commission Consultation Paper on the Patentability of Computer-Implemented

Inventions .

49

ISBN 84-88783-66-3 ©2003

La Intranet Educativa Municipal del

Ayuntamiento de La Coruña

Enrique Ocaña GonzálezIgalia, S.L.

Departamento de Servicios

A CoruñaEspaña

[email protected]

En este artículo se presentan brevemente los orígenes, presente y futuro de la intranet educativa mu-

nicipal 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.

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 expli-

carán a continuación.

Figura 1. Esquema de la intranet educativa municipal

Intranet

Internet

SERVICIOS CENTRALES

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


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 (progra-

mació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


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 ade-

cuado para implantar de modo experimental en las escuelas infantiles de la ciudad. Se ha bautizado a esta adapta-

ció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


El proceso centralizado en un servidor (de aula) con ventanas exportadas presenta problemas al ejecutar aplica-

ciones 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

ISBN 84-88783-66-3 ©2003

PROPIEDAD, S.L.: Propiedad y software

libre

Un enfoque educativo

José J. GrimaldosProfesor 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.

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 capa-

cidad 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 idioma1 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 últi-

mos 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 procesa-

dor, 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


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 al-

guna 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


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 pa-

gado, 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 pro-

grama 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 difi-

cultad, 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 funcio-

namiento, 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 hac-

kers 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


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 prote-

ger 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 nue-

vas 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


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 preceden-

tes, 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 perma-

nentes 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. Incluso aquí hay margen para la disidencia: la creación de software, ¿es sólo un trabajo?4. El fenómeno de la Internet, por sí mismo, justificaría varias tesis y varios ensayos.5. No en vano, la mayoría de programas informáticos son conocidos como aplicaciones

60


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 ciuda-

danos 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 capacita-

ció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 Gra-

nada (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


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 so-

ciedad, 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 califi-

can 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. Algu-

nas 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 conoci-

mientos 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 dese-

quilibrios 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, he-

rramientas 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 con-

vincente 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án-

donos 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 for-

mativos 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


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 valo-

rada. 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 impres-

cindible, 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

ISBN 84-88783-66-3 ©2003

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 empresa-

rial. 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ónde 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.

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 men-

sajes 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 utili-

zada, 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 utili-

zada, 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ín-

crona 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


Coyote

Esta librería, desarrollada ya dentro de la arquitectura por Advanced Software Production Line, está ínti-

mamente 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 impor-

tantes 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


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


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

ISBN 84-88783-66-3 ©2003

Gentoo Linux: filosofía e introducción

José Alberto Suárez LópezGentoo Linux

[email protected]

Gentoo Linux (http://www.gentoo.org) es una Meta-Distribución que ha destacado en el mundo del Soft-ware Libre gracias a seguir una filosofía o camino completamente distinto al del resto de distribucionesmás conocidas y usadas como puedan ser RedHat, Debian, etc. Esta pretende ser una introducción estadistribució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 enel documento de introducción (http://www.gentoo.org/main/en/about.xml) de Gentoo Linux, Gentoo Linux esuna Meta-Distribución. Gentoo Linux fue concebida desde un principio para dar un gran rango de flexibilidaddesde el mismo momento que se procede a instalarla. Gentoo Linux es un "sabor" especial de Linux que puedeser automáticamente optimizada y adaptada para el uso que necesitemos. El gran rendimiento y flexibilidad sonmarcas de la casa de esta distribución. Gracias a una tecnología llamada "Portage", Gentoo Linux puede serun servidor seguro, una estación de desarrollo, un escritorio profesional, un sistema para juegos, una soluciónempotrada 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 igualque 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 fromscratch (http://www.linuxfromscratch.org)) añadiéndole herramientas y tecnologías que facilitan su administra-ción, mantenimiento y uso. Esta diferencia hace que aquellos usuarios avanzados o con ganas de adentrarse aúnmás en el mundo de Linux (también llamados Geeks) prefieran está distribución, ya que permite hacerte tu propiadistribución adaptándola a tus necesidades y de una manera más simple que empezando desde cero. Y siguien-do su estupenda documentación (http://www.gentoo.org/docs) se aprende realmente lo que se esta haciendo, nosimplemente se hace (aunque también existe esta posibilidad). Gentoo Linux fue por este camino en lugar deseguir el camino de las interfaces gráficas, e instalaciones preconfiguradas que restan flexibilidad y en algunoscasos entorpecen ciertas tareas. Esto no quiere decir que no pueda existir un instalador gráfico para Gentoo Li-nux, de hecho existe, así como otros proyectos de interfaces gráficas pero son de un uso minoritario y totalmenteopcional. También existe un proyecto para la creación de un script (http://glis.sourceforge.net) que ayuda a dartodos los pasos necesarios en la instalación de Gentoo Linux. Así mismo también existen proyectos de creación

68


de frontends para ciertas características del sistema, como por ejemplo el fantástico "etc-update" que permite unamanejo 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 losusuarios piden. La lista de desarrollo (mailto:[email protected]) esta abierta para que cualquierusuario pueda sugerir, o implementar nuevas características, que si son de buen agrado para la comunidad y noperjudican 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 tan-tos 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 con-cretos, 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 deGentoo (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 elloes el hecho de la tremenda base de datos que se ha originado en los foros (http://forums.gentoo.org) de Gentoocon casí medio millón de entradas con una media desde que se crearon de casi 1000 al día, y con casi 30.000usuarios 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 mu-chas 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’. Estecomando 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 instalarlos últimos paquetes de Gentoo. Actualmente Gentoo Linux tiene:

• (comando ejecutado el 22 de Junio del 2003)

minime root # gentool-package-count

Number of categories : 76

Number of ebuilds : 9106

Unique 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 delos usuarios de Gentoo Linux.

Portage es también un sistema de creación e instalación de paquetes. Cuando quieres instalar un paquete solonecesitar hacer :

emerge nombre_paquete

69


Y Portage automáticamente descargará y creará una versión adaptada del paquete para tus especificaciones exac-tas, optimizándolo para el hardware que sea necesario y asegurándote que las características extras del paquetesque necesites serán también instaladas y por supuesto las que no necesites no serán instaladas. ¿Por què instalarel 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 aPortage 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 instaladoen el sistema si no puede ser instalado correctamente. Complementando a esto los archivos importantes de lospaquetes (osea los archivos de configuración) no serán sobreescritos sino almacenados a la espera de una decisióndel administrador por cada uno de ellos. Así como otra que permite tener varias versiones de un mismo softwaretrabajando 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íasqt-3.x y a la vez distintas versiones de programas que utilizan estas librerías, usando una u otra según hallamosespecificado 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/sys-devel/distcc.xml) (ver documentación (http://www.gentoo.org/doc/es/distcc.xml))que permite distribuir una com-pilación a través de una red para que el trabajo de compilación sea hecho por varios procesadores simultáneamentepor 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 entredependencias necesarias para la creación del paquete y dependencias necesarias para su ejecución. Y por supuestoes capaz de elegir que dependencia necesita un paquete en función del tipo de sistema y de las características deeste.

Portage ha bebido de muchos otros sistemas similares tomando lo mejor de ellos, y añadiéndoles nuevas caracte-rísticas y capacidades. Así como posee la facilidad y la robustez del comando ’apt-get’ también toma algunas desus características del sistema de paquetes de FreeBSD, y como no del sistema de paquetes de RedHat. Ademáscualquier usuario familiarizado con alguno de ellos se encontrará cómodo con el comando "emerge" de Portageo en su defecto con su símil del "rpm" el "epm" (http://www.gentoo.org/dyn/pkgs/app-portage/epm.xml). Con loque 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/portage-manual.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 muyactualizado. 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 distintospaquetes de software para conseguir un sistema estable y flexible a al vez. En un mismo árbol de portage seencuentranTODAS las ramas necesarias desde la inestable hasta la estable para procesadores x86 (intel) hasta paraMac o sparc. Una simple configuración permite usar mezcla y separar estas ramas sin ningún tipo de problema.

70


5. Optimización

Gracias a la flexibilidad de Gentoo y de la configuración centralizada del Portage (make.conf). Somos capacesde construir un paquete para las características exactas de nuestro sistema y de nuestras necesidades. Este es elllamado 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 nuestrasnecesidades, desde si preferimos usar gnome a kde hasta si no queremos tener soporte para gis en el sistema. Gra-cias a esto se puede construir el mozilla contra las librerías gtk2 y tan solo el navegador, por lo que esta aplicaciónen concreto estará adaptada a nuestras necesidades y optimizada para nuestro uso que será claramente percepti-ble. Gracias al sistema USE somos capaces de especificar una gran cantidad de características configurables porpaquete, siempre adaptado al sistema que deseemos tener y tan solo con lo que necesitemos usar. Esto facilita enmucho la administración y mantenimiento del sistema y su flexibilidad a la hora de dedicar un sistema para unatarea 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) podemostener 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 BitchXque usa las librerías gráficas "gtk" y esta depende de otras tantas. Simplemente especificando en el "USE" que noqueremos usar las opciones gráficas (USE="-x") estamos delimitando que se compilará, y no solo esto, sino quetambié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á loque necesite para que mozilla tenga el soporte java. La variable "USE" (así como cualquier otra variable), puededefinirse de una manera global en el archivo principal de configuración (/etc/make.conf) o en la propia línea de

71


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 -vim-with-x -X

Existen varias utilidades de Gentoo que nos permiten un control más intuitivo de las variables USE. Como porejemplo ufed (http://www.gentoo.org/dyn/pkgs/app-portage/ufed.xml) un buen gui que nos permite seleccionarlos USE a introducir en el make.conf con una descripción de cada uno. Así mismo existen dos tipo de variablesUSE. Las que se pueden aplicar a todos los ebuilds, o las que son especificas de un ebuild. Por lo que el nivel deconfiguració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 crearun paquete, y esto esta integrado totalmente con el sistema Portage. Gracias al uso de compiladores y librerías deultima generación como el gcc-3.x o las glibc-2.3.x el sistema es capaz de optimizarse para un tipo de hardwaremuy 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 (oal 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 compatibi-lidad del binario generado con otros procesadores. Hay un gran número de opciones, pero no son específicas deGentoo, dependen del compilador (en este caso gcc). Para más información acerca de esto visitar la web de opcio-nes de gcc (http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcc/Optimize-Options.html#Optimize%20Options) o de unaforma 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 nosayudan 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 consiguiendoque se inicien hasta un 50% más rápido. ¿Magia? no. Para que prelink funcione debemos tener un sistema conuna versión de glibc mayor o igual a la 2.3.1. Mandrake Linux usa esta tecnología de serie. Prelink funciona espe-cialmente bien en aplicaciones hechas en c++ (léase KDE). Prelink modifica el ejecutable deseado añadiéndole ellinkado de librerías que antes necesitaba hacer exteriormente. Aunque tiene cierto parecido, no es lo mismo queun ejecutable estático. Además Prelink es completamente reversible y seguro para el sistema. Tanto Mandrakecomo RedHat confían en el para acelerar sus sistemas de escritorio.

72


6. Conlcusión

Con Gentoo Linux nos creamos un sistema completamente adaptado a nuestras necesidades y a las característi-cas de nuestro hardware. Consiguiendo una gran flexibilidad y optimización de paso. Gracias a Portage nuestrosistema 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 porquenotarse 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 yMandrake. 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 cuentaque 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 factiblehacer 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 nuestrapropia prueba.

En un mismo ordenador con una Mandrake 9.1 muy bien configurada se ejecutaron una serie de aplicaciones yse midieron con el comando time. Más tarde se hizo una instalación de Gentoo Linux 1.4 GRP (una versión deGentoo Linux totalmente binaria exceptuando el kernel) y se ejecutaron los mismo comandos. Y por último seaplico el prelink a esas aplicaciones (no a todo el sistema) y se volvió a medir. Cabe destacar que la persona querealizo estas prueba es un recién llegado a Gentoo por lo que el sistema seguramente se podría haber optimizadomucho 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 2,82

NetBeans (no aplicable)

73


Kmail 0,03 0,02 0,01

En definitiva, los resultados hablan por si solos. Si en la comparativa anteriormente mencionada, Mandrake sesituaba por encima de Debian y una Gentoo un tanto malograda, al superar en esta comparativa una Gentoobá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 Eneotecnologí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 improvements from all the free software developers to you more quickly"

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

ISBN 84-88783-66-3 ©2003

Plone - Taller y experiencia docente

Gregorio RoblesGrupo de Sistemas y Comunicaciones - Universidad Rey Juan Carlos

[email protected]

Jesús M. González BarahonaGrupo de Sistemas y Comunicaciones - Universidad Rey Juan Carlos

[email protected]@gsyc.escet.urjc.es

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].

75


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


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 ac-

ceso 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 Miem-

bros (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


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 configu-

ració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


Figura 2.

Algunos objetos (como documentos, eventos o noticias) ofrecen la posibilidad de especificar las fechas de pu-

blicació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 su-

pone 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


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


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 gener-

ará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 car-

peta, 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


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


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 obser-

var, 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 ele-

mentos 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


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 Exter-

nalEditor, 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


8. Experiencia docente

Los autores de esta ponencia han tenido la suerte de poder utilizar Zope, ZWiki, Squishdot y Plone en una asigna-

tura 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 supe-

rior 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 colabora-

tivo 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 continua-

ció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


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 genera-

ció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-info-

inet/PracticasEspeciales/MalditosProfes.com/ .

[PloneBook] Andy McKay, The Plone Book, http://plone.org/documentation/book/ .

86


[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

actas de las iii jornadas andaluzas de software...

Documents