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

Escritorios
Por jorginius
departamento Descubriendo programas , Sección Software Libre
Puesto a las Sun Oct 30th, 2005 at 10:25:52 PM CET
Mirando en el cajón de sastre de la interfaz gráfica de usuario encontramos dos tipos de soluciones para X: una infinidad de gestores de ventanas (Sawfish, AfterStep, IceWM, Fluxbox...) y varios escritorios.

Los escritorios son paquetes que integran gestor de ventanas y aplicaciones usando un tema visual y un framework de desarrollo común. KDE y Gnome son los ejemplos más claros y los más populares, seguidos en un segundo plano por Xfce pero estos tres no son los únicos: hay más y en esta historia hablaré de ROX, uno de esos grandes olvidado dentro de los escritorios libres y del montón de buenas (e inusuales) ideas que lo componen.

 


1. Introducción

Hace unos días leí vía OSNews un debate sobre si RISC OS debería ser OpenSource ("Should RISC OS be open sourced?"). RISC OS no es un sistema operativo que conozca de primera mano y la verdad es que no conocía cuál era su interfaz gráfica, si es que tenía alguna, pero entre los comentarios de OSNews encontré varias alabanzas a la GUI y un comentario que apuntaba que ROX ("RISC OS On X") clonaba la excelente interfaz original en Unix y además como software libre.

De ROX nunca había leído comentarios excesivamente positivos. No era más que otro programa del que había visto screenshots y que no me habían causado una impresión muy buena. En ellos ROX tiene una pinta un tanto retro y del montón sin nada digno de destacar salvo esos iconos azules enormes. Además lo tenía catalogado mentalmente como un simple "file manager" (nunca como un WM y mucho menos como un escritorio completo) y para colmo parecía un proyecto bastante marginal: de hecho en Fedora Core 4 ni siquiera se incluye (ni en core ni en extras, ni siquiera en los repositorios de RPMforge.net).

Pensando que algo tendrá el agua cuando la bendicen, me decidí a darle una oportunidad y... Me ha soprendido. Creo que ha llegado a mi disco duro para quedarse :-)

2. El escritorio

ROX es un entorno de escritorio que juega en la misma liga que Xfce. Se trata de un entorno de escritorio relativamente ligero para todos aquellos que no quieran o no puedan correr pesos pesados como Gnome o KDE. Digo "relativamente ligero" porque no hay que perder de vista que el toolkit gráfico que emplea es Gtk+2 y además varias de las aplicaciones que lo componen están escritas en Python. Probablemente no sea buena idea correrlo en nada inferior a un Pentium II con 64 megas de RAM y tarjeta gráfica acelerada en X (aunque hay ROX para Zaurus). Una instalación típica no ocupa más de 8 megas en el disco duro.

El corazón del escritorio es el ROX-Filer que, además de ser gestor de archivos, puede manejar el "pinboard" (el fondo de nuestro escritorio), los paneles y la lista de aplicaciones minimizadas/abiertas sobre el mismo "pinboard".

Otros componentes destacados son ROX-Session o gestor de sesiones sobre DBus y OroboROX que es el WM. Junto a ellos hay varios applets y aplicaciones: AddApp, Archive, Clock, Edit, Fetch, Terminal...

El framework de desarrollo se compone de Gtk+2 y de la biblioteca ROX-Clib, de la que se incluyen además bindings para Python, Perl y Ruby.

Además de esto, trae su propia forma de paquetería para el manejo e instalación de aplicaciones. Esto, que a priori parece una mala idea ("¿para qué otro si ya tengo aptitude?" o "¿si actualizo con apt o con el suyo habrá interferencias?") no lo es tanto. Empezaré la descripción del entorno por este punto.

2.1 El sistema de paquetería: AppDir, los directorios ~/Apps ~/Libs y ~/Choices

A diferencia de Unix y de Windows y al igual que en Mac OS, las aplicaciones en ROX son autocontenidas. Para el usuario la aplicación aparece como un todo y no desperdigada por todo el sistema de archivos, como un icono que puede pinchar, configurar, mover donde quiera, instalar haciendo una copia y desinstalar simplemente borrando.

A este tipo de apliaciones se les llama AppDirs en la jerga ROX (presumiblemente jerga RISC OS) e internamente hablamos de un directorio que contiene el binario del programa, sus datos asociados, la ayuda, un icono (normalmente SVG), meta-información asociada en un archivo XML y un script AppRun que oculta los detalles y ofrece opciones normalizadas de arranque y configuración.

Para hacernos una idea más precisa haré una comparación con Klik. Klik es un proyecto reciente pero muy famoso que pretende hacer algo similar: distribuir aplicaciones autocontenidas con un mínimo de dependencias en un sólo archivo. En KDE-Hispano podéis leer una mini-introducción en castellano: "Klik - copiar y borrar para instalar/desinstalar".

Ahora enumero los pros de una AppDir frente a un paquete Klik:

La AppDir no depende de Linux. Un paquete Klik (igual que los dmg de Mac) es un mini-sistema de archivos en un fichero, particularmente ramfs comprimido y montado vía loop. Un AppDir no es más que un directorio que contiene algunos archivos regulares y no necesita de ningún soporte especial en el kernel (cramfs y loop) para funcionar ni de ningún punto de montaje y/o modificación del fstab.

