howtos

Hace algún tiempo estaba yo soltando un rollo sobre compatibilidades entre licencias de software y alguien me dijo (más o menos): «Vale. Pero sin follones ni líos: Supongamos que yo he hecho un programa y quiero liberarlo. ¿Qué hago?«.

Liberar un software puede llegar a ser tremendamente complicado e incluso, a veces, literalmente imposible. A menudo la cosa se complica por desacuerdos entre los autores, o con la empresa para la que trabajan, o líos legales con las distintas licencias que pueda tener un programa complejo…

Pero, en la mayoría de los casos, cuando dices «He hecho este programa y quiero liberarlo» es algo muy fácil, simple y rápido. De modo que, en adelante, supondremos que eres el autor del software y que no estás usando librerías ni código de otros autores.

Paso 1 Elegir Licencia:

Hay un montón de licencias libres para elegir, cada una de ellas con unas características propias. Algunas licencias son compatibles con unas pero con otras no. Si usas librerías o parte del código de otros, o si tu programa es una modificación del de otro, tendrás que usar su misma licencia o una licencia compatible con la suya. Si usas código de varias fuentes con licencias distintas, necesitarás encontrar una licencia compatible con todas ellas (y eso puede llegar a ser un lío tremendo en el mejor de los casos, o incluso imposible en el peor).

Pero sigamos suponiendo que todo el código es tuyo y no dependes de las licencias de otros. Entonces puedes elegir la licencia que quieras. Personalmente, te recomiendo que uses la licencia GPL. Es una licencia libre que permite todos los usos de tu software (incluso comerciales), permite redistribuirlo, modificarlo y crear software derivado, pero exige que todo ese software derivado se distribuya con esa misma licencia GPL. Esto es importante porque, de este modo, todas las mejoras, modificaciones o software derivado que hagan los demás de tu código también tendrán que ser libre (a esto, concretamente, es a lo que se llama «Copyleft»). Es también la licencia libre más usada y, de hecho, la que usa Linux.

Una vez elegida la licencia, tendremos que indicarla en cada uno de los archivos del código fuente. Veamos cómo.

Paso 2: Copyright.

Sólo la persona (o personas, si son varias) que tiene el copyright de un programa puede liberarlo. En principio, esa persona (o personas) es el autor (o autores) de ese programa.

Así que lo primero que tienes que poner en la cabecera de tu programa es un anota diciendo quién eres y que que tienes el Copyright, con algo parecido a esto:

Copyright 2013 Allan Psicobyte.

(si hubiera más de un autor se pondría una línea como esa por cada uno de ellos)

Después de la nota de copyright se pone un pequeño texto que indique concretamente la licencia que estamos usando. Suele haber un texto estándar para cada una de ellas, y en el caso de la GPL es este:

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

Paso 3: Archivo con la licencia

Además de poner el texto con copyright y licencia en cada uno de los archivos del código fuente, es conveniente acompañarlo con otro archivo que contenga el texto completo de la licencia. Por tradición, ese archivo es de texto plano y se llama README (así, en mayúsculas y sin extensión) o, mejor, LICENSE. El texto de la licencia, en el caso de ola GPL, se puede copiar de la versión que hay en la página del proyecto GNU (tal cual, sin modificar nada).

Paso 4: Publicar el código:

Lo siguiente es poner todo esto en algún lugar público al que se pueda acceder. Lo puedes poner para descargar como un archivo comprimido en tu página personal, usar tu propio servidor FTP o el método que prefieras pero, lo más recomendable con diferencia, es usar alguno de los muchos repositorios de Software Libre o forjas que existen. Estos sitios te permiten fundir el proceso de desarrollo, producción y distribución en uno sólo, y suelen estar dotados de herramientas muy útiles.

Hay muchos diferentes y, dependiendo del sistema de control de versiones que uses (y, si no usas ninguno, deberías hacerlo), preferirás uno u otro. Sourceforge, por ejemplo, es un clásico que usa subversion, aunque últimamente el que está pegando fuerte es github, que usa git y tiene un montón de herramientas de tipo «red social» que sirven de mucha ayuda.

Además, siempre que distribuyas el programa deberá ir acompañado del código fuente o, en su defecto, de un enlace o texto indicado cómo conseguirlo.

