jump to navigation

Adecentando mi Android 9 agosto 2011

Posted by Jesús in Android, Informática.
add a comment

Hace ya tiempo que me compré mi (entonces) flamante Samsung Galaxy Spica y, aunque la verdad es que Android me gusta mucho como sistema operativo, la instalación que venía de serie tenía una serie de carencias que, sin ser fatales, tocaban un poco las narices, la verdad:

  • La versión de Android es la 2.1, sin posibilidad de actualización oficial. Eso implica no poder instalar aplicaciones a la SD, no tener soporte JIT (y por tanto mucho mejor rendimiento), así como problemas con programas nuevos que ya empiezan a pedir Froyo (2.2) como mínimo.
  • Algunos programas están instalados a piñón, sin posibilidad de desinstalación (Twitter, Facebook, el vomitivo launcher por defecto). Teniendo en cuenta que el Spica no va muy sobrado de espacio, no hace ninguna gracia.
  • En general, no se pueden hacer bastantes cosillas por no tener acceso root.

Al final, y después de casi un año de usar el móvil tal cual lo compré, me lié la manta a la cabeza y, siguiendo las instrucciones de los foros de HTC Mania, le hice unas cuantas cosas:

  1. Rootearlo: Esto quiere decir cambiarle el kernel (Android en el fondo es un linux) por otro que permita acceder como superusuario y deje hacer muchas más cosas (tocar la velocidad de la CPU, controlar procesos de sistema, y otras muchas cosas).
  2. Cambiarle la ROM por una Samdroid con Froyo. Samdroid es una de las ROMs más conocidas para el Spica, y pretende (al contrario que CyanogenMod, que es la otra más famosa) mantener lo máximo posible el sistema operativo original. Me daba un poco de repelús eso de poner Froyo, ya que no es oficial y todo son alfas y betas, pero la verdad es que el resultado es muy estable.
  3. Cambiar el sistema de ficheros de RFS a EXT2. RFS es un sistema de ficheros de Samsung que por lo visto es lento como el caballo del malo. Cambiar a EXT2 es tan fácil como arrancar Samdroid en modo recovery, y seleccionar la opción pertinente.

¿El resultado? Pues lo que más se nota es la mejora de rendimiento, que con el tema del JIT y la conversión a EXT2 es bastante notable, y va todo mucho más fluido. Además, al tener Froyo puedo instalar programas a la SD, que va de maravilla dado el escueto espacio del Spica, y por fin me he quitado de encima todos los programas de morralla que venían con la instalación de Android de Samsung, que ocupaban lo suyo. Y por lo que respecta a la duración de batería, de momento me parece que viene a durar lo mismo, aunque ahora que puedo juguetear con la frecuencia de la CPU gracias a ser root, creo que aún hay margen para mejorar.

En definitiva, pasar por todo el proceso me parece muy recomendable para cualquiera que tenga el Spica. El proceso es sencillo, está muy bien explicado, y el resultado es completamente estable. Es casi como estrenar móvil nuevo.

¿Por qué nadie optimiza los PNGs? 20 agosto 2010

Posted by Jesús in Informática.
add a comment

Hace ya bastante tiempo que conozco una herramientita muy útil, llamada OptiPNG, que se dedica a recomprimir un fichero PNG probando diferentes valores para los parámetros de compresión, con la idea de reducir el tamaño del fichero. La cosa tarda un tiempo variable (en función del tamaño del fichero y la exhaustividad de las pruebas), pero al final casi siempre consigue una reducción del fichero de entre el 10% y el 30%.

Así las cosas, uno pensaría que este tipo de utilidades sería usado de forma masiva en la web, al fin y al cabo una reducción del 30% en el tráfico no es moco de pavo. Pues justo estaba hoy mirando una viñeta de la (excelente) tira Cyanide & Happiness, cuando me ha dado la impresión de que la imagen tardaba en cargarse. Ya sé que, con las conexiones de hoy en día, el tamaño de un fichero así es ridículo, y que la culpa casi seguro que es más de la conexión o el hosting, pero me ha dado por bajarme el PNG de la tira (72 KB) y pasarle el OptiPNG (con un simple “optipng -o7 fichero.png”). ¿El resultado? Un fichero de 44 KB, casi un 40% menos, y todo en 10 míseros segundos.