En la misma AppDir se puede distribuir varias versiones binarias de la misma aplicación, por ejemplo los ejecutables para PPC e IA32. En Klik es un paquete por arquitectura. De hecho el mecanismo de AppDir va un poco más allá y puede incluir también las fuentes del programa. Si el sistema no encuentra en el AppDir un binario apropiado para la arquitectura actual lanzará el proceso de compilación de manera transparente vía AppRun.

Dos críticas habituales que se le hacen a Klik son que malgasta el espacio al duplicar varias bibliotecas una y otra vez en cada paquete y que, en caso de que haya una bug en alguna de esas bibliotecas, hay que reemplazar todos los paquetes que la usen. El primer problema Klik lo palía con compresión pero para el segundo no propone nada.

Las AppDir no sufren esos problemas ya que las bibliotecas no se incluyen en cada aplicación sino que se distribuyen, a su vez, en formato AppDir. Para el usuario una biblioteca no es diferente de una aplicación: es un icono sobre el que puede pinchar (el sistema le dira que no es un programa, que es la biblioteca tal y es conveniente que la copie en el directorio ~/Lib), ver la documentación o recompilar de la forma habitual con AppRun.

Klik, por otra parte, tiene una ventaja importantísima y es que se pueden generar los paquetes automáticamente, directamente de los paquetes estándar de una distribución. A veces hay que pulir detalles a mano pero la mayoría de las aplicaciones pueden reempaquetarse en Klik sin tan isiquiera recompilar. Por contra, una aplicación contenida en un AppDir tiene que ser totalmente reubicable (la guerra que se libra en Autopackage), tiene que poder compilarse con el AppRun (esto es usando autoconf con un configure.in y unas macros propias) y hay que escribir a mano meta-información, interfaz de configuración y otros detalles. La parte buena de la historia es que existen wrappers -ROX-Wrap- para muchas de las aplicaciones que podamos tener ya instaladas. Estos wrappers las hacen pasar por AppDirs aunque, evidentemente, si instalamos los rpm de Gimp éstos no se van a desinstalar simplemente porque borremos el wrapper ni se va a copiar la aplicación entera a otra máquina sólo copiando el wrapper. También hay una aplicación AppFactory que nos permite generar de forma sencilla nuestros propios wrappers.

Claro que para un usuario típico de Unix tanto AppDir como Klik pueden parecer una aberración y la verdad es que lo son pero... A veces AppDir puede resultar muy práctico: imaginemos un laboratorio con unas cuantas máquinas de arquitecturas diferentes (Alpha, Sparc32, Sparc64, PPC e IA32), todos corriendo Linux, ahora queremos compartir por NFS los homes y lo que se pueda para ahorrar espacio en los discos y simplificar la administración.

Los directorios con binarios y bibliotecas no son compartibles entre todos, hay que tener uno por arquitectura y en cada máquina montar el apropiado. También hay que tener una base de datos de los paquetes instalados por arquitectura (los paquetes deb que se instalaron, por ejemplo. Un /var propio por familia). Para instalar o desinstalar una aplicación hay que que hacerlo en las 5 arquitecturas correspondientes y a veces la configuración de un programa que funciona en una de ellas no funciona en la otra con lo que se hace difícil compartir las preferencias.

AppDir simplifica las cosas en este escenario: las aplicaciones se copian en cada home e incluyen, en el mismo AppDir, la versión para las 5 arquitecturas. Compartiendo /home, el usuario se puede sentar en cualquier máquina y siempre tendrá los mismos programas (con el plus de que puede instalarlos/borrarlos él mismo). La configuración de cada programa no está contenida en su AppDir sino en el directorio ~/Choices, siguiendo un estándar que similar al que se está escribiendo en freedesktop.org (y que ROX adoptará cuando esté listo). Este estándar permite al usuario aplicar "perfiles de configuración" (para arquitecturas, en el ejemplo) de manera sencilla.

Dejando este ejemplo a un lado, quedan por abordar tres detalles de la paquetería en ROX: cómo se buscan los paquetes, cómo se maneja el tema de las actualizaciones automáticas y cómo se resuelve el tema del desperdicio de espacio: después de todo, si cada usuario instala sus propias AppDir en su $HOME podemos acabar con montones de copias de un mismo programa y/o de diferentes versiones de él, y lo mismo de sus bibliotecas. Para los tres la solución es la misma: 0install.

2.1.1 Zero Install o cómo correr el LGeneral desde la web

En primer lugar Zero Install o 0install no es propiamente una aplicación ROX, ni siquiera tiene porque ser una aplicación gráfica y con él puedes distribuir cualquier tipo de software pero, dado que todo ROX y la mayoría de las aplicaciones escritas para él usan este mecanismo o lo ofrecen junto con el típico tar.gz (con el AppDir dentro) y además está integrado en el escritorio mediante la aplicación AddApp, lo incluyo como una característica de la paquetería de ROX.

¿Qué es Zero Install?: una forma de distribuir software que permite correr aplicaciones sin tener que instalarlas. En cierto modo se podría decir que es la versión lenguaje-agnóstica y software libre de la tecnología Java Web Start de Sun. El usuario pincha en un enlace, o escribe "0launch url" y la aplicación se ejecuta sin más.