Por último, dependiendo de cómo sea tu programa, es una buena idea incluir algún aviso sobre la licencia en la documentación, la ayuda (el clásico «Acerca de…»), el manual, etc.

Y con esto, ya eres un programador de Software Libre. Enhorabuena.

(Publico este texto simultáneamente en mi blog y en el de la Oficina de Software Libre de la Universidad de Granada)

A menudo, la primera pregunta que se hace alguien que quiere empezar a colaborar en un desarrollo de software libre es cómo hacerlo.

Al comenzar a programar en una empresa o cualquier clase de proyecto con una estructura jerárquica tradicional, simplemente llegas y alguien te muestra una silla y te dice lo que tienes que hacer y cómo tienes que hacerlo. En una comunidad de software libre las cosas son muy distintas.

El desarrollo de software libre tiene un componente social muy importante, y las comunidades se estructuran, de forma deliberada o espontánea, como una meritocracia.

Esto tiene muchas ventajas de cara al desarrollo en sí mismo, pero puede dificultar mucho entrar en un proyecto.

Además, cada proyecto es un ecosistema en sí mismo y funciona de forma autónoma y distinta a todos los demás. Lo que vale para uno no tiene necesariamente que valer para otro. Lo que pongo aquí son unas reglas básicas, meramente orientativas, en base a lo que cuentan miembros de distintas comunidades (En especial recomiendo esta magnífica presentación de Plablo Neira, que es miembro del Core Team de Netfilter).

En algunos casos, sobre todo proyectos pequeños o incluso unipersonales con poca o ninguna comunidad, te bastará con escribir un correo al administrador para que te dé permisos de escritura en el repositorio, pero aquí vamos a suponer que estás pensando en un proyecto «grande», en el que no va a ser fácil que te hagan caso o incluso la recepción sea más que fría.

En un proyecto grande, un administrador puede recibir cada día cientos de parches de desconocidos que, directamente, no puede pararse a leer para ver siquiera si son simplemente válidos. Lo más probable es que los descarte directamente. Para entrar hay que hacerlo poco a poco, siguiendo los pasos correctos.

Insisto en que esto está escrito pensando en el caso más «difícil»: No quiero asustar a nadie XD

Para empezar, ármate de paciencia.

Elegir proyecto

Naturalmente, tiene que ser algo que te guste, porque no tiene mucho sentido meterte en algo que te aburra y que seguro que vas a abandonar más pronto que tarde.

Además debes buscar algo más o menos concreto. «Quiero trabajar en GNU/Linux» no es decir mucho.

Siempre es mucho mejor, si es posible, que trabajes en algo que usas, conoces y a lo que le has visto fallos/bugs/deficiencias/posibilidades de mejora.

Los proyectos pequeños con pocos miembros suelen ser más receptivos a la hora de admitir nuevos miembros, y más dados a ponértelo fácil, explicarte cada cosa, etc.

Conocerlo

Una vez que has decidido en qué quieres participar, tienes que buscar tres cosas principales (que, a menudo, van juntas) y darte de alta en ellas:

  1. Los foros/listas de correo de desarrolladores (no los de usuarios, ni howtos, aunque también conviene conocerlos).
  2. El bus tracería.
  3. El repositorio (cómo se usa el CVS que tenga, y bajarte el código, claro).

En los tres puntos de arriba, además, debes leerte los consejos de uso, buenas maneras y esas cosas.

Una vez hecho esto, meterse a enviar código como un loco es un error. Es el momento de «lurkear». Lee los mensajes, las peticiones, las respuestas…

La idea es que veas «el ambiente», cómo pregunta y responde la gente y cómo funcionan las cosas en general.

Empezando a participar

Cuando te sientas cómodo, puedes empezar a responder cuestiones en los foros o aportar soluciones a los bugs. Es mejor empezar con cuestiones simples, aunque sean tonterías o demasiado simples para tus conocimientos. Es probable que sean cosas de uso o configuración, que no requiera código. También es bueno que vayas viendo los parches que sube la gente, probándolos tú mismo, etc.