De acuerdo que estamos hablando de menos de 30 KB, pero en una tira con el número de seguidores que tiene Cyanide & Happiness, la cosa no es tan irrisoria. No he encontrado la cifra exacta en la web, pero veo que pone que tiene unos 250.000 seguidores en Facebook. Suponiendo que hay una tira cada 3 días (10 al mes), y que toda esa gente se la descarga, estamos hablando de un ahorro de tráfico de 70 GB al mes, que no es moco de pavo, y sólo por pasarle a un PNG  un programa que tarda 10 segundos.

Puedo entender que al que suba las imágenes se le olvide y/o le dé pereza andar procesando imágenes, pero es algo que se podría automatizar de mil maneras. Sólo por decir dos, se podría integrar la optimización en las subidas de ficheros de los gestores de contenidos, o también se podría hacer mediante una tarea cron que, por las noches, recorra y procese los ficheros alojados recomprimiendo lo que haga falta.

Pese a las ventajas y a la simplicidad del método, parece que a la gente le sobre el ancho de banda (y el dinero), y no se hace. En fin, cada cual tendrá sus motivos, pero para aquellos que tengan problemas de tráfico en sus webs, igual no está de más una pasadita por sus PNGs, igual se consigue aliviar la cosa.

Me han hackeado mi cuenta GMail 23 julio 2009

Posted by Jesús in General, Informática.
add a comment

Desde hace unos días he empezado a recibir algunos mails muy extraños en mi cuenta de GMail. Son básicamente errores que aparecen cuando el destinatario de un mensaje no existe y el mail rebota, y tenían asuntos como “Delivery Status Notification”, y el origen era Mail delivery subsystem.

Esto en sí no tiene por qué ser un problema, al fin y al cabo podía ser que yo le hubiese enviado un mail a alguien y me hubiese equivocado con la dirección, o algo así. Pero el volumen de mensajes (como 20 al día) y, sobre todo, su contenido (mensajes en chino, y a direcciones desconocidas para mí) me hizo sospechar que podría estar pasando algo.

Buscando buscando, he descubierto que GMail tiene una opción para ver la actividad reciente en la cuenta. Concretamente, hay que ir a la parte inferior de la ventana, y pulsar aquí:

info_detallada

En la pantalla que aparece al clicar, se empiezan a ver cosas raras:

detalle_actividad

En primer lugar, aparece que sólo tengo una sesión abierta. Bien. Pero después, cuando miro la actividad reciente, empiezo a ver accesos extraños, por ejemplo un acceso por SMTP hecho a las 6:50 de la mañana, cuando yo estaba durmiendo plácidamente (bueno, con el despertador a punto de sonar, pero definitivamente no mirando el correo). La IP que figuraba en estos accesos tampoco me sonaba, y buscando en alguna de las múltiples páginas de WHOIS, me sale que es de alguien de China.

En definitiva, que me han hackeado la cuenta, y la están utilizando para enviar spam, de ahí que me lleguen los mensajes rebotados de sus pobres víctimas. ¿La solución? En primer lugar, cambiar la contraseña de la cuenta. Otra opción que recomiendan es activar el cifrado HTTPS en las opciones de GMail, ya que estas cosas pueden pasar cuando se está mirando el correo en un entorno inseguro, como una conexión wireless o un cyber.

A ver si con estos cambios la cosa se arregla, porque la verdad es que he tenido suerte. Buscando en Internet casos similares, hay muchas historias para no dormir, y me podrían haber cambiado el password, borrado mails personales o enviado mails ofensivos en mi nombre, entre muchas otras cosas.

Progresando, que es gerundio 23 marzo 2009

Posted by Jesús in Informática, Linux.
1 comment so far

Hace un tiempo considerable, comentaba por aquí mis peripecias para conectarme a Internet usando el móvil. Aunque el proceso no era nada del otro mundo, implicaba ejecutar comandos de consola y editar oscuros ficheros de texto.

Unos meses y unas cuantas versiones de Ubuntu después, pruebo a hacer lo mismo y, antes de que me dé tiempo de abrir la consola y empezar con la magia negra, me aparece una ventanita en la que me dice que ha detectado mi móvil. Aunque se equivoca con el modelo, me muestra un asistente que, en dos clics, me pregunta qué operador tengo y algún detalles más, y en 30s ya estoy navegando. Más fácil imposible y, dicho sea de paso, mucho más sencillo que en Windows.

Va a ser verdad que vamos hacia adelante…

Conectando a Yoigo desde Ubuntu con un Samsung l760 27 junio 2008

Posted by Jesús in Linux.
Tags: , , , , , ,
6 comments

(Actualización: La cosa se ha puesto bastante más fácil en las últimas versiones de Ubuntu…)

Desde que me pasé a Yoigo llevaba buscando la manera de conectarme a internet usando el propio móvil, muy útil cuando se está con el portátil en algún lugar sin cobertura wifi, y que además sale muy bien de precio con las tarifas de Yoigo (1,2 eur/día como máximo). Desde windows es muy fácil, basta usar el programa que viene con el móvil (creo), pero desde linux la cosa es algo más enrevesada y sólo encontraba instrucciones específicas para otros modelos de móvil como el Nokia N70 o el Sony-Ericsson V800, pero no para mi Samsung l760.

Después de cacharrear un poco, finalmente he conseguido conectar. El proceso es muy parecido al de los otros móviles, pero cambian un par de sutilezas. En primer lugar hay que tener instalado el wvdial (si no, aptitude al canto). Una vez instalado, hay que conectar el móvil mediante su cable USB, y ejecutar sudo wvdialconf. Esta utilidad buscará el móvil, y generará una configuración básica para wvdial. A continuación la editamos (/etc/wvdial.conf), y hacemos que quede más o menos así:

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,”IP”,”internet”
Modem Type = USB Modem
Baud = 460800
New PPPD = yes
Modem = /dev/ttyACM0
ISDN = 0
Phone = *99***1#
Username = “internet”
Password=”internet”
FlowControl=NOFLOW
Stupid mode = 1
Compuserve=0
Auto DNS=1
New PPPD=yes

En realidad hay muchas cosas que no sé si son necesarias o no, ya que las iba añadiendo a base de prueba y error. Creo que son importantes las líneas de Init3, y la de Phone (que, a diferencia de otros móviles, necesita un 1 en vez de un 3).

Ahora sólo queda probar, ejecutando sudo wvdial. Si no se queja y empieza a mostrar mensajes de ppp, es que la cosa ha ido bien, y ya debería funcionar el acceso a internet. Una precaución adicional es, antes de ejecutar wvdial, desactivar el resto de interfaces de red que pueda haber en el sistema (eth0, eth1, etc., vamos, todas excepto lo) haciendo sudo ifconfig xxx down de cada una. De esta manera, cuando ejecutemos wvdial será la única interfaz, y ya se configurarán correctamente la puerta de enlace, DNSs y demás.

La velocidad de navegación es bastante correcta, a unos 30-40 KB/s que, sin ser una maravilla, cumple perfectamente para sacar de un apuro. También me falta comentar que mis pruebas las he hecho conectando el móvil directamente por USB mediante el cable que viene. Seguro que también se puede hacer por bluetooth, pero aún no lo he probado.

Configurar un stick USB para ver la TDT en Linux 9 diciembre 2006

Posted by Jesús in Informática, Linux.
10 comments

El otro día, después de mucho tiempo rondándome la cabeza lo de ver la TV en el ordenador, me compré por fin un stick USB para sintonizar canales de la digital terrestre. Como soy linuxero desde hace ya bastante, un tema que me preocupaba era que el bicho estuviese soportado, por lo que consulté previamente en LinuxTV.org, y finalmente me compré un Redbell TDT-2Go por 40 y pocos euros.

Teniendo en cuenta que las distros de linux últimamente hacen ya muchas filigranas, yo me esperaba que el proceso sería simplemente enchufar el cacharro, y mi flamante Ubuntu Dapper se encargaría de todo… Pues mi gozo en un pozo, al enchufarlo apenas si sale una línea en el registro del sistema, diciendo que hay un nuevo dispositivo USB, y listos, nada más. Después de investigar un poco he conseguido hacerla marchar, y para facilitarle la vida a alguien que esté en la misma situación pongo a continuación los pasos a seguir. Básicamente, todo está explicado aquí, pero bueno, lo re-explico un poco adaptándolo a mi caso:

  1. Preparar el sistema. Como los drivers DVB, que al estar muy activamente desarrollados cambian bastante y casi seguro que la versión que tengamos no sirve. Para ello, conviene bajarse el último snapshot CVS, sólo que esta gente no usa CVS sino un tal Mercurial. Por tanto, lo primero es instalarse el Mercurial y alguna cosilla más (porque también va a tocar compilar). En Ubuntu, sería simplemente aptitude install mercurial linux-headers-$(uname -r) build-essential.
  2. Bajarse la última versión de los drivers haciendo un hg clone http://linuxtv.org/hg/v4l-dvb
  3. Compilarla e instalarla, con make y make install (este último como root o con sudo, of course).
  4. Ahora ya tenemos los drivers puestos, pero resulta que estos cacharrines también necesitan un firmware. No hay problema, podemos consultar qué firmware lleva nuestro trasto aquí, y bajárnoslo de aquí o aquí. Al que se líe y no tenga claro cuál escoger, que no se preocupe, el propio driver se queja si no encuentra el firmware, y lo indica en el log de sistema. Una vez lo tengamos en nuestras manos, hay que copiar el firmware a /lib/firmware (al menos en Ubuntu, en otras distros puede ser otro sitio).

