Mostrando entradas con la etiqueta howto. Mostrar todas las entradas
Mostrando entradas con la etiqueta howto. Mostrar todas las entradas

23 septiembre 2009

Configuración MMS e Internet en Nokia N85 con Simyo

El Nokia N85 lleva como sistema operativo Symbian OS v9.3 y como interfaz de usuario un S60 3rd Edition, Feature Pack 2, con lo cual, las opciones de configuración están algo cambiadas respecto a 3rd Ed original o el FP1. Estas instrucciones deberían servir para otros S60 3rd Ed. FP2.

Configuración de los MMS

Menu > Herramientas > Ajustes > Conexión > Destinos > Punto de acceso > Paquete de datos

En el paso "Punto de acceso", si os pide comprobar automáticamente si hay puntos de acceso disponibles, decid que "No".

05 septiembre 2009

Arreglando problemas de fuentes con Chromium en Ubuntu Jaunty 9.04

Problema: Si tenemos en Ubuntu seleccionada como fuente de aplicación la Bitstream Vera Sans, Chromium tendrá problemas detectándola y no se iniciará correctamente:


oleguer@imhotep:~$ chromium-browser
[7085:7085:2011175710:FATAL:/build/buildd/chromium-browser-4.0.207.0~svn20090904r25449/build-tree/src/app/gfx/font_skia.cc(90)] Check failed: tf. Could not find font: Bitstream Vera Sans


Este es un problema conocido y aunque lo han marcado como resuelto, a mi sigue sin funcionarme correctamente.

Solución: Hay que cambiar la fuente de aplicación de Gnome, por ejemplo a Devjavu Sans (yo he usado el estilo Book)

Menú Sistema -> Preferencias -> Apariencia -> Tipografías -> Tipografía para la aplicación

10 abril 2009

Arreglando audacity en Ubuntu 8.10 Intrepid Ibex

El paquete que trae Ubuntu 8.10 para audacity no funciona correctamente con el nuevo servidor de sonido PulseAudio: cuando se carga cualquier audio y se intenta reproducir, la barra de progreso se mueve, pero no se escucha sonido alguno por los altavoces. Y tratándose de un editor de sonido, pues no es plan... XD

Buscando por el internete, he encontrado otra versión del paquete de audacity empaquetada por un tal David Henningsson en su Launchpad's Personal Package Archives (PPA) que sí funciona.

Los pasos para instalar dicha versión son:

PASO 1: Añadimos el origen del PPA al final del sources.list. Para ello, abrimos este fichero con gedit, (como root) poniendo esta línea en la consola:
$ gksudo gedit /etc/apt/sources.list
Al final del fichero, añadimos esta línea, guardamos y cerramos gedit:
deb http://ppa.launchpad.net/diwic/ppa/ubuntu intrepid main

PASO 2
: Añadir las claves del PPA de David en nuestro sistema. Ponemos esta línea en una consola:
$ sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com F62476D8

PASO 3: Actualizamos los paquetes. Si usamos Synaptic sólo debemos abrirlo, darle al botón "Recargar" primero, luego a "Marcar todas las actualizaciones" y finalmente "Aplicar". Podemos abrir Synaptic desde el menú Sistema -> Administración -> Gestor de paquetes Synaptic o poniendo esto en la consola:
$ gksudo synaptic

PASO 4: Abrimos audacity, escogemos Editar -> Preferencias en el menú. Luego, vamos a la pestaña Audio E/S y escogemos el dispositivo ALSA: pulse dentro del recuadro Reproducción. Escogemos el mismo dispositivo en el recuadro Grabación.

Con esto deberíamos poder abrir cualquier audio soportado por audacity y escucharlo correctamente al reproducirlo.

06 marzo 2009

Instalar JMF 2.1.1 Linux Performance Pack en Ubuntu

Este tutorial es para la version 2.1.1e de JMF en su versión Linux Performance Pack (fichero con el nombre jmf-2_1_1e-linux-i586.bin).

Resulta que el instalador oficial no funciona correctamente en Ubuntu, dando el siguiente error:
Unpacking...
tail: no se puede abrir «+309» para lectura: No existe el fichero ó directorio
Extracting...
./install.sfx.30138: 1: cannot open ==: No such file
./install.sfx.30138: 1: ==: not found
./install.sfx.30138: 3: Syntax error: ")" unexpected
La solución es simple:

