Primeras impresiones sobre Android

Esta semana he conseguido de nuestro proveedor habitual un teléfono HTC Hero para poder echarle un vistazo en serio a Android. Este teléfono viene con un Android 1.5, a la espera de Android 2.0 que se espera para finales de año.

¿Impresiones? Pues ciertamente IMPRESIONANTE. Hasta la fecha había hecho uso de smartphones basados en Windows Mobile 5 y 6, y ciertamente la diferencia con respecto a Android es espectacular. Cierto es que los operadores tienden a sobrecargar de aplicaciones absurdas y widgets inútiles sus smartphones, y en el caso de los HTC Diamond, por poner un caso, es realmente terrible. Pero incluso cambiando la ROM por una tuneada (que va mucho mejor que la original), al lado de este HTC Hero con Android palidecen.

Por un lado el rendimiento. No tiene absolutamente nada que ver. La fluidez de la interfaz, la velocidad de respuesta. Es otro mundo. Nada que enviar a los iPhone.

Por otro lado la interfaz. Clara, usable y muy lograda. Y eso que todavía pueden pulirlo más.

En cuanto al elenco de aplicaciones, a pesar de que el marketplace de Android todavía está lejos de la AppStore, las aplicaciones que empiezan a aparecer son muy curiosas. Lectores de código de barras, compresores, terminales de consola, etc, etc. Y todo lo que viene detrás.

Sobre trasteo del teléfono, he aprovechado para cambiarle la RADIO (firmware para GPS, 3G, batería, etc) y actualizar a una ROM más moderna de la propia HTC. Pero realmente el SDK de Android te permite hacer cualquier cosa con el teléfono, pudiendo logarte por consola y trabajar contra el linux que subyace como si de tu propio ordenador se tratara.

En fin, que la experiencia ha sido gratificante y por fin me libro de los ladrillos basados en Windows Mobile. No sé cómo será la versión 6.5... pero Microsoft como siga así lo tiene crudo.

Ah, como no todo puede ser bueno, la aplicación de correo que trae este HTC Hero deja un poco que desear. La parte de sincronización con Exchange funciona muy bien, pero tiene una gran pega y es que no sincroniza automáticamente las carpetas de correo. Esto en mi caso es una gran, GRAN pega. Esperemos que sea corregido pronto (la aplicación no es de Android, si no una aplicación externa proporcionada por la propia HTC).

Rendimiento en Drupal (II)

Sobre el tema que ocupaba en el anterior post, continuamos.

El site se diseñó sobre Drupal 5.x, el cual aunque tiene importantes mejoras de rendimiento sobre las versiones 4.x, no llega a lo que puede dar de sí 6.x o incluso la 7.x, actualmente en desarrollo.

Es por ello que tuvimos que implementar una serie de mecanismos para reducir el impacto sobre el hardware disponible. Estos fueron los mecanismos implementados.

- Uso intensivo de memcache. Memcache es un sistema de cachés en RAM, como su nombre indica. Se utilizó para evitar queries masivas sobre la base de datos (mysql). Drupal utiliza la base de datos para prácticamente todo. El ir añadiendo módulos y bloques hace que este uso sea tremendamente intensivo. Esto puede llegar a crear un gran problema. Memcache lo que hace es cachear las queries más habituales en una gran tabla hash, lo que reduce a la mínima expresión (updates e inserts) los accesos a BBDD. El impacto de memcache sobre el site fue brutal, especialmente a nivel de BBDD.

- Uso de las cachés internas de Drupal. Drupal 5.x tiene un sistema propio de cachés. Genera un expires en las páginas, de forma que el usuario que navegue no las recargue cada vez que pase por el site. En 5.x este sistema se limita a eso y poco más. En la versión 6.x se cachea por bloque, lo que produce un importante incremento del rendimiento, pero no así en la 5.x. Además, cada vez que un usuario registrado accede, se limpia la caché. Una lástima. Existen algunos módulos interesantes, como "Advanced Cache" (advcache) que mitiga parte del problema, o Block Cache que fue incluído en Drupal 6.x como caché de bloques. En nuestro caso, utilizamos una versión desarrollada a medida y más flexible de block cache para reducir la carga de site, la cual resultó muy beneficiosa.

- Uso de un proxy reverso. En este caso, squid 2.6. Un sistema de caché reversa puede salvar el pescuezo a cualquiera. Al contrario que la caché interna de Drupal que cachea principalmente objetos, el proxy reverso cachea las páginas renderizadas tal cual, así como los gráficos, css, javascript, etc. Si bien estos últimos apenas suponen carga para el servidor web, sí que implican el uso de procesos, escrituras del log, etc, etc. El cacheo de páginas renderizadas libera realmente al site de producción. En nuestro caso, modificamos drupal para generar dos tipos de URL. Una URL genérica para usuarios anónimos, y una URL con un parámetro para usuarios logados, de forma que el sistema de caché reversa cacheara todos los accesos anónimos (segun drupal indicara en su expires) y liberara de los mismos al servidor. Los usuarios logados seguían cargando (y mucho) el site, pero al menos crawlers, usuarios ocasionales (la gran mayoría) ya no lo hacían.

- PHP eaccelerator. Es un acelerador de PHP. Básicamente lo que hace es almacenar el código PHP ya compilado para que el sistema no tenga que volver a interpretarlo cada vez que una página es invocada. El rendimiento del código se incrementa entre x3 y x5. Hay otros sistemas como APC o Xcache que tienen un impacto similar.

- En MySQL, cambio de MyISAM a InnoDB. Soy poco fan de MySQL y siempre me ha parecido que postgres es un sistema de BBDD mucho más robusto, fiable y serio. Pero es lo que hay. Como estábamos trabajando con MySQL 5, teníamos posibilidad de usar InnoDB en lugar de MyISAM como sistema de almacenaniento. Aunque sobre el papel MyISAM es más rápido a la hora de realizar consultas por su mayor simplicidad, InnoDB es mucho más avanzado por cuanto que no bloquea tablas completas en consultas o updates. En nuestro caso, además, prácticamente no usamos las consultas porque memcache las sirve casi todas, y experimentamos bloqueos por queries un tanto "rudas" contra la BBDD que en algunas ocasiones colgaron el sistema. El paso a InnoDB solucionó este problema. Modificamos algunos puntos del código para eliminar bloqueos explícitos que realiza Drupal 5, pensado para MyISAM, en aras de mejorar el rendimiento, aunque como supondréis mucho, poco incrementó dicho rendimiento habida cuenta de que (otra vez) casi todo se lo come memcache.

Adicionalmente a estas medidas, y como red de seguridad, sugerimos una serie de cambios al proveedor (sí, lo sé, esto no debería haber sucedido jamás, pero el mundo de los sysadmins está lleno de manías y no es fácil decirle a uno lo que tiene que hacer. A todos nos sienta mal que nos lo digan).