Está escrito en Python y la idea detrás es sencilla: Zero Install detecta a que elementos intenta acceder el programa, busca en la caché si están y los descarga en caso contrario.

Zero Install se integra en ROX y no sólo las aplicaciones, sino las bibliotecas (podemos compilar y enlazar contra bibliotecas obtenidas mediante 0install). La aplicación AddApp genera un wrapper AppDir automático. Así si tienes un AppDir "ROX-Filer" obtenido mediante 0install/AddApp puedes estar seguro al pinchar en ella de que siempre estarás corriendo la última versión, sin preocuparte de las actualizaciones ya que de eso se va a ocupar 0install: si ve que no la tienes se descargará los componentes que le hagan falta.

Zero Install puede funcionar de forma offline (siempre que no borremos la cache) u online (uso mínimo de la red o completo, con o sin caché), planificar actualizaciones globales, manejar dependencias, firmas digitales y soporta ramas (estable, inestable, etc.). Además la caché puede ser compartida entre todos los usuarios, de manera que las aplicaciones que corre uno no las tiene qué volver a descargar 0install para otro.

2.1.2 No es oro todo lo que reluce

¿Ya estás convencido de que AppDir es panace? bueno pues si es así permiteme desconvencerte :-). Hay un fallo muy gordo en todo esto y que no tiene solución. Ni con el sistema de AppDir's por si sólo ni añadiendo 0install podemos manejar dependencias.

Quiero decir que 0install o una AppDir puede saber de qué depende tal o cual software adicional pero no puede saber qué tenemos instalado ya en nuestro sistema (vía apt, por ejemplo) así que el sistema está cojo: 0install podría descargarse aplicaciones que no funcionan porque no tenemos instaladas las bibliotecas "de sistema" necesarias (las que él no conoce y que da por supuesto que están). Los scripts de Python en ROX normalmente muestran mensajes adecuados si no encuentran tal o cual módulo en el $PYTHONPATH pero en aplicaciones en C muchas veces no veremos nada, son fallos silenciosos. Ni siquiera un script de Python mostrará algo si no tenemos instalado el intérprete de Python: ese tipo de cosas son las que no chequea 0install.

En realidad tampoco Klik lo hace aunque su aproximación de incluir un montón de bibliotecas en los paquetes lo hace un poco más robusto ante este problema. Con todo, sin kdelibs no podemos esperar que funcione el paquete Klik kmines.cmg.

Salvando ese pequeño problema (lógico teniendo en cuenta que estamos haciendo coexistir dos sistemas de paquetes incompatibles) el tema funciona razonablemente bien.

2.2 ROX-Filer

El ROX-Filer es, como ya he dicho antes, el verdadero corazón del escritorio. Se puede comportar como un vulgar gestor de archivos pero también puede ofrecer paneles para anclar aplicaciones y applets, y un "pinboard" donde añadir atajos a aplicaciones, directorios, puntos de montaje, etc.

ROX-Filer permite guardar varias configuraciones del "panel" y del "pinboard", asociando a cada una un nombre, de manera que podemos arrancar con paneles con iconos diferentes (una configuración para trabajar y otra para ocio, por ejemplo) pero por lo demás esos dos son bastante convencionales. Voy a centrarme en lo que es el gestor de archivos en si.

El aspecto visual por defecto es un poco desangelado pero no es tan malo como parece: está escrito en Gtk+2 y todo lo que ves es themeable así que es cuestión de cambiar los iconos y el tema de Gtk+2 al gusto. Una vez superado la repulsa inicial nos encontramos con que llamar austera a la interfaz es quedarse corto, muy corto: una barra de tareas con 8 botones (sin texto), una etiqueta indicando el número de elementos en el directorio que estamos navegando y ya está: ni menús, ni barra de estado ni nada parecido. No hay opción para trabajar con dos paneles ni parece haber opción para seleccionar archivos (aparte de un botón de Seleccionar todo/Invertir Selección) ni para visitar un directorio sin pasar por todo el árbol antes a base de clicks (botón derecho modo navegación, botón central modo espacial). Todo está oculto mediante atajos de teclado y menús emergentes.

Una característica muy potente de ROX-Filer es su línea de órdenes o mini-cli: si pulsamos "/" se nos permite escribir la ruta directamente en un cuadro de texto en la parte inferior de la ventana y aquí un inciso sobre la filosofía del entorno: los únicos diálogos son muy poco frecuentes y nunca modales. Es habitual que las aplicaciones saquen sus "diálogos" (como este mini-cli) en la parte de abajo de la misma ventana. Otros ejemplos son las barras de progreso o el diálogo de buscar palabras que no muestra un diálogo emergente sino que usa el mismo sistema que Firefox: diálogo integrado y abajo. Otra curiosidad es que no existen las barras de menús: el menú de todas las aplicaciones siempre es emergente, con botón derecho del ratón.