Si ves que hay buena recepción, ya podrás meterte en temas más serios y empezar a aportar soluciones a bugs reales (para estas alturas, ya deberías saber manejar la herramienta «diff»). Si todo va bien y confiando en tu habilidad y dedicación, para estas alturas ya te estás «haciendo un nombre» (o sea, que ya no eres un desconocido que acaba de aparecer). La mayoría de estos parches van a ser ignorados o descartados por la razón que sea (porque el formato no es el correcto, porque están demasiado/demasiado poco comentados, porque hay oro parche mejor…) pero, en algún momento, uno de tus parches acabará siendo aceptado. Enhorabuena.

Probablemente pases mucho tiempo escribiendo parches y, conforme tú aprendas a conocer el programa y la comunidad, y la comunidad aprenda a conocerte a ti y a tu código, irás «escalando puestos» en la meritocracia (que es una forma «chic» de decir que se irán fiando de ti e incluso te irán dando responsabilidades).

Básicamente, se trata de ir demostrando poco a poco lo que vales en base a tus aportaciones. No puedes llegar gritando «Aceptad mis commits, que soy un genio programador«, porque no serás bien recibido. No basta con programar bien, también hay que seguir las reglas de la comunidad y ponérselo a la gente que tiene que descubrir que programas bien.

Recientemente, con las últimas actualizaciones de algunas distribuciones basadas en Ubuntu, nos hemos encontrado con que han dejado de verse los vídeos de youtube en Firefox.

En concreto, hemos visto que el problema se está dando en algunas Guadalinex, y da la impresión de que es una incompatibilidad entre distintas versiones del plugin y de firefox.

Tras mucho trastear, tenemos una pequeña solución manual que nos puede servir mientras alguien va preparando el paquete oficial, consistente en copiar manualmente la librería del plugin a una dirección en concreto.

El procedimiento es simple:

En la siguiente página, puedes descargar el archivo comprimido del plugin (entre las opciones que da, debes elegir la denominada «.tar.gz para otros linux»)

http://get.adobe.com/es/flashplayer/

Obtendrás un archivo comprimido llamado «install_flash_player_11_linux.x86_64.tar.gz»

Dentro de este archivo hay varias cosas, pero la única que realmente nos interesa es un fichero llamado «libflashplayer.so«, que es el que usaremos.

Lo único que hace falta es copiarlo al directorio «/usr/lib/mozilla/plugins/» (para lo que vas a necesitar permisos de root).

Una vez copiado, Firefox debería mostrar correctamente los vídeos de youtube.

Hay muchas formas diferentes para hacer lo que hemos descrito arriba pero, si no tienes muy claro cómo hacer alguno de estos pasos, vamos a verlos cómo se harían uno a uno por medio de la línea de comandos.

Suponiendo que ya hemos descargado el archivo comprimido desde la página de adobe, abrimos una terminal, en la que escribimos lo siguiente:

cd Descargas

(Esto suponiendo que la carpeta «Decargas» sea donde se ha descargado el archivo. Si fuera otro, pon esa dirección)

Ahora extraemos el archivo libflashplayer.so con la siguiente orden:

tar xfvz install_flash_player_11_linux.i386.tar.gz libflashplayer.so

Y, por último, lo movemos a su destino correcto de este modo:

sudo mv libflashplayer.so /usr/lib/mozilla/plugins/

(el sistema te pedirá que introduzcas tu contraseña para permitirte copiarlo)

Con esto ya debería funcionar.

Con el gestor de arranque de Ubuntu 12.04 «Grub2», podemos probar los Live CD, sin la necesidad de grabarlo en un CD o en un pendrive.

Para ello nos basta la imagen «.iso» del Live CD, descargada en nuestro disco duro.
Además de utilizarlo para probar las distintas distribuciones que nos interese, es muy útil para realizar tareas de las cuales no queramos dejar ni rastro, por ejemplo acceder a nuestra cuenta del banco, etc…

Además, de esta forma nos ahorramos tiempo, ya que arranca y trabaja bastante más rápido que si lo hacemos desde un CD y por supuesto, no tenemos que andar metiendo y sacando CDs.

Vamos a ver como hacerlo: 

Nota: Como indico al final en «posible error», esto solo vale para los LiveCD de Ubuntu y sus derivadas. Para LiveCD de otras distribuciones como Fedora, OpenSuse, ArchBang, … hay que modificar el directorio y archivos donde encontrar el Kernel (núcleo) para el booteo.
Creamos un directorio en la raíz del sistema de archivos (/) al que llamaremos «/iso», para tener el sistema de archivos organizado, con el comando:

