Geek & Roll

En las últimas horas ha salido la noticia de un supuesto dongle USB que, al conectarlo al PS3, te permite copiar los juegos a una unidad externa para después ejecutarlos sin la necesidad del disco. El costo del dongle: $150 dlls. La noticia ha corrido como reguero de pólvora y no es para menos. De ser cierto, la última consola que quedaba de pie ante los crackers habría caído y de que manera. No hay nada que modificar, ni abrir la consola ni nada. Simplemente conectas el USB y listo.

Aparentemente no se trata de una unidad USB común y corriente, sino de un dongle USB. Es decir, no es una memoria, sino un modchip que se conecta al puerto USB con su propio procesador y firmware. Hasta el momento varias fuentes independientes han confirmado la autenticidad del producto, pero no ha llegado a manos de los consumidores.

Todo parece indicar que es real, pero hay $150 razones para esperar hasta una confirmación 100% confiable. Mientras eso sucede, pueden mantenerse informados en este mismo post que iré actualizando o en Ars Technica que ya cubrió la historia.

Update 1: Los Españoles de ElOtroLado han confirmado que se trata de algo 100% real. Visiten su post para más imágenes del dongle en funcionamiento.

Update 2 (tomarlo con una pizca de escepticismo): Se confirma que se ha filtrado desde un SAT de Sony, que se puede hacer de forma “casera”, que es posible que se bloquee en un futuro, que pueden marcar la consola para posibles baneos y que la distribución del JSJailbreaker (el software) será ilegal al incluir código propiedad de Sony. Fuente.

Update 3: Hay sospechas de que Geohot, el autor de los jailbreaks y unlocks para iPhone, esté detrás de todo esto. La sospecha viene de DemonHades y es bien sabido que no son mejores amigos, pero varias cosas tienen sentido como el hecho de llamarle Jailbreak (término popularizado por los hacks de Geohot al iPhone) cuando esto no tiene nada que ver con un Jailbreak.

Estaba esperando a que se calmaran los ánimos con aquello de la demanda de Oracle a Google con respecto a su uso de Java, para poder empezar a leer opiniones informadas sobre el tema y no el típico argumento de “Maldito Oracle, con ellos todo es sobre el dinero” o de “Pero Dalvik no es Java, estúpido Oracle” o de “Google tan buenos ayudando a Java a ser más popular y Oracle que los demanda, los odio”.

Pero ese tiempo aún no llega. El post más informado sobre el tema lo leí en el blog de Osvaldo Pinali, donde argumenta que Java es igual que Dalvik, es decir la máquina virtual (VM) que Google implementó para su sistema Android es, en esencia, lo mismo que Java. Tan es así que puede existir una herramienta relativamente sencilla que convierta las clases compiladas por Java del formato binario .class propio de Java al .dex propio de Dalvik. A nivel de código fuente es exactamente lo mismo con sus java.lang y toda la cosa. Convertir código compilado de Java a cualquier otra cosa es algo muy complejo, pregúntenselo a IKVM que ha tratado por años de convertir Java a .NET y le sigue costando bastante trabajo.

El punto es que la demanda tiene más trasfondo. Claro que tiene que ver con sacarle el mayor dinero posible a Google, pero también tiene que ver con el hecho de que Google en vez de pagarle a Sun por usar la Java VM, prefirió irse por el lado de implementar la propia y sacarle la vuelta al licenciamiento. Por supuesto que ya que iban a implementar una VM nueva, pues había que mejorar la existente y quien mejor que Google que tiene los recursos económicos y el conocimiento técnico.

Google no quiso pagar como lo hacen otros, RIM (los de la BlackBerry) por dar un ejemplo. Ahora Oracle quien se encuentra en una posición económica mucho mejor que la extinta SUN decide ir tras ellos, idea supuestamente producto del entonces CEO de SUN Jonathan Schwartz y que le plantó a Larry Ellison. Si Google hubiera decidido pagar a SUN por el uso de su tecnología, quien sabe, a lo mejor SUN todavía existiría (pero quien sabe, porque tenían una habilidad como pocos para no capitalizar).

Volviendo al tema de Dalvik (Android) y Java, ellos dos son uno mismo. Yo si pienso que Google con Android y GWT, ha ayudado a que más personas programen en Java haciéndolo aún más popular. Se agradece, pero eso no lo exenta de una demanda al tratar de sacarle la vuelta a las patentes de Oracle (por más ridículas que sean las patentes de software) ni convierte a Google en “el bueno”. Google sabía perfectamente lo que estaba haciendo y deliberadamente hizo a su VM compatible con Java, sus librerías y herramientas disponibles. Microsoft se encontraba en la misma situación al crear .NET, pero decidió tomar el camino más largo.

Así que quien es el malo, ¿Oracle, Google, ambos o ninguno?

Después de la muerte de los ratones, ahora se nos va Google Wave.

Extraño las dos veces que lo usé   :(

Tengo una carpeta llena de música que he ido acumulando a lo largo de los años. Siempre trato de mantener los ID3 tags correctos, pero de vez en cuando me encuentro algún MP3 que le hace falta información. Toda esta colección de música la tengo en el disco duro de mi computadora en una partición EXT4 para su uso desde Ubuntu, y respaldada en un disco duro externo de 1 TB con formato FAT32 para su uso en cualquier otro lugar.

El problema es que si edito, agrego, elimino o muevo un archivo en el disco externo, tengo que hacer lo mismo en el disco interno. Hacerlo manualmente no es una opción, y no puedo sincronizar utilizando alguna otra herramienta (como rsync) porque sólo sincronizan de una fuente a un destino, y en mi caso los cambios pueden darse en cualquiera de las dos carpetas, inclusive en las dos al mismo tiempo.

Esto es muy similar a como funcionan los sistemas de control de versiones, y precisamente el programa Unison File Synchronizer toma esta aproximación, le agrega algo de multiplataforma y facilidad de uso, resultando en una herramienta indispensable. Básicamente Unison puede tomar dos carpetas, compararlas y propagar los cambios de tal manera que al final queden ambas exactamente igual.

Por último, si alguna de las carpetas es de un sistema de archivos que no soportan permisos (como por ejemplo en mi caso, FAT32), hay que configurar Unison para que no intente sincronizar estos permisos. Para hacerlo hay que editar el archivo que se encuentra en ~/.unison/nombreDelPerfil.prf y agregar al final:

perms=0