Y con esto está todo. Un reinicio por si las moscas, y ahora al insertar el cacharrín debería reconocerlo y cargar el firmware correspondiente. Eso normalmente hace que se encienda alguna lucecita, pero en todo caso podemos hacer un cat /var/log/syslog para ver exactamente los mensajes que emite el driver, por si hubiese algún error.

Ahora que ya funciona, al abrir, por ejemplo, kaffeine debería preguntarnos cuatro cosas sobre el aparato (como la zona en la que vivimos, etc.) y permitirnos buscar canales y, por supuesto, verlos 🙂 .

En fin, que bien está lo que bien acaba, pero no dejo de estar un poco decepcionado de, a estas alturas, tener que recurrir a estos trabajos de fontanería para hacer funcionar algo que, en Windows, se hace con tres clics de los de  Siguiente->Siguiente->Siguiente. Y tampoco es que haya nada propietario de por medio que impida que las distribuciones lo automaticen todo, ya que todos los drivers son libres, pero bueno, a ver si se ponen las pilas y en la Ubuntu 8.xx lo hacen ya automático…

Montando un servidor de ficheros y P2P con un Linksys NSLU2 1 diciembre 2006

Posted by Jesús in Informática, Linux.
1 comment so far

Hasta hace no mucho, creo que mi configuración informática era bastante estándar: un ordenador encendido todo el día, más que nada para poder bajar cosas del eMule (aMule en mi caso), que es un tanto remolón y requiere de su tiempo para funcionar bien, y que también hacía de servidor de ficheros para otros PCs de la red. Ahora bien, un ordenador promedio consume en torno a los 100-150W, por no hablar del ruido que hace. Así las cosas, empecé a plantearme si no podría usar un ordenador chiquitín simplemente para servir ficheros y tener el aMule, reduciendo el consumo y el ruido. Investigando un poco, vi que había diferentes direcciones por donde tirar:

  1. Montar un ordenador a propósito para eso. En realidad es lo que ya tenía, o sea que no.
  2. Montarse un ordenador de muy bajo consumo, por ejemplo con un Via C3 (que no necesita ni ventilador). El problema es que sale algo caro, y requiere cacharrear bastante.
  3. Usar un dispositivo específico… o más o menos

Al final tiré por esta última, y me compré un Linksys NSLU2. No es que sea un ordenador de propósito general, sino que más bien es un servidor de ficheros al que se le enchufa un disco duro USB y permite acceder remotamente a ellos por Samba/NFS. Aunque no sea un ordenador genérico y lleve su propio firmware, es posible instalarle linux y cacharrear todo lo que se quiera. Además, tiene un tamaño ínfimo (algo así como una caja de CD) y apenas consume 9W.

Por tanto, me puse manos a la obra y, siguiendo estas instrucciones, le instalé una Debian a la criatura. Una vez instalado el sistema operativo, y gracias a las bondades de apt-get, instalar un servidor de ficheros y el aMule fue cuestión de, literalmente, dos comandos, por lo que la cosa es bastante fácil. Eso sí, me aseguré de instalar la versión no gráfica de aMule, ya que total no iba a instalar ningún entorno gráfico y tampoco es que el NSLU2 tenga recursos como para desaprovechar memoria.

¿Las conclusiones del proceso? Primero las positivas:

  • El hecho de poder apagar el ordenador “grande” y aún así tener ficheros compartidos y aMule se agradece, tanto por el consumo por la disminución de ruido. Vale que el disco duro externo hace algo de ruido, pero lo que es el NSLU2 no tiene ni ventiladores ni nada, y hace el mismo ruido que, pongamos, un router (o sea, nada).
  • Al hacer tan poco ruido y gastar tan poco, se puede tener encendido las 24h, por lo que las cosas del aMule bajan mejor.

