Libertonia || Havoc Pennington sobre el futuro de Gnome


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Havoc Pennington sobre el futuro de Gnome
Por pbenavent departamento la prensa es muy mala , Sección Diarios Puesto a las Sat Apr 23rd, 2005 at 06:38:44 PM CET

Hay gente que le gusta polemizar. En el peor sentido de la palabra. Si Havoc opina sobre Gnome me gusta saber que dice antes de opinar. Hay quien se lanza a la polémica sin más.

Recordemos que Havoc Pennington es un empleado de RedHat, desarrollador de Gnome y de freedesktop. Además, responsable en buena medida del tema de escritorio BlueCurve que utilizan las versiones gnome de RedHat y que da aspecto coherente a aplicaciones Gnome y KDE. Corregidme por favor, si me equivoco.

Havoc opina sobre el futuro de Gnome, menciona la palabra fork y se lía, por que algún comentario de los que suscita en Slashdot parece que ni han leído lo que dice.

Él mismo se lamenta de lo sesgado de entresacar frases de contexto y pone puntos sobre las ies: que si habla de una rama para la nueva arquitectura Gnome de ciclo más sosegado un ciclo de 6-9 meses para la actual rama 2.10,...

De hecho ha seguido reflexionando sobre la futura arquitectura de Gnome y cuales son sus ideas y no ha hecho tanto ruido, tal vez, porque para estar de acuerdo o en desacuerdo te lo tienes que leer todo y pensar, y para lo otro solo hay que leer una frase y decir chorradas.

Esta entrada en el diario es una pataleta contra el trolling y la falta de sensatez, a ver si hay animos y alguno hacemos una entrada sobre el asunto que reflexiona en voz alta el tal Havoc.

Por ejemplo acerca de romper las dependencias de compatibilidad hacia atrás para hacer un Gnome centrado en el usuario, habla acerca de ventanas, menús, habla de hacer una nueva arquitectura, para lo que a mi me parece, una propuesta de casi de comenzar de cero, y mantener Gnome 2.X para seguir haciendo aplicaciones, pero lo que sea el núcleo de la plataforma que se trabaje en ese hipotético Gnome 3...

< Movilización contra las patentes de software en Europa el 27-A (3 comments) | Debian en mac mini (I) (32 comments) >

Enlaces Relacionados

· Slashdot
· Havoc Pennington
· algún comentario de los que suscita en Slashdot
· More on pbenavent's Diary
· Also by pbenavent

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Havoc Pennington sobre el futuro de Gnome | 12 comentarios (12 temáticos, editoriales, 0 ocultos)

