Instalar GNESIS en un USB, desde Windows (con perdón)

— [ edit | raw ] migrated from node/633

Cómo crear una GNESIS USB si sólo dispones de un ordenador con Windows. Ya no tienes excusa, si sufres Windows es porque quieres.

Si estás leyendo esta receta, a priori, pensaría que utilizas Microsoft Windows de forma habitual y eso no puede ser. Sin embargo, estoy seguro que no es así y que simplemente te has equivocado de sitio por un despiste. Por ello, es conveniente que consultes Instalar GNESIS en un dispositivo USB desde GNU/Linux, que es lo que realmente usas ;-).

Ingredientes

  • Un pendrive USB
  • Microsft Windows XP (o sistema repugnante similar)
  • GNU dd para Windows

Al igual que en GNU, el programa dd te permite volcar el contenido del archivo .img a tu dispositivo.

Copiando GNESIS

Descomprime el ejecutable dd.exe por ejemplo, en C:\. Seguidamente, abre una cosa fea, rara y sin transparencias que se llama símbolo de sistema. Se encuentra en la ruta “Inicio→Todos los programas→Accesorios→Símbolo de Sistema” . Una vez abierto situate en el directorio en el que hayas descomprimido el ejecutable de dd:

cd C:\

Suponiendo que tienes el archivo .img el mismo sitio, es decir, en C:\; y que ya tienes enchufado el dispositivo USB, debes ejecutar lo siguiente:

dd if=c:\archivo.img of=\\?\Device\Harddisk1\Partition0 bs=1M --progress

Windows es muy intuitivo…

Creando la partición persistente para GNESIS

Para tener la opción persistente de GNESIS es necesario utilizar un particionador (libre, por supuesto) con el que puedas crear una partición adicional (de tipo ext3). Puedes crear tantas particiones como quieras pero, al menos, una de ellas tiene que estar etiquetada como “casper-rw”. Se recomienda que si el dispositivo tiene poca memoria (1-2GB) sólo se haga una partición para persistencia.

Para crear la partición, como he dicho, puedes utilizar cualquier particionador, o bien arrancar tu GNESIS y seguir la otra receta.

Referencias

FreeBand: guitarra y batería ¡más arcade que nunca!

— [ edit | raw ] migrated from node/631

Proyecto de un juego libre programado un python en el que puedes competir contra ti mismo o contra un compañero, pudiendo tocar una guitarra o una batería.

Hola chicos y chicas…

He hablado con David y he decidido que voy a empezar con esto en breve. Espero que se una toda la gente posible cuanto antes. Creo que David a lo mejor puede hacer una parte importante si el tiempo se lo permite.

El proyecto consiste en un juego arcade donde un jugador puede controlar una guitarra al estilo del FoF y otro una batería. Una vez conseguida la meta principal, se podrán aumentar los instrumentos y las posibilidades.

El primer hito a conseguir es el siguiente, los demás hitos se discutirán cuando se termine este:

(1) Tener un programa en python, modular y extensible, que dado un ogg y un archivo de texto o XML con un formato determinado, reproduzca un sonido al pulsar una tecla (o botón de un pad), un sonido distinto por cada una de las 5 posibles teclas, y que diga si se ha pulsado en el momento correcto según el archivo asociado.

(2) Tener un editor de dichos archivos dado un determinado OGG.

El archivo asociado debería contener la siguiente información:

  • MD5 y nombre del OGG al que pertenece
  • Tecla a pulsar (pueden ser varias en un mismo instante)
  • Momento en el que se pulsa
  • Tiempo durante el que se pulsa
  • Modificadores de nota (pulsar por ejemplo otro botón para hacer un bend de guitarra o redoble de charles)
  • (opcional) Letras de la canción

Se usará para reproducir el audio gstreamer, dejando la opción de incluir pads nuevos en cualquier punto desde la fuente de cada uno de los sonidos, hasta el destino final (alsa, oss, jack… de eso se encarga gstreamer también).

¿Cuánto tiempo nos ponemos para esto?

Unos cuantos números podrían ser:

  • Disparar sonidos con el teclado: 5 horas
  • Reproducir un ogg: 1 hora
  • Leer el formato del archivo asociado: 2 horas
  • Comprobar si hay una tecla pulsada en el momento correcto: 10 horas

Hay que tener un cuenta de que no se pueden dejar las teclas pulsadas siempre y que el programa crea que lo haces bien… aunque en la primera aproximación, podría ser válido.

  • Editar el archivo asociado:
  • Reproducir una parte espećifica del ogg: 5 horas
  • Diseño GUI: 30 horas
  • 6 checkboxes para cada momento editable
  • edit o barra con el tiempo asociado a cada checkbox
  • barra asociada al tiempo (desplazable)
  • play/stop
  • play for x seconds
  • avanzar/retroceder un bpm/resolución beat

Comentarios por favor. El que no quiera currar que no critique, que no vamos a cobrar un duro por el tiempo empleado.