Pero no todo es bueno:

  • Al conectarse el disco duro externo a través de USB, el acceso es algo lento, no ya por el USB en sí (que con 480 Mbps más o menos da de sí), sino porque las transferencias USB requieren mucha CPU y no se pueden usar argucias tipo DMA como sí se hace con discos IDE. Así las cosas, la velocidad de transferencia está en los 3 MB/s, que es algo pírrico comparado con usar un disco IDE normal, pero bueno, salvo para copiar ficherotes grandes ya va bien.
  • El cacharro no anda sobrado de recursos, precisamente. La CPU es de 100 y algo MHz, aunque más o menos da de sí. Más problemática es la memoria, ya que sólo tiene 32 MB y el aMule va bastante justito. De hecho, si bien nada más arrancar va bastante bien, cuando lleva un rato el uso del swap es considerable, con el consiguiente aumento de ruido y el desgaste del disco duro. No estaría mal disponer de, por lo menos, 64 MB, pero la memoria no es actualizable, qué le vamos a hacer.

Para hacer aún más silencioso el aparatejo, hay quien instala el sistema operativo en un stick USB, de manera que al disco duro sólo se accede para escribir y cuando está swapeando. Llevando esto más allá, también se puede usar un stick USB para hacer swap, de manera que el ruido cesa casi totalmente. El problema es que los sticks USB tienen un número de ciclos de escritura limitados, por lo que haciendo swap en ellos duran poco. De todas formas, en mi caso, y teniendo en cuenta que tengo bastantes sticks tirados por ahí, tengo un cron montado de manera que de día hace swap al disco duro, y por la noche cambia al stick USB, que uno es sensible a los ruiditos para dormir :-).

En definitiva, estoy contento con resultado, aunque si volviese a empezar seguramente usaría otra cosa, con algo más de RAM y conexión IDE para los discos duros. Ahora mismo, creo que lo mejor sería una placa con un Via C3, que va a unos 500 MHz, tiene tanta RAM como le queramos poner, y un interfaz IDE normal y corriente. Lo malo es que, entre placa, caja y fuente, sale por unos 200-250 eur, cuando el NSLU2 cuesta 99 eur. Lástima que los señores de Linksys no se planteen un NSLU2++ o NSLU3 un poco más dopado…

Convertir PDFs a texto (o por qué los PDFs no son un buen formato para eBooks) 29 agosto 2006

Posted by Jesús in Informática, Libros, Linux.
add a comment

Siempre que se convierte un fichero PDF a texto, aparecen una serie de problemas que, aunque se pueden resolver, son francamente molestos. Básicamente son:

  • Problemas con la codificación de caracteres
  • Desastres con la maquetación: cada línea del txt de salida tiene un salto de línea manual al final, y otras lindezas como incluir encabezados y números de página entre el texto, etc.

Después de cacharrear un poco, me ha salido el siguiente proceso para tener un resultado aceptable:

1) Convertir a texto con el comando (linuxero, no sé en windows cómo iría la cosa):

pdftotext -layout -enc Latin1 -nopgbrk fichero.pdf

Así se creará un fichero.txt con la codificación de caracteres correcta (-enc), sin encabezados ni pies de página mezclados con el texto (-nopgbrk) y con una estructura parecida al fichero pdf original (-layout). Justamente esto último da muchos problemas, ya que, al respetar el maquetado original, añade saltos de línea a tutiplén que no deberían estar. Lo malo es que la alternativa (no poner el -layout) da como resultado un párrafo infinito, por lo que es preferible dejar que haga desastres con el maquetado y arreglarlos después.

2) Abrir el fichero de texto en nuestro editor favorito (que sea un poco potable, con expresiones regulares y tal, por ejemplo vi, kate u openoffice writer).

3) A partir de aquí la cosa depende de cómo haya quedado el resultado. El objetivo es el mismo en cualquier caso: identificar los saltos de línea “correctos” y marcarlos para distinguirlos del resto.