sudo mkdir /iso

Descargamos la imagen.iso de la distribución que deseemos en nuestra carpeta de «Descargas» (dentro de nuestra carpeta personal).

Importante: En el tutorial voy a utilizar un nombre genérico: nombre-livecd.iso y vosotros tenéis que cambiarlo por el nombre exacto del archivo descargado, en todos los comandos y código que pondré. Es Muy importante que sea el nombre idéntico. Si queréis podéis renombrarlo por otro que os sea más fácil de escribir.

Consejo: en los nombres de los archivos, utilizad los guiones medios ( – ) o bajos ( _ ) entre palabras y no os compliquéis la vida poniendo espacios en blanco, porque entonces tendréis que escribirlos entre comillas. Por ej: «nombre livecd.iso«.

Copiamos el archivo descargado en la carpeta Descargas (~/Descargas/nombre-livecd.iso) y lo pegamos dentro del nuevo directorio que hemos creado con anterioridad (/iso), con el comando:

sudo cp ~/Descargas/nombre-livecd.iso /iso

En el archivo /etc/grub.d/40_custom, se pueden añadir sistemas operativos manualmente para que aparezcan en el grub. Lo editamos con el comando:

sudo gedit /etc/grub.d/40_custom

Al final del archivo añadimos las siguientes líneas, pero mucho ojo, antes de pegarlo, seguid leyendo más abajo, porque hay cosas que modificar en ellas (las que están en rojo).

menuentry "nombre livecd" {
set root=(hd0,2)
loopback loop /iso/nombre-livecd.iso
linux (loop)/casper/vmlinuz boot=casper locale=es_ES bootkbd=es console-setup/layoutcode=es splash iso-scan/filename=/iso/nombre-livecd.iso --
initrd (loop)/casper/initrd.lz
}

Vamos a ver las líneas una a una, para comprender qué estamos haciendo:

menuentry "nombre livecd"

«menuentry» es la línea que otorga el nombre que aparecerá en el grub. Podemos cambiar «nombre livecd», por el que queramos, por ejemplo «Xubuntu 12.04» a secas. (Aquí si podéis dejar espacios en blanco entre las palabras, ya que tiene las comillas)

set root=(hd0,2)

«set root=» determina la partición del disco duro «(hd0,2)», donde el sistema encontrará la imagen.iso que hemos pegado en /iso. Esto suele traer confusión, por lo que nos vamos a detener para explicarlo bien. Vamos a suponer que nuestro Ubuntu está en «/dev/sda2″, o sea, en la segunda partición (2) del primer disco duro (a). Por lo que entonces deberíamos de escribir: (hd0,2). Básicamente tenemos que tener en cuenta que: – La letra que designa el disco duro (a, b, c, …) es sustituida por un número (0, 1, 2, …). La nomenclatura de «hd» comienza por cero, o sea, el primer disco duro (a) es 0, el segundo (b) es 1, el tercero (c) es 2 … – El número de la partición (1, 2, 3, …) se quedará igual. Antes había que restar 1, ya que también empezaba por 0 (cero), pero lo modificaron porque creaba mucha confusión.
Os dejo un listado de las respectivas nomenclaturas en los dos primeros discos duros, por si os queda alguna duda:

loopback loop /iso/nombre-livecd.iso

«loopback loop …» Determina la ruta dentro de la partición, donde encontrará la imagen.iso. No hace falta poner la ruta en la que se montó el disco (/media/…/), ya que en la línea anterior «set root» ya pusimos el disco duro y la partición donde está. Solo tenemos que cambiar nombre-livecd.iso, por el nombre exacto de la imagen.iso que pegamos en /iso.

linux (loop)/casper/vmlinuz boot=casper locale=es_ES bootkbd=es console-setup/layoutcode=es splash iso-scan/filename=/iso/nombre-livecd.iso --

«linux (loop)/casper/vmlinuz boot=…» Determina la ruta del kernel con el que arrancará el Live-cd. En esta línea encontraremos los siguientes parámetros que podemos quitar o dejarlos, según nos convenga (recomiendo dejarlos tal cual): – locale y bootkbd, para que arranque con el idioma y la distribución del teclado en Español. – splash, para que muestre la imagen de carga (splash). Aquí, también debemos de cambiar al final de la línea: nombre-livecd.iso, por el nombre exacto de la imagen.iso que pegamos en /iso.