Mientras exista la polémica habrán trolls (none / 0) (#1)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Mon Apr 25th, 2005 at 03:45:14 AM CET
(Información Usuario) http://speedball.servemp3.com

No soy psicólogo ni sociólogo, pero creo que el fenómeno troll es una consecuencia directa de la existéncia de polémicas. Mientras haya una discusión polémica en el que existan dos o más bandos habrá gente que siga a uno de esos bandos como un acto de fe más que tras haber tenido una actitud reflexiva y haber concluido que uno de los dos tiene más razones que el otro.

En cuanto al camino que ha de seguir GNOME, no estoy seguro exáctamente hacia dónde debe ir, pero creo que hace tiempo que existe un problema importante. El problema de GNOME es que es una inmensa infraestructura desaprovechada, seguramente debido a una arquitectura excesivamente compleja o mal planificada.

La intención original de GNOME era crear una arquitectura atractiva para la creación de aplicaciones gráficas para el usuario. Principalmente se quería crear un modelo de componentes reutilizables y transparentes a la red. Un poco al estilo de OLE/ActiveX de Microsoft, pero para todo el escritorio y para todas las aplicaciones y utilizando un protocolo estándar (CORBA).

CORBA ha estado desde el principio, aunque se ha tenido que programar un ORB desde cero (ORBit) porque ninguno de los existentes previamente (en particular MICO) era lo suficientemente eficiente y enlentecía demasiado el escritorio. De hecho fue la lentitud de MICO lo que hizo desechar la idea de usar CORBA en KDE.

Lo que no ha estado desde el principio ha sido el sistema de componentes, Bonobo, que era la supuesta base sobre la que debía funcionar GNOME. Por eso han ido apareciendo más y más librerías, y más y más subsistemas que no se integran (por lo menos del todo) con el sistema de componentes, el cual parece que finalmente ha quedado un poco en desuso.

Otro problema que se ha presentado, es que tras el largo y doloroso parto de Bonobo, el resultado final parece ser que no es del todo satisfactorio, y existen voces que proponen substituirlo por el modelo de OpenOffice.org UNO, o por el modelo de Mozilla XPCOM.

Lo que me gustaría sería que se decidiesen definitivamente por un modelo de componentes, ya sea un Bonobo reparado, UNO, XPCOM o incluso Kparts. Eso si, debería seguir implementandose sobre CORBA, ya que el que pueda ser transparente en la red puede ser muy interesante, aunque no se si ORBit ya lo soporta (ORBit 1.x no lo hacía, pero creo que el 2.x si). Las librerías que formasen parte de GNOME deberían ser exclusivamente para dar soporte al sistema de componentes, y el resto debería programarse como componente.

Así por ejemplo gnome-vfs debería ser la implementación del componente Bonobo::Storage y GStreamer de Bonobo::Stream. Es decir, en vez de derivar directamente de GObject, debería ser GObject -> BonoboObject -> Steam -> gstreamer.

Evidentemente todos estos cambios harían que GNOME3 fuese incompatible no sólo en cuanto a binarios (ABI) sino que el código fuente también sería incompatible (API), pero tenía entendido que ese era ya el sistema empleado para hacer un cambio de numeración. El salto de GNOME 1.x a 2.x era precisamente por eso, porque eran incompatibles.

Cuidado, que lo he simplificado mucho, y nada es exáctamente como lo he puesto, aunque se acerca. Por ejemplo el componente Stream de Bonobo es más complejo, pero vale para hacerse una idea.

Quizás a muchos les importe más la cuestión gráfica del escritorio, pero sin duda muchos de los problemas gráficos de GNOME se deben a sus problemas arquitectónicos.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar

Si hay que romper la compatibilidad se rompe (none / 0) (#2)
por jamarier a las Mon Apr 25th, 2005 at 02:32:41 PM CET
(Información Usuario) http://barbacana.net/blog/

Un de los problemas técnicos que siempre le he achacado a la saga DOS...Windows XP es la historia de las compatibilidades. Por mantener la compatibilidad con todo lo anterior, se han ido manteniendo atrocidades inimaginables para otros campos. Qué decir de las memorias extendidas o expandidas que había que configurar para superar los 640k de memoria. o los sistemas operativos a 16 bits si hacer uso de 32bits hasta hace nada.

Una ventaja que tuvo Linux en estos casos es que muchas de estas limitaciones no se consideraron en su diseño porque ya habían sido superadas.

Personalmente prefiero romper la compatibilidad con lo anterior si eso nos permite mejorar en calidad. Si además se tiene un poco de vista y por medio de adaptadores se permite la ejecución de software antiguo con las nuevas tecnologías, pues mejor que mejor.

-----
Opinión expresada por alguien que puede que no sea yo.
[ Padre ]

La compatibilidad es opcional (none / 0) (#3)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Mon Apr 25th, 2005 at 03:24:58 PM CET
(Información Usuario) http://speedball.servemp3.com

Hoy día podemos tener compatibilidad con aplicaciones antiguas tanto como queramos, simplemente teniendo instaladas las librerías necesarias. Usamos GTK+ 2.x, pero no hay nada que nos impida ejecutar también una aplicación GTK+ 1.x ¿verdad?

Lo mismo pasa con GNOME, aunque usemos GNOME 2.8 o 2.10, podemos seguir usando viejas aplicaciones del GNOME 1.x siempre y cuando tengamos las correspondientes librerías. Cierto que quedan "desintegradas" con el resto de GNOME, pero también lo están las aplicaciones de Windows 3.11 en el XP, o las de MacOS 9 en el MacOS/X ¿no?. También es cierto que hay cosas que no se podrán usar, como por ejemplo los applets del panel de GNOME 1.x en el panel del GNOME 2.10, pero no es ningún trauma.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]

Sobre ORBit y los cambios en Gnome (none / 0) (#4)
por jorginius ("jorginius" en Google Mail) a las Mon Apr 25th, 2005 at 03:26:21 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

ya que el que pueda ser transparente en la red puede ser muy interesante, aunque no se si ORBit ya lo soporta (ORBit 1.x no lo hacía, pero creo que el 2.x si)

Define "transparente a la red". Cualquier versión ORBit funciona en red si te refieres a eso. Quizás hables de que en ORBit2 se incluyó entre otras cosas un mecanismo para recuperar los IOR vía url.

En CORBA no dicen nada sobre cómo recuperar los identificadores de los objetos, así que en teoría tienes que usar un mecanismo paralelo para publicar los IOR (escribirlos en archivos de texto y publicarlos en un servidor web o usar un sistema de archivos compartido o el registro de Gnome en local, por ejemplo). En la práctica todos los ORB incluyen algún mecanismo propio para resolverlo (bueno, TAO y Mico, que son los que conozco, lo tienen). ORBit no tenía nada de eso hasta la versión 2.

En cualquier caso, Bonobo/ORBit funcionan en red, pero no XPCOM ni KParts de las alternativas que pones.

XPCOM es bastante majete y multiplataforma. Las KParts sólo se pueden programar en C++.

En el fondo esos dos no son más que dlopen() atiborrado de esteroides. ORBit también funciona así si detecta que un objeto es local, por motivos de eficiencia. La detección además se hace una sóla vez y se cachea, para sobrecargar aún menos las resoluciones.

La verdad es que parece que algo falla cuando usar Bonobo no está generalizado, siendo uno de los pilares de la arquitectura. En KDE es muy raro ver alguna aplicaciones que no use/sea una KPart. En Gnome lo raro es encontrar las que usen Bonobo. ¿Será CORBA?, ¿será el api?... El marketing seguro que no, aunque ahora se hable mucho menos de Bonobo que hace unos años.

Evidentemente todos estos cambios harían que GNOME3 fuese incompatible (...) pero tenía entendido que ese era ya el sistema empleado para hacer un cambio de numeración. El salto de GNOME 1.x a 2.x era precisamente por eso, porque eran incompatibles.

Ojala sólo hubiera cambios entre las versiones mayores. Le he ido perdiendo la pista a la rama 2.x y quizás ahora sea más estable pero antes se colaban cambios que te obligaban a reescribir el código entre subversiones de Gnome e incluso entre revisiones menores.

Es malo arrastrar la compatibilidad hacia atrás como una losa pero es mucho peor tener que reescribir las aplicaciones cada seis meses.

Vamos, que si siguen como antes, no se les iban a caer los anillos por meter un cambio como éste entre versiones :-)

[ Padre ]

Los bonobos no paran de joder (none / 0) (#5)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Mon Apr 25th, 2005 at 04:35:13 PM CET
(Información Usuario) http://speedball.servemp3.com

Quizás hables de que en ORBit2 se incluyó entre otras cosas un mecanismo para recuperar los IOR vía url

Si, me refería a eso.

En cualquier caso, Bonobo/ORBit funcionan en red, pero no XPCOM ni KParts de las alternativas que pones

Efectivamente, ni XPCOM, ni KParts, ni UNO funcionan en red, ya que no estan implementados sobre CORBA, mientras que Bonobo si. La idea que expongo, y que no ha sido propuesta por mi, sino por auténticos desarrolladores de GNOME e incluso de Bonobo, es copiar la misma jerarquía de clases de UNO o incluso XPCOM e implementarla sobre CORBA, tal como esta hecho con Bonobo.

Supongo que lo que no ha gustado de Bonobo son cosas como un pobre rendimiento en su versión original (la que llevaba GNOME 1.4) y la jerarquía de clases.

Me parece que fue con MrProject que aparecieron las quejas más duras sobre Bonobo y que redujeron su uso al menú o algo así para aumentar el rendimiento.

En Gnome lo raro es encontrar las que usen Bonobo. ¿Será CORBA?, ¿será el api?... El marketing seguro que no, aunque ahora se hable mucho menos de Bonobo que hace unos años.

Así es, no sólo aparece mucho menos Bonobo en los textos modernos de GNOME, sino que además todas las novedades de GNOME no se basan en absoluto en Bonobo. Así por ejemplo, las tres novedades arquitectónicas principales de GNOME que yo recuerde no emplean ni se relacionan en absoluto con Bonobo: gnome-conf2, gnome-print, gnome-vfs y gstreamer. Por lo menos, si no recuerdo mal, gnome-db si esta bonobizado.

No creo que el problema sea CORBA, ya que se supone que Bonobo debía abstraer CORBA y hacerlo invisible al programador (o casi). De todas formas, tampoco me parece que CORBA, tal como se usa en GNOME, sea la hostia de complicado. De hecho en mi humilde opinión, es precisamente CORBA lo que lo hace interesante.

Me da la sensación que debe de ser una conjunción de pobre rendimiento, un diseño que no convence a nadie por intentar agradar a todos y un retraso en su implantación provocando una inercia a no usarlo muy grande.

Ojala sólo hubiera cambios entre las versiones mayores. Le he ido perdiendo la pista a la rama 2.x y quizás ahora sea más estable pero antes se colaban cambios que te obligaban a reescribir el código entre subversiones de Gnome e incluso entre revisiones menores.

Todavía no he probado GNOME 2.10 en serio, pero esos problemas que efectivamente se presentaban en los GNOME 1.x no los he sufrido en el GNOME 2.x. Me da la sensación de que se ha estabilizado mucho la API principal, aunque en alguna cosas, como en gstreamer precisamente, es muy normal acabar teniendo dos versiones de las librerías, pero lo cierto es que no ha entrado a formar parte de GNOME oficialmente hasta hace muy poco.

La impresión que me da es que los binarios para GNOME 2.0 deben funcionar sin problemas en GNOME 2.10.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]

UNO sí (none / 0) (#6)
por jorginius ("jorginius" en Google Mail) a las Mon Apr 25th, 2005 at 05:50:05 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

UNO me sonaba que soportaba objetos distribuidos, y lo confirman en su página: UNO Development Kit

Para XPCOM salió un bridge (¿obsoleto?) de IBM para Bonobo, explicado en una serie de dos artículo del 2001. "Bridging XPCOM/Bonobo: Techniques" y "Bridging XPCOM/Bonobo: Implementation". Hace años pude leer estos mismos enlaces, pero ahora piden registro (¿?). No sé si con bugmenot...

[ Padre ]

A lo mejor estoy totalmente equivocado (none / 0) (#8)
por shamkao a las Mon Apr 25th, 2005 at 09:44:46 PM CET
(Información Usuario)

Hace ya bastante tiempo, me baje una charla que dio Miguel de Icaza en la universidad politécnica de cataluña (creo que fue allí) y que fue enlazada en barrapunto.

En dicha charla, Miguel de Icaza hablaba sobre Mono (fue la charla de la polémica en la que decían que Miguel no debería haber hecho un chiste sobre el mariquita de la clase cuando se refería a los que programaban en visual basic, no se si sabéis la que os digo). Si veis esa charla, en ella reconoce que intentar usar CORBA en Gnome fue el gran fracaso de su carrera, porque descubrió que no merecia la pena y que existían alternativas mucho mejores. No se si era una campaña de marketing en favor de Mono, y tampoco conozco CORBA, pero creo que a partir de ahora en Gnome se va a ver poco de eso (CORBA) y se va a tirar más hacia Mono. Todo esto no es que me lo esté inventando yo, esto está dicho por el que parte el bacalao en Gnome.

[ Padre ]

Miguel cada día parte menos bacalao (none / 0) (#9)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Mon Apr 25th, 2005 at 10:09:03 PM CET
(Información Usuario) http://speedball.servemp3.com

Además, Corba y Mono no tienen en principio nada que ver, es como si digeses que los ordenadores Dell van a dejar de usar discos IDE por usar PCI eXpress.

De hecho, hoy por hoy Mono funciona sobre Corba en cuanto que programas sobre GNOME, y GNOME utiliza Corba mucho.

En cuanto a que no añade ventajas, pues discrepo, porque el poder usar componentes a traves de la red y sin que el usuario lo vea es muy interesante. Otra cosa es que en los escritorios actuales no se aplique, debido a que la computación distribuida no acaba de... ni hay un mercado de servicios Corba, y tal, con lo que las ventajas quedan hoy por hoy muy diluidas ante los posibles inconvenientes, tales como una sobrecarga puntual que las alternativas, en principio menos potentes, no tienen.

En cuanto al liderazgo de Miguel de Icaza en GNOME, si miras en las sucesibas votaciones para la GNOME Fundation, va perdiendo apoyos contínuamente, y es más, cada vez interviene menos en el desarrollo de GNOME, ya que ahora la niña de sus ojos es Mono, que no parece que vaya a ser aceptado como parte de GNOME en mucho tiempo.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]

Es verdad que no tienen que ver pero... (none / 0) (#11)
por jorginius ("jorginius" en Google Mail) a las Tue Apr 26th, 2005 at 01:00:33 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Además, Corba y Mono no tienen en principio nada que ver, es como si digeses que los ordenadores Dell van a dejar de usar discos IDE por usar PCI eXpress.

De primeras sí que son dos tecnologías ortogonales. Uno podría tener un binding de ORBit para C# (o un wrapping del api correspondiente de Gnome) y usar los componentes Bonobo, vía CORBA, y seguir con CORBA.

Pero Mono, por otra parte, sí que podría reemplazarlo. Me explico:

Con el framework de .NET se pueden construir y manejar de serie componentes inproc y outproc. La plataforma .NET duplica "a su manera" esa funcionalidad que está en Gnome sustentada en CORBA.

Supongamos que se usa mucho .NET/Mono:

Es normal que ahora, al principio, en Mono y en .NET se tiendan puentes entre los objetos .NET y la arquitectura de componentes subyacente (ya sea COM o Bonobo) para reutilizar lo que ya hay... Pero a la larga se acabará escribiendo los nuevos componentes sólo .NET y reemplazando los antiguos. ¿Para qué vas a tener dos frameworks en la misma plataforma, el de Gnome de ahora y el de .NET, que hacen lo mismo?. Lo lógico es que te quedes con uno.

Bueno, ¿Y con cuál te quedas?. A priori son iguales: AFAIK los componentes .NET te dan la misma funcionalidad al menos que la que te dan los de Gnome... Con el fastidio de tener que cargar con framework, el código intermedio y demás.

Pero .NET trae también algunas ventajas frente a la solución CORBA, sobre todo facilidad de uso, binding y en componentes inproc (es decir, lo que realmente se usan en el escritorio y los únicos que soporta KParts).

Con CORBA, por muy rápido que sea el ORB, al no haber algo similar a un CORBA ABI, hay que pasar por él siempre y el peso del marshalling de los datos en CORBA es un poco/demasiado excesivo para tener un escritorio componentizado. En componentes outproc da un poco igual, pero en inproc .NET arrasa a CORBA... Y el 99.99% de los componentes se piensan para usar inproc.

En resumen: por poder, .NET puede reemplazar a la actual arquitectura de componentes de Gnome. De hecho puede reemplazar a COM en un futuro (que es algo mucho más maduro), aunque ahora esté centrado en interoperar con lo que ya hay en Windows... Pero también puede pasar que se siga con CORBA y C#/.NET quede como un lenguaje más para programar en Gnome.

También podría ser (ojo, que no sé si es posible por compatibilidad con el estándar) que se usase internamente CORBA/ORBit como middleware de los componentes .NET en Mono, y que al final se siguiese usando CORBA pero con otro envoltorio.

En fin, todo depende del nivel de integración de Mono con Gnome.

[ Padre ]

Citando de nuevo aquella charla (none / 0) (#12)
por shamkao a las Tue Apr 26th, 2005 at 02:07:09 PM CET
(Información Usuario)

Miguel de Icaza decía que CORBA introducía problemas que no eran sencillos de resolver y cuya solución no era muy eficiente, y como ejemplo, puso el recolector de basura de objetos distribuidos. En ese punto destacó que con Mono se deshacían de esos problemas y optaban por una estrategía de que cada máquina tuviese su framework e intercambiasen los binarios.

No se si en el vídeo ese lo mencionó o lo leí posteriormente, pero decía que el objetivo era que Gnome 4 estuviera escrito totalmente en Mono; que no se reimplementaría todo lo que ya está hecho hasta ahora, pero que todo lo que se hiciera nuevo sería deseable que fuera hecho con Mono. No se muy bien donde encaja CORBA en todo esto.

Puede que Miguel cada vez tenga menos peso, pero su opinión por eso no deja de ser escuchada, puesto que fue uno de los creadores de Gnome, y siempre quedará en una figura tipo "presidente honorífico" que tienen en el PP con Aznar, que quieras que no, seguirá influyendo aunque sólo sea por expresar lo que piensa.

[ Padre ]

No se si viene a cuento (none / 0) (#7)
por shamkao a las Mon Apr 25th, 2005 at 09:32:23 PM CET
(Información Usuario)

Si ese tío es responsable del tema blue curve, lo que ha conseguido no es coherencia sino dar una puñalada trapera al estilo y el buen gusto. (Opinión personal)

No se si es el arículo que he leido hace poco enlazado en www.osnews.com, pero lo que sí se es que el futuro no llega por sí sólo y que hay que trabajarselo. No me parece mal que se coja un código y se haga un fork para cosas experimentales y pruebas de concepto, como se hace ahora mismo con luminocity.

Un argumento en contra de eso puede ser que en gnome llevan muchos ciclos haciendo cosas y refactorizando a continuación y no se si la gente podría aguantar eso otra vez. No conozco en profundidad el entorno gnome así que no puedo hablar con propiedad, pero esa es la impresión que tengo.

A veces pienso que al software libre va por detrás en tema de innovación. Es decir, que la innovación llega de las empresas y luego en el software libre se imita y se extiende la funcionalidad de esos productos. Pero eso no es cierto, hay una gran cantidad de proyectos en los que se innova y muchísimo, lo único que hace falta, creo, es una mayor coordinación, que es lo que tienen en las empresas y los resultados que se obtienen son anunciados a bombo y platillo (marketing) dando la impresión de que ellos son la leche. Es decir, lo que necisitamos es conocido bulgarmente un mogollón de pegatinas de "powered by free software".

Las empresas no innovan: venden (none / 0) (#10)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Mon Apr 25th, 2005 at 10:20:31 PM CET
(Información Usuario) http://speedball.servemp3.com

Uno puede tener una idea genial, desarrollarla y probarla en plan conceptual, pero no encontrarle una auténtica utilidad práctica. En cambio la empresa, que busca el beneficio, de la idea genera un producto y se encarga de buscar o crear un mercado en el que resulte interesante.

La auténtica invención de la empresa es ese, hacer conocido la idea original y acercarla al público en general. Por ello la mayoría de la gente se piensa que eso fue inventado por la empresa que lo popularizó.

Un ejemplo es lo del escritorio/gestor de ventanas 3D. Existe desde hace tiempo proyectos más o menos operativos totalmente libres, pero hasta que Sun no lo ha metido en un anuncio no ha llegado a mucha gente. Y hasta que dentro de cinco años no lo lleve el Windows de turno, para la masa no existirá. Así para todo el mundo los escritorios 3D los habrá inventado Bill Gates, para los muy entendidos habrá sido Sun, y sólo cuatro pirados sabrán que se copió la idea de sistemas libres.

¿Acaso no sucede ya que para la mayoría las interficies gráficas las creó Microsoft, para los entendidos fue Apple y sólo algunos sabios dicen que éstos se la copiaron a Xerox? ¿y cuánta gente sabe de quién copio la idea Xerox?

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]

Havoc Pennington sobre el futuro de Gnome | 12 comentarios (12 temáticos, editoriales, 0 ocultos)

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda