Con un poco de zoom, podemos ver la diferencia entre el AMOLED del Nexus One y la pantalla LED del Nexus S:

Nexus One	Nexus S

El resultado es tan ligero que parece subjetivo, pero la realidad es que el LED del Nexus S se ve más nitido que el AMOLED del Nexus One.

No sé en qué estará pensando Samsung al ponerles nombres a sus tabletas, pero la verdad es que la están armando. Ahora mismo, podemos ver:

• Samsung Galaxy Tab - GT-P1000
• Samsung Galaxy Tab 10.1v - GT-P7100
• Samsung Galaxy Tab 10.1 - (GT-P7500/GT-P7510)

Así a primera vista, uno pensaría que, de menor a mayor, irían "Tab, 10.1, 10.1v"... pero no es así. Resulta que el "Galaxy Tab 10.1" es un modelo superior del "Galaxy Tab 10.1v" (WTF?!), mientras que el "Galaxy Tab" a secas es una versión como quien dice beta. Si se lo querían complicar a los compradores, no veo mejor forma que esa.

Tampoco ayuda mucho el que por delante las tabletas sean prácticamente idénticas:

La forma de diferenciarlas, es dándoles la vuelta y mirando la posición de la cámara... diferente en cada una y que obliga a que las fundas protectoras también tengan los agujeros en lugares distintos:

P1000	P7100	P7500/P7510

Y la diferencia entre los modelos no es moco de pavo. La P7100 trae una cámara trasera de 8Mpx, sí, pero las P7500/P7510 traen una de 3Mpx con autofocus, que por mucho Mpx no se consiguen mejores fotos si están todas borrorsas.

Una de las quejas sobre los juegos multijugador online, es que están basados en objetos. Esto es, a medida que el personaje avanza en el juego, va recogiendo objetos que representan su progreso, y su capacidad para desenvolverse dentro del mismo, hasta el punto de que a un personaje con objetos de un nivel inferior le es prácticamente imposible hagar frente a otro personaje con objetos de nivel superior. Ya no digamos cuando la diferencia supone más de un nivel. La misma diferencia se nota de manera muy acusada no sólo entre los personajes, sino también entre personajes y elementos del mundo de juego.

Al mismo tiempo, al entregarse objetos en propiedad a los personajes, no pueden crearse objetos únicos en el juego dado que nunca se sabe cuándo el personaje dejará de existir o, simplemente, el jugador dejará de conectarse al juego. Y aunque esto pudiera solucionarse con personajes persistentes en el tiempo independientemente de la conectividad de los jugadores, tales soluciones presentan otros problemas aún mayores (compartición de personajes, IA, etc.).

Otra queja bastante común, en los juegos con modo cooperativo, que por otro lado son los que brindan mayores posibilidades, es que por culpa de jugadores incapaces de desempeñar una serie de funciones básicas, el resto de jugadores sufren una derrota al ser incapaces de conseguir los objetivo marcados para el grupo. Esto se debe en gran medida a que jugadores con poca experiencia sobreestimar su propia capacidad para hacer frente a los objetivos del juego, llegando a desoír las advertencias e insinuaciones del resto de jugadores y conduciendo al grupo al desastre.

La solución posible a ambos problemas, podría ser el uso de "puntos de combate". Esto es, puntos asignados a cada jugador en función del desempeño de sus funciones durante los combates, de cara a la consecución de los objetivos de cada misión. De esta forma jugadores con un mejor desempeño podrían tener acceso a mejores armas exclusivas y únicas en el mundo, entregadas solamente en el momento de iniciar el combate determinado, acceso a funciones de mayor responsabilidad, tales como generales o guías, ofreciendo al mismo tiempo una mejor experiencia al resto de jugadores en modo cooperativo. Al mismo tiempo, se podría mejorar la asignación de las posiciones en las batallas para dar preferencia a los jugadores más experimentados, o aplicar factores de corrección en función de las experiencias relativas de las facciones, sin obligar al mismo tiempo a ningún jugador a comprometerse más allá de lo deseado.

Los puntos de combate podrían ser asignados de forma general, o repartidos en categorías según las acciones desempeñadas durante un combate determinado. Por ejemplo, un jugador experimentado en el combate cuerpo a cuerpo, no necesariamente tendría que tener un buen desempeño en la organización estratégica de una batalla, y viceversa. Creando categorías según las funciones, se podría optimizar el desempeño de los jugadores de forma adaptativa, para ofrecer una mejor experiencia de juego en beneficio de todos. Como beneficio adicional, también aumentaría la posibilidad de los jugadores de aparecer en listas de "top 10" dentro de su especialidad.