Volviendo al mini-cli del Filer, hay auto-completado pulsando el tabulador y con la tecla de retroceso subimos un nivel en el árbol de directorios ("retrocedemos un tramo" en el path). Mientras escribimos los directorios el contenido de la ventana va actualizándose en consecuencia, en segundo plano y muy rápidamente (incluso con thumbnails ROX-Filer saca chispas en mi máquina comparado con Nautilus y Konqueror).

El autocompletado también funciona como filtro: si por ejemplo tenemos un directorio con tres archivos "ejemplo1.txt", "ejemplo2.txt" y "ejemplo3.txt", junto con unas cuantas decenas más, al completar "ejemplo" en la mini-cli restringimos el desplazamiento del cursor de selección de los archivos (el que se puede mover con las flechas de dirección) a esos tres nada más. Para seleccionar archivos por patrones se pulsa "." y aparece otra mini-cli en la que podemos escribir expresiones regulares completas más potentes que el glob de la shell.

Copiar, mover, enlazar, etc. A todo se accede con alguna combinación de botones de ratón (usa 3) y teclas. Con todo esto cuesta hacerse con el control pero después es de lo más eficiente. Usar el mini-cli es como tener una consola de texto pero con iconos y realimentación visual.

Copiar, mover, enlazar y demás se apoya en el Drag&Drop. No parece una práctica extraña (casi todos los gestores de archivos lo hacen, ¿no?) pero ROX-Filer lo lleva al extremo. Por ejemplo, para asociar una acción a un tipo MIME o a un archivo concreto hay que arrastrar una aplicación sobre el area de acción. Todo se hace arrastrando y soltando: cambiar iconos, modificar menús como el de "Enviar a...", añadir applets a un panel, instalar aplicaciones, descargar archivos, descomprimir...

Pinchando sobre un AppDir, éste arrancará por defecto. La meta-información contenida en el AppDir sirve para modificar los menús contextuales del Filer, de manera que si sobre lo que pinchamos con botón derecho es una aplicación nos dará la opción de navegar por dentro o de configurarla o de verificar las versiones (si es un 0install). Los puntos de montaje de los dispositivos también los trata de manera especial: mostrando si están montados o desmontados, con opciones de desmontar, expulsar CD...

Un buen detalle es que a cualquier elemento (directorio, punto de montaje, programa) le podemos asignar un atajo de teclado global.

2.3 Otras aplicaciones

Con ROX vienen o se pueden instalar muchas pequeñas aplicaciones: applets como SysTray, Pager, Volume, TaskList o el XDG-Menu, que permite tener un botón con los menúes según estándar XDG de freedesktop.org (el que sigue las últimas versiones de Gnome, en las que hay que editar los menúes con Smeg), un editor "Edit" basado en GtkSourceView, con realzado de sintaxis y demás, Album que permite hacer AppDir con colecciones de MP3/OGG Vorbis y que se reproduzcan con un click o un grabador de CD's a golpe de Drag&Drop.

Hay una lista más o menos exhaustiva en la web de ROX: Software Index y Desktop Utilities.

