Luego de 6 meses de trabajo, el equipo de desarrollo de Canaima GNU/Linux se complace en publicar la primera versión alfa de Tribus (0.1~a1). Tribus es nuestra apuesta por conectar a todos los colaboradores que deseen aportar sus contribuciones en algunas de las múltiples áreas de trabajo de la Metadistribución Canaima GNU/Linux. Es también, además, un sistema que nos permitirá automatizar muchas tareas repetitivas o predecibles que forman parte del proceso productivo de las Comunidades de Software Libre. Si quieres conocer más acerca de Tribus, puedes leer un artículo anterior. Durante el desarrollo de Tribus participaron 4 desarrolladores del CNTI pertenecientes a la Oficina de Operaciones Canaima, y 2 miembros de la Comunidad Canaima, con diferentes asignaciones y actividades. Utilizamos diferentes tecnologías libres como Python/Django, AngularJS, PostgreSQL, MongoDB, Redis, OpenLDAP, HTML5/CSS3, entre otros, para poner en marcha la planificación de esta versión (0.1~a1), la cual contiene las siguientes características: Sistema de Autenticación con el directorio de usuarios de la Plataforma Colaborativa de Canaima (OpenLDAP): permite que todos los usuarios previos de la Plataforma puedan loguearse en Tribus con sus credenciales (usuario y contraseña), sin necesidad de volverse a registrar. Además, posee las mismas funcionalidades del Sistema de Registro de Canaima (reestablecer y cambiar contraseña, registro de nuevos usuarios, etc). Sistema de Mensajes Cortos (microblogging): permite publicar mensajes cortos (máximo 200 caracteres) en una cola de mensajes para cada usuario. En cada mensaje los usuarios pueden publicar comentarios cortos (máximo 200 caracteres) que luego pueden eliminar, al igual que con los mensajes cortos. Sistema de Perfiles de Usuario: cada usuario de Tribus tiene un perfil de usuario en donde se exponen algunos de sus datos personales, así como también los mensajes cortos publicados recientemente. El perfil permite “seguir” las actualizaciones de mensajes de otros usuarios, haciendo click en “Seguir a este usuario”. Sistema de Perfiles de Paquetes: muestra un perfil descriptivo (o ficha técnica) de cada uno de los paquetes que se encuentran en los repositorios de Canaima. Sistema de Búsqueda: permite buscar diversos tipos de elementos que se almacenan en Tribus, hasta ahora, usuarios y paquetes. Durante los próximos meses estaremos desarrollando la versión 0.2~a1, en donde seguiremos agregando funcionalidades que permitirán seguir mejorando el proceso productivo de la Comunidad Canaima, y por ende, de la Metadistribución Canaima GNU/Linux. Si deseas colaborar en el desarrollo de Tribus, puedes encontrar mayor información en la documentación. Sin más preámbulo, puedes acceder a Tribus en la siguiente dirección web: http://tribus.canaima.softwarelibre.gob.ve/
Hace algún tiempo, con un poco de insomnio, hice un script para ayudar al compañero Erick en la tarea de la internacionalización de Canaima. Escribo este artículo a manera de reseña y documentación de este script, el cuál posiblemente sea de utilidad para alguna otra distribución que esté comenzando sus tareas de internacionalización. La internacionalización de una distribución es diferente del concepto tradicional que aplica en el desarrollo de aplicaciones, aquí lo importante es: Permitir al usuario escoger el idioma en el cuál se va a instalar su sistema operativo, por lo que predeterminar un idioma en específico está fuera de lugar. Este procedimiento generalmente va en el instalador de la distribución. Generar el procedimiento pertinente para poder habilitar el idioma seleccionado, durante (o posterior) a la instalación del sistema operativo. La idea de este script es generar una base de datos (en forma de diccionario de python) que asocie los códigos de locales (lenguajes), con los paquetes de traducciones de una serie de aplicaciones conocidas y presentes en Canaima. Algunos se preguntarán, ¿Por qué no se utilizan los paquetes de internacionalización de Debian?, la respuesta es que están incompletos. Si bien existen los paquetes de tareas que traducen al español y otros lenguajes comunes, los cuales agrupan los paquetes de traducciones para páginas de manual, diccionarios, entre otros, existen casos en los cuales no existen paquetes de tareas para un lenguaje poco común. ¿Cómo funciona? Este script utiliza la base de datos de locales (lenguajes) soportados, el cuál se encuentra en /usr/share/i18n/SUPPORTED y es colocado allí por el paquete locales. Es utilizado para determinar la lista de los códigos de localización existentes en la forma xy-zw, como por ejemplo: es-es, en-us, en-gb, entre otros. Estos códigos son utilizados luego para ciclar a través de una serie de paquetes de localización comunes, y determinar si existen en los repositorios o no. Por ejemplo, si el paquete myspell-es-es existe, se incluye bajo el ítem 'es-es' del diccionario, y así para todos los paquetes de traducción conocidos (la lista puede ampliarse). Obtendremos algo así: { ... 'es-ve': ['manpages-es', 'myspell-es', 'aspell-es', 'cunaguaro-l10n-es-es', 'libreoffice-l10n-es', 'libreoffice-help-es'], 'et-ee': ['myspell-et', 'aspell-et', 'cunaguaro-l10n-et', 'libreoffice-l10n-et', 'libreoffice-help-et'], 'eu-es': ['hunspell-eu-es', 'aspell-eu-es', 'cunaguaro-l10n-eu', 'libreoffice-l10n-eu', 'libreoffice-help-eu'], 'eu-fr': ['cunaguaro-l10n-eu', 'libreoffice-l10n-eu', 'libreoffice-help-eu'], 'fa-ir': ['myspell-fa', 'aspell-fa', 'cunaguaro-l10n-fa', 'libreoffice-l10n-fa'], ... } Se deben aclarar varias cosas: El script debe ejecutarse como root, de la siguiente forma: bash /ruta/al/archivo.sh El script utiliza los repositorios existentes en el archivo /etc/apt/sources.list, por lo que el diccionario se calculará con la base de datos de paquetes resultante. Esto significa que si se quiere, por ejemplo, hacer una base de datos de paquetes de traducción para Debian Sid, deben introducirse sólo los repositorios de Debian Sid en el archivo /etc/apt/sources.list antes de ejecutar el script. El resultado de este script se guarda en un archivo de nombre locales.dict dentro de la misma carpeta donde se encuentre el script. Este archivo por sí mismo no hace nada, puesto que es simplemente un diccionario de python. La lógica para instalar los paquetes según el código de lenguaje utilizado, debe implementarse en una aplicación aparte. Sin más preámbulo, acá dejo el script con algunos comentarios para explicar. #!/bin/bash -e # Actualizamos la base de datos apt apt-get update SIZE=0 LIST="" # Obtenemos la lista de códigos de locales soportados por el sistema LOCALES="$( cat /usr/share/i18n/SUPPORTED | tr '[:upper:]' '[:lower:]' | sed 's/_/-/;s/[.@ ].*//' | sort -u )" # Construímos estructura de datos inicial en el arcivo 'locales.dict' echo "" > locales.dict echo "{" | tee -a locales.dict # Recorremos la lista de locales for L in ${LOCALES}; do # Determinamos el lenguaje raíz ROOTLC="${L%-*}" # Inicializamos el buffer con el primer corchete de la lista # Esta será la lista de paquetes que se imprimirá en el ítem # del diccionario BUFFER="[" # Recorremos los paquetes comunes for P in manpages hunspell myspell ispell aspell guacharo-l10n cunaguaro-l10n libreoffice-l10n libreoffice-help; do # Si existe un paquete en el repositorio que se llame "NOMBRE_PAQUETE-CÓDIGO_LENGUAJE" ... if apt-get --print-uris download "$P-$L" 1>/dev/null 2>&1; then # Lo metemos en el buffer BUFFER="${BUFFER}'$P-$L', " # Lo metemos en la lista de paquetes LIST="${LIST} $P-$L" # Obtenemos su tamaño SIZE="$( apt-cache show "$P-$L" | grep "Installed-Size: " | awk '{print $2}' )+${SIZE}" # Si no existe un paquete que coincida con el código de lenguaje, pero si existe # su lenguaje raíz ... elif apt-get --print-uris download "$P-$ROOTLC" 1>/dev/null 2>&1; then # Lo metemos en el buffer BUFFER="${BUFFER}'$P-$ROOTLC', " # Lo metemos en la lista de paquetes LIST="${LIST} $P-$ROOTLC" # Obtenemos su tamaño SIZE="$( apt-cache show "$P-$ROOTLC" | grep "Installed-Size: " | awk '{print $2}' )+${SIZE}" fi done # Imprimimos el ítem de diccionario, más el contenido del buffer # el cuál contiene la lista de paquetes de traducción y luego lo # introducimos en el archivo locales.dict echo "'$L': ${BUFFER}]," | tee -a locales.dict done # Cerramos el diccionario echo "}" | tee -a locales.dict # Esta es la lista de paquetes completa echo "La lista de paquetes a incluir en el pool de la ISO:" echo "${LIST}" | sort -u # Este es el tamaño total de todos los paquetes echo "EL tamaño sin comprimir de todos los paquetes:" echo "${SIZE}" | bc
El título de este artículo puede parecer pomposo, pero no tiene ni una pizca de amarillismo o exageración. Una jaula, desde el punto de vista de desarrollo, es un sistema embebido dentro de otro que permite establecer una comunicación entre los procesos del sistema anfitrión y el huésped, es decir, permite hacerlos interoperables. En debian, tener una jaula (o varias jaulas) permite tener otro sistema operativo encerrado en una carpeta, listo para usar, sin la necesidad de utilizar máquinas virtuales. Incluso, es posible tener un sistema huésped de arquitectura diferente al anfitrión. En teoría, cualquier sistema operativo que cumpla con los estándares POSIX y LSB (la mayoría de los GNU/Linux), y que además compartan el mismo tipo de kernel que el sistema anfitrión, puede convertirse en un sistema huésped; por ejemplo, ArchLinux y Debian, Gentoo y Debian, Canaima y Debian, CentOS y Debian, Fedora y Debian, entre otros. La única desventaja es que está pensado para propósitos de desarrollo, es decir, para uso por consola (aunque existen guías para arrancar la interfaz gráfica con Xnest). Los casos de uso para las jaulas son infinitos. Por su capacidad para aislarse del sistema anfitrión, es usado en casos de compilación y empaquetamiento, en donde se hace necesario instalar dependencias que pueden dañar o desconfigurar el sistema anfitrión (que a menudo es nuestro sistema de uso personal y cotidiano), pero al hacerse dentro de la jaula, todo posible daño queda confinado en el sistema huésped. ¿Cómo se hace una jaula? Existen varias herramientas para generar y gestionar jaulas, dependiendo del sistema operativo que utilices y el tiempo que dispongas. Las cosas pueden ser tan fáciles como un comando sencillo, o varios comandos al estilo Linux from Scratch. Para este caso utilizaremos Debian Sid como sistema Anfitrión y Canaima Kerepakupai (4.0) como huésped, y para asistirnos en la creación y operación de la jaula, usaremos debootstrap y coreutils. Los instalamos así, usando una consola de root del sistema anfitrión: aptitude install debootstrap coreutils Chroot es una aplicación que engaña al sistema anfitrión, haciéndolo creer que es el sistema huésped para la sesión de consola que se está ejecutando. Por otro lado, deboostrap es un script que automatiza la creación de la jaula, instalando todos los paquetes esenciales que necesita un sistema operativo básico para funcionar. El único detalle con debootstrap es que sólo contiene scripts para un número limitado de versiones de Debian y de Ubuntu. Nosotros resolveremos este problema haciendo un enlace simbólico desde Debian Wheezy a Canaima Kerepakupai en una consola de root, así: ln -s /usr/share/debootstrap/wheezy /usr/share/debootstrap/kerepakupai Luego ejecutamos debootstrap para crear la jaula dentro de una carpeta que escojamos, diciéndole que no revise las las llaves de las firmas del repositorio (--no-check-gpg) y que la arquitectura de la jaula será i386 (--arch="i386"): mkdir /media/jaulas/kerepakupai-i386 debootstrap --arch="i386" --no-check-gpg kerepakupai /media/jaulas/kerepakupai-i386 http://paquetes.canaima.softwarelibre.gob.ve/ Terminado este paso, la jaula está lista, pero todavía debemos hacer otras operaciones antes de empezarla a utilizar. El sistema huésped utilizará el espacio de kernel del sistema anfitrión para obtener las funcionalidades básicas del sistema operativo, sin embargo, para gestionar los dispositivos del sistema (entre otras cosas), necesita tener disponibles algunas otras cosas dentro de la jaula. Para ello hacemos: mount -o bind /proc /media/jaulas/kerepakupai-i386/proc mount -o bind /sys /media/jaulas/kerepakupai-i386/sys mount -o bind /dev /media/jaulas/kerepakupai-i386/dev mount -o bind /dev/pts /media/jaulas/kerepakupai-i386/dev/pts Estos montajes son del tipo “bind” (enlaces), permitiendo que el comportamiento de /dev, /dev/pts, /proc y /sys del sistema anfitrión se replique en el sistema huésped. Además son montajes temporales: si reinicias la computadora, los montajes se perderán y tendrás que volverlos a hacer. Si quieres montajes permanentes deberás editar el archivo /etc/fstab. Ahora estamos listos para ingresar en la jaula con el comando: chroot /media/jaulas/kerepakupai-i386 Al estar dentro, el sistema anfitrión ya no existe, estamos dentro de la jaula y podemos hacer desastres.
El sistema de paquetes de Debian es uno de los gestores de instalación y desinstalación de software más avanzados en el mundo de las distribuciones GNU/Linux. No podría ser de otra manera, ya que Debian también es una de las distribuciones que más paquetes posee en sus repositorios (mas de 32.000 para la versión 7.0). Si tienes Debian, Canaima o Ubuntu, ¿Alguna vez haz tenido la oportunidad de listar todos los paquetes que tienes instalados? Normalmente daría dolor de cabeza tratar de buscar un paquete en una lista de entre 1000 y 2000 nombres (la cantidad promedio de paquetes instalados en un sistema operativo de escritorio). Es por ello que existen diversos filtros de búsqueda para manejadores de la base de datos de paquetes como aptitude (aunque, estos filtros son implementados de forma nativa por aplicaciones gráficas como Synaptic y Software Center). Normalmente buscamos en la base de datos con aptitude search [paquete], sin embargo, existen formas de ser más específicos con los términos de búsqueda. Por ejemplo, supongamos que queremos buscar todos los paquetes que comiencen con la palabra google. En ese caso, haríamos aptitude search google y tendríamos un resultado así: Como observamos, existen algunos resultados que no necesariamente coinciden con lo que queríamos buscar, puesto que también existen paquetes que contienen la palabra google en el medio de la palabra, por ejemplo. Veamos que sucede su utilizamos el patrón de búsqueda por nombre de paquete ~n y agregamos la expresión regular ^ al principio de google, indicando que queremos listar todos los paquetes que comiencen por google, de la siguiente forma: aptitude search ~n^google. Como vemos, el resultado es más corto y preciso que el anterior. Existen muchos patrones de búsqueda que son útiles en nuestra búsqueda de paquetes; por ejemplo, búsqueda por descripción, por versión, por mantenedor, por repositorio, entre otros. Más abajo tenemos una tabla con todos los patrones disponibles: Forma corta Descripción ~F Selecciona ningún paquete. ~T Selecciona todos los paquetes. [PATRÓN1] [PATRÓN2] Seleccionar cualquier paquete que coincida con el [PATRÓN1] y el [PATRÓN2]. [PATRÓN1] | [PATRÓN2] Selecciona paquetes que coincidan con el [PATRÓN1], el [PATRÓN2] o ambos. ![PATRÓN] Seleccionar cualquier paquete que no coincida con el [PATRÓN]. ~n[PATRÓN] Selecciona paquetes cuyo nombre coincida con [PATRÓN]. ~m[PATRÓN] Selecciona paquetes cuyo mantenedor coincida con [PATRÓN]. ~d[PATRÓN] Selecciona paquetes que contengan [PATRÓN] en su descripción. ~V[PATRÓN] Selecciona paquetes cuya versión coincida con [PATRÓN]. ~E Selecciona paquetes esenciales (aquellos que contienen Essential: yes en sus archivos debian/control). ~O[PATRÓN] Selecciona paquetes desde el origen que coincida con [PATRÓN]. ~P[PATRÓN] Selecciona paquetes que proveean otro paquete que coincida con [PATRÓN]. ~p[PATRÓN] Selecciona paquetes que tengan una prioridad que coincida con [PATRÓN]. ~s[PATRÓN] Selecciona paquetes que pertenezcan a una sección que coincida con [PATRÓN]. ~G[PATRÓN] Selecciona paquetes que contengan un DebTag que coincida con [PATRÓN]. ~t[PATRÓN] Selecciona paquetes que estén en una tarea que coincida con [PATRÓN]. ~M Seleccionar paquetes que estén marcados como instalados automáticamente. ~a[PATRÓN] Seleccionar los paquetes que se encuentren marcados para una acción de aptitude (p. ej.: “install”, “upgrade”) que coincida con [PATRÓN]. ~A[PATRÓN] Seleccionar paquetes desde un rama de un repositorio en específico que se encuentre en el archivo /etc/apt/sources.list (p. ej.: sid) y que coincida con [PATRÓN]. ~b Seleccionar paquetes que tengan al menos una dependencia rota. ~C[PATRÓN] Seleccionar paquetes que entran en conflicto con los paquetes que coincidan con [PATRÓN]. ~c Seleccionar los paquetes que fueron removidos pero no purgados y aún tienen archivos de configuración en el sistema. ~g Selecciona paquetes que no son requeridos por algún paquete instalado manualmente.. ~D[TIPO]:[PATRÓN] Seleccionar paquetes que contengan un [TIPO] de dependencia sobre paquetes que coincidan con [PATRÓN]. ~i Selecciona paquetes que se encuentren instalados. ~N Selecciona paquetes nuevos que hayan sido incorporados al repositorio desde la última vez que se hizo aptitude update. ~o Selecciona paquetes obsoletos, es decir, que después del último aptitude update hayan sido removidos del repositorio (probablemente reemplazados por otros paquetes). ~U Selecciona paquetes instalados que puedan ser actualizados luego de un aptitude update. ~v Selecciona paquetes virtuales. Ejemplos prácticos Todos mis paquetes (en Canaima): aptitude search ~mFaneyth Todos los paquetes de Erick Birbe, Sasha Solano, Carlos Espinoza y Francisco Vásquez que estén instalados (en Canaima): aptitude search ~i~merickcion ~i~mssolano ~i~marmikhael ~i~mfranjvasquezg Todos los paquetes que dependen de Blender: aptitude search ~DDepends:Blender Todos los paquetes que provean al paquete virtual “mail” y que estén instalados aptitude search ~i~DProvides:mail o lo que es lo mismo: aptitude search ~i~Pmail Todos los paquetes que estorban de tu sistema: aptitude search ~c ~g Todos los paquetes que tengan “RC” (Release Candidate) en su número de versión y que estén instalados aptitude search ~i~VRC ¿Cuántos paquetes tengo instalados? aptitude search ~i | wc -l Todos los paquetes de desarrollo para python que estén instalados: aptitude search ~i~n^python.*dev$ Y así, espero que puedas encontrar lo que estás buscando. ¡Hasta una próxima!
¿Te preguntabas cómo hacer un chroot de Canaima 4.0? Aquí está en cuatro pasos: Instala coreutils y debootstrap: aptitude install coreutils debootstrap Enlaza el script de Debian Wheezy a Canaima Kerepakupai: ln -s /usr/share/debootstrap/wheezy /usr/share/debootstrap/kerepakupai Ejecuta debootstrap así (--no-check-gpg porque no tenemos las llaves del repositorio): debootstrap --no-check-gpg kerepakupai /ruta/a/la/carpeta/ http://paquetes.canaima.softwarelibre.gob.ve/ Entra a la jaula: chroot /ruta/a/la/carpeta/ ¡Listo!, ya tienes un Canaima 4.0 básico para empezar a hackear. Enjoy. Gracias a Flamel Canto por el Beta testing :-D
El día sábado estuvimos compartiendo con la Comunidad Debian en el evento denominado “Día Debian”, en donde se celebraron 20 años del nacimiento de esta genial distribución. Para este evento llevamos una presentación acerca de Tribus, destinada a introducir el proyecto a la comunidad. Por acá les dejamos la presentación que utilizamos.
Un poco de historia El Proyecto Canaima nació a finales del año 2007, en la forma de un sistema operativo destinado a satisfacer una necesidad concreta: el cumplimiento de la migración a Software Libre establecida en el Decreto Presidencial 3390. Durante esas épocas, era común escuchar a Carlos Figueira, Jhon Monrroy y Ernesto Hernández-Novich hablar sobre conceptos de remasterización, Debian y distribuciones derivadas en las oficinas del Centro Nacional de Tecnologías de Información (CNTI). La primera versión de Canaima (1.0) fue una remasterización de Debian que sirvió para migrar las oficinas internas del CNTI y comenzar el plan piloto de migración. La segunda versión de Canaima (2008), estuvo determinada a abrir las puertas para el desarrollo comunitario en Canaima. José Parella, Nehomar Barragán, Carlos Marrero, entre otros, lograron poner las bases fundacionales a través de un esquema de construcción de paquetes y una plataforma de servicios capaz de articular el flujo de desarrollo, gestionar la comunicación a través de listas de correo, impulsar la documentación a través de una enciclopedia colaborativa, entre otras funcionalidades. Sin embargo, la historia demostraría que sería necesario un estudio más profundo de las interacciones comunitarias. 6ta Cayapa Canaima. Imagen de David Hernández (by-nc-sa). El enfoque de la tercera versión de Canaima (2011), estuvo centralizado en impulsar las herramientas de colaboración desde el ámbito del usuario. La creación de herramientas como Canaima Semilla, para facilitar la creación de distribuciones derivadas y aclarar el proceso de construcción de imágenes; y Canaima Desarrollador, para facilitar la creación de paquetes, estuvieron enfocadas en esa dirección. Mini Cayapa de Sabores Canaima. Imagen de David Hernández (by-nc-sa). Durante el año 2011, 2012 y lo que ha transcurrido del 2013, la dinámica comunitaria ha venido gestando espacios de construcción y organización de los procesos internos de la Metadistribución Canaima. A través de Cayapas y Mini Cayapas, se han planteado diferentes procedimientos y estructuras para optimizar la participación comunitaria en Canaima. Es preciso destacar las siguientes ideas: Máquina de empaquetamiento de software automático a través de Buildbot: Jesús Lara. Herramienta de valoración de colaboración (Colab): Orlando Fiol, Leonardo Caballero, entre otros. Sabor de Canaima basado en Debian Testing, como Rolling Release (Canaima Comunitario): Ernesto Crespo, Franklin Mendoza, entre otros. Flujo de desarrollo entre Canaima Popular y Canaima Comunitario: Mesa de Plataforma en la 6ta Cayapa. Esquema de desarrolladores, aprendices y mentores “Chamanes”: Héctor Colina, Joaquín Muñoz, entre otros. Estructura organizacional de los “Caimancitos”: Canaima Universitario. Esquema de Chamanes, por Héctor Colina/Joaquín Muñoz. Imagen de David Hernández (by-nc-sa). Basándose en éstas ideas, el equipo de desarrollo de Canaima en CNTI ha decidido componer una aplicación integral que conjugue todos estos elementos para que finalmente se materialice una plataforma que realmente permita potenciar la participación comunitaria. ¿Qué es Tribus? Tribus es una aplicación que está siendo escrita principalmente en Django, un conocido framework web escrito en python. Elegimos django debido a la existencia de gran cantidad de código reutilizable que facilitará el proceso de desarrollo. Además, python es cool. Primero que todo debe advertirse que es una plataforma ambiciosa y su tiempo de desarrollo será prolongado, así que probablemente su implementación se haga por fases. Además su estado de desarrollo es prematuro, y los diagramas de la aplicación no están completos aún. Dicho esto, la intención con Tribus es que sea un desarrollo comunitario que permita realizar un ensayo de la dinámica que vendrá luego de que la aplicación esté en línea. ¿Cómo se hace para participar? Estaremos trabajando en GitHub. GitHub permite hacer seguimiento de los aportes de los participantes a través de tickets, llevar la documentación interna a través de una wiki y gestionar fácilmente las copias internas del equipo a través de forks y pull requests. También estaremos usando Read the docs para mantener una copia actualizada de la documentación y un foro en Google Groups para comunicación entre desarrolladores. Si deseas iniciarte en el desarrollo de Tribus, te recomendamos las siguientes lecturas: Protocolo para la incorporación de contribuciones Herramientas de mantenimiento y desarrollo Normas de estilo para contribuciones Documentación conceptual Hojas de ruta Podemos resumir el flujo de trabajo de la siguiente manera: Luego de que hayas curioseado lo suficiente (clonando el código, revisándolo, reproduciendo el ambiente de desarrollo), puedes mirar aquí para que veas cuales son las tareas pendientes. Cada tarea pendiente (debería) tener asignado un ticket y un Documento de Especificaciones. El ticket nos permite llevar un registro de quién está haciendo que cosa, mientras que el Documento de Especificaciones nos explica en qué consiste esta funcionalidad. Si falta la asignación de ticket o el Documento de Especificaciones, ten un poco de paciencia, los desarrolladores de Tribus lo completarán pronto. Si lo deseas recuérdanos en el foro que estos elementos no se encuentras asignados a la tarea que quieres realizar. Si todo está en orden, haz un comentario en el ticket manifestando tu deseo de llevar a cabo la tarea que se describe, también comenta cualquier duda, sugerencia o indicación que tengas. En poco tiempo, un desarrollador de tribus te asistirá. Realiza todas las modificaciones de tu aporte en una rama de git por separado, como se indica en el protocolo de contribuciones. Cuando hayas terminado de trabajar en el ticket, realiza un pull-request como se indica aquí. Opcionalmente puedes cerrar el ticket con el pull-request. ¿Y qué vamos a hacer? Puedes echar un ojo a los diagramas de la aplicación. Y tu, ¿nos echas una mano?
Mucho se ha hablado en las comunidades de software libre acerca de los cambios drásticos que tuvo el ambiente de escritorio Gnome a partir de su versión 3.0. Impulsados por la aparición de los dispositivos táctiles y portables, los desarrolladores de Gnome hicieron un escritorio para tablets. Tomando en cuenta que hoy en día la venta de tablets ha superado la venta de laptops y computadores de escritorio, es posible que al final, hayan tomado la decisión correcta. A muchos usuarios les afectó el cambio y empezaron a mirar hacia otros lados. Incluso, algunos de los desarrolladores de Gnome estuvieron en desacuerdo con los nuevos paradigmas. Por ejemplo, destacan las las pataletas públicas de Miguel de Icaza (ex desarrollador Gnome). En una jugada que yo calificaría como oportunista, la distribución Linux Mint derivó el gestor de ventanas de Gnome (Gnome Shell) para hacer otro al que llamaron “Cinnamon”. Básicamente, le devolvieron el antiguo esquema de menúes y ventanas que tenía la versión 2.0 de Gnome, preservando algunos efectos especiales. Lo cierto es que las derivaciones en el software libre no son bien vistas. Cinnamon es, aunque muy vistoso, una pieza de software que no le llega ni a los talones a Gnome Shell. Cosas muy útiles como la accesibilidad, las extensiones, y el código en general, simplemente están rotas en Cinnamon. Es por ello que, en Canaima decidimos aventurarnos en tratar de combinar la robustez de Gnome con la funcionalidad y vistosidad de Cinammon, para crear algo a lo que llamamos Gnamon. Gnamon es un compendio de temas para GTK2/GTK3, Shell, Metacity, íconos y cursores, con un conjunto de extensiones cuidadosamente seleccionadas. Gnamon está desarrollado para Gnome Shell 3.4, así que si utilizas Debian Wheezy podrás instalarlo. También es el tema que viene por defecto en Canaima 4.0. Gnamon está compuesto de 4 paquetes: gnome-shell-extensions-gnamon: Contiene un conjunto de extensiones descargadas desde extensions.gnome.org. Accede al Código Fuente. gnome-icon-theme-gnamon: Contiene un tema de íconos basado en el tema Faience, completando los íconos faltantes con Faenza. Además contiene los cursores verdes tradicionales de Canaima. Accede al Código Fuente. gnome-themes-gnamon: Contiene un tema GTK2/GTK3, Metacity y de Gnome Shell. Accede al Código Fuente. fonts-jara: Contiene las fuentes de la familia Jara para la interfaz gráfica. Accede al Código Fuente. Para instalarlos, agrega la siguiente línea en tu archivo /etc/apt/sources.list con tu editor de texto favorito: deb http://paquetes.canaima.softwarelibre.gob.ve/ kerepakupai main aportes no-libres Es recomendable que comentes las demás líneas de repositorios que tengas colocando un # al principio de la línea. Luego, actualiza los repositorios e instala los componentes de Gnamon con los siguientes comandos en una Terminal de Root (Menú > Accesorios > Terminal de Root): aptitude update aptitude install gnome-shell-extensions-gnamon gnome-icon-theme-gnamon gnome-themes-gnamon fonts-jara Luego de terminada la instalación, deberás abrir el gnome-tweak-tool (Menú > Preferencias > Configuración avanzada) en la pestaña “Tema” y seleccionar todos los temas que se llamen “Gnamon”. Además, debes habilitar las siguientes extensiones en la pestaña “Extensiones de GNOME SHell”: AXE Menu. Message Notifier. Remove Username. Status area horizontal spacing. Coverflow ALT-TAB. Move Clock. Dash to Dock. Nothing to do. Show Desktop. Window List. Old Network Manager. Shut Down Menu. Windows Overlay Icons. Extend left box. Acá más abajo mostramos un video de la experiencia de usuario que además muestra otros elementos de Canaima 4.0. ¡Disfruten! Ver en youtube en Alta Definición El video fué mezclado enteramente en Software Libre. Usamos xvidcap para capturar la pantalla del computador y pitivi para editar sonido+video. La canción de fondo es “Ingenue” de Atoms for Peace.
AVISO: Este juego no debe ser instalado ni usado por niños y niñas sin la adecuada supervisión de sus padres o representantes. Luego del lanzamiento del primer alfa de Canaima 4.0, iremos mostrando paulatinamente algunas de las nuevas aplicaciones que se incluyen en ella. En esta oportunidad, mostramos 0AD: un juego de estrategia de alto perfil que no tiene nada que envidiarle a otros juegos de estrategia comerciales, privativos, hechos para el sistema operativo de Microsoft. El juego es muy parecido a los juegos de estrategia clásicos ambientados en diferentes épocas de la historia y las diferentes cicilizaciones emergentes. Lo resaltante de 0AD es la variedad de civilizaciones y las características de cada una. En 0AD podemos encontrar Cartaginenses, Celtas, Romanos, Helenos, Iberios, y Persas, además de los diferentes pueblos y corrientes de cada una de las facciones. Además, los detalles en 0AD son muy abundantes, los gráficos no podrían ser mejores y la eficiencia en los recursos y espacio es fenomenal. Lo más importante es que es Software Libre y está disponible para su instalación directa en Canaima 4.0 y Debian 7.0. Abre una terminal de root (como se muestra en la figura de abajo) y teclea el siguiente comando: aptitude install 0ad Esto comenzará a descargar 0AD, el cual pesa unos 350MB. Luego de la instalación, podrás encontrarlo en Menú > Juegos > 0 A.D. Puedes ver un video del gameplay más abajo, pero la idea es que lo compruebes tu mismo y nos cuentes en los comentarios que tal te pareció. Ver en youtube en Alta Definición El video fué mezclado enteramente en Software Libre. Usamos xvidcap para capturar la pantalla del computador y pitivi para editar sonido+video. La canción de fondo es “Dropped” de Atoms for Peace.
El día de hoy, con alegría y entusiasmo, el equipo de desarrollo de Canaima anuncia el lanzamiento de la primera versión en desarrollo (alfa1) de Canaima 4.0, bajo el nombre código “kerepakupai”, en honor al Kerepakupai Vená, nombre originario (Pemón) de la caída de agua más alta del mundo, ubicada en el Parque Nacional Canaima, en Venezuela. Luego de transcurrido el primer trimestre del ciclo de desarrollo, y con un avance del 30% de los objetivos planteados inicialmente, el equipo de desarrollo se prepara para continuar con las tareas necesarias para seguir promoviendo y apoyando el desarrollo y la independencia tecnológica de nuestra Patria. Canaima 4.0 es una versión que promete revolucionar el escritorio del usuario tal como lo conocemos. El cambio de paradigma de los dispositivos computacionales hacia formatos cada vez más pequeños y portables, además de la masificación de tecnologías táctiles, de reconocimiento de voz y la necesidad de que los sistemas operativos lleguen cada vez a más personas de diversas edades y culturas, hacen necesario un estudio profundo en los conceptos de interacción humano-computador, usabilidad y funcionalidad. Es precisamente por eso que esta versión mayor de la Metadistribución pone el acento en el usuario y sus necesidades. Se han planificado laboratorios de usabilidad móviles, como por ejemplo, el realizado en la Universidad Marítima del Caribe (Catia La Mar, Edo. Vargas) el 25 de abril. Allí se recolectaron las opiniones e impresiones de los usuarios acerca del uso y exploración de diversos ambientes de escritorio. Los resultados están siendo tabulados y analizados cuidadosamente para retroalimentar las siguientes fases del proceso de desarrollo. Canaima 4.0 (alfa1) se hace público al usuario luego del lanzamiento estable de la versión 7.0 de su Metadistribución madre Debian, el pasado 4 de Mayo. El equipo de desarrollo de Canaima ha seleccionado e incorporado un importante grupo de aplicaciones y componentes para poder brindar una mejor experiencia de usuario y funcionalidades novedosas. Entre ellas podemos mencionar: Escritorio Gnome 3.4. Kernel Linux 3.2.0. Servidor de ventanas X.org 7.7. Suite Ofimática LibreOffice 4.0.1. Navegador Web Cunaguaro 22.0 (basado en Iceweasel). Cliente de Correo Guácharo 17.0.5 (basado en Icedove). Programa de manipulación de imágenes GIMP 2.8. Editor de gráficos vectoriales Inkscape 0.48. Lenguaje Python 2.7/3.2. Lenguaje Perl 5.14. Es importante destacar que esta versión todavía está en desarrollo, lo que significa que no es apta para ambientes de producción ni para el uso cotidiano de usuarios principiantes. Este lanzamiento está dirigido a desarrolladores, usuarios expertos y entusiastas que deseen colaborar con el desarrollo de Canaima o deseen probar las nuevas funcionalidades “recién salidas del horno”. Si deseas probar la nueva versión, es necesario que descargues un archivo de imagen ISO desde la página web de Canaima. Las imágenes ISO contienen el sistema operativo con modo “en vivo”, esto quiere decir que podrás probarlo antes de instalarlo. Por otro lado, las imágenes están disponibles para descargar según dos arquitecturas de computador: soporte 64 bits (amd64) y soporte 32 bits (i386). Si no estás seguro de cuál corresponde a tu computador, escoge la que soporta 32 bits. Enlace de descarga a imagen ISO con soporte a 32 bits (820MB). Enlace de descarga a imagen ISO con soporte a 64 bits (818MB). Luego de completada la descarga, necesitarás grabar la imagen en un medio físico como un Pen Drive USB (con capacidad de 1GB o más) o un DVD (la imagen no cabe en un CD). Una vez grabada la imagen, se coloca el DVD en la bandeja o el Pendrive en el puerto USB y se reinicia el computador para comenzar la instalación. El sistema operativo arrancará desde el DVD o Pendrive automáticamente. Si esto no ocurre así, es necesario configurar el BIOS para que el primer dispositivo de arranque sea el DVD o el Pendrive. Finalmente, espera a que cargue el escritorio para que el instalador aparezca y sigue las instrucciones en pantalla. Debemos aclarar que por ser esta una versión todavía en desarrollo, no existe aún un método para hacer una actualización desde la versión 3.0/3.1 a la versión 4.0~a1. Conforme siga avanzando el ciclo de desarrollo, haremos público los pasos para realizar la actualización. Te invitamos a que pruebes la nueva versión y nos cuentes que te pareció a través de nuestra lista de correo desarrolladores@canaima.softwarelibre.gob.ve, nuestra cuenta en twitter @CanaimaGNULinux, o si tienes un reporte de error, puedes hacerlo a través de nuestro sistema de tickets.