- Limitar el número de procesos de Apache (para evitar que el servidor se sature). Mejor hacer esperar al usuario unos segundos encolado, a hacerle esperar para siempre porque nuestro servidor se ha ido a freir monas. Aquí lo ideal es realizar un estudio a grosso modo entre la memoria utilizada por proceso, la memoria de la máquina y la potencia de CPU de la máquina. Esto es, si cada proceso viene a tomar 100MB, tenemos una máquina con 2GB de memoria y un procesador doble núcleo, no parece lógico coger más a allá de 15 procesos en Apache para no quedarnos sin memoria... o sin CPU, si la aplicación es muy intensiva.

- Limitar el número de conexiones a BBDD. Tanto a nivel de gestor como a nivel de php. En este caso, si como máximo vamos a tener 15 procesos, no tiene sentido dar más de 15 conexiones a BBDD. Como siempre, mejor "encolar" que ser "enculados" (no tiene gracia, pero bueno).

Con estos cambios más algunos a nivel de código que realizaron los desarrolladores (desde la parte de administración IT podemos hacer muchas cosas para mitigar, pero a fin de cuentas muchos de los problemas, si no casi todos -que no ha sido en este caso-, se solucionan desde la pantalla del programador) conseguimos que lo que fue una abrupta salida en producción se convirtiera dos días después solo en un problema, y al cabo de dos semanas en un problemilla.

Todavía hay muchas mejoras que se pueden hacer, sobre todo a nivel de cachés de Drupal y optimización de algunos componentes internos, pero a nivel de IT poco más se puede hacer. Y si alguien tiene alguna sugerencia que me la diga, que estoy completamente abierto a nuevos planteamientos.

Rendimiento en Drupal (I)

Recientemente hemos tenido una incidencia en un proyecto basado en Drupal debido a un problema grave de rendimiento. El site es un portal público con un gran número de accesos, y obviamente, al salir a producción emergió este problema.

Normalmente este tipo de situaciones no debería darse si se dimensionan unos benchmarks en condiciones, pero lamentablemente no fue este el caso. Un error muy común a la hora de definir benchmarks es no plantearlos adecuadamente.

Por un lado, hemos de diseñar unos casos lógicos de navegación. De poco basta definir una prueba de carga contra una home si luego la mayor parte de los usuarios se centran en dos o tres páginas concretas. Es importante, así pues, contar con una estadística de accesos al portal previo (caso de una actualización) o con una estimación lo más ajustada posible en caso de una nueva salida. Para este último caso se puede contar con un grupo de usuarios de control que, durante una temporada, hagan uso del portal para así generar un patrón de uso lo más realista posible.

Por otro lado, a la hora de diseñar los patrones de navegación es importante realizar varios patrones diferentes, incluir páginas diferentes en cada uno de esos patrones e incrementar lógicamente el número de hits sobre las páginas que van a ser accedidas con mayor frecuencia.

Todo esto y mucho más se puede realizar perfectamente con Jakarta JMeter.

Finalmente, y para el caso que nos ocupa, en el dimensionamiento de las pruebas, y este fue el GRAN ERROR, no se tuvo en cuenta que no es lo mismo un usuario anónimo que un usuario registrado. Estos últimos, por las características inherentes de Drupal, hacen que se haga flush del sistema de cachés por toda página sobre la que navegas.

El resultado es que aunque los test de carga daban un portal que podría soportar lo que fuera, a la hora de la verdad fue todo lo contrario.

En resúmen, es muy importante plantear y diseñar un sistema de pruebas de carga lo más realista posible a la hora de sacar un site a producción, especialmente cuando son sites sobre los que se va a tener una gran concurrencia.

Chrome en Linux

Hace ya algunos meses que las alphas de Chromium compilan en Linux y más que menos funcionan. Son realmente rápidas, pero además de incluir algunos bugs y funcionalidad sin terminar, no soportan plugins como flash, java y otros.

Si ya de por sí en Linux solemos tener problemas con algunos plugins creados en exclusiva para Windows, que encima los más comunes tampoco se soporten en Chromium hacen que el navegador quede relegado a pruebas o a sites donde queremos velocidad sin importarnos los dibujitos.

Pero esto ha cambiado. Desde hace muy poco, ya podemos igualmente hacer funcionar los plugins sobre Chromium, eso sí, añadiendo algo de inestabilidad al sistema.

Para ello basta con ejecutar Chromium desde línea de comandos:

chromium-browser --enable-plugins

Y automáticamente todo plugin de firefox estará disponible en Chromium (con sus ventajas y desventajas).

Para usuarios de Ubuntu y derivados, tenéis las builds disponibles en lauchpad como de costumbre.

Virtualbox o VMware (player)

Virtualizar es algo realmente útil, especialmente para aquellos como yo que nos encanta trastear y nos vemos en la obligación en muchas ocasiones de utilizar software que no está preparado para funcionar en nuestro sistema operativo favorito (en mi caso, Linux).
Pero una vez puestos, hay que seleccionar el software de virtualización preferente. En mi caso, tras años de trabajar con VMWare, me he encontrado con una grata sorpresa al probar por pura curiosidad VirtualBox 3 de Sun.
VMWare, de siempre, ha contado con su VMWare Server, el cual da unas grandes prestaciones y hasta la fecha me ha servido realmente bien. Con la llegada de la versión 2.0 decidieron abandonar definitivamente la interfaz cliente nativa y se centraron en una interfaz web, dejando por otro lado el producto VMware Client como hasta la fecha.
El problema de VMware server, ahora, es que al levantar un servidor web es bastante más pesado que antaño, y además, este cliente es mucho más lento. Además, para tomar control sobre la máquina nos vemos obligados a usar el Add-on de Vmware para firefox, el cual tiene la peculiaridad de no funcionar sobre FF 3.5, el cual vengo usando en versión beta y RC desde hace meses. En resúmen, VMware orientó su VMWare Server para servidores y su VMWare client (productos separados) para ejecuciones locales. El problema viene con que además, VMWare client no te permite crear virtuales y es incompatible el tenerlo funcionando con VMWare Server, de forma que has de instalar VMware server, crear tu máquina virtual, desinstalar, instalar VMware Client y seguir a partir de este punto. Además ya no podrás tocar dicha máquina salvo que modifiques el .vmx a mano. No podrás crear nuevos discos (vmdk), no tendrás aceleración 3D (no es que me importe pero bueno)... en resúmen, te encontrarás con un producto capado que, aunque para la mayor parte de los mortales es más que suficiente, te obliga a desinstalar e instalar el Server a la hora de crearte una nueva máquina virtual.
La alternativa es VMware Workstation, que te permite hacer todo esto en una única aplicación... pero... hay amigo... es de pago. Y no nos gusta pagar cuando hay alternativas gratuitas y mucho menos piratear que es de mala gente (los que usan Windows y tal) :)

Al probar Sun VirtualBox me encontré con un producto muy similar a VMware Workstation, con un magnífico rendimiento y una consola "nativa" que me permite crear máquinas virtuales, tocar opciones, ejecutar máquinas, parar, reanudar, pasar a pantalla completa, etc, etc al igual que VMware Server en sus versiones 1.X.
Lo único que no trae VirtualBox que si trae VMWare (client) es la posibilidad de lanzar aplicaciones "en ventana" de forma que puedas lanzar, por ejemplo, Office directamente como aplicación en lugar de como máquina al completo, aunque en realidad la máquina virtual se ejecuta al completo pero solo te muestra la aplicación que te interesa. Esto está muy bien para usuarios finales que quieran tener la "sensación" de que están operando una aplicación nativa, pero no deja de ser una curiosidad.
Por otro lado, virtualbox hasta la fecha se me ha revelado bastante más sólido que VMware Server, el cual me colgó en un par de ocasiones la máquina.

Lo dicho. Me he pasado a VirtualBox, si bien para entornos corporativos sigo jugando en la liga de VMware... aunque claro, ESX Server, nada que ver con los productos de "andar por casa" que son VMware client y VMware server.

Actualizando a Debian 5 (lenny)

Hace poco que Lenny (Debian 5) vio finalmente la luz tras dos años de desarrollo.
Como siempre, nos dispusimos en mi empresa a abordar la a veces complicada y delicada tarea de migrar de una "major version" a la siguiente, y es que al igual que en el mundo Microsoft, en el mundo Linux los saltos hacia adelante nunca son sencillos.
Tras evaluar las posibles implicaciones de una actualización de esta magnitud, quedaron identificados como posibles principales fuentes de problemas los siguientes servicios: ldap, samba, openvpn y apache a través de php5. Como nota sobre esto último, decir que Debian 5 finalmente deja atrás el eterno php4 y solo trae soporte para php5. Debido a que muchas de nuestras aplicaciones en php nunca han sido testeadas en php5, lo hemos identificado como principal problema a resolver.
Hasta la fecha hemos actualizado todos los servidores de la DMZ, por ser los más expuestos, sin que hayamos encontrado ni un solo problema salvo el citado en php con los servicios que desde ellos se ofrecen: dns, smtp -via postfix-, proxy reverso (via apache) o servicio de páginas web, salvo una pequeña aplicación desarrollada in-house en la que encontramos un problema menor por los includes recursivos en php4 que fue rápidamente parcheada.
Dentro de la red interna, tampoco hemos tenido problemas con otros servicios críticos como puedan ser el dhcp en modo failover. Curiosamente el paso de samba 3.0.24 a samba 3.2 no ha tenido ni una sola complicación, y eso que usamos una configuración bastante complea con OpenLDAP como backend.
El principal problema que sí que hemos sufrido en nuestras carnes ha sido el paso de openldap 2.3 a opendap 2.4. Por motivos de compatibilidad hacia atrás (y un poco de vagancia) seguíamos trabajando con el eterno slurp. Y con Openldap 2.4 no funciona demasiado fino. Afortunadamente uno de mis chicos se puso manos a la obra y realizó los cambios para empezar a replicar con syncrepl, que por cierto funciona muchísimo mejor que slurp (realiza sincronizaciones completas desde cero) una vez solucionadas sus "peculiaridades".
Otros servicios como squid (proxy-cache), cvs y demás tampoco han dado el menor problema
Las bases de datos por ahora seguimos con postgresql-8.1, si bien debian5 ya no lo incluye y han pasado a postgres-8.3. Aquí el cambio es bastante delicado dado que postgres 8.3 si bien incluye potentes mejoras, también añade muchas restricciones a nivel de tipado en procedimientos almacenados o cambios profundos en los módulos de indexación textual (tsearch) por lo que la posible migración la abordaremos más adelante como proyecto independiente.
Ahora mismo nos centramos en los servidores que en breve actualizaremos, y que principalmente afectan a Gforge, subversion y el nodo principal de VPNs (openvpn). Con respecto a este último tenemos serias dudas debido al fix de la vulnerabilidad de las claves SSL en debian. Es posible que el nuevo daemon de VPN se niegue a usar dichos certificados, y esto nos podría generar el tener que rehacer todo el sistema. Es algo que habrá que abordar en algún momento.
En fin, si bien ya están actualizados cerca del 80% de los servidores bajo Debian 5, todavía nos queda un intenso 20% que iremos migrando en sucesivos días. Ya veremos con qué nos encontramos.

Ubuntu Jaunty, primeras impresiones

Desde hace casi un mes estoy trabajando diariamente con Ubunty Jaunty.
¿Que por qué ando trasteando con una Alpha? Pues simplemente porque hice el canelo y cambié mi partición primaria a ext4, de forma que luego desde Intrepid no podía arrancar.
Y como ya no estoy para andar con recompilaciones de kernel cada dos por tres y demás, directamente decidí probar Jaunty.
¿Impresiones?
Ext4 se nota, y se nota bastante. Sobre todo en el arranque y luego en lo que es el uso del sistema operativo día a día. Va más fluído. No pensé que un cambio en un sistema de archivos pudiera notarse tanto, pero he de reconocer que esta vez así ha sido. Tiene alguna pega, como un puñetero bug que hace que con determinadas aplicaciones que no utilizan la llamada fsync puedas perder datos si apagas o reinicias sin haber esperado un ratito, pero afortunadamente no he sufrido este problema.
En cuanto al sistema en sí, han metido novedades en Gnome 2.26. Ahora las notificaciones salen en mensajes emergentes muy bonitos en la barra de programas. Muy interesante y mucho más usable.
La única pega es que sigo sufriendo los cuelgues cuando entra el screensaver y compiz está activo, pero tiene que ver más con el driver para X de la tarjeta intel que trae mi portátil que otra cosa. Es fácil de solucionar: fuera compiz y screensaver en negro... poco se pierde.
Teniendo en cuenta que vamos por la Alpha6?, creo que esta release de Ubuntu va a salir muy redonda y realmente va a merecer la pena. Además viene ya con Openoffice 3.0.1 de serie.

A correr se ha dicho.

Este sábado 22 de Febrero, y para celebrar mis 33 años, me propuse correr mi primera media marathon...
Hasta la fecha he corrido muchas carreras de 10km, tipo San Silvestre y similar, con unos tiempos bastante aceptables (por debajo de los 45 minutos). Y dado que hace tiempo que no sufro "contratiempos" (tendinitis, sobrecargas y monerías por el estilo) decidí animarme a por los 21.1km de la media, con mucho miedo y muy tranquilito, eso sí.
Me fui con un buen amigo (Luisín) que suele ser compañero de este tipo de locuras, y allí nos plantamos, a las 10 de la mañana para correr la Media Marathon de la Latina, con un perfil complicado (muchas subidas y bajadas), muchas ganas, y un poco de acojone.
Al final terminé, mucho menos hecho polvo de lo que pensaba, enterito y sin que la rodilla llorara (se quejó una vez pero se quedó solo en eso) y con un tiempo más que digo, 1h 46 minutos....