PASO 1: Bajamos el Java Media Framework de su web y lo guardamos por ejemplo en /home/usuario/jmf-2_1_1e-linux-i586.bin

PASO 2: Arreglar el instalador: a este le falta el parámetro "-n" al comando tail que usa internamente. Mejor usar sed que editores interactivos como vim o gedit, pues estos pueden alterar el instalador:
$ cd /home/usuario
$ cat jmf-2_1_1e-linux-i586.bin | sed 's/tail +309 $0 > $outname/tail -n +309 $0 > $outname/' > jmf-2_1_1e-linux-i586.bin.fixed 
PASO 3: Ejecutar el instalador arreglado concediéndole antes permisos de ejecución:
$ chmod u+x jmf-2_1_1e-linux-i586.bin.fixed
$ cd /directorio/donde/queremos/instalar/jmf
$ /home/usuario/jmf-2_1_1e-linux-i586.bin.fixed
Luego podemos pasar a configurar JMF siguiendo los pasos de este enlace (esta entrada cubre solamente el paso que falla 2: Run the Installation program to extract JMF to a directory).

30 octubre 2008

GPicView 0.1.10 en Ubuntu Gutsy

GPicView es un rápido visor de imágenes, bastante más rápido que el que incluye Ubuntu por defecto (eog). El problema es que en Gutsy no viene incluido en los repositorios -o yo no he sabido encontrarlo- y hay que instalarlo a mano.

Nos bajamos pues la última versión des de la web de gpicview, en mi caso la 0.1.10.

Primero hay instalar las dependencias para poder compilarlo:
$ sudo apt-get install libgtk2.0-dev

Y luego seguimos el proceso estándar de configure, make y make install (si faltaran más dependencias, configure nos lo indicaría).
$ tar xvzf gpicview-0.1.10.tar.gz
$ cd gpicview-0.1.10/
$ ./configure
$ make
$ sudo make install

Podemos ejecutarlo des de la consola con:
$ gpicview

También encontraremos un nuevo lanzador de la aplicación en el menú "Aplicaciones" > "Gráficos".

Si queremos configurar gpicview como nuestro visor de imágenes por defecto (con los tipos de imagen que tiene actualmente eog):
$ xdg-mime default gpicview.desktop `grep 'MimeType=' /usr/share/applications/eog.desktop | sed -e 's/.*=//' -e 's/;/ /g'`

¡Y listos!

13 julio 2008

Instalando Passenger (modrails) con Ubuntu 8.04 (aka Hardy Heron)

Voy a explicar los pasos que he seguido para instalar Passenger en Ubuntu 8.04, puesto que los "oficiales" que explica el instalador de Passenger no funcionan sin antes retocar algunos sencillos aspectos de la configuración de Apache.

Para empezar, doy por hecho que ya tenemos instalado en nuestro sistema los ingredientes previos necesarios, o sea Ruby, RubyGems y Rails. En caso contrario, sólo hay que seguir estos pasos (se explica para Ubuntu 7.10, pero imagino que no cambia casi nada para 8.04).

Paso 0: Evidentemente, debemos tener instalado Apache 2:
$ sudo apt-get install apache2
Paso 0,5: Además, necesitaremos las librerías de desarrollo de este, para que el instalador de Passenger pueda compilar el módulo:
$ sudo apt-get install apache2-prefork-dev
Paso 1: Instalar Passenger, con el "método fácil":
$ sudo gem install passenger
$ sudo passenger-install-apache2-module
Paso 2: Configurar Apache 2:
El segundo comando del paso anterior lanza el instalador del módulo de Passenger para Apache, que busca dónde está este, compila el módulo y lo instala. Además nos indica que debemos añadir las siguientes líneas al fichero de configuración de Apache, cosa que haremos con nuestro editor favorito y con permisos de root (el contenido de las líneas puede variar ligeramente):
$ sudo vim /etc/apache2/apache2.conf
Las lineas a añadir (al final del fichero) son:
# Passenger (modrails) module:
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.0.1/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.0.1
PassengerRuby /usr/bin/ruby1.8
Paso 3: Probarlo con una aplicación Rails que sea über-cool.
Creamos nuestra aplicación rails con:
$ rails /home/usuario/my_fantastic_blog
$ cd /home/usuario/my_fantastic_blog
$ rake db:create
$ rake db:migrate
Ahora tenemos 2 opciones: modificar la configuración del sitio por defecto que trae Apache en ubuntu (/etc/apache2/sites-available/default) creamos un virtual host aparte como nos recomienda el instalador de Passenger. Yo he optado por esta última opción (¡atención a poner como DocumentRoot el directorio public de nuestra aplicación Rails!):
$ sudo vim /etc/apache2/sites-available/my_fantastic_blog
Ponemos esto:
<VirtualHost 127.0.0.1:8000>
   ServerName localhost
   DocumentRoot /home/usuario/my_fantastic_blog/public
