Multimediando

Cacharreo, tutoriales

Paseando por un centro comercial cualquiera acabé dentro de una cadena de electrodomésticos cualquiera, en la que había un interesante disco duro multimedia de 1 tera con conexión de red y bittorrent integrado: un MemUp LX Series. Por si fuera poco anunciaban que soportaba MKV y H.264 en FullHD, con lo que no me lo pensé y me lo compré. Luego resultó que esos dos formatos sólo los soporta si pones un ordenador a trascodificar para que le envíe los datos masticados por red, pero aún así, el cliente bittorrent integrado tenía buena pinta. Además, con suerte usaría un Linux embebido (empotrado siempre me sonó mal 🙂 ), con lo que incluso era posible que pudiese hacerle modificaciones. Y aunque no fuese así, al menos podría ver mis series favoritas en la tele sin tener que andar de un lado para otro con un DVD regrabable.

La primera prueba, reproducir un DivX, fue excelente: buena calidad de imagen y sonido, buenos menús (incluso tiene una previsualización y todo)… buena pinta. El acceso por red, por su parte, lo considero simplemente aceptable: es por SMB (red de windows), lo que no me convence mucho porque, aunque una vez que has entrado funciona bien, a veces da algún problemilla, así que añadir un servidor FTP sería una buena idea.

Por desgracia, en cuanto intenté usar el cliente BitTorrent desde la (espartana) interfaz web, empezaron los problemas: la descarga no arrancaba, e incluso el aparato se colgaba en según qué momentos (!). Un poco mosca, decidí dejar de lado el cliente BT de momento e investigar por otro lado a ver qué descubría.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Avisados estáis.

Comencé con un escaneo de puertos, y apareció nada menos que un servicio de telnet. La cosa se ponía interesante. Me conecté, puse root como usuario, y p’adentro, sin clave ni nada (así da gusto). Lo primero que hice fue echar un vistazo a /proc/version, /proc/cpuinfo y /proc/meminfo, que devolvieron lo siguiente (he marcado en rojo las partes interesantes):

Trying 192.168.1.103...
Connected to 192.168.1.103.
Escape character is '^]'.
Venus login: root
warning: cannot change to home directory