Próxima parada: Media Marathon de Madrid.

P.D: Realmente llegué (221).

Casi dos años abandonado...

Bueno, tras dos años con el blog prácticamente abandonado vamos a ver si retomamos la sana costumbre de ir añadiendo algún articulillo aunque sea de vez en cuando.
La excusa que tengo es perfecta. No, no me he tomado un par de años sabáticos, más quisiera yo. La verdad es que tener un enano es una labor muy muy ardua que te deja muy poquito tiempo libre para otras muchas cosas. Y claro, hay que priorizar. Y el escribir articulillos suele ser de lo primero que se sacrifica.

Así pues, vamos a ver si nos volvemos a poner las pilas, porque la verdad es que en estos dos años han pasado muchas cosas, y empezamos a darle un poco más de vida al blog. :-)

Google Apps

Tras una temporada aislado del mundo de la banda ancha (mi tarjeta 3G HSDPA ha cubierto las necesidades básicas, pero está limitada en cuanto a transferencia total y la subida es muy lenta), me vi obligado a llevarme mi pequeño barebone que hace las veces de servidor a la oficina.
Hasta aquí todo hubiera ido perfecto, de no ser porque además tengo un problema en el USB por una sobretensión jugueteando con discos duros externos que hizo que de vez en cuando se me cuelgue.
El caso es que es un coñazo tener que ir a resetearlo a la oficina, y no siempre estoy allí. Normalmente se cuelga en el momento más inoportuno (para los interesados, es una debian sarge, pero el problema es hardware, no software ;-) ).
Finalmente, tras recordar que Google tenía un servicio para dar correo y web a empresas tiempo atrás, hoy mismo me he pasado a ver si por fin era de libre acceso... y... ¡¡ bingo !!
El servicio se llama Google Apps y está disponible en http://www.google.com/a/

Entre otras cosas, te dan:
- Google Mail con tu dominio, con capacidad hasta 2GB y hasta 50 cuentas de correo.
- Listas de correo para tu dominio.
- Espacio Web (100MB)
- Agenda (google calendar)
- Chat
- Búsqueda

Lo único que hay que hacer es activar el servicio, y apuntar tus registros MX de tu DNS (para el correo) o CNAME (para el web) a los servidores que se te indican.
En apenas unos minutos ya tenía plenamente operativo el traspaso.

He ganado en seguridad, en comodidad y sobre todo en interfaz. La interfaz de Gmail es soberbia, y tenerla en mi propio correo es un plus a valorar.
Por otro lado, no se pierde la posibilidad de seguir usando tu programa de correo de toda la vida (Thunderbird, Evolution o los Outlook de M$) dado que puedes habilitar el acceso por POP3 (en un futuro, también por IMAP).

Resumiendo, un servicio que recomiendo a cualquiera interesado en tener su dominio y sus cuentas completamente gestionadas, sin pagar un duro, y con una funcionalidad de campeón.

¡ Ya soy papá !

El 19 de Abril a las 18:28 nació el pequeño David. Un bicho de niño, pero muy guapo.
Están siendo unos días duros (lo que cuesta tener a gusto a un canijo) pero muy divertidos y llenos de nuevas experiencias. ;-)

Toyota Prius 2006

Este año he cambiado de coche. Tras siete años con un Renault Megane 1.9 dti, he pasado a un Toyota Prius 2006.
Para los que no conozcan este vehículo solo comentar que es uno de los pocos vehículos híbridos (motor gasolina y eléctrico) que actualmente se encuentran en el mercado, junto con algún Lexus y un Honda Civic.
El coche es una pequeña maravilla tecnológica. Cuenta con un silencioso motor gasolina de 1.5l y 78 CV de potencia y un eléctrico de 68 CV, ambos funcionando en serie y ayudándose mutuamente según las circunstancias.
El resultado es seguramente el coche más silencioso del mercado, y uno de los mas económicos a la hora de gastar combustible, el que más dentro de ciudad, y el que menos emisiones de CO2 (tan solo 104gr por kilómetro) emite a la atmósfera.
Es un coche suave de conducir, que no se parece en nada a ningún otro que haya llevado hasta la fecha. A bajas velocidades (por debajo de los 30km/h) y si no se le pisa, va completamente en eléctrico. A partir de esa velocidad entra el gasolina complementado con el eléctrico según las circunstancias. Apenas hay vibraciones y solo a partir de los 80-100km/h el coche empieza a sonar algo. Evidentemente en las subidas siempre va a sonar más, y en las cuestas abajo directamente apaga el motor y solo recupera energía.
Lleva un cambio automático llamado CVT de infinitas posiciones, por lo que nunca se nota un "cambio" de marcha. Es como un videojuego. El se las apaña solo, sin cambios en la aceleración por cambio de marcha.
La batería, que no da para mucho en modo 100% eléctrico (unos 2km), se recarga mediante el exceso de energía producido por el gasolina en llano, o mediante la inercia al soltar el acelerador o mediante la frenada regenerativa. Nunca se agota, dado que antes de que eso suceda él se encargará de encender el gasolina para que ello no suceda.
En cuanto a los consumos, tras practicar un poco con las técnicas de conducción, estoy en los 4.8l/100 en combinado, esto es, carretera, autopista... y atasco, mucho atasco en la M40.
En fin, que es un coche que realmente merece la pena y que realmente me convenció desde la primera prueba que hice en su momento, y más ahora que me lo he comprado. ;)

Pero como todo, tiene sus peguillas que no dejan de hacer que lo califique con un rotundo 9.5, a saber:
- Luces. Le falta potencia (luces de xenón, desde luego).
- Automatismo en luces y limpiaparabrisas. Con todo lo que trae ya podrían haberlo puesto.
- Batería. Un poco más... 10 ó 20 km de autonomía en modo 100% eléctrico y hubiera sido una pasada. Y un enchufe para recargar le hubiera puesto la guinda. ;) En cualquier caso hay un grupo de americanos locos que ya están ello...
- Aviso del freno de mano. Como lo tiene en el pie izquierdo me olvido de que existe... pero no me pita. Y eso que me pita por todo (marcha atrás, si no llevas cinturón, etc).
- Que vuele... pero eso es otra historia. ;-)

Dejo un par de links al repecto:
* Un review en km77 muy recomendable.
* Los foros de usuarios de Prius en España.
* El link al coche en la web de Toyota.
* Unos consejos de conducción para exprimir al máximo cada litro de gasolina.

Zimbra en Español.

Como parte de mis colaboraciones al proyecto Zimbra, acabo de completar las traducciones de la interfaz de usuario, interfaz de mensajes e interfaz de correos al castellano / español de España para la versión 4.5:

http://www.zimbra.com/forums/showthread.php?t=6379

Zimbra 4.5 ya está en la calle

Incluye bastantes bugs cerrados, especialmente algunos relacionados con el conector de Outlook 2003 y la internacionalización.

Entre las mejoras y nueva funcionalidad añadida, caben destacar:

- Nuevo sistema de backup, gestionable desde la consola de administración.
- Zimlets gestionables desde la consola.
- Cambio de los skins. Ahora los menús de Contactos, Correo, Notas, etc están en la parte superior.
- Agregador POP3/IMAP4 y gestor de identidades.

Actualizacion Dell Axim x50v a Windows Mobile 5 A02 ingles.

Hace algunos meses que salió la actualización a Windows Mobile 5 (WM50) para las Dell Axim de la serie X50 (concretamente la X50 y la X50v).
Dicha actualización pasó por ser una de las más tristes y fatídicas de la historia. Una PDA muy maja que funcionaba muy bien bajo Windows Mobile 2003 Second Edition pasó a convertirse en un trasto que funcionaba a duras penas a base de parches, injertos y programas asociados para evitar cuelgues, consumos increíbles de CPU y otros.
Afortunadamente para la gente con la versión inglesa, Dell sacó al poco tiempo una utilidad para "volver hacia atrás". Algo que no sucedió, como no, con la versión en español. El resultado fue que los que actualizamos a WM50 nos quedamos compuestos... y sin apenas PDA (no quiero decir que no funcionara... sí, funcionaba, pero mal. Cuelgues absurdos y usos constantes del 100% de la CPU).

Pues bien, hace apenas un mes Dell sacó su versión A02 de WM50 para Dell Axim x50V. Y todo el mundo en los foros americanos contaba lo bien que ahora va su Axim. Oh!, como siempre los europeos a esperar, entre ellos los españoles, porque la Axim no soporta un cambio de lenguaje... ¿seguro? ;-)

El siguiente método sirve para actualizar una Dell Axim X50(v) a cualquier versión de cualquier idioma. En este caso, voy a explicar cómo pasar una versión de WM50 A00 en ESPAÑOL a WM50 A02 en INGLES.
¿Por qué a ingles? Pues porque además de ser la única versión A02 disponible (se supone que en algún momento del año saldrá también en español) incluye detalles que la versión española no trae, como el reconocimiento de escritura manual.

ADVERTENCIA: El procedimiento es bastante delicado. Podrías llegar a perder tu PDA si lo realizas de forma incorrecta. Bajo tu propia responsabilidad. Dell no da garantía para esto.

ADVERTENCIA2: Las ROM que adjunto son solo para Axim X50V. No vale para la X50 normal (sin V) ni para las X51. Si bien el procedimiento es similar, tendrás que buscarte las ROM por tu cuenta.

El procedimiento es conocido como SD Bootloader. Tienes más información en AximSite (www.aximsite.com)

1- Descargar las ROMs para tu Axim. Para la X50v las tienes aquí:
http://operation.nt.free.fr/Dell%20Axim%20X50v/X50v%20WM50%20A02EN/

La ROM se compone de dos partes. El bootloader y la ROM en sí, con su correspondiente fichero de CRC para comprobar su autenticidad. Se sacan de Axim ya actualizadas.

Vamos a actualizar primero el BOOTLOADER y luego la ROM. Si ya estás con WM50 no es necesario actualizar (en teoría) el Bootloader, pero dado que el existente está en español y que no quiero sorpresas (además de que pretendo pasar a usar actualizaciones posteriores oficiales en inglés) lo actualizaremos igualmente.

*** RECUERDA: SOLO PARA x50V *** Si metes la X50 (sin V) la cagaste.

2- Coloca tu AXIM en su base. Haz un backup manual lo que no quieras perder y sincroniza. EL BACKUP que te realiza la propia Axim no te será válido, así que prepárate para reinstalar al acabar.

3- Formatea la tarjeta SD (o MMC) en FAT32 desde Windows. Yo lo he hecho insertándola en una cámara digital enchufada al ordenador. Tiene que ser FAT32. No vale FAT a secas. La tarjeta de vale con una de 64MB.

4- Copia los ficheros anteriores a la tarjeta SD.
a) Si estás con WM 2003, los copias tal cual.
b) Si ya estás con WM50, renombra los dos ficheros que empiezan con "DiMA_B..." a "WM50_B...". Esto es debido a que en WM50 el bootloader a actualizar debe empezar con este nombre.

5- Pulsa (y mantén pulsado) con la AXIM encendida y en la base las siguientes teclas: Wireless (lateral) + Standby (parte de arriba) y, SIN SOLTAR NINGUNA DE LAS DOS pinchas en el botón de reset de la parte de atrás con el puntero. NO SUELTES LAS DOS TECLAS. Aparecerá una pantalla donde pone Dell Update A02. MANTEN LAS DOS TECLAS APRETADAS hasta que aparezca un pequeño menú donde aparecerán las dos ROMs a actualizar.

Nota: No te preocupes si no te sale a la primera. A veces falla y sale la pantalla azul de actualización y te empieza a arrancar normalmente la PDA o bien te dice que pulses la tecla de "contactos" para resetear todo. Apaga, enciende (fuera batería) y vuelve a intentarlo. No te cargarás nada hasta que actualices la ROM, así que prueba sin miedo. Yo lo conseguí al intento 20.

6- Selecciona la actualización del BOOTLOADER (WM50_B_A02_X50v_WM50_A02EN_Bootloader) y pulsa con el botón central del PAD para actualizar. La actualización durará algunos segundos, tal lo cual tendrás que hacer un full reset de tu PDA (Botón de standby + pinchar en el botón de reset de atrás).

7- Ahora repetimos el procedimiento anterior, pero esta vez seleccionaremos la actualización de la ROM que no es el bootloader, esto es, WM50_K_A02_X50v_WM50_EN.
Esta vez el procedimiento llevará al menos 20 minutos, y verás una barra de progreso que te indicará cómo va.

8- A reinstalar todo y resincronizar con el PC.

Con esto tendrás tu Axim X50V en inglés y con la última ROM disponible. Os puedo asegurar que es mano de santo, que mi PDA vuelve a ser una PDA útil, fiable y va mucho, mucho pero que mucho más rápida.

Greylisting, spam contra las cuerdas

Hace más de un mes implementamos en nuestros servidores perimetrales un sistema para bloqueo de spam, en vista de la inoperancia de los sistemas tradicionales basados en el análisis de contenidos.
Desde hace algunos meses, los spammers están evolucionando hacia un nuevo tipo de correo incrustado en imágenes, de forma que los tradicionales filtros bayesianos o de reglas que se basan en el contenido disminuyen terriblemente en cuanto a eficacia. Esto está provocando que otros sistemas alternativos que hasta la fecha no habían tenido demasiada importancia hayan subido muchos puntos en la lucha contra el spam y se revelen como los únicos realmente efectivos. Dos aproximaciones toman especial interés: el reconocimiento de imágenes mediante sistemas de OCR y los sistemas de greylisting (listas grises).
Mientras que el primero requiere una gran cantidad de recursos por parte de los diferentes sistemas de análisis (aplicar un filtro de reconocimiento de caracteres implica un gran consumo de CPU y memoria, especialmente en sistemas con mucha carga), el segundo apenas requiere implementación y es de una simpleza asombrosa.
Un sistema de greylisting consiste en rechazar todo correo de aquellos remitentes que no conocemos durante un período de tiempo determinado. El sistema, al recibir un correo de un usuario (origen@dominio.com) para uno de nuestros destinatarios en particular (destinatario@midominio.com) a partir de una IP en concreto (iporigen) comprueba si en una base de datos local dicha "tripla" está permitida (origen,destinatario,iporigen). Si aparece en la lista, el correo automáticamente entra en nuestro sistema y se procesa directamente. Por el contrario, si no aparece, se rechaza con un código 550 (rechazo temporal) y se añade la tripa (origen,destiantario,iporigen) a nuestra lista. Al recibir este código, el servidor que envió el correo lo encola y lo volverá a intentar pasado un tiempo (de unos minutos a un par de horas). Esta segunda vez, el correo se volverá a chequear contra nuestra base de datos, pero como previamente se añadió la entrada a nuestro sistema, esta vez se acepta.
¿Y qué aporta este sistema si cualquier spammer puede intentar reenviar el mensaje al cabo de una hora? Pues bien, los spammers no se paran a comprobar que un correo está bien recibido. Simplemente lo intentan, y si entra fantástico. Si no entra, se descarta. Son sistemas preparados para procesar millones de direcciones, no para garantizar su entrega. Además utilizan máquinas de terceros que han sido infectadas por troyanos y que, por lo tanto, no tienen un sistema de envío de correo SMTP completo. De esta forma, ese primer "rechazo" hace que nuestro spammer no consiga su objetivo y el correo se pierda y no entre en nuestros sistemas.
El retardo también sirve para que si un spam vuelve a intentar entrar, nuestro sistema secundario basado en listas negras ya haya podido recibir la información de las listas antispam (pyzor, razor2, etc) que existen por internet y que en pocas horas estarán al día.

Además de almacenar la tripa "origen,destino,iporigen", también almacenamos el número de veces que esa tripa se usa, esto es, el número de mensajes recibidos desde una ip para uno de nuestros destinatarios y el tiempo pasado desde la última vez que se recibió. Esta información extra se utiliza para limpiar nuestra base de datos de spam que una vez intentó entrar y ahora se ha rechazado (esto es, spam que solo tiene un intento de entrada en nuestro sistema). Así la base se mantiene en un número de entradas razonables.

A día de hoy, greylisting es posiblemente el mejor sistema en relación coste/beneficio en la lucha contra el spam. La única pega es el posible retardo que a algunos usuarios puede incomodar, pero este retardo es solo con el primer correo recibido desde un determinado usuario. No hay efectos secundarios de correos legítimos rechazados salvo en casos de que el origen utilice un MTA con una mala implementación que no sepa interpretar un "rechazo temporal". Afortunadamente esto es extremadamente raro.
Eso sí, un sistema de greylisting siempre ha de complementarse con sistemas tradicionales basados en RBL (Relay Blocking List), listas negras/blancas (pyzor, razor, etc) para que el sistema antispam sea un sistema efizar y robusto.

¿Efectivo? Ciertamente. MUY EFECTIVO. Nuestro índice de spam se ha reducido en un 90%, y la mayor parte de ese 10% que entra es spam legítimo, esto es, aquellos correos comerciales de los cuales nos podemos dar de baja sin el menor problema.

De vuelta tras las vacaciones de diciembre

De nuevo estoy de vuelta por Madrid, tras unas vacaciones en Cuba.
Curioso país. Por un lado comunista, por otro completamente capitalista. El sistema es incapaz de garantizar la solvencia de sus ciudadanos, los cuales no tienen más remedio que buscarse la vida en la más absoluta jungla social. El resultado, es un sistema que es más capitalista que haya conocido, una doble vida y una doble cara de un sistema que se revela completamente inoperante tras la caída del bloque soviético. El único punto bueno que se le puede sacar es que ha mantenido un fuerte sistema educativo en funcionamiento a pesar de las dificultades y que la gente no se muere de hambre como sucede en otros países de lationamérica. Gran logro, si tenemos en cuenta el bloqueo que sufre la isla desde hace medio siglo.
El futuro nos dirá que le depara a esta isla tras el fin del reinado de Castro. Esperemos que sea para mejor, si bien es curiso que ni los propios cubanos lo ven claro. El "Señor Oscuro" acecha desde el otro lado del estrecho de Florida. :)

Virtualización: ¿el futuro está aquí?

Mucho se ha hablado y se está hablando del término virtualización. Desde hace unos cuantos años este término aparece y se repite habitualmente en los círculos de tecnólogos, administradores de sistemas y otros, aunque hasta hace poco no había pasado más allá de ser un tema más de conversación sobre tecnología puntera que promete pero no acaba de consolidarse.

Aplicado a sistemas de información, la virtualización no es ni más ni menos que, a partir de una plataforma hardware, ejecutar un programa de "virtualización" que oculta el hardware que hay por debajo creando una máquina emulada por software.

Las aplicaciones de la virtualización son inumerables. Por un lado, permite reaprovechar al máximo los recursos hardware de la máquina. Gran parte de la plataforma de servidores instalada hoy en día está la mayor parte del tiempo ociosa, o no se destina el 100% de su potencia a las tareas asignadas porque simplemente la unidad de procesamiento no tiene más que hacer. Esos espacios muertos de tiempo pueden ser empleados para que otra tarea se lleve a cabo. El contar con una plataforma virtualizada implica que podemos tener de forma simultánea varias máquinas virtuales corriendo aplicaciones en nuestra máquina de forma completamente independiente. Esto no sería en sí una gran ventaja (podemos tener un servidor con múltiples aplicaciones instaladas) si no fuera por la seguridad que añadimos a la hora de ejecutar aplicaciones en entornos aislados: si nos falla una máquina virtual las otras permanencen impasibles. También permite asignar recursos bajo demanda a una máquina virtual cuando los necesite: procesador, memoria, etc, permitiendo en nuestra plataforma virtual ir añadiendo recursos o eliminando según se vayan necesitando o desplazando máquinas a o desde nuesta plataforma real según se vaya necesitando.

Esta es la segunda gran ventaja de la virtualización: la seguridad. El mantener entornos completamente estancos e independientes, aun siendo dentro de la misma plataforma, implica que si uno de nuestros servicios sufriera una interrupción por un mal funcionaminto del programa, la caída únicamene afectaría a dicha máquina y no al resto de máquinas virtuales que se ejecuten. Es como tener varios servidores, cuando en realidad solo tenemos uno.

La tercera gran ventaja es la versatilidad. Para determinadas aplicaciones (entornos de desarrollo y pruebas), el estar constantemente instalando, desinstalando y reinstalado sistemas operativos es una tarea común. Las máquinas virtuales nos permiten que, en cuestión de segundos, cambiemos una máquina por otra igual que si cambiáramos un disco duro de nuestro PC con un sistema operativo por otro disco duro completamente distinto. Si a esto añadimos que se nos permite realizar snapshots (fotos de estado en un momento dado), tenemos la posibilidad de volver a un estado anterior en cuestión de segundos. Podemos imaginarnos a un equipo de testing y calidad probando inumerables versiones de un mismo producto y desinstalándolas, sin ni siquiera tocar una tecla, dejando la máquina como estaba minutos antes.

A partir de estas premisas las aplicaciones son innumerables. Desde consolidar diferentes servidores ubicados en máquinas distintas mal aprovechadas dentro de una máquina más potente donde se ejecutan sus respectivas máquinas virtuales hasta que equipos de evaluación de software no requieran de una segunda o incluso tercera máquina para realizar sus pruebas y pueden lenvantar distinas máquinas con distintos sistemas operativos en cuestión de segundos según sus necesidades. Los beneficios cubren distintas y variadas áreas: desarrolladores, centros de proceso de datos, departamentos de sistemas, etc.

En el caso de servicios de alta disponibilidad, en caso de caída o mal funcionamiento de una plataforma hardware, podemos trasladar la máquina virtual en cuestión de minutos (o segundos si utilizamos almacenamiento compartido) a una nueva plataforma hardware completamente distinta y ponerla a funcionar sin tener que reconfigurar absolutamente nada.

Actualmente, la virtualización se está popularizando debido a una serie de avances técnicos, tanto a nivel hardware como software, que hacen que a día de hoy sea una alternativa a los servidores tradicionales a tener muy en cuenta. Por un lado, el desarrollo de los procesadores ha alcanzado un grado de desarrollo muy alto con la intruducción de micros de doble núcleo (Intel acaba de lanzar sus procesadores de cuatro núcleos). Este incremento en el número de unidades de ejecución en los microprocesadores hace que el coste de hardware en relación a su potencia se haya reducido considerablemente. Una máquina de ocho procesadores que hace unos pocos años costaba miles de euros podría reducir su coste al de una máquina de dos procesadores si utiliza pastillas de cuatro núcleos. Por otro lado, la reducción del precio de la memoria RAM y disco duro hace que estén a disposición del consumidor grandes espacios de almacenamiento a precio reducido. Paradójicamente, el tamaño de las aplicaciones y datos a almacenar no ha aumentado a una velocidad tan vertiginosa, por lo que de facto hoy en día sobra mucho espacio en la mayoría de los servidores. Finalmente, los nuevos procesadores que surgen en el mercado vienen preparados específicamente para facilitar al desarrollador de máquinas virtuales mecanismos para mejorar el rendimiento de sus entornos emulados.

Por otro lado, el desarrollo del software de virtualización tampoco se ha quedado atrás, y a los tradicionales productos comerciales como VMWare o Microsoft Virtual Machine se han añadido alternativas opensource, algunas con más éxito que otras, como Xen, Qemu o Boschs.

Evidentemente no todo son ventajas en el área de la virtualización, y sus detractores argumentan que el rendimiento se resiente, especialmente en aplicaciones con muchas operaciones de entrada / salida o que un fallo hardware en un servidor que incluya varias máquinas virtuales haría que todas esas máquinas dejaran de funcionar.

En cualquier caso, recomiendo a cualquiera que esté interesado que evalúe las herramientas que a día de hoy existen en el mercado, experimente y vea la facilidad y versatilidad que un sistema basado en máquinas virtuales pueda aportar. A día de hoy existen alternativas gratuítas (tanto comerciales como opensource) más que de sobra para hacerse una idea.

VMWare Server: http://www.vmware.com
Microsoft Virtual PC: http://www.microsoft.com/spain/windows/virtualpc/default.mspx
Qemu: http://www.qemu.org
Xen: http://www.cl.cam.ac.uk/research/srg/netos/xen/
Bochs: http://bochs.sourceforge.net

3G/UMTS con Linux Ubuntu Edgy / Feisty

*** Actualizado a 8/5/2007 con comentarios para Ubuntu 7.04 (FEISTY) ***

Bueno, tras un poco de investigación finalmente he conseguido hacer funcionar mi Ubuntu Edgy en mi portátil con la conexión 3G/UMTS de alta velocidad (HSDPA). En mi caso, el operador que estoy usando es Orange, pero el procedimiento será válido tanto con Movistar como Vodafone, y posiblemente también con otros operadores internacionales (me basé en un thread de un foro alemán sobre Vodafone.de).

Nota: Feisty (Ubuntu 7.04) ya trae compilado el módulo de NOZOMI, por lo que esta sección del tutorial se puede omitir y pasar directamente a instalar gcom.

Lo primero, por supuesto, es verificar la tarjeta a utilizar. En mi caso es una QUADCOMM GT 3G+ del servicio Bussiness Everywhere de Orange.
Así pues, empezaremos por traernos el módulo para que funcione nuestra tarjeta, que es el "nozomi". Para ello

sudo apt-get install nozomi-source linux-headers-2.6.17-10-generic

Nota: Sustituye linux-headers-2.6.17-10-generic por la versión de kernel que tengas. Puedes verla con el comando uname -a

Esto nos va a traer el código fuente del módulo, el cual deberemos compilar y modificar.
Con el kernel 2.6.17 deberemos parchear un fuente para que nos funcione, así pues, iremos a

cd /usr/src
tar -jxvf nozomi-source.tar.bz2
cd modules/nozomi
sudo vim nozomi.c

