jump to navigation

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…

Anuncios

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.

Fallo de arranque en Ubuntu Dapper 23 agosto 2006

Posted by Jesús in Linux.
add a comment

Si esta mañana, al encender el ordenador, os habéis encontrado que la cosa no arranca, que no cunda el pánico. Por lo visto ayer actualizaron en los repositorios de Dapper el servidor X a una nueva versión, con tan mala pata que uno de los parches que incluía da problemas a muchos usuarios y les impide arrancar la máquina.

De todas formas, la cosa tiene fácil solución. En la pantalla negra que seguramente se habrá quedado, hay que pulsar alt+f1 (o f2, o f3…) para abrir una consola de texto. Iniciamos sesión con nuestro usuario, y ejecutamos los típicos aptitude update y aptitude dist-upgrade (o con apt-get, como prefiera cada cual). De esta manera, se actualizará el servidor X a la nueva versión ya arreglada, y con un ctrl+alt+supr volverá a arrancar el ordenador como si nada.

En fin, que final feliz y tal, pero tengo sentimientos encontrados sobre esto: no sé si quejarme de que la gente de Ubuntu no revise un poco los paquetes antes de subirlos a los repositorios (se supone que la Dapper es bastante estable), o bien alegrarme de la rápida respuesta y de las maravillas de la gestión de paquetes de las distribuciones basadas en Debian. Lo dejaremos en empate técnico por esta vez…