Para implementar un sistema de este tipo, haría falta definir los parámetros del combate de forma algorítmica, así como definir funciones de evaluación del desempeño de los jugadores en pro de la consecución del objetivo de la misión. Habría que tener en cuenta que cada acción de un jugador puede tener consecuencias tanto directas por medio de sus acciones, como indirectas en el tiempo o secuencia, y el espacio o posición. Posiblemente para una aproximación práctica no sería suficiente una valuación estática con asignación de puntos tras concluir el combate, sino que se haría necesaria una evaluación dinámica tomando en cuenta los objetivos y el desempeño comparativo con datos estadísticos similares, a medida que estos fuesen siendo recopilados.

Durante este fin de semana me ha tocado recuperar una copia de seguridad, y me he dado cuenta de que guardar copias de seguridad horarias de rdiff-backup durante un año es una gran idea... salvo por un problema: la cantidad de ficheros generados puede acabar siendo tal, que el sistema no es capaz de procesarlos de forma eficiente al intentar hacer un simple listado. En concreto, dado que las copias de seguridad se ejecutan de forma constante guardando ficheros en directorios dispares, para realizar el listado de un solo directorio que puede contener decenas de miles de ficheros, cuando la cantidad superada un límite de entre 50,000 y 100,000 ficheros, el sistema debe buscar tantos sectores aleatorios para juntar el listado completo de un solo directorio, que la velocidad de acceso durante la realización de un listado baja en picado.

Desde hace bastante tiempo, antes incluso de conocer rdiff-backup, tenía la idea de poder crear copias de seguridad de cada poco tiempo, y posteriormente poder consolidar las más antiguas para ahorrar espacio. En el caso de rdiff-backup esto realmente no es necesario ni eficiente para un número pequeño de copias y/o con una política de borrado periódica de las copias más antiguas. Sin embargo, cuando el número de copias se hace tan elevado como lo que decía antes, el problema deja de ser tanto del espacio ocupado por las copias de seguridad, como intentar reducir la fragmentación y el espacio ocupado por los listados mismos de los ficheros. En un sistema de copias de seguridad diseñado desde cero, todos los meta datos de las copias de seguridad deberían estar almacenados en una base de datos. El problema de rdiff-backup consiste en que usa como "base de datos" la misma estructura de directorios del sistema, que no está realmente preparada para manejar cantidades tan ingentes de elementos. Posiblemente, y esto no lo he probado, sistemas de ficheros basados en un árbol balanceado, pudiesen hacer frente a estos problemas (viene a la cabeza el malamente famoso reiserfs).

Mientras tanto, la solución pasa por:

• una herramienta para rdiff-backup que permita consolidar copias antiguas (las intermedias entre dos fechas dadas)
• usando una herramienta capaz de consolidar deltas de rdiff/librsync

Esta segunda parte es por donde he empezado, y tras unas horas de investigación (librsync, menudo jaleo de código) junto a otras cuantas de programación, aderezado todo con alguna que otra volviéndome loco con un par de bugs, hoy me desperté con la solución al último de todos, que permitía al código pasar todos los tests que tenía preparados.

El funcionamiento de rdiff-delta-merge es muy simple:

• se le ofrece una serie de ficheros delta
• devuelve un fichero delta que sirve para sustituirlos.

Internamente, la herramienta realiza una unión de todos los ficheros delta, resultado de aplicar los cambios de uno a otro sobre el primero de ellos, conservando todas y sólo las secciones literales necesarias para generar el fichero final.

En el caso de ficheros delta referentes a cambios continuados desde el todo o gran parte de un fichero, el ahorro de espacio respecto a mantener todos los ficheros delta separados es considerable, dado que sólo se guardar la parte literal del último de ellos. Lo mismo ocurre si los ficheros delta se refieren a movimientos de secciones de un fichero, o de una mezcla de ambos. Solamente no sea ahorra espacio en caso de crecimiento secuencial de un fichero (aunque, como he mencionado al principio, sí sea ahorra el no tener tantos ficheros sueltos por ahí).

Por ahora el algoritmo parece que funciona, aunque no está demasiado optimizado. Por ejemplo, le falta juntar secciones literales del fichero delta resultado, y está el tema de pasarlo de C++ a C a secas... cosa que no sé si me voy a animar a hacer.

Descarga:

• http://www.jarfil.net/forge/rdiff-delta-merge-0.1.tar.gz

Más información en la wiki:

• rdiff delta merge
• rdiff-backup delete intermediate