Un saludo,
brue

Cruzar el atlántico a nado... No tiene precio.

— [ edit | raw ] migrated from node/630
Sigamos la siguiente secuencia:

Nueva GNESIS 3.0 "fRincón" Pre-Release2

— [ edit | raw ] migrated from node/629

En la página web de GNESIS (en la sección descargas) podeis encontrar la nueva Pre-Release que se ha generado con las siguientes novedades:

  • Entornos gráficos XFCE y GNOME, a elegir.
  • Mucha mayor personalización de la Debian-Live original.
  • OpenOffice y Iceweasel (castellanizados)
  • Utilidades para conectividad wireless.
  • Entorno completo de programación en C.

Pysoya: menú de ejemplo

— [ edit | raw ]
migrated from node/628
Dependencias: python-soya

GNU Emacs: Edición «rectangular» (selección vertical)

— [ edit | raw ] migrated from node/627

Cómo utilizar los comandos de manipulación de rectángulos de Emacs, que facilitan enormemente ciertas tareas repetitivas.

Recuperación de un sistema completo: Mondo y Bacula

— [ edit | raw ] migrated from node/625
A pesar de que en anteriores recetas explicamos cómo realizar y recuperar backups en bacula, esto no es suficiente en el caso de querer recuperar un sistema completo. En caso de desastre total deberíamos volver a crear particiones, instalar un sistema base en el que recuperar los backups y, si no hicimos backup de la configuración del sistema, tendríamos que volver a configurarlo todo. Deberíamos separar backups del sistema y backups de los datos del sistema. Así podremos encontrar un método mejor para realizar nuestros respaldos.

Backup de los datos

Bien... hay mucho que explicar... pero está todo en las recetas sobre bácula: Lo único que debemos saber es qué es lo que vamos a almacenar. Esto es fácil: /var/ (no todo... las bases de datos, páginas web, repositorios, etc.) y /home. Como seréis buenos usuarios, no usaréis root para nada, por tanto ese no hace falta salvar. Ahora sólo nos queda salvar el sistema...

Backup del sistema

Para hacer backup del sistema hay que tener en cuenta un par de cosas: qué ficheros salvar, sus enlaces, atributos, particiones, sector de arranque, etc. y lo que es más importante: en caso de que nos quedemos sin sistema... ¿cómo lo podemos recuperar? ¿una live? como véis no es tan trivial como puede parecer en un principio... necesitamos un método para hacer todo esto de una forma fácil y rápida: mondo.

Instalar mondo

Para los debianitas y similares:
$ apt-get install mondo
Lo normal en estos casos es que ahora ponga unos comandillos para invocar a mondo... pero mondo tiene GUI!!! :jawdrop: (para que luego digan los de hassefroch) (algunos dirán que 6 botones en modo texto no son gui... pero otros dicen que un ratón tiene potenciómetros así que estamos en paz). Vienen muchas opciones, la más normal será hard disk. Esta opción creará unas imágenes iso del tamaño que digamos con nuestro respaldo del sistema. Hay una opción (create DVD images) que también podríamos usar... esta opción graba directamente los DVD's... pero tiene un problema: deberíamos estar todo el proceso ahí para ir cambiando los grabables... en un sistema grande eso puede ser un auténtico tostón. Otra cosa que hay que tener en cuenta es que en el directorio temporal necesitamos una gran cantidad de espacio libre (un poco más que el tamaño total de los ficheros a hacer backup). A la hora de hacer el backup excluiremos todos aquellos directorios que ya tengamos incluídos en las cintas de backup, /home sobre todo. En cuanto a /var, excluiremos todo aquello que no hayamos metido en cinta, cosas como la base de datos de dpkg, etc.

Restaurar el sistema

Bien... hemos creado las imágenes con mondo y justo después se nos ha reventado el sistema :jawdrop:. No pasa nada! Tanto si perdimos algunos ficheros como el sistema entero... reiniciamos el PC con el primer DVD insertado. El DVD arranca y nos aparece otra gui con varias opciones: testear backup, restauración manual y restauración automática. Realizamos una restauración automática, nos irá pidiendo los DVD's y extraerá los ficheros y tal. Una vez hayamos terminado reiniciaremos el PC ya sin los DVD's y arrancará nuestro sistema. Como nuestro sistema ya tenía bácula restauraremos los datos de /home desde las cintas (siguiendo las recetas).

Apéndice A: automondo

El uso del gui en mondo tiene un problema: exige interacción con el usuario. Puede ser que necesitemos poder crear imágenes sin que un usuario lo exija (cron). Además puede ser necesario almacenar alguna configuración en algún sitio. Para estas cosas he creado un pequeño y tonto script que he llamado automondo. El script lo copiaremos en /usr/sbin, lo llamaremos automondo y le daremos permisos de ejecución. El script es el siguiente:
#!/bin/bash