initrd (loop)/casper/initrd.lz

initrd (loop): determina la ruta dónde está el initrd (sistema de archivos temporal usado por el núcleo Linux durante el inicio del sistema)

Cuando tengamos el archivo correctamente, guardamos, cerramos el archivo y actualizamos el grub con:

sudo update-grub

Nota: se pueden añadir tantos LiveCD como queramos, añadiendo al archivo el correspondiente grupo de líneas («menuentry {…}) y con sus respectivas imágenes.iso pegadas en el directorio /iso. En el grub aparecerán todos los Live-CD, desde los que podremos arrancar cualquiera de los añadidos

Como ejemplo os dejo mi archivo, en el que he añadido Xubuntu y Lubuntu.

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Lubuntu 12.04 Live" {
set root=(hd0,2)
loopback loop /iso/lubuntu-12.04-desktop-i386.iso
linux (loop)/casper/vmlinuz boot=casper locale=es_ES bootkbd=es console-setup/layoutcode=es splash iso-scan/filename=/iso/lubuntu-12.04-desktop-i386.iso --
initrd (loop)/casper/initrd.lz
}
menuentry "Xubuntu 12.04 Live" {
set root=(hd0,2)
loopback loop /iso/xubuntu-12.04-desktop-amd64.iso
linux (loop)/casper/vmlinuz boot=casper locale=es_ES bootkbd=es console-setup/layoutcode=es splash iso-scan/filename=/iso/xubuntu-12.04-desktop-amd64.iso --
initrd (loop)/casper/initrd.lz
}

A mi me ha funcionado igual 😉
Gestor de arranque Burg
En el Foro, el compañero Makova (yo mismo) nos deja que hacer si tenemos Burg (menú animado para el Grub2):
Básicamente hay que hacer lo mismo, a excepción de:
– En lugar de editar el archivo «/etc/grub.d/40_custom», editamos este otro: «/etc/burg.d/40_custom» (cambiar grub por burg):

sudo gedit /etc/burg.d/40_custom

– Al final, actualizar el burg con:

sudo update-burg

Posible error:
Si al arrancar os aparece el siguiente error:

you need to load the kernelk first

Es por que «no encuentra el archivo para el arranque del kernel» y esto es debido a que el directorio /casper y los archivos vmlinuz y initrd.lz solo se utilizan en Debian y derivadas (Ubuntu, Linux Mint, Guadalinex, …), por lo que en otras distribuciones se debería de cambiar las líneas pertinentes con la ruta/archivo adecuada, para que encuentre el archivo.
Gracias a: Juanetebitel

El programa APTonCD permite realizar una copia de seguridad de todos o algunos de los programas instalados en el ordenador para poder, posteriormente, instalarlos con facilidad. Está disponible para Ubuntu y Debian.

Para la instalación podemos dirigirnos a la página de descarga y seguir las instrucciones de instalación. O bien, directamente descargarlo de softonic. Si utilizamos este segundo enlace, será necesario utilizar el fichero Makefile tras descomprimir el archivo descargado escribiendo en un terminal:

    $ tar -xvzf aptoncd-*.tar.gz
    $ cd aptoncd/
    $ sudo make install

Tras iniciar el programa nos da dos opciones: crear o restaurar. En primer lugar creamos una copia de seguridad. Se pueden añadir o quitar programas de la lista de todos los programas que se encuentran actualmente instalados. Cuando finaliza, se genera una iso.

Para restaurar, se indica la localización de la iso previamente generada (ya sea en un cd/dvd si se ha grabado, o en un directorio). También permite elegir qué programas de todos los que se encuentran en la copia de seguridad se quieren instalar. Es interesante marcar la opción de generación de dependencias automáticas para que se detecten luego a la hora de instalar. Tras la restauración aparece una notificación de que los programas han sido añadidos, aunque no han sido instalados todavía.

Para instalar todos los programas añadidos y restaurados basta con instalar todos los .deb que se han generado en la restauración, es decir:

    $ cd /var/cache/apt/archives
    $ sudo dpkg -i *.deb
    $ sudo apt-get install -f

