Google Wave

Google ya tuvo en su día una gran idea cuando unificó el chat web y gmail en una sola aplicación; al fin y al cabo ambos son mensajes de texto, unos más "inmediatos" y cortos que otros, pero igualmente mensajes, y ambos comparten muchas cosas, como las operaciones con contactos. Para rizar el rizo, hoy Google acaba de dar un paso adelante más, desvelando Google Wave, un invento que se podría describir como la siguiente generación de redes sociales, y que parece tratar de unificar todo lo que tenga que ver con comunicaciones en una sola aplicación: correos, chats, fotos, videos, mapas, edición colectiva de documentos...la captura del invento publicada (no está abierto aun al público) lo deja más claro que cualquier descripción.

Como ni mi descripción ni la captura me convencen, traduzco la descripción del anuncio oficial de Google:

"Un 'wave' [ola] es una conversación y un documento a partes iguales, en el que la gente puede comunicarse y trabajar juntos con texto enriquecido, fotos, videos, mapas, y más cosas. Así es como funciona: En Google Wave puedes crear un 'wave' y añadirle personas. Todo el mundo dentro de tu 'wave' puede usar texto enriquecito, fotos, gadgets, e incluso feeds de otros sitios web. Pueden insertar una respuesta o editar el 'wave' directamente. La edición del texto enriquecido es simultánea, puedes ver casi instantáneamente en tu pantalla lo que tus colaboradores están escribiendo en el 'wave'. Eso quiere decir que Google Wave está igualmente adaptado a mensajes rápidos como a contenido persistente - permite tanto colaboración como comunicación. Tambien puedes utilizar "playback" para rebobinar el 'wave' y ver como ha ido evolucionando'

Todo ello está implementado a base de edición colectiva, todo ello es un documento XML, tanto si es una frase de un chat como un documento de verdad, cuya edición se presenta en tiempo real, y sin bloqueos de UI, a los participantes. Una pequeña descripción del diseño interno se puede encontrara aquí. Por cierto: la parte de presentación del cliente web está hecho con HTML 5 (usando el google web toolkit), soportando cosas como cut&paste y drag&drop. Visto lo visto, el fin del camino hacia la desaparición de las diferencias entre aplicación local y aplicación web podría estar más cercano de lo previsto. Hay unos tutoriales para programar gadgets y robots que interactuen con Wave que son bastante reveladores. O este para embeber un 'wave' en una página web externa.

¿De verdad se programarán la mayor parte de aplicaciones del futuro de esta forma, tal como prometen que se hará? Tal como Google está explotando HTML5, no parece que ni Silverlight ni AIR vayan a tener muchas oportunidades: Además, carecen de los servicios de servidor de Google, que en realidad es el corazón de la compañía; el lenguaje de programación y toolkits que utilicen para implementar los clientes no deja de ser un detalle. ¿Para qué, en el fondo, tanta lucha por el dominio del lenguaje del internet futuro, no es acaso más importante lo que se implemente que con qué se implemente, acaso hay en Silverlight, Air o HTML 5 alguna ventaja que no vayan a copiarse unos a otros con el paso del tiempo?

Wave unifica y dan pie a todo tipo de comunicaciones, incluido, aparentemente, un derivado fortalecido del chat, fortalecido porque no se limita a texto sin formato. El chat, magnífico sistema de comunicación hoy bastante en desuso, por lo complejo que se hace para los usuarios juntar y configurar los programas necesarios, pero de un valor incalculable. Quienes aun hoy utilizamos el chat con frecuencia lo sabemos bien, el IM es un magnífico invento pero no reemplazó los chats, ni tan siquiera con las capacidades de charla coletiva y de chat de Jabber. Era cuestión de tiempo que alguien lo desenterrara. Es fácil preveer que muchos foros, páginas web, equipos de juego online, acaben utilizando este invento (si es que no lo adoptan directamente, según evolucione, como sistema de comunicación central, prescindiendo de los foros PHP).

¿Qué otra cosa podemos hacer unas personas con otras en la web que comunicarnos de una u otra manera? Un sistema que unifica buena parte de esas funciones en un solo programa, y parece empezar con buen pie en la tarea, parece tener muchas perspectivas de éxito.

SELinux sandbox

Eric Paris acaba de anunciar un nuevo juguete para SELinux: Una "sandbox" que permite aislar a cualquier aplicación privándola de red y de acceder a otros archivos. Aparentemente está orientado a pequeños comandos, los típicamente utilizados en shells, para hacer su funcionamiento un poco más seguro. En este blog hay más detalles.