Un programa que merece un poco más de atención es OroboROX, el gestor de ventanas. OroboROX es un gestor muy sencillo, integrado y con un buen soporte de temas. Consume poca memoria pero por contra no tiene muchas opciones. Por ejemplo el interfaz para configurar el comportamiento de las ventanas según su WM_CLASS es casi inexistente (habrá que tirar de Devil's Pie) pero no es eso lo que me interesa.

Como ya dije, en ROX-Filer (y en ROX, por extensión) todo se hace con Drag&Drop. Por desgracia esto no funciona muy bien con el sistema de foco típico de Windows (y que han adoptado por defecto la mayoría de WM, incluidos los de KDE y Gnome). Para ilustrar el problema pongo un ejemplo:

Imaginemos que estoy visitando la página de LGames y quiero echar una partida al LGeneral. Entonces tengo que arrastrar el enlace 0install de Firefox hasta la ventana en la que tengo AddApp pero... Firefox lo tengo maximizado y, en el momento que pincho en el enlace para arrastrarlo, la ventana de Firefox pasa a primer plano y tapa la ventana donde está AddApp. Para poder llevar el enlace hasta el instaldor primero he de cambiar el tamaño de la ventana de Firefox, con la correspondiente molestia.

Por eso el manejo del foco por defecto en OroboROX es diferente al habitual: si pinchas en el contenido de la ventana ésta obtiene el foco pero no pasa al primer plano. Es decir, que al pinchar en el enlace en Firefox para arrastrarlo, Firefox no pasa al primer plano tapando la ventana de AddApp, sino que esta sigue estando ahí (el efecto es como si la configurásemos para estar siempre encima). Al arrastar el enlace dentro de AddApp, su ventana gana el foco y todo funciona correctamente. Para conseguir que una ventana pase a primer plano hay que pinchar en el marco de la ventana (la barra de título o los laterales) o bien hacerse una combinación de teclas.

No es obligatorio usarlo así pero después de un rato con él se llega a la conclusión de que es la forma más efectiva de entre las propuestas (la típica de Windows/Mac, la típica de Unix y esa) para poder explotar el Drag&Drop.

2.4 ROX-CLib

La interfaz de programación usual de ROX está compuesta de Gtk+2, una biblioteca C propia y el correspondiente binding Python (ROX-Lib2) más libxml2. La biblioteca ROX-CLib no es demasiado extensa y ofrece las siguientes funcionalidades:

Sobre Gtk+2 sólo aporta un widget nuevo pero merece la pena explicarlo. Se trata de GtkSaveBox y con él descubrimos una de las características más curiosas de ROX: no hay diálogo de selección ni de guardado de archivos. ¿Cómo funciona entonces? pues para abrir es sencillo de adivinar: usaremos Drag&Drop de los documentos sobre sus aplicaciones. ¿Y para salvar?... También Drag&Drop. ROX usa el protocolo XDS (otro estándar de freedesktop.org y van...) para salvar los archivos. Desde el punto de vista del usuario funciona así:

Supongamos que acabas de escribir algo con Edit y pulsas el icono de Guardar. Aparece una ventana no modal (el GtkSaveBox) con un cuadro de texto con el nombre y un icono que representa el archivo. Sólo tienes que darle un nombre, y arrastrarlo donde quieras guardar. En el Artículo de ROX de la Wikipedia hay un screenshot que ilustra perfectamente esta característica.

Hace algún tiempo comenté en Libertonia algo parecido, al hilo de una Comparación entre el diálogo selector de archivos de Gnome y el de KDE

Quizás la solución ideal [para Gnome] sería una ventana de Nautilus, que al pinchar en "Abrir" te aparezca una ventanita del Nautilus del último directorio en el que guardaste y ahí puedas pinchar lo que quieras o arrastrarlo directamente en la aplicación. Un comportamiento bastante consistente, creo yo: para tener un mal diálogo mejor no tener ninguno.

Perdón por lo egocéntrico de citarme a mi mismo pero me ha sorprendido: por aquel entonces no conocía ROX pero implementa prácticamente lo mismo en lo que estaba pensando, tanto para abrir como para salvar.

Otra funcionalidad que nos aporta el API es el soporte para SOAP, tanto para clientes como para servidores. Aún no lo había mencionado pero las aplicaciones ROX pueden comunicarse entre ellas por medio de peticiones SOAP y nosotros también podemos invocar funciones de manera programática desde C, un script Python o incluso desde la shell en el caso del Filer, de manera bastante similar a como lo haríamos con DCOP en KDE. La interfaz SOAP de ROX-Filer está descrita en el manual pero, para hacernos una idea, abrir un directorio tiene esta pinta:

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body xmlns="http://rox.sourceforge.net/SOAP/ROX-Filer">
  <OpenDir>
   <Filename>/tmp</Filename>
  </OpenDir>
 </env:Body>
</env:Envelope>

Y esto se podría mandar directamente con el API de SOAP en ROX, aunque para el caso particular de ROX-Filer se nos ofrece también una interfaz simplificada. Hay varios añadidos construidos sobre esto: por ejemplo el soporte para dispositivos extraibles vía HAL. Un script se encarga de añadir/quitar del panel los iconos de los dispositivos cuando estos se conectan, comandando los paneles mediante SOAP.

Por completar, ROX-CLib también incluye funciones para soportar el Drag&Drop (XDND, XDS, decodificación de URI's, etc.) que trabajan con widgets Gtk+ y las API's más o menos previsibles: manejo de la configuración (las Choices) e interfaz de opciones "a lo ROX", diálogos de información y error, lectura de meta-datos (AppInfo.xml), MIME y programación de applets. La filosofía general es la de registrar retrollamadas (punteros a función)

3. Despedida y cierre

Esto es todo lo que tenía que he investigado sobre ROX los tres días que llevo jugando con él.

En definitiva, pienso que es un gran programa y no me explico por qué es menos popular que, digamos, Xfce cuando EMHO es bastante superior tanto desde el punto de vista de productividad como en el tecnológico. No es lo mismo de siempre (leasé lo mismo que Mac o Windows) y exige un pequeño periodo de aprendizaje pero es eficiente, práctico e incluso bonito con un tema adecuado. Es tan práctico que este friki que para hacer casi cualquier cosa con los archivos tira de consola ha descubierto que se puede vivir sin abrirla más que para cosas puntuales :-). Por cierto, ROX no incluye su propio emulador de terminal, la aplicación Terminal delega en xterm, rxvt, aterm o lo que tengamos instalado. A mí personalmente me gusta Terminal (nombre original donde los haya): es un emulador completo, con pestañas y helpers para manejar urls, y con pocas dependencias.

¿Hay otros programas que penséis que están infravalorados?, aplicaciones cuyo nivel de popularidad es bajo pero para vosotros son de las mejores de su clase.

< Internet podría fragmentarse (14 comments) | Nueva versión de Ubuntu 5.10 (3 comments) >
Enlaces Relacionados
· escomposlinux.org
· Sawfish
· AfterStep
· IceWM
· Fluxbox
· KDE
· Gnome
· Xfce
· ROX
· "Should RISC OS be open sourced?"
· RISC OS
· OSNews
· ROX tiene una pinta un tanto retro y del montón
· RPMforge.net
· ROX para Zaurus
· ROX-Filer
· ROX-Session
· OroboROX
· ROX-Clib
· Klik
· "Klik - copiar y borrar para instalar/desinstalar"
· Autopackage
· ROX-Wrap
· Zero Install
· Java Web Start
· Smeg
· GtkSourceView
· Software Index
· Desktop Utilities
· Devil's Pie
· LGames
· LGeneral
· XDS
· Artículo de ROX de la Wikipedia
· Comparación entre el diálogo selector de archivos de Gnome y el de KDE
· SOAP
· DCOP
· La interfaz SOAP de ROX-Filer
· Terminal
· More on Escritorios
· Also by jorginius

Encuesta
¿Cada aplicación en su directorio?
· Arderéis en los infiernos por copiar a Windows/Mac 14%
· Quiero una distro que instale la base y luego todo por Klik/AppDir 9%
· Hay poderosas razones para seguir la Unix-way 33%
· Lo adoro: mi distro es GoboLinux 0%
· Da igual si la Unix-way apesta desde la GUI. Con apt no hay problema 23%
· Lo que diga la rubia 19%

Votos: 21
Resultados | Otras Encuestas

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

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
ROX | 8 comentarios (8 temáticos, editoriales, 0 ocultos)
Más sobre 0install (4.00 / 1) (#3)
por jorginius ("jorginius" en Google Mail) a las Sun Oct 30th, 2005 at 01:52:52 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Está todo en los enlaces pero, por si alguien prefiere ir a tiro fijo, Thomas Leonard, padre de ROX y 0install, escribió un artículo en freshmeat describiendo la criatura (Zero Install and the Web of Software). En él se describe la versión no portable -escrita en C e integrada en el kernel de Linux- y explica las ventajas que, según él, tiene 0install sobre los instaladores tradicionales, como APT.

Por otro lado, limitarse a comparlo con un gestor de paquetes es rascar sólo la superficie. 0install es, desde el punto de vista técnico más general, un sistema de archivos remoto que usa http simple como protocolo de transporte y que emplea una agresiva política de caché para mejorar la latencia. Como sistema de archivos tiene más aplicaciones.

Hay proyectos -OC9 (una prueba de concepto, hay que "entrar" por 0install para ver algo)- que montan su sistema de archivos usando Zero Install, haciendo innecesario algo como "apt-get install" porque... ¡Todo el software está ya instalado!.

Si el usuario quiere correr gimp no tiene por qué buscarlo en los repositorios e instalarlo. Él ya vé el icono de gimp (y el binario "gimp" en /usr/bin). Simplemente pincha y arranca, con la "magia" de 0install entre bambalinas. En realidad lo que ocurre es:

  1. Al acceder al binario se produce un fallo en la caché. 0install lo descarga (mostrando un diálogo de progreso ZeroProgress) y lo ejecuta
  2. Gimp va provocando fallos de caché según va resolviendo sus bibliotecas. 0install las va descargando
  3. Gimp por fin arranca provocando algunos fallos más (los locales del usuario, plugins, etc.)
  4. El usuario ya puede trabajar incluso desconectado de la red. Aunque si quiere cambiar el idioma de sus locales o consultar la ayuda habrá fallos en la caché y 0install no podrá descargarlos si no hay conexión.


Creo que como tecnología es interesante y más cuando se basa en http puro y duro, con lo que es susceptible de atravesar cortafuegos, ser cacheado por un Squid o por Coral o de ser replicado en mirrors... Y lo mejor es que la configuración del lado del servidor es prácticamente nula.

Quizás estaría bien tener los dos dvds de Sarge disponibles de esta manera :-)



Install (none / 0) (#8)
por pouhl a las Sat Jul 15th, 2006 at 12:08:29 PM CET
(Información Usuario)

voz1 voz2 voz3 voz4 voz5 voz6 voz7 voz8 voz9 voz10 voz11 voz12 voz13 voz14 voz15 voz16 voz17 voz18 voz19 voz20 voz21 voz22 voz23 voz24 voz25 voz26 voz27 voz28 voz29 voz30 voz31 voz32 voz33 voz34 voz35 voz36 voz37 voz38 voz39 voz40 voz41 voz42 voz43 voz44 voz45 voz46 voz47 voz48 voz49 voz50 voz51 voz52 voz53 voz54 voz55 voz56 voz57 voz58 voz59 voz60 voz61 voz62 voz63 voz64 voz65 voz66 voz67 voz68 voz69 voz70 voz71 voz72 voz73 voz74 voz75 voz76 voz77 voz78 voz79 voz80 voz81

[ Padre ]


 
MC (none / 0) (#1)
por advocatux a las Sat Oct 29th, 2005 at 06:56:47 PM CET
(Información Usuario)

Pues ya que preguntas por "programas un tanto olvidados que son lo mejor de su clase" -en realidad no sé cuán olvidado está, pero bueno, merece la pena recordarlo- es el MC o GNU Midnight Commander.
--
- Por una Europa libre de Patentes de Software - EuropeSwPatentFree


A ese pobre programa Gnome lo mató (none / 0) (#2)
por jorginius ("jorginius" en Google Mail) a las Sat Oct 29th, 2005 at 10:57:18 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

"programas un tanto olvidados que son lo mejor de su clase" -en realidad no sé cuán olvidado está, pero bueno, merece la pena recordarlo- es el MC o GNU Midnight Commander.

Sí, es un Gran Programa que se merece unas líneas... Aunque al pobre me lo mataron hace unos 5 años o así, cuando a Icaza se le metió entre ceja y ceja hacer de sus tripas el gestor de archivos estándar de Gnome.

No es que haya nada de malo en tratar de componentizar una aplicación y sacar una interfaz gráfica pero se hizo de la peor forma posible:

  1. El core se reescribió para introducir nuevas dependencias derivadas de Gnome que no pintaban nada en el mc de interfaz texto.
  2. La interfaz del gmc (el gestor de archivos de Gnome hasta la versión 2.0) no pegaba ni con cola: pasamos de un gestor de archivos clásico de dos paneles a un calco del explorador de MS Windows 95.
  3. Se metieron bugs a paladas. Yo fui usuario ocasional de mc hasta la versión 4.0.x o 4.1.x y hasta que me harté de los petes y lo abandoné. Estuve un tiempo con dos versiones instaladas: una para usar en Gnome -por aquel entonces era lo que usaba- y otra para texto pero era un fastidio tener que rehacer el mc texto cada vez que actualizaba.


Así que, hasta que no lo has mencionado tú, no había vuelto a saber de él :-). He visto que la última versión es de julio de este año y que le han dado boleto a todo lo que huela a interfaz gráfico (bien por ellos) pero ahora depende de ¡Glib2! (AKA "ocupo mega y media") y su código es Enorme, con E mayúscula y más cuando es C puro y duro y versiones pre-Gnome ocupaban la cuarta parte.

Parece que mc ya nunca más será un programa que quepa en un disquete...

Claro que lo peor no es eso, lo peor es que se cargaron el mc para terminar adoptando Nautilus: que hacía lo mismo, petaba incluso más y era diez veces más lento y pesado. Cosas de éstas son las que me hacen huir de Gnome, en fins.

[ Padre ]


 
Rox no me gusta como suena (none / 0) (#4)
por SEEDHVB a las Tue Nov 1st, 2005 at 09:59:46 PM CET
(Información Usuario) http://www.vernis.com.ar

Veamos, No descarto que esto pueda ser util en algunos entornos especificos, y que estos desarrollos puedan servir para en el futuro obtener mejores cosas.

Pero, hoy por hoy, ¿Tiene sentido? En mi caso particular no.

1. Rox y 0install me obligan a estar siempre on-line, no gracias, no tengo banda ancha.

2. Si la tuviera siempre se actualizaria, o sea, no podria tomar decisiones de cuando hacer mis actualizaciones. No pudiendo testear con anticipacion las posibles incopatibilidades.

3. Tendria todo duplicado por el disco, las bibliotecas no fueron inventadas solo para facilitar la vida a los programadores, tambien ahorran espacio en disco.

Apt es fabuloso, por el momento es lo mejor para mi.

Igualmente es muy bonito el ROX, se parece mucho a GNOME

Saludos

Sergio



Que va, al contrario... (none / 0) (#5)
por jorginius ("jorginius" en Google Mail) a las Wed Nov 2nd, 2005 at 12:24:54 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

1. Rox y 0install me obligan a estar siempre on-line, no gracias, no tengo banda ancha.

Nop. En el momento que tienes la aplicación en caché no tienes por qué seguir on-line. Como si no quieres conectarte nunca más.

Por otro lado la caché tiene un formato muy sencillo (son directorios, con un hash y los archivos) así que también puede funcionar el invento sin conexión en absoluto. Puedes compartir la caché entre máquinas, meter bibliotecas o programas directamente, pasarla a un dvd y cosas así.

2. Si la tuviera siempre se actualizaria, o sea, no podria tomar decisiones de cuando hacer mis actualizaciones. No pudiendo testear con anticipacion las posibles incopatibilidades.

Tampoco es así si no quieres. La política de caché es muy conservadora y, por defecto, a menos que vuelvas a refrescar no intentará bajarse nada de la red. Vamos, que a menos que cambies la configuración sólo buscará nuevos contenidos si le das al botón. Incluso si borras la caché se volverá a bajar versiones antiguas si no refrescas.

Además, ya que lo mencionas, en la mayoría de las aplicaciones de ROX distribuidas por 0install suelen venir varias versiones. Dentro del AppDir hay un directorio 0.1, 0.2, .... 2.2, etc. más un enlace "latest", que es el que usa AppRun por defecto.

Este esquema junto con 0install te permite probar en cualquier momento la versión moderna de una aplicación sin tener que a) reemplazar media distribución por tema de dependencias o b) buscar un backport. También te ofrece la posibilidad de actualizar todo y quedarte por siempre jamás con alguna versión antigua que necesites. Siempre sin conflictos.

3. Tendria todo duplicado por el disco, las bibliotecas no fueron inventadas solo para facilitar la vida a los programadores, tambien ahorran espacio en disco.

Zero Install ahorra espacio, por lo menos en teoría. Piensa que apt se baja toda la aplicación y 0install sólo las partes que uses.

El ejemplo más evidente son las traducciones y la documentación en varios idiomas. No tiene sentido bajarte las traducciones de todos los idiomas si luego sólo vas a usar la del tuyo. Con apt no puedes discriminar pero 0install sí lo hace.

Aunque no solo sirve para eso, hay casos más interesantes. Muchos programas tienen dependencias que no son directas: plugins que están enlazados con bibliotecas raras y que no usamos, usan Perl sólo para una tontería pero arrastran la dependencia con él, etc. Con 0install no tienes que descargar todas esas dependendicas "laterales".

En Debian miran con lupa los paquetes para conseguir que sean pequeños y que tengan el mínimo de dependencias posibles. Están aplicando un montón de esfuerzo humano para resolver un problema que con 0install no existe y además por mucho que se quemen las pestañas la solución es peor, con menos granularidad.

Quizás se vean mejor las ventajas en otras distribuciones que mimen menos los paquetes. Por ejemplo el KDE de Fedora se distribuye en "paquetes gordos" (kdenetwork, kdepim, kde-i18n, etc.) que con apt hay que bajarse enteros y cada vez que hay que actualizar pasar por el mismo calvario. Con 0install sólo se descargarían y se actualizarían los programas que usásemos, y con con una precisión milimétrica:

Si sólo quieres kopete de kdenetwork te bajarás kopete. Si sólo usas el plugin de MSN entonces ese será el único plugin que tengas en caché. El resto de plugins, de kbibliotecas y de kaplicaciones (y de kioslaves, y de manuales y de...) que no uses no los tienes que cachear, no te los descargas ni te ocupan espacio en disco, y como es tráfico http normal se puede servir comprimido de la forma habitual.

Como ves es bastante respetuoso con conexiones lentas, más que apt de hecho.

Si aún no he sido capaz de convencerte, entonces echa un vistazo a lo que dice el autor del invento: The Zero Install system. Allí responde preguntas que son muy parecidas a las tuyas, con respuestas que son parecidas a las mías X-D

[ Padre ]


Gracias por las aclaraciones (none / 0) (#6)
por SEEDHVB a las Mon Nov 28th, 2005 at 03:52:16 PM CET
(Información Usuario) http://www.vernis.com.ar

Bueno, ahora suena mucho mejor.

Vere si en algun momento le puedo echar una mirada al tema.

Saludos

SEEDHVB

[ Padre ]


Si quieres ver algo más que una demo... (none / 0) (#7)
por jorginius ("jorginius" en Google Mail) a las Mon Nov 28th, 2005 at 07:11:19 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Te sugiero que eches un vistazo a Konvalo, que es la misma idea pero usando CODA y está más máduro para un uso general. Hay rama para Linux, los *BSD y Mac OS X.

El punto fuerte de Zero-Install es la sencillez: es un sistema de archivos distribuido con un único punto de montaje universal y que usa http simple (sin configuraciones especiales en en el lado del servidor) como protocolo de transporte.

Pero a veces esta sencillez pasa factura. Zero-Install, como sistema de archivos, se queda bastante corto. Por si mismo no contempla restricciones de acceso ni cifrado (aparte de las firmas digitales), ni permisos, ni usuarios (todo lo que ves pertenece al usuario 0install, es de solo lectura y no puede haber binarios suid) y además fuerza a que los volúmenes se accedan a través de directorios con la uri del proveedor como nombre ("/uri/0install/rox.sourceforge.net/", por ejemplo).

CODA, en eso, es el "hermano mayor" de 0install. Nos da lo mismo que éste, un sistema de archivos distribuido con caché, y además:

  1. Incluye seguridad de acceso a lo Kerberos
  2. Permisos de usuarios (ACL's). Por supuesto soporta escritura.
  3. Negociación del ancho de banda/prestaciones.
  4. Aparte de ser mucho más versátil, está mucho más probado. Funciona desde 1987 aunque la implementación para Linux es más moderna :-).


CODA está pensado para trabajar con clientes móviles, donde la conectividad es intermitente (vas con tu portátil y, aunque de pronto te quedes sin cobertura puedes seguir trabajando de forma más o menos transparente) y/o en sistemas tolerantes a fallos.

Todas estás prestaciones traen también algunos inconvenientes:

  • Para el administrador montar un servidor CODA no es trivial.
  • El sistema tiene que manejar problemas de coherencia (¿qué ocurre cuando dos clientes han escrito en el mismo archivo desconectados y vuelven a conectarse? o, si hay un error en un servidor, ¿cuál copia hay que replicar?) y definir claramente qué ocurre en todos los casos con o sin fallos de red.
  • El cliente tiene que poder conectarse al puerto del servidor CODA (no estar detrás de un proxy o nat, por ejemplo) y, por supuesto, correr un sistema operativo con soporte de CODA.


En fin, entre las miles de cosas que se pueden hacer con CODA :-) está la de distribuir software públicamente y eso es lo que hace Konvalo: ofrecen un volúmen que puedes montar (y usar por Internet) con un montón de programas, con un scriptillo que hace la configuración del cliente sencilla, en sólo lectura y con los permisos básicos "a lo 0install".

En mi opinión es un caso claro de sobreingeniería y la solución de 0install me parece, además de más sencilla, más elegante pero lo que está claro es que CODA es estándar y 0install no.

[ Padre ]


 
ROX | 8 comentarios (8 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
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