Y nos vamos a la lína 966, sustituyendo esto:
if (tty->flip.count >= TTY_FLIPBUF_SIZE) {

por esto:
if (tty_buffer_request_room(tty, i) < face="georgia">A continuación compilaremos el módulo y lo instalaremos
sudo make
sudo mkdir /lib/modules/2.6.17-10-generic/kernel/drivers/3G
sudo cp nozomi.k /lib/modules/2.6.17-10-generic/kernel/drivers/3G
sudo depmod -a

Nota: Ajusta 2.6.17-10-generic a tu versión de kernel.

Si hemos llegado hasta aquí es que todo va bien. Ahora deberemos comprobar que el módulo nos funciona adecuadamente. Para ello, comprueba que el módulo PCMCIA está operativo, cargamos el módulo de nozomi y verificamos en el log del kernel:

sudo /etc/init.d/pcmciautils start
sudo modprobe nozomi
dmesg

Deberá aparecer algo así en el log:
[17243729.156000] ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 16 (level, low) -> IRQ 169
[17243729.156000] Nozomi driver nozomi_tty<6>[792] nozomi_read_config_table(): Version of card: 3
[17243729.468000] [784] nozomi_read_config_table(): Initialization OK!

Verfica además, que los siguientes dispositivos existen:
ls /dev/noz*

Llegado a este punto, y si están los dispositivos creados, necesitaremos unos nuevos paquete para manejar adecuadamente la tarjeta.
sudo apt-get install gcom wvdial

Una vez instalados, comenzaremos las pruebas para ver si la tarjeta funciona.
sudo gcom -d /dev/noz0 info

Deberá devolver algo como esto:
##### GlobeTrotter Configuration #####
Manufacturer Text: Option
IMEI and Serial Number: XXXXXXXXXXXXXXXXXXXXXX
Manufacturer's Revision: (Date: May 31 2006, Time: 15:49:25)
Hardware Revision: 2.2
Network Locked: 1
Customisation: Not defined
Band settings: Europe 900/1800MHz (4)
Auto Attach:

##### END #####

A continuación, introducimos el PIN:
sudo gcom -d /dev/noz0

Tras pedirnos el PIN, devolverá algo tal que así:

SIM ready
Waiting for Registration..(120 sec max)
Registered on Home network: "E AMENA",2
Signal Quality: 31,99

Finalmente, comprobaremos los operadores y que todo va bien
sudo gcom -d /dev/noz0 /usr/share/doc/gcom/examples/operator

Devolverá algo tal que así:
SIM ready
Waiting for Registration..(120 sec max)
Registered on Home network: "E AMENA",2
Signal Quality: 30,99
Getting Operator list: ..................

+COPS: (1,"E AMENA","AMENA","21403",0),(2,"E AMENA","AMENA","21403",2),(1,"vodafone ES","voda ES","21401",0),(1,"vodafone ES","voda ES","21401",2),(1,"movistar","movistar","21407",0),(1,"movistar","movistar","21407",2),,(0, 1, 3),(0-2)

==============================================================
Format: (Access,Long Name, Short Name, Network ID [,Technology])
Access: 2 - Registered, 1 - Available, 3 - Forbidden
Technology: 0 - GSM/GPRS, 2 - UMTS (Not available on all cards)

Enter the Network ID to attempt manual registration
[blank = automatic selection]:
Registration request accepted
Command was: AT+COPS=0

Ahora que todo funciona, ya podemos proceder a realizar la conexión. Para ello configuraremos el wvdial:

sudo vim /etc/wvdial.conf
Nota: Tanto el username como la password deberá ser cambiada para que coincida con el operador que tengas. En el caso de Orange, es CLIENTE y AMENA, pero sé que en Movistar y Vodafone esto cambia. Mira en tu teléfono la configuración del servicio, pregunta en tu operador o consulta por internet.
De igual forma, deberás cambiar el APN. En el caso de Orange es "internet", pero cambiará igualmente con Vodafone y Movistar. El resto de la configuración debería ser la misma

[Dialer Defaults]
Phone = *99***1#
Username = CLIENTE
Password = AMENA
Stupid Mode = 1
Dial Command = ATDT
New PPPD = yes

[Dialer hsdpa]
Modem = /dev/noz0
Baud = 460800
Init2 = ATZ
Init3 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ISDN = 0
Modem Type = Analog Modem

[Dialer 2gonly]
Init4 = AT+COPS=0,0,"internet",0

[Dialer 3gonly]
Init4 = AT+COPS=0,0,"internet",2

[Dialer orange]
Init5 = AT+CGDCONT=1,"IP","internet";

[Dialer 384k]
Init6 = AT+CGEQMIN=1,4,64,384,64,384
Init7 = AT+CGEQREQ=1,4,64,384,64,384

[Dialer 144k]
Init6 = AT+CGEQMIN=1,4,64,144,64,144
Init7 = AT+CGEQREQ=1,4,64,144,64,144

[Dialer 64k]
Init6 = AT+CGEQMIN=1,4,64,64,64,64
Init7 = AT+CGEQREQ=1,4,64,64,64,64

Modifica igualmente la configuración del wvdial para ppp:
sudo vim /etc/ppp/peers/wvdial

Con esta información:
plugin passwordfd.so
noauth
name wvdial
replacedefaultroute
noipdefault
nomagic
usepeerdns
ipcp-accept-local
ipcp-accept-remote
nomp
noccp
nopredictor1
novj
novjccomp
nobsdcomp

Finalmente comprobaremos que podemos conectarnos... y navegar!!!
sudo wvdial hsdpa orange

Deberemos ver una salida de este tipo:
--> WvDial: Internet dialer version 1.56
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1,"IP","internet";
AT+CGDCONT=1,"IP","internet";
OK
--> Modem initialized.
--> Sending: ATDT*99***1#
--> Waiting for carrier.
ATDT*99***1#
CONNECT 1800000
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Tue Nov 14 11:16:57 2006
--> Pid of pppd: 15133
--> Using interface ppp0
--> local IP address 83.231.16.108
--> remote IP address 213.143.42.106
--> primary DNS address 213.143.32.20
--> secondary DNS address 213.143.33.8
--> Connect time 0.1 minutes.
--> local IP address 83.231.16.108
--> remote IP address 213.143.42.106
--> primary DNS address 213.143.32.20
--> secondary DNS address 213.143.33.8

Ahora que ya estamos dentro, podemos crearnos un script de inicialización que ejecutaremos cuando queramos conectarnos.
sudo touch /usr/bin/3G.sh
sudo chmod a+x /usr/vim/3G.sh
sudo vim /usr/bin/3G.sh

Script:
-----
#!/bin/bash

case $1 in
start | init)
echo "Cargando modulo"
sudo modprobe nozomi
echo "Inicializando tarjeta 3G"
sudo gcom -d /dev/noz0
wait
echo "Conectando"
sudo wvdial hsdpa orange
;;
eject)
echo "Ejectando tarjeta"
sudo pccardctl eject
echo "Ya puede retirar la tarjeta"
;;
* )
echo "Uso: 3G.sh [start|eject]"

Uso:

Para iniciar la conexión:
sudo 3G.sh start

Para finalizar la conexión: CTRL^C

Para sacar la tarjeta
sudo 3G.sh eject

Prevenir mejor que curar

Según un informe del reputado economista Sir Nicholas Stern, remitido directamente a Tony Blair, parece claro que el impacto de la actividad humana sobre el medio ambiente va a tener consecuencias, por mucho que nuestro presidente del mundo (George Bush) se empeñe en negarlo.
Se ha escrito mucho sobre la exageración de los efectos que el calentamiento global puede causar en nuestro planeta (sin ir más lejos, la última novela de Michael Crichton apunta en este sentido), si bien todo parece indicar que cuando el río suena, agua lleva.
El hecho de que una alta personalidad del mundo económico sea quien haya alertado del coste que esto podría acarrear a nivel mundial (un impacto 20% del producto interior bruto mundial) frente a lo que podría costar evitarlo (un 1%) da mucha más trascendencia al asunto. El que además haya puesto cifras a las hasta ahora apocalípticas predicciones lanzadas por los grupos ecologistas da todavía más peso a este informe.
En cualquier caso, ese 1% del producto interior bruto mundial
equivaldría a la friolera de 610.000 millones de dólares... o algo así como 60 veces el producto interior bruto español... se dice pronto... :-o