¿Cómo distinguir los saltos de línea “correctos”? Bueno, en muchos textos, la primera línea de cada párrafo tiene una sangría adicional, que en la conversión se habrá traducido a unos cuantos espacios más que el resto de líneas, que podemos aprovechar para distinguirlos. Otra forma es aprovechar que en muchas ocasiones se deja un espacio extra entre párrafos, que en el txt se convierte en saltos de línea adicionales. De esta manera, los saltos a conservar serán aquellos que aparezcan de dos en dos (uno el del párrafo, y otro el del espacio). En el peor caso (no hay manera de distinguirlos) se puede usar una regla no infalible pero que funciona bien en la mayoría de casos, que dice que un salto de línea correcto es el que va precedido de un punto (u otros caracteres como :, interrogantes, admiraciones y tal vez otras cosas).

Sea como sea, una vez sabemos cómo identificar el salto de línea que hay que conservar, lo sustituimos por una cadena arbitraria, por ejemplo INTROREAL. La idea es que si marcamos así todos los saltos de línea “buenos”, eliminamos el resto, y sustituimos estos marcadores que hemos añadido por un salto de línea, el resultado será un texto maquetado como toca.

4) Eliminar todos los saltos de línea innecesarios
Ahora toca quitar todos los saltos de línea, y aquí nos encontramos con una de las miserias del tratamiento de textos bajo linux. Lo ideal sería poder buscar todos los “\n”, sustituyéndolos por “” (o sea, nada), pero mucho me temo que las cosas no funcionan así.

La mayoría de editores de texto que he probado en linux funcionan línea a línea, lo cual quiere decir que, en búsquedas y demás, no se puede operar con textos en diferentes líneas. Esto hace que eliminar los saltos de línea sea algo más bien imposible, ya que en el tratamiento del texto línea a línea ya se da por implícito que la línea de texto es lo que va entre un intro y el siguiente, por lo que el intro en sí no se puede tocar. Así he visto que funcionan OpenOffice y Kate. Mi bienamado vi, por otra parte, si bien no tiene esta limitación, no parece muy optimizado para estas cosas, y en mi ordenador, a la que intento hacer algo así como eliminar todos los fines de línea, empieza a consumir memoria hasta que acaba con la RAM y el swap, por lo que no es muy usable que digamos.

Al final he resuelto la cosa escribiendo un mini-programa en Python (cómo me mola este lenguaje) que sustituye los saltos de línea de un texto por espacios. Al mismo tiempo, también va sustituyendo los marcadores que hemos puesto antes por un salto de línea, total, ¿para qué hacer las cosas dos veces cuando se pueden hacer de una vez? 🙂

import sys
import re

for l in sys.stdin:
	print re.sub("INTROREAL","n",l[:-1]),

El programa funciona a través de la entrada/salida estándar, por lo que se puede guardar con un nombre tipo quitaintros.py y ejecutar:

cat fichero.txt | python quitaintros.py > fichero_bien.txt

Y con esto ya estaría todo lo que se refiere al texto. Ahora faltaría idear alguna manera de arreglar los títulos de capítulo y demás, pero teniendo un poco de ojo se puede usar el mismo método (buscar algún rasgo que los distinga del resto del texto, y con un par de buscar/reemplazar bien puestos ponerlos como queramos).

Es verdad que es un poco trabajoso, pero el resultado final vale la pena. Lo triste es que recuerdo que en mis tiempos windowseros tenía automatizado todo esto como una macro de Word, pero mucho me temo que en el OpenOffice (dejando de lado el horrendo lenguaje de macros que tiene, que es tema para otro día), algunos de los pasos son imposibles de llevar a cabo, y hacen falta herramientas externas.

Moraleja: ¡No usar PDF para eBooks! La gracia de un eBook es poder adaptarlo a las necesidades de visualización de cada cual: unos querrán leer en pantalla, otros imprimírselo en A4, otros en A5, otros leer en un PDA… Esto requiere un mínimo de acceso al documento, que un PDF no da ni mucho menos y que obliga a hacer pirulas como las descritas arriba. Por tanto, es mucho más deseable, a la hora de trabajar con libros electrónicos, utilizar formatos como el ODT/DOC/RTF, HTML o el texto plano.

Hemos evolucionado 24 agosto 2006

Posted by Jesús in Programación.
add a comment

Desde hace tiempo, tenía la sensación de que en la programación no habíamos evolucionado mucho. Al fin y al cabo, hoy en día casi todo se sigue moviendo en torno a C++/Java y alguna cosilla más, lo cual no es muy diferente a cómo estábamos hace 4 o 5 años. Ahora bien, estos días he tenido que hacer un poco de flashback en mi forma de programar debido a mis cacharreos con la DS, y me he dado cuenta de que hemos evolucionado, y mucho.