Ahora que toca veranito, parece que en PcBox se han puesto las pilas alpargatas y han decidido remodelar la web... llenándola de cagarrutas flash estúpidas sin ton ni son.

Para el que le toque las narices tanto como a mí ver una web que se arrastra, por simples estupideces como objetos flash separados para meter fondos estáticos, o simples transparencias flotantes, basta con copiar y pegar las siguientes reglas de exclusión en el AdBlock de turno (el que no lo use, que se lo adapte a lo que sea):

|http://www.pcbox.com/catalogo/imagenes/1/es-ES/novedades.swf
|http://www.pcbox.com/catalogo/imagenes/1/es-ES/topVentas.swf
|http://www.pcbox.com/banners/secciones/*.swf
|http://www.pcbox.com/cflash/1/bordeIzq.swf
|http://www.pcbox.com/cflash/1/bordeDer.swf
|http://www.pcbox.com/cflash/1/filtrar*.swf
|http://www.pcbox.com/cflash/1/listado*.swf
|http://www.pcbox.com/cflash/fondoBanner.swf

Ale, menos pijerío y a mamarla.

Opcionalmente, a pasar olímpicamente de esta tienda, que será lo que hagan el resto de clientes; total, últimamente ya van subiendo los precios que da gusto. A ver si les funciona la estrategia (ja! )

Me llama mi madre:

Riing riing...

- ¿Sí?
- Mira ahora rápido si encuentras a José Ignacio Boyero.
- ¿Qué?
- En internet.
- Vale, veamos.

Lo tecleo en Google.

- Pero es urgente - me increpa.
- Hm... veo algo de un tal José Ignacio Boyero San José, ¿ese?
- No sé el segundo apellido.
- Pues, José Ignacio Boyero a secas, hay muchos.
- Busca donde están los médicos, a ver qué ponen de él.

Vaaale... claro, ¿cómo no se me habrá ocurrido?, "donde están los médicos".

- Eso no existe, ¿qué es lo que quieres encontrar exactamente?
- A José Ignacio Boyero.

Sigo mirando... ¿+médico? ¿+bilbao? ¿Boyero San José?... hm.

- Por cierto, el San José es de Salamanca.
- No no, donde están los médicos de Bilbao.
- Pues veo muchos Boyero, pero ningún médico de Bilbao.
- Es que estoy buscando su dirección.

Espera... ¿su dirección? ¿resultará que lo que quiere es la dirección?

- Esto... a ver, ¿lo que necesitas es su dirección?
- No, quiero saber qué dicen de él.
- ¿Entonces para qué quieres darme su dirección? No veo ningún médico de Bilbao que se apellide Boyero.
- Que lo he encontrado antes.
- ¿Lo has encontrado? ¿dónde?
- No recuerdo.
- Menudo imbécil, 32 años y... - se oye decir a mi padre.

¡Click!

Buen intento, pero tarde.

Pues sí, va a ser que soy imbécil.

Ayer, en un viaje para recordar la masacre de Katy?, se ha estrellado el avión en el que iban el presidente de Polonia, junto con representantes del gobierno y otras gentes importantes. El presidente del banco nacional (NBP), representantes de diversas organizaciones de damnificados, y gente relacionada.

Lo han vuelto a hacer.

Hace 70 años, nada más empezar la II Guerra Mundial, tras pactar con los nazis el reparto de Polonia (pacto Ribbentrop), reunieron a todos los generales del ejército polaco y los fusilaron. Luego, cuando resultó que los nazis en realidad eran los malos, se han pasado 70 años mintiendo y ocultando la atrocidad que cometieron.

Ahora, lo conmemoran... ¡cargándose al presidente y medio gobierno!

Lech Kaczy?ski, en calidad de jefe supremo de las Fuerzas Armadas Polacas, tenía costumbre de imponer su rango para obligar a pilotos a aterrizar, desoyendo las recomendaciones de la torre de control de turno.

En este caso, el piloto intentó aterrizar hasta ¡cuatro veces!

A la cuarta, tras abortar el aterrizaje, debido a la espesa niebla y seguramente nervioso por las órdenes del Presidente, no vio los árboles del final de la pista, chocando contra ellos con los motores y convirtiendo el avión en una bola de fuego, masacrando a todos los que estaban a bordo.

El piloto, tras ser advertido por la torre de control, se empeñó en aterrizar aún en condiciones adversas, y por un fallo suyo el avión reventó.

...y hasta aquí puedo leer.

La respuesta, cuando avance la investigación y haya pruebas.