sábado, 20 de marzo de 2010

Presentación de netjack2

###################################
Notas de revisiones:
Revisión 0: 21 marzo 2010. Publicado.
###################################

Experimentos con netjack2

El otro día hicimos un intento de compartir audio y MIDI en tiempo real a través de una red local cableada, con un ordenador maestro (con su tarjeta de audio conectada a los altavoces) y varios esclavos. Las pruebas iban a ser:

1. En cada ordenador esclavo se reproduce una canción. Estas no suenan en el esclavo; se envían al maestro que decide cuál poner o las mezcla a su antojo.

2. En cada ordenador esclavo hay un sintetizador software. El maestro reproduce una canción en un secuenciador MIDI, con varias pistas. Cada pista MIDI se se envía a un esclavo diferente, que "traduce" el MIDI a audio con su propio sinte y envía el audio de vuelta al maestro.

3. Los esclavos envían mensajes MIDI al maestro a traves del teclado. El maestro traduce el MIDI a Audio con un sampler o un sintetizador software.

Yo no esperaba más de tres ordenadores con el software necesario instalado pero al final fueron 6 en total... No hubo tiempo de montar y probar bien la red y ésta resultó poco robusta. El experimento 2 no dio resultado :(

Lo que sí conseguimos fue reproducir canciones desde dos ordenadores esclavos a través de la tarjeta de audio del ordenador maestro. El que maneja el mezclador del maestro decide qué canción suena. Debe ser muy fustrante poner una canción en un reproductor y que no suene... ¡Sólo si le gusta al otro!

También salió bien el experimento 3. Usamos vmpk para enviar notas MIDI desde los teclados hasta hydrogen, que hacía de sampler, con un drumkit hecho a medida para la ocasión (un kit al que añadí un silbato y otros ruidos raros). Vamos, una batukada digital con tres "músicos" aporreando los teclados del ordenador. Para pasar el rato.

Las CCCP (Charlas con Café, Copa y Puro) son reuniones de sobremesa donde intentamos arreglar el mundo gracias al software libre y al hardware barato. En serio, hacemos charlas y presentaciones. Era mi primera presentación. A ver qué os parece.

Cómo instalar software (programas) en (ubuntu) GNU/Linux. I. Introducción

###################################
Notas de revisiones:
Revisión 0: 20 marzo 2010. Publicado.
###################################

Comienzo una serie de tres partes en la que explico cómo se instala software en Linux, dirigido sobretodo a recién llegados desde Windows. Está orientado a ubuntu, pero los fundamentos son los mismos para cualquier otra distribución moderna de "Escritorio". Este es un tema muy documentado pero me apetecía explicar algunas cosas que he ido aprendiendo y desaprendiendo con el tiempo.

Normalmente, la documentación oficial de las distribuciones se dirige a los nuevos usuarios como si fueran completamente nuevos a la informática. No tiene en cuenta que la mayoría llevan años usando Windows y tienen algunas ideas preconcebidas que en GNU/Linux no son válidas. La documentación se esfuerza sobretodo en enseñar, no tanto en desenseñar.

Preguntas frecuentes:

¿Es instalar software en Linux (="una distribución de GNU/Linux") más fácil o más difícil que en Windows?

Depende. Al fin y al cabo, en Windows también se puede compilar, no? :P

Si tomamos como referencia el conocido: "bajar-un-programa-desde-una-página-de-confianza-doble-click-setup.exe-aceptar-licencia-next-next-next" o, el un poquito más complicado y triste pero cierto: "bajarlo-desde-cualquier-lugar-incluido-crack-pasar-antivirus-etc"... se puede decir que instalar software en Linux puede ser desde mucho más fácil hasta mucho más difícil que esto.

Básicamente, existen dos formas de instalar un programa:

1. Por medio de un instalador ejecutable

2. Compilando el código fuente antes de instalar

La primera forma es como el clásico "setup.exe" de Windows: Un instalador binario. Sin embargo, una distribución moderna lo pone mucho más fácil que Windows, como veremos en el siguiente capítulo.

La segunda es un poco más complicada. Lo veremos en el tercer capítulo. Normalmente no es difícil pero suele llevar un rato. Es cuestión de cogerle el truco. Pero no os asustéis, cada vez es menos necesario y/o más fácil, pues al aumentar el número de usuarios aumenta el número de empaquetadores-distribuidores, informadores de fallos, "pedigüeños" (quiero este programa en ubuntu por favor!!!), profesores y ayudantes, traductores, incluso programadores aficionados (este programa está bien pero hay que mejorarlo, me apunto, toma parche!)... En general, esto redunda en beneficio del usuario final que cada vez está más cerca de las versiones "recién horneadas", al tiempo que éstas son cada vez mejores.

¿Entonces, cuál es la mejor forma de instalar?

Depende...Aquí debemos mantener un equilibrio y pensar un poco antes de actuar sobre qué es lo mejor en cada caso. Yo diría que hay 4 factores, la seguridad de que el programa será estable en nuestro sistema [1], la facilidad de instalación, la funcionalidad que esperamos y la paciencia que tengamos. Resumiendo y en primera aproximación:

- Lo más seguro y muy fácil, perdiendo quizás alguna funcionalidad de un programa concreto, pero esperando que mejorará con el tiempo --> Repos oficiales.

- Menos seguro y bastante fácil, en busca de versiones más recientes o de un programa que no está en los repos oficiales--> Repos no oficiales o paquetes sueltos desde internet (a ser posible desde la página oficial de los proyectos, si se facilitan).

- Muy seguro y no fácil, cuando queremos estar a la última con un programa concreto que nos interesa especialmente --> Compilar la última versión estable de un programa, después de descargar el código fuente desde su sitio oficial.

- Menos seguro y no fácil, cuando queremos tener la versión de desarrollo, para evaluarla y/o colaborar con el proyecto --> Compilar las versiones diarias cuyo código fuente bajamos desde el sistema de control de versiones que utilice el proyecto.

Los dos primeros métodos los vemos en la segunda parte.

¿Dónde se instalan los programas?. Pues no existe un directorio llamado "Archivos de programa" ni nada que se le parezca.

Los programas se instalan... cada archivo en su lugar. El ejecutable en el directorio de ejecutables, las bibliotecas en el directorio de las bibliotecas, las configuraciones generales en su directorio, las configuraciones de usuario, en su sitio, los iconos en su sitio, la documentación en su lugar, etc. Pues sí, un programa bien diseñado repartirá archivos por todo el sistema.

¿Por qué no tengo permisos para hacer lo que yo quiera en mi propio ordenador?

Los sistemas derivados de UNIX, como GNU/Linux, están diseñados desde su base para ser multiusuario. Hay un administrador y tantos usuarios como éste determine. En un ordenador personal, de usuario único, hay un administrador y un usuario. Los programas los debemos lanzar "como usuario". La gestión de nuestros archivos la debemos hacer también como usuario. Lo que no podemos hacer como usuario es, por ejemplo, instalar un archivo ejecutable en el sistema operativo. Eso sólo lo puede hacer el administrador. Si el ordenador es tuyo, el administrador eres tú, pero no "tú usuario", sino "tú administrador". Algunos nuevos usuarios piensan que esto es un engorro porque implica introducir una contraseña cada vez que queremos instalar algo. A mí me parece mucho más engorroso formatear, eliminar virus con sospechosos antivirus de código cerrado, etc, sólo porque a un "sistema operativo" le da por ejecutar un programa que hace cosas malas sin que el dueño del ordenador lo haya instalado intencionadamente.

¿A quién me puedo quejar si instalo un programa que no funciona?

Si es software bajo la GPL, no hay garantía. El software se ofrece tal y como es. Tienes derecho a estudiar su código, a modificarlo, a redistribuirlo, a usarlo en tantos ordenadores como quieras... pero no hay garantía. No puedes denunciar a nadie porque no funcione. El software libre está basado en la confianza de que las cosas se han hecho lo mejor posible, y todo el mundo está invitado a participar en su mejora y su desarrollo.

Y ahora, al grano


[1] Descarto el malware. Cuando hablo de seguridad, me refiero a fallos no intencionados, sean del programador, del empaquetador-distribuidor, o del propio usuario que ha tomado decisiones sin saber bien lo que hacía.

viernes, 12 de marzo de 2010

Cómo instalar software (programas) en (ubuntu) GNU/Linux. III. Compilar

###################################
Notas de revisiones:
Revisión 0: 20 marzo 2010. Publicado.
###################################


Compilar es traducir desde el lenguaje de programación que saben escribir y leer (algunos) humanos al lenguaje binario que entienden los ordenadores.

El usuario no programador tiene que entender que cada programa es "de su padre y de su madre" y a la hora de compilarlo no hay una regla básica universal. Bueno, en realidad hay una: Lee el README (y el INSTALL).

En ubuntu hay un paquete llamado "build-essential" que incluye el compilador de C, y otros paquetes "esenciales para compilar". Es lo primero que debemos instalar.

Como regla general, si B es una dependencia de A instalar el programa A precompilado obligará a instalar la librería B, que como vimos, también esta "empaquetada". De esto no tenemos que preocuparnos pues apt (apt-get, aptitude, synaptic, centro de software...) lo hace automágicamente. Ahora bien, compilar el programa A nos obliga a instalar el "paquete de desarrollo" de la librería B, que podremos identificar porque acaba en "-dev". Puede que se llame libB-dev.

Un truco para resolver las dependencias de desarrollo necesarias para compilar es usar "apt-get build-dep". Por ejemplo, tenemos ardour 2.8.2 en los repos de karmic y queremos compilar una versión posterior de ardour2. Es muy probable que esta nueva versión tenga las mismas dependencias que la existente en los repos de ubuntu. Entonces:


$ sudo apt-get build-dep ardour

Nos instalará todas las dependencias de desarrollo. Si la nueva versión hace uso de una librería nueva, habrá que instalarla aparte pues "apt-get build-dep" no es adivino.

La forma más clásica de compilar e instalar es el típico:

./configure
make
sudo make install

Sin embargo, es un error pensar que esta es la única manera de hacerlo. Ni mucho menos. Por ejemplo, hydrogen usa scons.

scons
sudo scons install

y siempre vendrá bien un:

scons --help

para ver las opciones de compilación.

Últimamente parece que waf está de moda entre los desarrolladores de linux audio.

./waf configure
./waf build (o simplemente, ./waf)
sudo ./waf install

Y por supuesto, podemos dar opciones en los scripts de configure, para que los programas se instalen en directorios alternativos, se habilite o deshabilite alguna función, o alguna particularidad...

Como ya he dicho antes, compilar no suele ser estrictamente necesario. Cuando lo es, lo mejor para el usuario principiante que no está especialmente interesado en las tripas del sistema operativo es seguir una guía particular para ese programa.

domingo, 7 de marzo de 2010

Cómo instalar software (programas) en (ubuntu) GNU/Linux. II. Instalador ejecutable

###################################
Notas de revisiones:
Revisión 0: 20 marzo 2010. Publicado.
Revisión 1: 9 abril 2010. Añadido enlace a guía ubuntu
###################################

Si no has leido la introducción, ahora es el momento.

CONTENIDOS
""""""""""""

1. Instalar software desde repositorios

El "gestor de paquetes"
Conoce tus repos
Dependencias
Metapaquetes
Añadiendo repositorios
Clavar y forzar versiones

2. Instalar "paquetes sueltos"

______________________________________________________________


Hay guías, documentación oficial de las diferentes distribuciones, blogs... que podréis encontrar fácilmente usando vuestro buscador favorito.

Recomiendo esta magnífica guía

Otro buen tutorial con pantallazos incluidos para instalar software en ubuntu es el del colega José GDF.

Aquí intento ir un poco más allá de las herramientas de instalación pues lo diferente y lo sorprendente está a un nivel más fundamental.

1. Instalar software desde repositorios

El "gestor de paquetes"

Si comparamos el software con un producto que unos fabrican y otros utilizan, las distribuciones serían intermediarios que se ocupan del empaquetado y la logística. Sus almacenes de "paquetes de software" son los denominados "repositorios" y el usuario final tiene acceso directo a los mismos a través de un "gestor de paquetes". Estos "paquetes" tienen la extensión .deb en Debian [2] y en todas las distribuciones basadas en debian como ubuntu, Linux Mint y otras. En Fedora y Suse, tienen la extensión .rpm.

En el entorno gráfico de escritorio gnome (el que usa ubuntu por defecto), el gestor de paquetes gráfico se encuentra en el menú principal, Sistema -> Administración -> Gestor de paquetes Synaptic.

La introducción rápida explica en pocas palabras: "El software en su sistema se organiza en lo que se denominan paquetes...".

Instalar software a través de synaptic es coser y cantar. Buscar la aplicación, marcar para instalar y aplicar. Con esto, enviamos una petición al repositorio para que nos sirva el paquete o paquetes requeridos, y de la misma tirada, lo instalamos en el sistema. El "centro de software" es aún más sencillo pues facilita aún más la búsqueda de programas y oculta al usuario los "paquetitos" de bibliotecas y en general los "subprogramas" cuyos nombres no dicen gran cosa al usuario final.

Existen otras herramientas como aptitude o apt-get, que podemos usar desde la terminal. De hecho, instalar software desde la terminal tiene un ventaja; es más rápido, pero una desventaja; no es intuitivo ni familiar para los principiantes. Por lo demás, usemos el método que usemos conseguiremos instalar el programa deseado igual de bien.

Conoce tus repos

No, lo que marca la diferencia no es el gestor de paquetes que usemos. Lo que es de VITAL IMPORTANCIA son los repositorios habilitados. Si uno compra una pieza para un coche mercedes en un almacén donde sólo sirven para seat, igual la instala y le funciona pero si no sabe bien lo que hace es posible que no funcione. O que queriendo arreglar un problema origine otro peor por culpa de esa pieza que compró en el almacén equivocado.

Pero ojo, es fácil fastidiarla sin querer pues los almacenes son del todo "self-service" y no hay nadie que te diga, "¿Tu no tenías un Mercedes? ¿Estás seguro de que quieres una pieza de Seat?"

Simplemente, hay que saber dónde comprar. Pero veréis que es muy fácil, y os aseguro que comprendido esto y siguiendo unas "buenas prácticas" el riesgo de romper el sistema es muy bajo. Al contrario, si esto no se comprende y nos gusta mucho "enredar", probar las últimas versiones o conseguir nuevos programas por ahí... y pensamos que mientras sea un .deb no hay problema... el desastre y los "infiernos de dependencias" están asegurados.

Los repositorios están declarados en uno o más archivos del sistema [3]. Podemos editar estos archivos manualmente o bien podemos acceder a ellos desde Sistema -> Administración -> Orígenes del Software [4]. Veamos:



En esta imagen aparecen los repositorios "oficiales" de ubuntu. Main, Universe, Multiverse, y Restricted. Si no hemos tocado nada, tendremos estos repos activados, donde hay miles de paquetes, muchos de los cuales son programas y otros muchos (la mayoría) utilidades, bibliotecas, extensiones de programas, metapaquetes...



Aquí podemos habilitar los repositorios de actualizaciones y la configuración de las mismas. Mi consejo es mantener lo que viene por defecto, "karmic-secutiry" y "karmic-updates". De aquí vendrán las actualizaciones.

El gestor de actualizaciones es una herramienta más. Conseguimos exactamente lo mismo si vamos a Synaptic, recargamos, marcamos todas las actualizaciones y aplicamos, o también si hacemos desde la terminal:

sudo apt-get update (para actualizar las listas de repositorios, lo mismo que "recargar")
sudo apt-get upgrade (para actualizar las versiones de los paquetes instalados)

Dependencias

Muchas veces, cuando instalamos un paquete se marcan también otros para instalar, sin que, al menos de forma sencilla, podamos hacer nada para evitarlo. Son las llamadas "dependencias".


Metapaquetes


Un metapaquete no instala ningún "archivo de programa" (ejecutables o bibliotecas), simplemente marca paquetes para instalar como sus "dependencias". Por ejemplo, Ubuntu tiene un megapaquete llamado "ubuntustudio-audio-plugins" que marca como dependencias un montón de plugins de audio.

Esto nos instala decenas de programas con dos clicks de ratón (marcar para instalar, aplicar) o con una línea de terminal (sudo apt-get install ubuntustudio-audio-plugins).

Añadiendo repositorios

Puede que nos venga bien un paquete que no está en los repos oficiales. Las aplicaciones están en un proceso de desarrollo continuo. Especialmente en lo que ocupa a este blog, las distribuciones no están tan al día como algunos usuarios que prueban nuevas aplicaciones bajándose "las fuentes", es decir, el código del programa, que facilitan los propios programadores. Esto es sólo posible en un modelo de desarrollo público, de código abierto y que permite la libre distribución. Cualquier usuario que sepa cómo hacerlo puede "empaquetar" software y colocarlo en repositorio personal, por ejemplo en un PPA.

Podéis ver la entrada "PPA's, tesoros de ubuntu" donde se dan un par de PPA's para ubuntu karmic que pueden ser útiles. Allí se explica cómo añadir un PPA a la lista de repositorios. Aparecerá en la pestaña "otro software" de los "Orígenes del software". Hay otros repos que no son necesariamente PPA's, uno de los más populares, el de medibuntu, el cual aloja googleearth, bibliotecas necesarias para ver DVD's, códecs privativos, etc.

Lo más importante a la hora de añadir repositorios externos es que sean compatibles con la versión de nuestra distribución.

En general, si queréis evitar problemas, no tengáis normalmente habilitados repos no oficiales. Cuando añadáis uno porque sabéis que contiene paquetes interesantes, una vez instalados, deshabilitarlo. Es más fácil que se equivoque alguien que mantiene un repositorio personal, a que lo haga el equipo de mantenedores de ubuntu. Estos son mis repos "no oficiales" actualmente en ubuntu karmic, sólo tengo permanentemente habilitado el de medibuntu, que nunca me ha dado ningún problema.




Bloquear y forzar versiones

Aunque es recomendable estar al día con las actualizaciones, en algunos casos nos puede convenir que un paquete no se actualice nunca. Una forma de hacerlo es desmarcarlo cuando nos salte el gestor de actualizaciones, pero hay otra mejor, "clavar" el paquete o bloquear versión. Está en Synaptic, menú Paquete.

Ahora, imaginemos que hemos añadido un PPA y hemos actualizado un paquete que en este repo está con una versión más reciente que en el oficial. Por lo que sea, para nuestro disgusto, nos funciona peor. Podemos volver atrás, "forzando versión" (menú Paquete) pues tenemos dos versiones diferentes del mismo paquete en dos repos diferentes.




2. Instalar "paquetes sueltos" desde internet


En algunos sitios ofrecen paquetes deb. Nos debemos asegurar que el sitio es de confianza y que es compatible con nuestra versión de ubuntu, es decir, que sus dependencias, si existen, están en los repos oficiales de nuestra versión de ubuntu. Una vez descargado, lo podemos instalar muy fácilmente con GDebi (botón derecho sobre el paquete). Desde terminal, lo podemos hacer con:

sudo dpkg -i paquete.deb


[2] Una de las principales distribuciones GNU/Linux.

[3] El archivo /etc/apt/sources.list y otras listas que puedan existir dentro del directorio /etc/apt/sources.list.d/

[4] También desde el propio Synaptic, Configuración -> Repositorios