</VirtualHost>
Y creamos un enlace simbólico que le indica a Apache que el nuevo virtual host está disponible:
$ sudo ln -s /etc/apache2/sites-available/my_fantastic_blog /etc/apache2/sites-enabled/001-my_fantastic_blog
E indicamos que nuestra aplicación estará disponible en el puerto 8000:
$ sudo vim /etc/apache2/ports.conf
Añadiendo la línea Listen 8000 al fichero /etc/apache2/ports.conf de forma que quede tal que así:
Listen 80
Listen 8000
<IfModule mod_ssl.c>
   Listen 443
</IfModule>
Finalmente, recargamos la configuración de Apache y ponemos en el navegador la dirección http://localhost:8000 para ver nuestra flamante aplicación Rails corriendo con Passenger:
$ sudo /etc/init.d/apache2 force-reload

PD
: Con una prueba rápida (y para nada científica :) he comparado Passenger + Apache2 contra 1 único Mongrel (corriendo en el puerto 3000 y con entorno de producción) usando para ello la herramienta httperf y la configuración por defecto tanto de Mongrel como de Passenger y Apache, resultando que: modrails es la leche! XDD. Para ser justos, debería haber utilizado nginx + un cluster de mongrels, pero daba una pereza de configurar.... Se aprecia en los resultados que un único Mongrel simplemente no puede con tantas conexiones, de ahí los errores de timeout. El PC es un Pentium 4 HT @ 2.6 GHz, con 1 GB de RAM.

Resultados para mongrel:
$ httperf --port 3000 --rate 300 --num-conn 2700 --num-call 1 --timeout 5
httperf --timeout=5 --client=0/1 --server=localhost --port=3000 --uri=/ --rate=300 --send-buffer=4096 --recv-buffer=16384 --num-conns=2700 --num-calls=1
Maximum connect burst length: 4

Total: connections 2700 requests 2366 replies 2354 test-duration 13.031 s

Connection rate: 207.2 conn/s (4.8 ms/conn, <=752 concurrent connections) Connection time [ms]: min 1.6 avg 1250.2 max 7995.8 median 704.5 stddev 1265.8 Connection time [ms]: connect 716.3 Connection length [replies/conn]: 1.000 Request rate: 181.6 req/s (5.5 ms/req)
Request size [B]: 60.0

Reply rate [replies/s]: min 197.8 avg 199.9 max 202.0 stddev 2.9 (2 samples)
Reply time [ms]: response 537.9 transfer 0.0
Reply size [B]: header 197.0 content 7557.0 footer 0.0 (total 7754.0)
Reply status: 1xx=0 2xx=2354 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.68 system 11.69 (user 5.2% system 89.7% total 95.0%)
Net I/O: 1378.5 KB/s (11.3*10^6 bps)

Errors: total 346 client-timo 346 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
Resultados para Passenger:
$ httperf --port 8000 --rate 300 --num-conn 2700 --num-call 1 --timeout 5
httperf --timeout=5 --client=0/1 --server=localhost --port=8000 --uri=/ --rate=300 --send-buffer=4096 --recv-buffer=16384 --num-conns=2700 --num-calls=1
Maximum connect burst length: 1

Total: connections 2700 requests 2700 replies 2700 test-duration 8.998 s

