Ubuntu Linux 10.04 (64bits) on a Sony Vaio VPCEB2X5E

Other names for the model (for Google): VPC EB 2X5E VPCEB 2X5E

Specs

  • CPU: i5 2.40Ghz
  • RAM: 6GB
  • GPU: ATI MobileRadeon HD5650 with 1GB RAM
  • Hard Disk: 320GB 5400 RPM
  • Screen: 15.4’’

Things that worked

  • Ubuntu installed fast and flawlessly, including the Windows 7 partition resizing. If you want to get more space you can delete the second partition (the one marked as “Windows Vista") because is the Sony recovery partition (and on this laptop takes a lot of space).

  • Once installed, I run the propietary driver installation program (is somewhere under Menu->Administration) and it installed the ATI fglrx drivers. A reboot later, I was on a fully 3D accelerated desktop with compiz and the effects automatically enabled. No “beta driver” watermark was shown, no graphical glitches were found and the accelerated effects all work beautifully. Good job on AMD/ATI on this one.

  • The integrated webcam worked perfectly out of the box (tested with Skype), without needing to install anything. Finally I can show my penguin on Chatroulette!

  • No network or WIFI problems.

  • Suspend and hibernate work perfectly. Everything is restored when the computer wakes up.

  • HDMI output works perfectly with my Samsung TV, but if you want to hear anything on the TV you must remember to select HDMI as audio output: click on the sound icon on the taskbar, click on “Sound Settings” under the volume control, choose the “Output” tab and finally select “Redwoord HDMI Audio [Radeon 5600 Series]”.

  • Of the Fn functions the volume/mute keys work (but see below about sound), as does the suspend and the keys for alternating the output (HDMI/monitor/both) and but the ones for the screen brightness one don’t. No problem, since I can changue the gamma of the monitor with xgamma anyway.

Things that didn’t work (with a fix)

  • The Fn functions for the screen brightness doesn’t work.

The only other problem I found is that the sound didn’t work. After a five minutes Google search I found an easy solution; just follow these steps on a terminal:

  1. wget http://ftp//ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-verb/hda-verb-0.3.tar.gz
  2. tar xf hda-verb-0.3.tar.gz
  3. cd hda-verb-0.3
  4. make
  5. sudo cp hda-verb /usr/bin
  6. sudo gedit /etc/rc.local
  7. Add the following line before exit 0 : /usr/bin/hda-verb /dev/snd/hwC0D0 0x19 SET_PIN_WIDGET_CONTROL 0x22
  8. Save and reboot (or run “sudo /usr/bin/hda-verb /dev/snd/hwC0D0 0x19 SET_PIN_WIDGET_CONTROL 0x22” to avoid rebooting)

In order to enable the sound after suspend do:

  • sudo gedit /etc/pm/sleep.d/15_sound
  • Put this content:

    #!/bin/sh

    case “$1” in resume) /home/juanjux/bin/hda-verb /dev/snd/hwC0D0 0x19 SET_PIN_WIDGET_CONTROL 0x22 ;; esac

  • Save
  • Run on a terminal: sudo chmod +x /etc/pm/sleep.d/15_sound

It seem that this problem has already been fixed on recent kernel versions so maybe you won’t need to do it.

Some tuning

I found the screen gamma was to high on the LCD, so testing with the “xgamma” command I found that the setting 0.60 ("xgamma -gamma 0.60") was perfect for me, so I made it permanent adding these lines to /etc/X11/xorg.conf (edit the file as root with sudo):

Section "Monitor"
    Identifier  "Generic Monitor"
    Option   "DPMS"
    Gamma    0.6
EndSection

Conclusion

This is a perfect machine to run Linux in.

Rails y Django

Pues nada ya puedo decir que se Rails sin experiencia. Conozco todo el ORM, el scaffolding, los helpers de AJAX, las funciones de los controladores, las vistas, etc.

Debo decir que sin duda alguna es más potente que Django en cuanto a funcionalidad; tiene cosas más avanzadas en la parte de ORM (aunque la generación de los modelos es más rústica, pero con los scripts que trae al final tardas menos en generar los modelos), hace migraciones casi automáticas hacia delante y hacia atrás, en las plantillas empotras directamente Ruby (no un lenguaje de plantillas), los helpers de AJAX molan, etc. Si miro los cambios de las versiones 1.1 y 1.2 de Django realmente lo que veo es que juegan a hacer catchup con Rails, pero Rails ya va a sacar la 3.0 que tiene mogollón de cosas nuevas. Lo único que Django tiene que no tenga Rails es el admin; pero en Rails hay un módulo que hace un admin más chulo incluso que el de Django (usando AJAX en todo).

Sin embargo…

Empecé a picar el esqueleto de mi proyecto veraniego. Generé los modelos, controladores y demás (con los scripts estos de scaffolding la verdad es que te ahorras muchísimo tiempo haciendo boilerplate, es algo que tendrían que meter en Django sí o sí), empecé a implementar funcionalidad en los controladores, pero…

Pero entonces miré el código. QUE FEALDAD. Que feo es Ruby, como decía mi amigo Miguel, es como otro Perl. En Django uno mira el código, y ve algo escueto, bonito, que hasta alguien que no conozco Python o Django pero sepa programar en cualquier otro lenguaje prácticamente lo entiende.

Así que mi proyecto veraniego va a ser con mi amado Django. Para el tema de integrar AJAX sin meter mucha basura voy a usar Dajax que ayuda mucho.

Ruby Vs Python

I’m learning Ruby, coming from a Python background.

Python is clearer, easier, more mantenible and usually faster.

Ruby is elegant, concise and sometimes misterious.

The thing is clear:

Python is a dog and Ruby is a cat

Mini revisión de Android 2.2 "Froyo" en el Nexus One

Pues nada, ya tengo la versión rooteada que hay por ahí, iba a hacer una revisión cojonuda del tema, pero como me duele un poco la cabeza haré ésta.

Sobre el JIT y las distintas optimizaciones, la verdad es que va muy bien, pero antes también iba bien en cuanto a velocidad y multitarea, así que en eso no hay mucha diferencia y no puedo decir que el JIT haya cambiado mi vida; también es verdad que no uso juegos. Tampoco noto una diferencia extrema con respecto a que el navegador tenga el motor javascript V8; lo mismo, sigue funcionando bien aunque sí que vi que monstruos como el Google Wave cargan mejor.

El Flash funciona y funciona correctamente; se pueden ver vídeos de Vimeo, Gametrailers y demás sin problemas, y los juegos chorras flash que he probado lo mismo. Lo único que jode un poco es cuando cargas una mierdapágina que tiene mucho Flash empotrado para anuncios y tonterías (tipo ElMundo o similar) porque se ralentiza mucho la carga. Por suerte se puede configurar para que cargue bajo demanda (tocando) que es como lo he puesto.

Lo que si me ha gustado mucho, como desarrollador, es que las aplicaciones cuando petan tienen la opción de mandar el stack trace al desarrollador, que luego te sale en tu página del Market. A mi me han llegado ya 3 que me han servido para arreglar un bug. Eso va a hacer que las aplicaciones del Market mejoren mucho, pues antes si no podías reproducir el bug tenías que decirle al usuario que se instalase el alogcat y te mandase un volcado, y muchos usuarios simplemente pasan (no están tan interesados por el programa como para ponerse a hacer eso) y otros se lían.

Otra cosa que me ha gustado es lo de poder cambiar el idioma del teclado (y del corrector) al vuelo porque yo a veces escribo en castellano o en inglés, según la web o el email. También lo de sincronizar opciones en “la nube” (o sea, en servidores de Google en idioma no-pedante), me va a venir muy bien porque reinstalo con frecuencia para probar firmwares.

La cosa de envíar pushes al móvil es útil para mandarte páginas con la extensión de Chrome, aunque tampoco es una gran diferencia con respecto a enviarte un email a ti mismo y pinchar el link. Imagino que los desarrolladores le darán usos útiles en el futuro, aunque pudiendo en Android tener programas que se levanten con alarmas o se ejecuten como servicio no es tan útil como en un iPhone.

Estaría bien que el reconocimiento de voz para escribir en campos de texto lo traiga en español, con mi inglés lo que digo generalmente no tiene nada que ver con lo que escribe, a veces escribe cosas bastante divertidas, el otro día se me saltaron los lagrimones cuando le dije algo y lo transcribió como “Ride the lady for the fun”.

Lo demás, hotspot WIFI, instalar cosas en la SD, más memoria activada, software de cámara mejorado y kernel más nuevo lo tenía ya el Cyanogen que venía usando (y que volveré a usar en cuanto haga una versión basada en 2.2).

Está claro que Google y el resto de desarrolladores que contribuyen a Android van como una locomotora, en sólo año y medio han metido muchísimas mejoras y la competencia, iPhone, Maemo, Windows Mobile 7, y WebOS van a tener que sudar sangre para pillarles. RIM no lo pongo como competencia porque siempre fue un zurullo a pesar de lo cual vende como churros, en ese caso Google y los demás tendrían que hacer un genocidio con los clientes de RIM para ganarles o cambiar el target para orientarse hacia cierto tipo de usuario que no da más de si, cosa que tampoco les conviene.

Redes Sociales Distribuidas (explicado para no geeks)

Sin duda una de los productos más disruptivos en Internet en los últimos 5 años han sido las redes sociales. El motivo es que permiten comunicarnos con nuestros amigos/socios/clientes de una forma más cómoda que los métodos existentes anteriormente, generalmente la mensajería instantánea o el email, pues escribiendo en un sólo sitio nuestras actualizaciones de estado, que pueden ser desde contar como nos va la vida, lo que estamos haciendo, poner un link, una foto o un álbum de fotos (entre otras cosas). Anteriormente lo normal era que cuando teníamos algo que comunicar a cierto número de nuestros contactos les mandáramos un email, que es más intrusivo, sobre todo cuando el receptor no está interesado en lo que estamos diciendo.

Las redes sociales también suelen permiten crear grupos con los que organizar nuestros contactos y algunas permiten crear eventos para los cuales los asistentes pueden confirmar o rechazar asistencia. Además, algunas redes sociales (más notablemente Facebook) permiten a terceros desarrollar aplicaciones que pueden interactuar con el usuario, que pueden ir desde encuestas o juegos a cosas realmente útiles como generadores de estadísticas o grafos de nuestra red de contactos.

Una de las primeras redes sociales que consiguieron popularidad en los Estados Unidos fue MySpace, aunque en otros países triunfaron más otras redes como Orkut. Sin embargo, la gran ganadora de las carreras de las redes sociales ha sido sin duda Facebook. La razón por la que ha tenido tanto éxito no es obvia, aunque sospecho que tiene que ver con que la página en sí era mucho más usable que MySpace (que es un horror) y que tomaba la filosofía de que sólo compartíamos con nuestros amigos, al contrario que MySpace donde por defecto se compartía todo públicamente. No voy a incluír Twitter o Google Buzz como redes social en este artículo, a pesar de su popularidad carecen de algunas de las funcionalidades que hacen realmente útiles a las demás porque permiten sólo publicar actualizaciones de estado o enlaces.

Pero las tecnologías de Internet siempre están en movimiento y en 2009 y 2010 están surgiendo un nuevo tipo de redes sociales, las redes sociales distribuidas (también llamadas redes sociales federadas). La diferencia de estas redes sociales con respecto a las tradicionales como Facebook o MySpace, es que si en las segundas toda nuestra red de contactos, nuestras actualizaciones de estado, grupos, y en resumen toda nuestra información las mantiene el proveedor del servicio sin posibilidad de interconexión directa con otras redes (salvo de forma indirecta a través de herramientas de terceros), en las distribuidas, pueden existir varios proveedores distintos. En el caso de las redes centralizadas normalmente estamos hablando de compañías privadas y les interesa tener el mayor número de usuarios, evitando la migración hacia otros proveedores. Sin embargo la mayoría de tecnologías de Internet no funcionan con el modelo de proveedor único y servicios incompatibles sino con otro modelo que hoy se suele denominar federado.

¿Cómo funciona este modelo? Pensemos en un ejemplo sencillo: el correo electrónico. Aunque existen grandes proveedores de correo electrónico (GMail, Hotmail, Yahoo Mail) todos esperamos que si pepito@gmail.com envíar un email a manolita@hotmail.com el mensaje llegue perfectamente. Incluso podemos crear nuestro propio servidor de correo “@pepitoperez.com” sin mucha dificultad (sólo nos haría falta un servidor permanentemente conectado a Internet) y este servidor seguirá comunicándose sin problemas con los “grandes” o con otros servidores pequeños. Siguiendo con el ejemplo del email, a nadie se le ocurriría usar hoy por hoy un servicio de correo “fistromail.com” que sólo permitiera enviar mensajes a usuarios del mismo servicio. Sin embargo exactamente así es como funcionan las redes sociales mayoritarias en 2010.

Las redes sociales distribuidas que han estado surgiendo en los últimos dos años aspiran a crear tecnologías (protocolos e implementaciones) que permitan, sin perder las funcionalidades existentes, crear redes sociales constituidas por distintos proveedores pero que puedan comunicarse entre sí, de modo que a efectos del usuario es como si fuera una gran red única. Volviendo al ejemplo práctico, si imaginamos un futuro no muy lejano donde un protocolo se comunicación (el “idioma” que hablarían los distintos proveedores de redes sociales entre sí) se ha establecido como estándar (por ejemplo “OStatus” sobre el que hablaremos después), podemos tener una cuenta en el servidor de red social que proporcione Google, pongamos “pepito@googlesocial.com”, pero también podremos añadir como amigos a gente que tenga una cuenta en otros proveedores, por ejemplo “manolita@msnsocial.com”. Exactamente igual que el correo, como se puede ver. El usuario no tendría que preocuparse de saber si manolita va a un servidor u otro, sería el sistema el que se encargaría de forma transparente de saber que el contacto “Manolita” tiene sus datos en msnsocial.com, y comunicar con dicho servidor para recibir sus actualizaciones de estado, comentarios, eventos, y enviarle a su vez los de Pepe. También, de nuevo como en el caso del correo, Guillermo, que es un friki y además un paranoico de la privacidad, puede instarse en un servidor que tiene en su casa, un software de red social distribuida comunicando igualmente bien con el resto de sus contactos.

Si hemos entendido la explicación podremos ver que este nuevo tipo de redes sociales tiene varias ventajas sobre el modelo centralizado, siendo la principal que no dependemos de un proveedor único, de modo que si no nos gusta por cualquier motivo (porque va muy lento, porque se vuelve malvado y empieza a vender nuestros datos, por lo que sea), podemos cambiarnos a otro sin perder nuestra red social. Además al existir varios proveedores para un mismo servicio en el cual no pueden encerrar a los usuarios con incompatibilidades es de esperar que aquellos con interés comercial en tener el mayor número compitan entre sí ofreciendo mejoras reales como mayor velocidad, más funcionalidades o interfaces de uso superiores (exactamente como compiten los proveedores de webmail hoy en día.)

Imagino que ahora muchos de los que hayan leído ésto querrán probar ésto. La mala noticia es que hoy por hoy el idílico panorama que he relatado no existe. Sin embargo, se están produciendo avances rápidamente por varios frentes para llegar a ello. Es de esperar que al igual que han habido dos “guerras de navegadores” dentro de poco presenciemos una “guerra de redes sociales” donde existan varias redes sociales interesantes, algunas centralizadas (Facebook) y otras distribuidas pero usando distintos protocolos (es decir, no podrán hablar entre sí) de la cual es probable que salga un ganador. Estas guerras, en mi opinión, no son malas pues provocar que los productos involucrados mejoren a pasos agigantados. Y no creo que las redes sociales centralizadas sobrevivan a esta guerra salvo que se adapten al modelo distribuido.

De todas formas para hacernos una idea de como va la cosa, voy a poner algunas de las tecnologías en desarrollo que hoy por hoy me parecen más interesantes, pero antes es necesario hacer un pequeño inciso que intentaré mantener lo menos técnico posible.

Protocolos e implementaciones

Cuando en Internet hablamos de protocolos, nos referimos a una forma de comunicación entre dos máquinas para un fin concreto. Como un idioma que hablan dos máquinas entre si.

Internet se puede considerar que no es más que un montón de máquinas hablando protocolos entre sí para proporcionar distintas funcionalidades. Por ejemplo cuando cargamos una página web en el navegador, nuestro PC está usando varios protocolos para comunicarse con la máquina que le tiene que dar la web. El protocolo que se usa para decir “dame esta página web”, el de la WWW, se llama HTTP. Pero HTTP es un protocolo “de alto nivel” lo que quiere decir que debajo del mismo hay otros, muy especialmente el protocolo TCP/IP que es el más importante de Internet (aunque hay otros protocolos de bajo nivel.) Para entendernos, si estamos hablando con un amigo por teléfono, el teléfono sería el “protocolo de bajo nivel” mientras que el lenguaje español sería el protocolo de alto nivel; no es posible hablar a distancia sin el de teléfono, de igual modo que aunque tengamos el teléfono no podemos comunicarnos con nuestro amigo si no hablamos el mismo idioma.

Pero el protocolo en sí no es suficiente para que se establezca la comunicación; del mismo modo que un idioma no sirve de nada si no hay al menos dos personas que lo usen, un protocolo no sirve de nada si no hay un programa que lo utilice. En el caso de cargar la página web los dos programas que lo usan son, por nuestro lado, el navegador, y por el lado de la máquina que nos da la web, el servidor web. Sin embargo al igual que no existen dos personas iguales, no hay un único navegador (podemos usar Firefox, o Chrome o Explorer, entre otros) ni un único servidor web (aunque esto nos suene menos están Apache, Nginx, MSII, etc.) Podemos elegir diferentes programas, tanto nosotros como la persona que tiene el servidor que nos da la página, pero como hablan el mismo “idioma” (protocolo) todos pueden comunicarse entre sí. En este caso decimos que existen distintas implementaciones del protocolo.

Esta parrafada que acabo de soltar era necesaria porque cuando hable de redes sociales distribuidas, aunque nosotros como usuarios generalmente vamos a acceder a las mismas a través de una página web, tiene que haber un protocolo que comunique los distintos servidores que componen la red para que puedan intercambiar las actualizaciones de los usuarios entre sí. Si no hablasen entre si no serían muy distribuidas ¿verdad? Teniendo ya un protocolo de comunicación, ya no será necesario que los programas - las implementaciones - sean iguales, puede haber distintos programas creados por distintos programadores que a través del protocolo hablen entre sí.

Pasemos a ver, ahora sí, las implementaciones y protocolos de redes sociales distribuidas que me parecen más interesantes a día de hoy.

Diaspora

Protocolo: OStatus (ampliado)

Estado: inicial sin nada publicado

Diaspora tiene una historia interesante. Como muchas otras grandes cosas en el mundo de la tecnología (Mac, Windows y Linux, por ejemplo), ha surgido de la mente de unos chavales recién licenciados pero con muchas ganas de hacer cosas. Diaspora pretende implementar todas las funcionalidades que podemos esperar de una red social hoy en día (como Facebook) pero de forma federada, siendo la implementación software libre (en resumen muy resumido, con “las tripas a la vista” y por lo tanto facilitando contribuciones de terceros), y con un énfasis muy importante en la seguridad de las comunicaciones.