Veamos un ejemplo práctico: para manejar imágenes en Python, basta hacer algo como:

import Image  

img=Image.open("fichero.png")
img.resize((640,480))
img.save("fichero_salida.png")

Fácil, ¿no? Pues bien, estos días intento hacer algo parecido en C pelado, y mirando la documentación de libpng, me sale que para abrir un PNG hay que hacer algo parecido a esto:

char header[8];	// 8 is the maximum size that can be checked

/* open file and test for it being a png */
FILE *fp = fopen(file_name, "rb");
if (!fp)
	abort_("[read_png_file] File %s could not be opened for reading", file_name);
fread(header, 1, 8, fp);
if (png_sig_cmp(header, 0, 8))
	abort_("[read_png_file] File %s is not recognized as a PNG file", file_name);

/* initialize stuff */
png_ptr = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL);

if (!png_ptr)
	abort_("[read_png_file] png_create_read_struct failed");

info_ptr = png_create_info_struct(png_ptr);
if (!info_ptr)
	abort_("[read_png_file] png_create_info_struct failed");

if (setjmp(png_jmpbuf(png_ptr)))
	abort_("[read_png_file] Error during init_io");

png_init_io(png_ptr, fp);
png_set_sig_bytes(png_ptr, 8);

png_read_info(png_ptr, info_ptr);

width = info_ptr->width;
height = info_ptr->height;
color_type = info_ptr->color_type;
bit_depth = info_ptr->bit_depth;

number_of_passes = png_set_interlace_handling(png_ptr);
png_read_update_info(png_ptr, info_ptr);
...

…y paro porque la cosa sigue un rato más (el que quiera el ejemplo entero lo puede encontrar aquí). Y esto es sólo para abrir el PNG, ni hablemos ya de empezar a procesarlo y demás.

En fin, que juro por la cobertura de mi móvil que no volveré a decir que la programación no evoluciona (y que el monstruo espagueti volador bendiga a los creadores de Python 🙂 )

Programando en la Nintendo DS 23 agosto 2006

Posted by Jesús in Programación.
9 comments

Como orgulloso poseedor de una flamante Nintendo DS, y asiduo lector de libros, una de las primeras cosas que me pasó por la cabeza al ver las dos pantallas que tiene fue “esto como lector de libros puede estar muy bien”. Después de mirar un poco a ver si alguien había pensado lo mismo y había hecho ya un lector de libros, vi que la cosa estaba muy verde aún, y como a veces me pega el punto de cacharrear con estas cosas, busqué un poco qué posibilidades de desarrollo en la DS hay hoy en día.

Pues bien, la cosa está bastante factible: hay un kit de desarrollo basado en software libre y creado por aficionados, que se puede instalar en Windows con un asistente de los de siguiente->siguiente y lo deja todo listo para empezar a programar (en linux es un pelín más complicado montar el tinglado, pero tampoco mucho). La programación se hace usando la librería PALib, que es bastante completita y está muy bien documentada, tienen un wiki con toda la documentación y un montón de tutoriales. El principal problema es que para ejecutar software casero hay que comprarse el típico copión, que se enchufa al slot de cartuchos de la DS y permite meterle ROMs en tarjetas SD. La verdad es que vale una pasta, pero entre las posibilidades de desarrollo que da, y que además permite probar los juegos antes de comprarlos, creo que merece la pena.

Lo que sí me ha sorprendido es lo fácil que es programar un trasto de estos. Yo me esperaba una cosa más a bajo nivel (ensamblador por un tubo, interrupciones y tal), pero resulta que toda la gestión de sprites, fondos, planos de scroll, música y demás la hace ya por hardware la consola, por lo que el programador se puede centrar en el juego en sí. Imagino que el esquema es similar a todas las antiguas consolas de 16 bits tipo Megadrive y Super Nintendo, pero como es mi primer contacto con estas cosas, me ha llamado la atención. De momento, en los pocos días que llevo trasteando, ya he podido mostrar texto por pantalla(s) sin problemas (en un programa de 15 líneas, mirad si es fácil), y aunque el soporte de texto en PALib es un poco precario, la DS promete como lector de libros. Si al final encuentro el tiempo y consigo sacar adelante algo usable, ya lo publicaré en alguna parte…