# Cargamos la configuracion (si existe)
#
CONFIG_FILE=/etc/mondo/automondo.conf
if [ -e $CONFIG_FILE ]
then
        . $CONFIG_FILE
fi
# Cargamos valores por defecto (en caso de que no exista CFG o falten parametros)
if [ -z "$IMG_DESTINATION" ]
then
        IMG_DESTINATION=/root/images/mondo
fi
if [ -z "$IMG_PREFIX" ]
then
        IMG_PREFIX=`hostname`
fi
if [ -z "$IMG_SIZE" ]
then
        IMG_SIZE=4200m
fi
if [ -z "$BCK_EXCLUDE" ]
then
        BCK_EXCLUDE="/tmp /lost+found"
fi
if [ -z "$TMP_DIR" ]
then
        TMP_DIR="/tmp"
fi
# Creamos el destino si no existe
if [ ! -d $IMG_DESTINATION ]
then
        mkdir $IMG_DESTINATION
fi
# Creamos el temporal si no existe
if [ ! -d $TMP_DIR ]
then
        mkdir $TMP_DIR
fi
# Invocamos el asunto...
/usr/sbin/mondoarchive -O -d $IMG_DESTINATION -p $IMG_PREFIX -i -E "$BCK_EXCLUDE" -N -s $IMG_SIZE -9 -T "$TMP_DIR" -S "$TMP_DIR"
Y ahora creamos el archivo /etc/mondo/automondo.conf con el siguiente contenido:
# Destino para las imagenes
#
IMG_DESTINATION=/root/mondo/images

# Prefijo en el nombre de las imagenes
#
IMG_PREFIX=`hostname`

# Tamaño de los iso
#
IMG_SIZE=4200m

# Directorios a excluir (proc y tal lo excluye mondo automáticamente)
#
BCK_EXCLUDE="/var/tmp /var/run /home /root/mondo"

# Directorio temporal
#
TMP_DIR="/root/mondo/temp"
Si ahora ejecutamos automondo se nos crearán automáticamente las imágenes del sistema ;).
Nota: Existe un "pequeño" problema que no se muy bien como arreglar. Resulta que aunque las imágenes las crea bien y funcionan (doy fe) da un "error" al final del proceso y pide la pulsación de intro para continuar. Cleto me ha sugerido el siguiente cambio en la última línea del script:
echo -e \n | /usr/sbin/mondoarchive -O -d $IMG_DESTINATION -p $IMG_PREFIX -i -E "$BCK_EXCLUDE" -N -s $IMG_SIZE -9 -T "$TMP_DIR" -S "$TMP_DIR"
Es pasar un intro al programa para que se pulse... pero no termina de convencerme el asunto... ¿qué opináis?

Enlaces

Las recetas sobre bácula que menciono al principio. Mondo Rescue Home Page.

Plataforma anti soporte gratuito a microsoft

— [ edit | raw ]
migrated from node/626

Interesante propuesta muy en la línea del post Microsoft somos todos de un tal Cleto que solía escribir por aquí.

SVN Externals: dependencias entre repos subversion

— [ edit | raw ] migrated from node/624

Los svn:external son una feature muy interesante de subversion, que permite que cuando descargas o actualizas una copia de un modulo automáticamente ‘tire’ de otros módulos que pueden estar en otros repositorios. Una especie de gestión automática de dependencias entre repos.

Es algo bastante sencillo, usaremos las propiedades de SubVersioN. En concreto “externals”. Los externals de svn son un conjunto de mappings entre un directorio local y una url que puede ser de cualquier cosa que se pueda traer mediante svn.

Esto puede serte útil si, por ejemplo, necesitas construirte una copia de trabajo que contenga directorios de diferentes repositorios, o del mismo repositorio, pero de diferentes localizaciones.

Para ello, simplemente editamos “los externals” del directorio en concreto:

$ svn propedit svn:externals .

Lo que nos lanzará un editor de texto en el que podemos poner los mappings, de la siguiente manera:

dir_local url_destino

Cada línea será un directorio nuevo con el contenido que especifiquemos. También podemos ver los que ya existen con:

$ svn propget svn:externals

Existen versiones acortadas de los comandos: pget o pg, pset o ps y pedit o pe para propget, propset y propedit respectivamente.

Tiene algunas limitaciones: no se pueden colocar rutas relativas, ni usar ficheros como mappings. Al hacer commit, sólo se realiza en la copia de trabajo principal, no en las externas.

Posible problema

En los enlaces externos que usan ssh, por defecto determina que el nombre de usuario sea el local (igual que si haces ssh host sin especificar el nombre de usuario). Puedes modificar este comportamiento añadiendo los nuevos hosts en el archivo ~/.ssh/config y especificando ahí el nombre de usuario para el servidor concreto al que se refieres el “external”:

Host repo.example.com
     User Pepito.Grillo

Referencias

Propuesta de creación de SL.

— [ edit | raw ] migrated from node/623
Hola a todos,