Los padres de Diáspora son cuatro programadores de la universidad de Nueva York que anunciaron con una serie de vídeos y textos su intención y crearon un proyecto en Kickstarter, una web para conseguir financiación a través de donaciones, con la intención de recaudar 10.000$ con los que poder trabajar intensamente durante el verano para crear una primera versión de su idea. La parte interesante es que su anuncio coincidió con una oleada de indignación pública contra Facebook (en el sector freak de la población, al menos) por hacer el enésimo cambio en sus políticas de privacidad y sus opciones por defecto de modo que en lugar de los 10.000$ que querían a día de hoy 17 de mayo llevan más de 170.000$. Con ese montón de dinero posiblemente no sólo consigan trabajar durante el verano como querían, sino que tendrán para vivir durante uno o dos años trabajando exclusivamente en el proyecto, por lo que es de esperar que se produzca un buen resultado .

Quizás la parte más interesante de Diaspora, y la que podría hacer que sea la solución que triunfe al final, es el interés público que ha causado; han salido en el New York Times además de casi todos los blogs tecnológicos grandes (Techcrunch, Boing Boing, Engadget, etc). Esto podría hacer que cuando el proyecto sea usable por el usuario normal, consigan un número inicial de usuarios interesante, algo extremadamente importante pues aparte de las consideraciones técnicas las redes sociales son más interesantes cuanto más gente tengan.

Los autores de Diaspora han dicho que quieren usar como protocolo OStatus, pero trabajando con los autores del protocolo para ampliarlo y mejorarlo (por ejemplo, imagino que querrán añadir cifrado fuerte en las comunicaciones.)

OneSocialWeb

Protocolo: XMPP (ampliado)

Estado: inicial con versiones alfa publicadas

OneSocialWeb es un proyecto creado por el grupo de I+D de Vodafone en el cual están trabajando varios programadores a tiempo completo. El proyecto ya publicó una versión de varias partes (el servidor, la interfaz web y alguna otra cosa), aunque actualmente es una versión muy previa ("alfa") que todavía no hace mucho. Como en el caso de Diaspora, su intención es lanzar una primera versión usable para el final del verano. El código fuente de su trabajo también está disponible como software libre, aunque ahora mismo no aceptan contribuciones externas (salvo informes de fallos), algo que han prometido cambiar en el futuro.

El protocolo que usa OneSocialWeb es el XMPP, que es el mismo que usa el sistema de mensajería Jabber (usado por Google Talk o el chat de Facebook, entre otros), pero ampliándolo con una serie de extensiones para cosas como actualizaciones de estado, solicitudes de seguimiento y demás, más propias de las redes sociales.

Elgg

Protocolo: OStatus (aún no implementado)

Estado: producto completo pero no federado; comunicación federada en fase inicial

Elgg es interesante porque de los tres proyectos que comento es el único que tiene una versión que podría considerarse terminada (aunque lo siguen mejorando) implementando casi todas las características que se pueden esperar de una red social (perfiles, flujos de actividad, microblogging, páginas, widgets, grupos, fotos, etc). Además permite usar plugins para añadir nuevas funcionalidades, de los cuales hay una colección bastante extensa (más de 800 ahora mismo).

El problema es que la implementación actual de Elgg no está federada, por lo que si bien podremos crear usando el software (también libre) una red social en una máquina nuestra, no podremos comunicar con otros servidores, con lo cual lo que tendríamos es una especie de “minifacebook” que puede ser interesante para empresas o centros educativos pero no como herramienta global de Internet. Ellos mismos venden un servicio de hosting con un coste mensual para crear nuestra mini red social fácilmente sin conocimientos técnicos.

Elgg está en esta lista, sin embargo, porque algunas personas están implementando sobre el código de Elgg la posibilidad de que los servidores puedan comunicarse entre sí. El protocolo que se está usando para esto es OStatus, con lo cual podrían comunicarse con servidores que lo implementen como Diaspora.