Connection rate: 300.1 conn/s (3.3 ms/conn, <=3 concurrent connections) Connection time [ms]: min 0.1 avg 0.6 max 8.6 median 0.5 stddev 0.3 Connection time [ms]: connect 0.0 Connection length [replies/conn]: 1.000 Request rate: 300.1 req/s (3.3 ms/req)
Request size [B]: 60.0

Reply rate [replies/s]: min 300.0 avg 300.0 max 300.0 stddev 0.0 (1 samples)
Reply time [ms]: response 0.6 transfer 0.0
Reply size [B]: header 260.0 content 7557.0 footer 0.0 (total 7817.0)
Reply status: 1xx=0 2xx=2700 3xx=0 4xx=0 5xx=0

CPU time [s]: user 1.88 system 6.46 (user 20.8% system 71.8% total 92.6%)
Net I/O: 2308.2 KB/s (18.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0


Actualización
Acabo de encontrar este enlace donde explica este mismo procedimiento para Ubuntu 7.10 (eso sí, en inglés) junto con una bonita tarea de Capistrano que hace automáticamente un touch del fichero my_fantastic_blog/tmp/restart.txt (el cual reinicia la aplicación Rails) y además elimina el fichero my_fantastic_blog/tmp/public/.htaccess que según el puede causar problemas.

15 junio 2008

Una de rails: usando lockdown con JRuby (y Netbeans)

Ahora mismo estoy trasteando con RubyOnRails 2.1 + JRuby + Netbeans 6.1 creando una pequeña aplicación Rails para ver cuan diferente es el desarrollo con ruby nativo (MRI) vs. JRuby. La idea es que esta aplicación funcione en un servidor de aplicaciones Java via JRuby.

Por otro lado, una parte fundamental de las aplicaciones web es la autenticación de usuarios. Para ello he decidido aplicarme el principio de DRY (o no reinventar la rueda) y usar algun sistema ya existente para RoR. El elegido ha sido Lockdown (web anterior) pues su filosofía es simple: cierra el acceso a una aplicación Rails de forma global y permite dar determinados permisos a diferentes grupos de usuarios para realizar tareas concretas.

Y aquí viene el primer problema: el JRuby integrado en Netbeans utiliza un directorio propio para almacenar las gemas, de forma que las que tengamos instaladas en el ruby "nativo" del sistema no las podemos utilizar. Hay que instalar las gemas que vayamos a usar en el proyecto con la herramienta que encontraremos en el menú "Tools -> Ruby Gems" de Netbeans, asegurándonos que tenemos escogida la plataforma "Built-in JRuby" en el momento de la instalación.

Según el web de Lockdown, estos son los pasos para utilizarlo en un proyecto rails con ruby nativo:

$ sudo gem install lockdown
$ cd ~/code/rails/miproyecto
$ lockdown .
Como esto no nos sirve para el desarrollo con Netbeans, aquí van los pasos equivalentes:
  1. Instalar la gema lockdown en el JRuby de Netbeans: Abrir "Tools -> Ruby Gems", escoger la plataforma ruby "Built-in JRuby", ir a la pestaña "New Gems" e introducir en "Search" la palabra "lockdown" + la tecla intro. Seleccionar la gema "lockdown" de la lista de resultados y pulsar el botón "Install".
  2. Abrir una consola e ir al directorio del proyecto rails:
    • cd ~/code/rails/miproyecto
  3. Ahora la triquiñuela: ejecutar el lockdown instalado en Netbeans (averiguando antes dónde está instalado el Netbeans) con este comando:
    • PATH=/opt/java/netbeans-6.1/ruby2/jruby-1.1/bin:$PATH lockdown .
Si todo ha ido bien, veremos la siguiente salida en la consola:

------------------------------------------------------------
Installing Lockdown
create lib/lockdown
create lib/lockdown/session.rb
create lib/lockdown/init.rb
------------------------------------------------------------

------------------------------------------------------------
Modified config/environment.rb by adding:
require "lockdown/init"
------------------------------------------------------------

------------------------------------------------------------
You are now locked down. To open up access to your
application please modify lib/lockdown/init.rb. This is
where you'll add permissions and create user groups.

To modify the contents of your session and to add access
methods, modify lib/lockdown/session.rb.

For the wiki, news, forum and issue tracker please visit:

http://stonean.com/projects/show/lockdown

------------------------------------------------------------

Ahora hay que utilizar el generador que proporciona lockdown para crear sus controladores, modelos, vistas y migrations específicos. En teoría, el generador debería aparecer en Netbeans clicando con el botón derecho sobre el proyecto, opción "Generate..." y entonces bajo el desplegable "Generate:". Como a mí no me ha aparecido, he usado la consola (ojo a utilizar el jruby correcto!):

$ /opt/java/netbeans-6.1/ruby2/jruby-1.1/bin/jruby ./script/generate lockdown -all

Se ejecutan las migrations con: click botón derecho sobre el proyecto, opción "Migrate Database" -> "To Current Version" y se elimina el fichero de índice "public/index.html" creado por defecto por Rails.

Arrancamos el servidor (tecla F6 o icono del "play" en Netbeans), y ya podemos acceder a nuestra aplicación rails con las credenciales admin/password en la página de login que aparecerá.

Podemos ver los usuarios en http://localhost:3000/users, los grupos en http://localhost:3000/user_groups y los permisos en http://localhost:3000/permissions.

Y listo. Ahora sólo queda modificar el fichero lib/lockdown/init.rb creando permisos y grupos de usuarios de forma apropiada.

Para más detalles, consultar la documentación del generador de lockdown.

05 julio 2007

Instalar DBDesigner 4 en Ubuntu Linux (Feisty Fawn y Gutsy Gibbon)


DBDesigner 4 es un sistema de diseño visual de bases de datos que integra diseño, modelado, creación y mantenimiento de estas en un único entorno. Está pensado para crear bases de datos MySQL pero permite algunos sistemas comerciales como Oracle o SQLServer y -con ciertos trapicheos- es posible crear esquemas para otros SGBD libres como PostgreSQL.

Es un sistema de código libre (GNU GPL) y se pueden obtener sus ejecutables desde la web http://fabforce.net/dbdesigner4/, desde la que se ofrecen versiones para GNU/Linux y Windows.

Otra cosa es que estos binarios funcionen tal cual en GNU/Linux y... ¡Sorpresa! En Ubuntu no rulan por defecto. La única forma en que están estos empaquetados para Linux es en un fichero .tar.gz

Tras indagar un poco, estos son los pasos para hacer que el programa vaya como la seda:
  1. Descomprimir el .tar.gz con el programa en un directorio (se recomienda el directorio HOME para un sólo usuario y el directorio /usr/local/bin para una instalación de sistema).
    • $ cd ~
    • $ tar xvzf ruta/a/la/descarga/DBDesigner4.0.5.4.tar.gz
    • $ cd DBDesigner4
  2. Instalar paquetes con las librerías necesarias. En una consola, ponemos:
    • $ sudo aptitude install libxft1 libstdc++2.10-glibc2.2
  3. Con los dedos cruzados, probamos si funciona:
    • ./startdbd
  4. [Paso estético: cambiar fuentes del programa]
    • En el menú "Options -> DBDesigner Options" escogemos la pestaña "Visual Options" y cambiamos la fuente a, por ejemplo, Bitstream Vera Sans con 8 puntos en el desplegable "Application font".
    • En el menú "Options -> Model Options" escogemos la pestaña "General Options" y en el desplegable "Default Font" cambiamos la fuente a Bitstream Vera Sans.

En caso que no arranque el programa, podemos mirar el fichero de log que se creará en ~/.DBDesigner4/DBD4.log para ver qué problema hay.


ACTUALIZACIÓN: Instalación en Gutsy Gibbon

Es necesario bajar e instalar la libreria liborqt (adaptado de aqui):
$ wget ftp://fr2.rpmfind.net/linux/sourceforge/s/sk/skychart/libborqt-6.9.0-2.i386.rpm
$ sudo apt-get install alien
$ sudo alien libborqt-6.9.0-2.i386.rpm
$ sudo dpkg -i libborqt_6.9.0-3_i386.deb

Luego le indicamos al programa dónde encontrar la nueva libreria:

$ cd ruta/donde/hemos/descomprimido/DBDesigner4
$ cd Linuxlib
$ mv libqt.so.2 libqt.so.2.old
$ ln -s /usr/lib/libborqt-6.9-qt2.3.so ./libqt.so.2
En Gutsy ya no existe el paquete libxft1. En su lugar, se debe instalar el libxft2:

$ sudo apt-get install libxft2

Y crear un enlace simbólico que permite "camuflar" la libxft2 como si fuera la libxft1:

$ sudo ln -s /usr/lib/libXft.so.2.1.2 /usr/lib/libXft.so.1

Si con el paso anterior sigue sin arrancar el programa, intentamos esto:

$ cd ruta/donde/hemos/descomprimido/DBDesigner4
$ ln -s /usr/lib/libXft.so.2.1.2 Linuxlib/libXft.so.1

13 julio 2006

Instalando openSUSE 10.1 en Virtual PC 2004 SP1

Con la aparición de Virtual PC 2004 SP1 en su versión gratuita (que ¿casualmente? ha salido el mismo día que la versión estable de VMWare Server 1.0) me he decidido a darle una oportunidad. El VMWare Server me pareció en su momento demasiado lento, debido quizás a que era una beta.

La excusa era probar el programa Java que desarrollo en el curro en Linux, pues el desarrollo lo hago en el @#?* equispé. Con ello puedo trastearlo tanto en Win como en Lin sin tener que reiniciar el -un poco lento- sistema.

Pues bien, el primer candidato era Ubuntu 6.06 LTS, pero debido a un raro error en la instalación de este dentro del Virtual PC he decidido pasarme al lado oscuro de openSUSE 10.1.

He bajado la ISO del DVD de openSUSE (3.49 Gb descargados en 1 hora! Viva la manga, digooo banda ancha) y...

  • Primer fallo: el Virtual PC no lo quiere montar como imagen por no ser múltiplo de 2 el tamaño de esta... WTF! Mirando en la ayuda del programa (lo sé, algo que nadie hace y menos un informático ¬¬) he encontrado el problema: Virtual PC sólo acepta imágenes ISO de hasta 2.2 Gb. Vaya truño. ¿Qué le costaba a M$ llegar a los 4.7 Gb o a los 8 de un DVD normal/doble capa?
Estaba por borrar las imágenes de Ubuntu y openSUSE (esta me iba a doler) cuando se ha encendido la bombillita: en la ayuda no decía que la unidad física de DVD tuviera esa limitación. Vamos a grabarlo en un DVD pues!
  • Segundo fallo (este de mi PC del curro): No tengo ni grabadora de DVD's a mano ni tampoco lector de DVD's en el PC...
Esto si que era un problemón. Entonces se ha encendido la segunda bombillita del dia: con DAEMON Tools se puede crear unidades virtuales que montan imágenes ISO y se comportan como unidades de CD/DVD físicas. Mmmm... Podría funcionar. Aunque con dos emulaciones de DVD's (la que hace el DAEMON tools y la que hace el Virtual PC) la cosa tiene que ir leeeeeentaaa de c****es.

Efectivamente la cosa va algo lenta pero funciona, que es lo que cuenta. Ahora se está instalando el openSUSE dentro del VirtualPC. Lleva un buen rato "Evaluando la selección de paquetes".

RESUMEN PARA INSTALAR IMÁGENES ISO DE DVD'S EN VIRTUAL PC
1) Instalar DAEMON Tools 4 (gratuito). Si pide reiniciar, pues a reiniciar. De verdad, hacedme caso...
2) Instalar Virtual PC 2004 SP1 (gratuito, de momento no requiere registro ni validación del Güindows).
3) En DAEMON Tools montar la imagen ISO del DVD. Fijarse en qué unidad la monta (D:\, E:\, etc)
4) En Virtual PC crear una configuración de máquina virtual nueva. Indicar tipo de SO "other" si instalaremos algo que no sea de M$ (GNU/Linux, *BSD, etc).
5) Arrancar la configuración creada y cuando aparezca la ventana de esta hacer clic -rápidamente- sobre el menú "CD" y -ya no tan rápido- sobre "Use Physical Drive X:", sustituyendo X: por la unidad del paso 3). Con esto arrancará desde la imagen de DVD sin necesidad de que la tengamos que quemar en un DVD sobrevalorado por la aplicación de un canon injusto.