Sin embargo, he de confesar que al leer los detalles, me ha decepcionado. No por la idea, claro, sino por SELinux. Resulta que este "juguete" no tiene nada de especial: no es ningún parche en el kernel, ni nada especial en las herramientas de espacio de usuario de SELinux...se trata tan solo de una nueva política de SELinux, sandbox_t, que está configurada con todas las restricciones citadas, y un ejecutable, /usr/bin/sandbox. La nueva política ha sido creada, según el autor, en 10 clicks con la herramienta gráfica de SELinux. Tan solo tienes que ejecutar "sandbox foo", y el comando foo se ejecutará dentro de la sandbox.

Y lo que me apena es, paradójicamente, la sencillez de todo. 10 clicks para crear la política, un pequeño ejecutable....uno se pregunta: ¿no es una pena que esto no se haya podido hacer antes? SELinux es una maravilla de sistema, creado por nada menos que la NSA y que fue incluido en el kernel hace seis años, ningún sistema operativo común y corriente tenía entonces nada parecido. Incluso hoy muchos sistemas carecen hoy de cosas parecidas, y los que lo tienen es porque lo han imitado (TrustedBSD para FreeBSD y Mac OS X). Hasta los de TrustedSolaris acabaron imitándolo (despues de jurar durante años que su sistema era superior en todos los aspectos).

Y esta enorme ventaja temporal y técnica, ¿cómo la ha aprovechado Linux? Medianamente bien en los servidores (Red Hat lo usa por defecto desde RHEL 4), no tanto en el escritorio. Aun hoy muchas distros no incluye SELinux activado por defecto, debido a la enorme complejida; solo Fedora apostó fuerte por ello debido a los trabajadores de Red Hat, y aun así les ha costado años hacer el sistema mínimamente usable. Asi que mientras Linux intentaba hacer de SELinux algo más mainstream, otros SOs, como Windows Vista o OS X, han añadido sus propios sistemas antes. Resulta especialmente significativo el caso de OS X, cuyo comando "sandbox", introducido en 10.5, está basado en TrustedBSD; a pesar de llevarle años de ventaja, Linux acaba de presentar su comando "sandbox" hoy.

Me alegro de que se empiecen a oir estas buenas noticias sobre SELinux, pero por otra parte queda un sabor amargo, porque durante años la gente de SELinux insistió e insistió en que la culpa de no usar SELinux era de las distribuciones, ignorando las quejas de éstas acerca de lo enormemente dificil que era usarlo.

SGI UV sobrevive

Ya dije que estaría al tanto de lo que ocurriera con la parte linuxera de SGI tras su compra por parte de Rackable (quien, por cierto, ha decidido adoptar el nombre de la empresa comprada), ya que contribuía bastante a Linux y podría desaparecer en la nueva empresa. Y hoy una entrevista al mandamás de la compañía, quien por cierto, por el apellido parece ser de familia descendiente de vascos, se confirma no solo que van a fabricar el SGI UV (UltraViolet), sino que además les interesa bastante: "If you don’t believe in UV, you would not have brought the two companies together".

El SGI UV es el intento de SGI de abandonar Itanium, para pasar a construir sus monstruosas máquinas basadas en x86-64 (Xeon, en concreto). No se trataría de un simple cluster formado por cientos de pequeñas máquinas x86-64, sino una sola máquina x86-64 con miles de procesadores, terabytes de memoria funcionando con un solo kernel. O eso pensaba yo, pobre de mi.

Si uno echa un ojo a los orígenes del proyecto UltraViolet, que tiene sus orígenes en el 2004, dicen que quieren que se trate de una máquina "multiparadigma" que pueda, además de ahorrar en la factura de la electricidad, tener las ventajas tanto de procesadores escalares (o sea, los de toda la vida), como de procesadores vectoriales, o sea, al estilo de la parte MMX/SSE de los procesadores tradicionales, las GPUs, el Cell o el Intel Larrabe (aunque a éstos SGI no los categoriza como procesadores vectoriales puros, sino como "app-specific"). En un sistema Ultraviolet, la capacidad de cálculo escalar vendría de CPUs Intel estándar, y la vectorial de algún tipo de procesador específico (o de Larrabe en futuras CPUs Intel, supongo).

¿Suena absurdo? Pues teniendo en cuenta al Intel Larrabe, el Cell, y todo lo que está haciendo Nvidia últimamente, tal vez no lo sea tanto. Igual hasta SGI se ha anticipado en su campo con este cacharro.

Volviendo a Linux, para crear un sistema monstruoso con Xeons se necesita hardware específico para ello. Y como hardware específico que es, se necesita soporte específico en el SO. Ese soporte ya está en Linux desde hace unas versiones. Por lo que resulta dificil pensar que Rackable, perdón, SGI, vaya a despedir a sus programadores Linux. Si va a continuar con SGI UV, va a necesitarlos para que Linux funcione como Dios manda en esas máquinas, ya que es el único SO que puede funcionar en esas máquinas. Asi que la gran duda que me quedó cuando se anunció la compra de SGI queda disipada: Si, seguirán apoyando a Linux, seguirán contribuyendo a Linux.