Y ya están todos los programas del backup instalados.

Si APTonCD no funciona correctamente al intentar restaurar es posible que sea necesario instalar hal:

    $ sudo apt-get install hal

Hacer un hackathon no es fácil, pero merece la pena. Ninguno es perfecto, pero en cada uno se sacan una serie de conclusiones que nos pueden servir (aunque a veces no) para el siquiente. Cada uno es diferente, y de este hemos sacado las siguientes conclusiones.
Pablo en el discurso final.

  • Este hackathon ha sido un fracaso que en realidad ha parecido un éxito. Las fotos muestran una gran cantidad de público, y de hecho ha habido unas 50 personas más alguna que se ha pasado de forma efímera; es más del 50% de los inscritos, lo que es excepcional. Pero lo cierto es que había más personas de fuera de informática que de dentro. Si no hubiera sido por la cantidad de traductores que nos lograron traer Ruth Burbat y Eugenia Arrés, los proyectos habrían atraído uno, dos o quizás tres informáticos. Es cierto que eran muchos proyectos, pero la lección aprendida es que tenemos que intentar difundir mejor, tanto la oficina como los propios proyectos, el hackathon entre nuestros compañeros. Lo cierto es que, como ya resulta habitual, la presencia de profesorado y graduados/doctorandos de la ETSIIT ha sido nula, y si los profesores no difunden nuestras actividades entre sus alumnos, no vamos a ningún lado
  • Los créditos, como siempre, son una espada de doble filo. Aunque se han solicitado créditos para la ETSIIT, no se ha difundido este hecho, para que los créditos sean un premio a los que quieren asistir por otra razón, no para los que no tienen otra razón para asistir. Eso ha restado asistentes, claro, pero los asistentes informáticos que hemos tenido han sido entusiastas y comprometidos. Hay que mantener un equilibrio entre calidad y cantidad, y no sé si se habrá tomado la decisión correcta optando por la cantidad.
  • El año pasado comentábamos que el hackathon era para informáticos, y lo cierto es que, pese a las apariencias, sigue siendo así. Una vez más, la calidad y cantidad de gente que ha asistido de traductores oculta el fracaso por atraer personas de otras carreras. Incluso ofertando créditos para Bellas Artes, Comunicación, y haberlos solicitado en Ciencias, nadie de esas carreras se ha inscrito siquiera. Falla la comunicación, quizás, pero tampoco tenemos canales para poder publicitar cosas en cada una de las facultades, incluso en las que hemos pedido. La conclusión sigue siendo prácticamente la misma: hay que concentrarse donde sepamos que va a tener cierta repercusión.
  • La preparación de los proyectos es fundamental, y el liderazgo de los mismos también. Es esencial llegar al hackathon con ideas bien claras de lo que quieres hacer y cómo vas a hacerlo; una lista de tareas realista y que pueda ocupar a todo el mundo. La lista de tareas tiene que estar abierta para redibir a personas de toda procedencia y conocimientos; aunque lo más probable es que vengan sólo informáticos, también pueden venir de primero de grado y no saber demasiado
  • Tener siempre copia de seguridad, incluso de los procedimientos: ni siquiera se puede contar con que la Internet funcione. En esta ocasión se cayó la forja de RedIris el mismo fin de semana, y hubo que recurrir a otros métodos. Skype, Whatsapp, teléfono de dial rotatorio, todo preparado para que en caso de no poder verse físicamente el fin de semana se pueda seguir trabajando y eventualmente hacer una buena actividad en la forja
  • La formación sigue siendo imprescindible: desde alguien que explique qué es el sotware libre desde 0, hasta alguien que cuente cómo funcionan los sistemas de control de fuentes o metodologías ágiles; si varios proyectos tienen herramientas comunes(Python, Django), identifícalo y consigue que alguien dé una charla sobre el tema
  • Preved material informático para las personas que no se lo lleven: unos cuantos portátiles con software usable directamente, o un aula de prácticas que se pueda usar. Recordad que aunque todo el mundo haya recibido información al respecto, es posible que alguien, por error o simplemente porque no disponga de él, no lleve su portátil para trabajar. Si tenéis material para prestar, usadlo para esto; y comprobad previamente que esté en correcto estado de funcionamiento.