BusyBox v1.1.3 (2008.12.15-01:58+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

/ # cat /proc/version
Linux version 2.6.12.6-VENUS (root@localhost.localdomain) (gcc version 3.4.4 mipssde-6.03.01-20051114) #13 Mon Mar 9 14:40:01 CST 2009

/ # cat /proc/cpuinfo
system type             : Realtek Venus
processor               : 0
cpu model               : MIPS 4KEc V6.4
BogoMIPS                : 199.06
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes
ASEs implemented        :
VCED exceptions         : not available
VCEI exceptions         : not available

/ # cat /proc/meminfo
MemTotal:        56984 kB
MemFree:          9460 kB
Buffers:           760 kB
Cached:           6436 kB
SwapCached:          0 kB
Active:           6812 kB
Inactive:         2976 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        56984 kB
LowFree:          9460 kB
SwapTotal:          32 kB
SwapFree:           32 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:           7208 kB
Slab:             3476 kB
CommitLimit:     28524 kB
Committed_AS:     7848 kB
PageTables:        368 kB
VmallocTotal:  1048560 kB
VmallocUsed:       696 kB
VmallocChunk:  1047804 kB

¡Sí, un Linux con entorno BusyBox! Eso simplificaba mucho las cosas. Por otra parte, un procesador MIPS es buena cosa también. Habría sido mejor un ARM, sin duda, pero éste también está bastante bien soportado. Sin embargo, lo que no me cuadraba era la memoria: ¿sólo 57MB de RAM y sin Swap? Un poco raro. De hecho, esa falta de memoria podría tener algo que ver con los cuelgues.

Al principio sospeché que el sistema podría ser un uClinux, el cual, al ser para sistemas sin MMU, no puede utilizar Swap. Pero por otro lado, hasta donde yo sabía, todos los micros MIPS llevan gestor de memoria, por lo que no tenía mucho sentido.

Decidí echar un vistazo al sistema de archivos para ver si podría probar a crear una partición de Swap que aliviase el escaso margen de memoria, y entonces apareció la segunda sorpresa:

/ # fdisk /dev/hda

The number of cylinders for this disk is set to 121601.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
 (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/hda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

 Device Boot    Start       End    Blocks   Id  System
/dev/hda1               2          21      160650   82  Linux swap
/dev/hda2              22          41      160650   83  Linux
/dev/hda3              42      121581   976270050    7  HPFS/NTFS

¡Ya había una partición de Swap definida! ¿Pero por qué no la usaba? Probé a activarla a mano con swapon /dev/hda1 pero sólo conseguí un mensaje de error. Sospechando que algo raro pasaba con ella, decidí hacer un volcado a mi ordenador de sobremesa y examinarla con Ghex2 (un editor hexadecimal) para ver qué contenía, no fuese a ser una partición de datos con un tipo incorrecto. La sorpresa fue mayúscula cuando descubrí ¡que estaba completamente a cero! La partición de Swap no estaba formateada, y por eso no la reconocía el sistema como tal.

Mi primer impulso fue formatearla manualmente, pero entonces recordé que en el menú Ajustes -> Sistema había una opción para formatear el disco. Decidí probarla a ver si también hacía algo con ésta, y así fue: después de ordenar el formateo desde el menú del disco multimedia, no sólo se borró la partición principal, sino que formateó también la partición de Swap y la montó correctamente. Sin embargo, la interfaz web había desaparecido, y en su lugar sólo aparecía una página de demostración de CGIs.

¿Qué había pasado? Nada más terminar de formatear, el disco pregunta si queremos instalar BT/SAMBA, y nos da cinco escasos segundos para pulsar OK si queremos hacerlo. Yo me despisté, el temporizador venció, y no instaló nada. Así que decidí formatearlo de nuevo y esta vez estuve atento para pulsar el OK en el momento adecuado. Una vez hecho todo quedó perfecto: la interfaz Web apareció y el cliente BitTorrent funcionó perfectamente, sin cuelgues.

Así pues, si teneis un disco de este tipo y os da problemas, probad a formatearlo desde el menú principal. Con un poco de suerte puede ser que se solucione (pero no os olvidéis de copiar antes los archivos que tuvieseis en el disco duro multimedia, ya que se perderán por completo durante el formateo).

Dado que la entrada me está saliendo algo larga pararé aquí y seguiré con mis descubrimientos sobre el sistema de archivos, el entorno de desarrollo y otras hierbas en otra entrada.

Mono

Programación

A principios de verano surgió una agria polémica sobre la conveniencia o no de usar Mono (la implementación libre de los estándares ECMA-334 y ECMA-335) dentro de GNOME. El problema en buena medida venía dado por las diferentes opiniones sobre la libertad de Mono. Los que estaban a favor afirmaban que Microsoft había reconocido de manera explícita que renunciaba a denunciar a nadie por usar sus patentes sobre ambos estándares, mientras que los que estaban en contra afirmaban que dicho texto legal era lo suficientemente obtuso como para que no garantizase prácticamente nada, y que habría que abandonar por completo Mono, proponiendo algunos reemplazarlo por Vala. En su momento no escribí nada, en parte porque ya había suficiente polémica, y en parte por falta de tiempo, así que ahora que los ánimos están más calmados me gustaría dar mi opinión sobre una cuestión relacionada.

Para empezar, todo el mundo se centra directamente en si hay riesgo de que haya demandas por patentes a la hora de usar Mono. En ese punto no voy a entrar puesto que se trata de una cuestión legal y yo no soy abogado. Donde sí me gustaría entrar es en el tema de qué aplicaciones es razonable que se escriban en Mono (y, en realidad, en cualquier otro lenguaje que trabaje sobre un runtime, como Java o Python) y cuales deberían ir siempre en Vala.

Para presentar el problema me iré al caso de un viejo conocido de todo el mundo: Windows Vista. Tras su lanzamiento surgieron grandes críticas por su excesivo uso de memoria, lo que obligaba a instalar al menos 2GB para conseguir una fluidez equivalente a la de un Windows XP con 512MB.

Y ese es el problema de utilizar Mono, Java, Perl o Python en donde no se deben usar. Recordemos que el usuario utiliza un ordenador con un fin concreto: realizar un trabajo. Para ello utiliza un programa determinado: si quiere dibujar, utilizará un programa de dibujo; si quiere escribir una carta, utilizará un procesador de texto, etc. Una vez que ha terminado la tarea, cierra el programa (liberando los recursos utilizados) y abre otro para hacer otra tarea.

Por otro lado, tanto los usuarios como los programas necesitan de un sistema operativo que actúe como intermediario. Es importante recalcar que el sistema operativo, hasta cierto punto, debería ser transparente: el usuario no utiliza el sistema operativo para hacer sus trabajos, sino los programas concretos. Así pues, el sistema operativo debe ser parco en el consumo de recursos, pues éstos deben estar disponibles para los programas.

El problema surge cuando hacemos parte del sistema operativo en un lenguaje interpretado o que necesite una máquina virtual. En ese momento nos encontraremos con un consumo mayor de memoria y de procesador, lo que significa que está consumiendo recursos que no debería. Un ejemplo de esto sería programar applets de escritorio o extensiones del gestor de archivos utilizando Mono o Python, o demonios que se queden en ejecución en segundo plano durante toda la sesión. Sin embargo, una aplicación sí puede estar escrita en estos lenguajes porque, a fin de cuentas, es lo que el usuario quiere utilizar. Podría ser deseable que utilice menos recursos, pero ya no es algo tan crítico porque aquí sí estamos utilizando lo que, a fin de cuentas, nos corresponde. Y por aplicación incluyo aquí también aplicaciones oficiales de Gnome, como por ejemplo, Banshee o F-Spot. La clave está en si son programas que permanecen abiertos durante toda la sesión y consumiendo recursos, o son aplicaciones que el usuario lanza expresamente cuando quiere realizar una tarea y que cierra cuando ha terminado de hacerla, liberando los recursos que utilizó. No olvidemos que una aplicación se puede cerrar y volver a abrir, mientras que un applet o un demonio tienen que estar corriendo constantemente para cumplir su función.

¿Entonces debemos utilizar siempre C para realizar las aplicaciones de escritorio, complementos y demonios? Aparentemente sería lo deseable; sin embargo, tiene el grave problema de que programar en C no es tan cómodo, ni los programas son tan mantenibles, como programar con Python, C# o Java (por algo existen). Y es justo aquí donde Vala brilla con luz propia: al tratarse de un lenguaje de alto nivel, con gestión de memoria asistida y una biblioteca de funciones y componentes que crece día a día, simplifica la escritura y mantenimiento del código hasta el nivel de los otros lenguajes comentados; y al compilarse directamente a código nativo, sin necesidad de ningún runtime extra, el resultado es prácticamente tan bueno como si se hubiese utilizado C desde el principio. Por supuesto, Vala también se puede utilizar para escribir aplicaciones, pero considero que aquí ya es cuestión de preferencias, así que cada uno utilice lo que más le guste: Perl, Python, C, Vala, Mono, Lisp, Ook… Pero para partes del sistema operativo o del escritorio considero que sólo se debería utilizar Vala.

Y debo reconocer que consejos vendo pero para mí no tengo, porque una de mis aplicaciones (GtkPSproc) está escrita justo al revés: el programa principal, que sólo se lanza cuando el usuario quiere imprimir algo, y que lleva la interfaz gráfica y hace todo el trabajo, está escrito en C, mientras que un pequeño applet (que, por tanto, está ejecutándose desde que se inicia el escritorio hasta que se apaga la máquina) que se encarga de reenviar la impresión al programa principal, está escrito en Python. En mi defensa diré que la aplicación principal la escribí antes de aprender Python, y que escribir el applet en python fue una chapuza inicial que acabó quedando como definitiva (¿Cuela?).

Vala de plata

Programación, tutoriales

Hace un par de meses descubrí la existencia de Vala, un nuevo lenguaje de programación similar a C# pero con una característica muy interesante: en lugar de compilar directamente a código máquina o a código de una máquina virtual, compila a código C, usando GObject para implementar el sistema de clases y objetos. La gran ventaja de  esto es que permite crear bibliotecas y clases GObject sin necesidad de lidiar con la complejidad de este sistema, lo que, para los fans de Gnome nos resulta especialmente atractivo. También permite trabajar en un lenguaje moderno, lo suficientemente parecido a C# como para que casi no se note la diferencia, pero sin perder ni un ápice de rendimiento (lo siento, sigo sin creerme que un JIT consiga siempre mejores rendimientos, fuera de casos patológicos  y pruebas de laboratorio).

Otro detalle que me ha parecido fascinante es que simplifica mucho la gestión de memoria. Al contrario de lo que podría parecer, no utiliza un recolector de basura como el de Java, sino conteo de referencias. Lo interesante es que todo el proceso es muy transparente, pues el propio lenguaje se encarga de utilizarlo casi siempre. Así, un trozo de código como éste:

using GLib;

class cPrueba:Object {

}

int main() {

    cPrueba miObjeto,miObjeto2;

    miObjeto=new cPrueba();
    stdout.printf("Referencias: %udn",miObjeto.ref_count);
    miObjeto2=miObjeto;
    stdout.printf("Referencias: %ud %udn",miObjeto.ref_count,miObjeto2.ref_count);
    miObjeto=new cPrueba();
    stdout.printf("Referencias: %ud %udn",miObjeto.ref_count,miObjeto2.ref_count);
    return 0;
}

cuando se ejecuta, devuelve la siguiente salida por pantalla:

Referencias: 1d
Referencias: 2d 2d
Referencias: 1d 1d

Vemos que, cuando se hace la primera asignación, se crea un nuevo objeto de tipo cPrueba y se asigna a miObjeto, con lo que su contador de referencias es 1. Luego hacemos la segunda asignación. Como miObjeto y miObjeto2 son, realmente, punteros al mismo objeto (y apuntan, por tanto, a la misma zona de memoria), lo único que hace Vala es incrementar en uno el contador de referencias; por eso los contadores de referencias de miObjeto y miObjeto2 valen 2 en la segunda línea de la salida: porque en realidad son el mismo objeto, pero está referenciado por dos punteros.

Cuando, finalmente, asignamos un nuevo objeto a miObjeto, primero Vala libera el objeto al que apunta, lo que en la práctica consiste en decrementar su contador de referencias. Si en ese momento éste pasase a valer cero, entonces ese objeto quedaría huérfano (ningún puntero apunta a él), por lo que Vala procedería a destruirlo automáticamente, liberando su memoria; sin embargo, en este ejemplo eso no ocurre porque miObjeto2 está apuntando al objeto viejo, así que lo único que ocurre es que su contador de referencias pasa a valer 1. Por su parte, se crea un nuevo objeto de tipo cPrueba, apuntado por miObjeto, cuyo contador de referencias también vale 1, como vemos en la tercera línea de la salida.

Si observamos el código fuente generado (usando valac -C prueba.vala) su función MAIN queda como:

gint _main (void) {
    cPrueba* miObjeto;
    cPrueba* miObjeto2;
    cPrueba* _tmp0;
    cPrueba* _tmp2;
    cPrueba* _tmp1;
    cPrueba* _tmp3;
    gint _tmp4;
    miObjeto = NULL;
    miObjeto2 = NULL;
    _tmp0 = NULL;
    miObjeto = (_tmp0 = cprueba_new (), (miObjeto == NULL) ? NULL : (miObjeto = (g_object_unref (miObjeto), NULL)), _tmp0);
    fprintf (stdout, "Referencias: %udn", ((GObject*) miObjeto)->ref_count);
    _tmp2 = NULL;
    _tmp1 = NULL;
    miObjeto2 = (_tmp2 = (_tmp1 = miObjeto, (_tmp1 == NULL) ? NULL : g_object_ref (_tmp1)), (miObjeto2 == NULL) ? NULL : (miObjeto2 = (g_object_unref (miObjeto2), NULL)), _tmp2);
    fprintf (stdout, "Referencias: %ud %udn", ((GObject*) miObjeto)->ref_count, ((GObject*) miObjeto2)->ref_count);
    _tmp3 = NULL;
    miObjeto = (_tmp3 = cprueba_new (), (miObjeto == NULL) ? NULL : (miObjeto = (g_object_unref (miObjeto), NULL)), _tmp3);
    fprintf (stdout, "Referencias: %ud %udn", ((GObject*) miObjeto)->ref_count, ((GObject*) miObjeto2)->ref_count);
    return (_tmp4 = 0, (miObjeto == NULL) ? NULL : (miObjeto = (g_object_unref (miObjeto), NULL)), (miObjeto2 == NULL) ? NULL : (miObjeto2 = (g_object_unref (miObjeto2), NULL)), _tmp4);
}

(He omitido toda la parte de la definición GObject de la clase ejemplo porque no aporta nada). Vemos en las distintas líneas como cada vez que se hace una asignación de un objeto a una variable, primero se procede a liberar lo que hubiese en dicha variable utilizando una llamada a g_object_unref, para asegurarse de que el contador de referencias decrece correctamente. Luego llama a g_object_ref con la variable que se copia para incrementar su contador de referencias. Como vemos, este proceso automático nos simplifica la vida lo suficiente como para que nos podamos olvidar de la gestión automática de la memoria…

O casi, porque existe, al menos, un caso en el que no se cumple todo ésto: las listas. Sin embargo, tras buscar y rebuscar, encontré que es un bug en Vala, así que ya está reportado (http://bugzilla.gnome.org/show_bug.cgi?id=586577) y debería estar corregido en breve, asi que no añadais una llamada a unref a mano, sino simplemente esperad a que lo corrijan y recompilad para eliminar el memory leak.

Existe, de todas formas, una opción alternativa, que es utilizar LibGee y su ArrayList. Este tipo de listas no tiene el bug que comento, por lo que, si se utiliza, no hay riesgo de memory leaks.

Pese a todo, es importante señalar un par de detalles sobre las listas de Glib en Vala: si vemos la documentacion, hay varias formas de declararlas, en concreto:

  • var milista = List<contenido_de_lista>();
  • List<contenido_de_lista> milista = List<contenido_de_lista>();
  • List milista = List<contenido_de_lista>();

Siendo contenido_de_lista una clase de elementos que contendra la lista. Asi, si quiero hacer una lista de strings la definiria como List<string>.  La cuestion es que, en base a las pruebas que he hecho, solo se realiza gestion de memoria si la lista se define como en la primera o la segunda opcion, porque solo ahi el compilador podra estar seguro de que el contenido es una clase derivada de Object y tiene, por tanto, contador de referencias. Si definimos la lista como en el tercer caso no se realizara gestion de memoria, por lo que podriamos incluso encontrarnos con que metemos en una lista global un elemento definido localmente y que, al terminar la funcion en donde se definio dicho elemento y volver a la funcion principal, dicho elemento es liberado, consiguiendo un hermoso core dump en cuanto intentemos acceder a dicho dato en la lista. Por tanto, mi consejo es utilizar siempre listas bien definidas, salvo que se sepa perfectamente lo que se esta haciendo.

Gemelos

Sin categoría

Acabo de lanzar dos nuevas versiones de mis programas.

El primero es HTMLProc. Al principio sólo iba a corregir el uso de os.Popen2 (está obsoleto en Python 2.6), pero al probarlo descubrí que sólo añadía el tamaño a las imágenes añadidas en las páginas principales, pero no en las imágenes de las páginas añadidas con el comando include. Ya está corregido y aproveché para subir de nuevo todas las páginas corregidas.

El segundo es DeVeDe. La lista de cambios está en su sección, así que poco voy a comentar, salvo un par de detalles:

  • Ahora permite reempaquetar un fichero sin recomprimir: ésto es muy útil para ficheros VOB, los cuales están en formato MPEG-2 y, por tanto, en teoría deberían poder utilizarse «tal cual» con DeVeDe. Por desgracia, si se usan activando la opción «Este fichero ya está en formato MPEG-PS» DeVeDe falla. La razón es que es un PS con algunos campos extra, lo que hace que DVDAuthor se lie y falle. Al activar esta opción, DeVeDe extrae el audio y el vídeo y los vuelve a meter en un PS, pero sin recomprimirlo, simplemente copiandolo; de esta manera no tiene campos extra, y además no se pierde ni un ápice de calidad porque no se está descomprimiendo y volviendo a comprimir.
  • Elimina ficheros viejos en caso de que existiesen previamente, al usar LN: si se hacía una previsualización de un fichero con la opción «Este fichero ya está en formato MPEG-PS» y se cancelaba la conversión, nunca se borraba el enlace, por lo que si se intentaba hacer otra previsualización, fallaba.
  • Ahora soporta ficheros de subtítulos cuyos nombres contengan caracteres reservados en XML: en efecto, antes, si un nombre de fichero de subtítulos tenía un caracter específico de XML, DeVeDe fallaba.
  • Ahora ya no se cuelga al añadir un vídeo en un formato desconocido: en versiones anteriores, cuando se añadía un vídeo en un contenedor conocido pero con un codec desconocido, al intentar obtener los parámetros del vídeo (tamaño, tasa, etc) MPlayer lanzaba una gran cantidad de mensajes de error que saturaban la salida de error, lo que hacía que DeVeDe se colgase. Un ejemplo es un fichero FLV de Flash: el contenedor es reconocido por MPlayer, pero el contenido no.

Que lo disfruteis con salud.

Con gettext y a lo loco

Programación

Hoy estaba preparando la nueva versión de DeVeDe para enviarla a los traductores y, cuando ejecuté el script para actualizar los ficheros de cadenas salió un error: no podía encontrar el fichero devede.glade. Obvio, porque había cambiado a GtkBuilder, así que quité el fichero en POTFILES.IN y añadí todos los nuevos. Sin embargo, me encontré con que ahora no encontraba ni la mitad de las frases.

Una rápida búsqueda en google me dio la solución: por defecto, intltool-update confunde los ficheros .ui de glade con descripciones ui de Bonobo. Para solucionarlo no hay más que añadir la cadena [type: gettext/glade] antes de cada nombre de fichero de glade en POTFILES.IN.

Microerrores

Sin categoría

Acabo de sacar una microrevisión de DeVeDe, la 3.13.1, en donde corrijo un par de fallos… fallitos… despistes realmente.

Para empezar, ahora ya se puede grabar la estructura del DVD (faltaba una w al crear la ventana). Por otro lado, la ventana de propiedades de un título se cerraba cada vez que se cambiaba la acción. Ambos fallos debidos a la migración a GtkBuilder. Por último, he corregido un detalle que impedía copiar la fuente de letra para subtítulos cuando se instalaba desde un paquete DEB, con lo que si nunca se había ejecutado antes, no se podía utilizar.

A disfrutarlo.

De uno a otro confín

Sin categoría

Hoy voy a poner una bonita foto que hice hace unos días, a ver qué os parece:

Si pinchais sobre ella la podreis ver a tamaño real (8192 x 1616 pixels).

Esta panorámica de Vigo la hice a partir de cinco fotos, uniéndolas luego con Hugin, un programa libre específico para este tipo de tareas. El proceso fue prácticamente automático, no tuve que tocar nada. Es cierto que si uno se fija, puede ver un par de zonas en donde se nota un poco la unión, pero también ha influído el hecho de que no sólo roté la cámara, sino que también me tuve que desplazar por las características del sitio desde donde las saqué.

La licencia de uso de esta foto es Creative Commons BY-NC-SA: Creative Commons License
Esta obra está bajo una licencia de Creative Commons

Mal número si no crece

Nueva versión

Me refiero, obviamente, a la versión 13 de DeVeDe, que estaba terminada y prometida desde finales del mes pasado. No la publiqué antes no sólo por movidas personales, sino también porque necesita de la versión 2.16 de GTK, que sólo está disponible en la nueva Ubuntu.

Los cambios son pequeños, muy pequeños: para empezar, unas correcciones en la traducción a griego, y por otro lado la comentada migración de LibGlade a GtkBuilder.

En la próxima versión quiero hacer algunos cambios internos en el código que convierte los archivos, para que sea más sencillo añadir nuevos formatos de salida. También espero añadir nuevas opciones, como por ejemplo permitir hacer DVDs sin menú principal, o añadir por defecto ficheros de subtítulos que haya en el mismo directorio que una película, para poder hacer más cosas con un simple Arrastrar y Soltar. También quiero retocar un poco más la interfaz para que sea más utilizable en equipos con pantallas pequeñas (como los netbooks).

¡Que la disfruteis!

Ubuntu y el Asus F5GL

Trucos, tutoriales

Actualizado el fichero de prioridades. Finalmente conseguí hacer que el Asus F5GL de mi amigo funcione como es debido. Para ello, ha «bastado» con instalar la versión 9.04 (la actual estable) y añadir el núcleo de la versión 9.10, con el correspondiente sistema de pinning para que se actualice pero sin tocar nada del resto del sistema. Para los que tengan el mismo problema, explicaré cual es el proceso:

Seguir leyendo Ubuntu y el Asus F5GL →