Con todas las lecciones buenas y malas aprendidas, sigue siendo una experiencia muy interesante, tanto para los del proyecto, como para los asistentes, que se convierten en cantera para participar en el concurso de software libre en años sucesivos.

Kazam es una aplicación open source para la grabación del escritorio en Linux.

Características principales:

  • Graba vídeo y sonido.
  • Dispone de una cuenta atrás personalizable antes del comienzo de la grabación.
  • Permite pausar la grabación.
  • Realiza la renderización mientras graba el vídeo.
  • Por defecto genera vídeos en formato .webm
  • Permite capturar hasta 60 fps

Para instalarlo, pues no se encuentra disponible, en este caso, en los repositorios de Ubuntu

sudo add-apt-repository ppa:kazam-team/stable-series

sudo apt-get update

sudo apt-get install kazam

 Y la aplicación es muy simple de usar:

Podemos seleccionas las fuentes de vídeo, sonido, y el tipo de codecs, podemos variar el contador de cuenta atrás, varias los frames de captura y si queremos que capture el ratón o no.

En el caso de que queramos capturar un área determinada, usaremos el Record Region, y nos aparece la siguiente ventana que podemos mover, escalar, etc.

Blog oficial: http://www.twm-kd.com/category/linux/kazam/

Launchpad:https://launchpad.net/kazam

Este mini-howto lo hacemos a petición de Zoey. En realidad se añaden conjuntos de iconos completos, que incluyen, por supuesto, al cursor. Se va a el repositorio de iconos de Gnome (que es el sistema de gestión de ventanas que usan estos portátiles) y se elige cualquier tema pinchando sobre él. Hay unos cuantos de diferentes estilos. Al pinchar, se abrirá una ventana que te preguntará qué hacer con él, indicando que se puede abrir con el «Instalador de temas (predeterminado)». Simplemente dar a «Aceptar», con lo que se descargará el tema y saldrá una ventana que te preguntará si deseas aplicarlo ahora, o mantener el tema. Si se pulsa en «Aplicar el nuevo tema» automáticamente comenzarán a usarse los nuevos iconos. Puedes probar algunos muy curiosos como Nerdy lines.

Si desaparecen los menús y decoraciones de las ventanas, apareciendo todas en la esquina superior izquierda y sin posibilidad de moverse, podéis hacer lo siguiente (aunque es un poco drástico).

  • Cerrad la ventana que oculte los menús o, si no podéis, rearrancar
  • Ejecutad Aplicaciones->Accesorios->Terminal
  • Os saldrá una línea de órdenes así:

    usuario@pc30-1 ~/

    . Escribid entonces mv .gconf dot-gconf y dadle al Enter

Eso es todo. El problema es que algo en la configuración se ha torcido, y tendréis que borrarlo (o tratar de averiguar qué ha sido). Con esa medida tan drástica habréis borrado toda la configuración: apariencia de las ventanas, clave del WiFi… pero nada que no pueda recuperarse (espero)

Web Campus Infantil 2019
Logo y enlace Web Campus Infantil 2019
Web SereIngeniera
Logo y enlace Web SereIngeniera 2018
Web Jornadas De Software Libre
Logo y enlace Web Jornadas de Software Libre 2018
Calendario
septiembre 2020
lunes martes miércoles jueves viernes sábado domingo
31 agosto, 2020 1 septiembre, 2020 2 septiembre, 2020 3 septiembre, 2020 4 septiembre, 2020 5 septiembre, 2020 6 septiembre, 2020
7 septiembre, 2020 8 septiembre, 2020 9 septiembre, 2020 10 septiembre, 2020 11 septiembre, 2020 12 septiembre, 2020 13 septiembre, 2020
14 septiembre, 2020 15 septiembre, 2020 16 septiembre, 2020 17 septiembre, 2020 18 septiembre, 2020 19 septiembre, 2020 20 septiembre, 2020
21 septiembre, 2020 22 septiembre, 2020 23 septiembre, 2020 24 septiembre, 2020 25 septiembre, 2020 26 septiembre, 2020 27 septiembre, 2020
28 septiembre, 2020 29 septiembre, 2020 30 septiembre, 2020 1 octubre, 2020 2 octubre, 2020 3 octubre, 2020 4 octubre, 2020
Archivos
Categorías