27 de junio de 2009

La insoportable levedad de Mono (II)

(Continuación de la primera parte)

Todas esas razones ya de por si suponen un problema para Mono considerando su objetivo de convertirse en plataforma de programación para Gnome. Pero dejando de lado estas razones que afectan más bien a los programadores, tambien hay que mirar las cosas del lado del usuario. Y en ese lado del campo, la razón por la que Mono no se ha convertido en algo imprescindible para los usuarios de Gnome es la ausencia de aplicaciones.

Personalmente, no tengo Mono instalado en mi sistema, tampoco lo tenía cuando utilizaba Gnome. Es decir, no lo necesito. ¿Tal vez no me he adentrado en el mundo de aplicaciones Mono? Bien, hagámoslo ahora, echemos un ojo a esto y a esto. Pero por mucho que lo miro y remiro, no veo nada que me interese de verdad, no veo nada imprescindible. Si que tengo aplicaciones pygtk de las que no podría prescindir (no podría vivir sin virt-manager), tengo alguna que otra aplicación GTK hecha en C o C++, tengo hasta una aplicación que hace uso de wxWidgets en su versión GTK, amule. Pero nada con Mono. ¿Monodevelop? Tengo eclipse, o Kdevelop. ¿Beagle? Pregunten a Ubuntu porque se pasaron a Tracker. ¿Gnome Do? Los paneles y menus normales me son suficientes. ¿Banshee? Este si que es atractivo, pero yo diría que lo es fundamentalmente por las carencias de rhytmbox. ¿F-spot? Tambien es atractivo, incluso intenté usarlo, pero ciertos bloqueos de la interfaz y fallos diversos me hicieron desinstalarle, y como tampoco soy de los que necesita un gestor de fotos no fue una gran pérdida.

En resumen, que a la hora de la verdad, las únicas aplicaciones Mono que personalmente veo algo interesantes son (aparte de mod_mono, que sin duda será útil para migraciones de ASP.NET) son banshee y f-spot, pero ninguna se me hace imprescindible, puedo prescindir de ambas fácilmente, o encontrar equivalentes superiores. Tal vez para algunas personas si que sean críticas, pero no dejan de poder contarse con los dedos de la mano.

Pero ojo: una de las aplicaciones estrella de Mono que se suelen citar es Tomboy. Y he de reconocer que cuando veo a alguien poner a una aplicación de notas como ejemplo del potencial de Mono lo siento, pero me da la risa. Y no porque las aplicaciones de notas sean cosa de risa -para muchas personas son imprescindibles y les ayudan a mejorar su productividad-, sino porque tampoco es que sean precisamente la aplicación más interesante que se puede enseñar en un escritorio. Cualquier programador novato puede solventar casi todas las necesidades básicas de los usuarios de aplicaciones de notas con una implementación muy simplista (como la que yo uso en KDE). La "wikificación" y la sincronización en red de notas que tiene no serán tan sencillas, pero tampoco son features precisamente críticas -sospecho que muchas aplicaciones de notas no tienen esas cosas simplemente porque les importa un rábano-, y tampoco es que se puedan programar solo usando C#.

El potencial de Mono debería mostrarse a los usuarios no con una aplicación de notas, sino con algo con más sustancia. Algo como, por ejemplo, una reescritura de Evolution (se dice que Mono surgió precisamente como reacción a su inmantenibilidad). O de Gimp, o de Openoffice, o de Pidgin, incluyendo una reimplementación completa de los protocolos de red. ¿Les parece que pido mucho? Es mucho, pero ya ven, no son propuestas exageradas: KDE tiene un equivalente de Evolution, de Gimp, de Pidgin y de OpenOffice.org, todas ellas más que decentes. Y todas ellas en....C++. Si Mono es tan awesome y tan superior a otros lenguajes de programación pues, carajo, deberían tener cosas así. Deberían demostrar su awesomeness con algo acorde a su grandeza, no con aplicaciones de notas.

Teniendo en cuenta la ausencia de aplicaciones imprescindibles, ¿debería ser sorprendente que una distro evite incluir mono por defecto en sus CDs? Las distros no son tan burras como algunos piensan, muchas han incluido e incluyen los drivers de nvidia y ati, y el plugin flash -o facilitan enormemente su instalación- cuando es necesario, cuando se trata de algo verdaderamente imprescindible la teología de licencias pasa a un segundo plano. En el caso de Mono, a mucha gente le desespera, y con razón, tener que incluir todo el runtime para unas pocas aplicaciones. Y a los usuarios tambien, claro.

23 de junio de 2009

La lista de los 500 principales

Hoy acaba de ver la luz la edición de Junio de la lista de los 500 supercomputadores más potentes del mundo.

Las tendencias vienen a ser las de siempre: El 88.60% (443) utiliza Linux -y muchos de ellos utilizan Lustre-, frente a un 87.80% de hace 6 meses y un 85.40% de hace un año. Windows mantiene su cuota de cinco equipos (1%), Mac OS X sale de la lista (lo cual no creo que quite el sueño a ningún maquero), y Sun mantiene 1 equipo con OpenSolaris. En cuanto a procesadores, Intel sigue dominando, IBM es segundo gracias a los Cell, y AMD en tercer lugar.

Lustre es un magnifico ejemplo del desorden interno que sufría Sun (aunque no tan bueno como el de Java). Lustre es un sistema de archivos distribuido opensource diseñado en principio para Linux y muy exitoso: lo utilizan 2/3 de todos los equipos del TOP500, 7 de ellos están entre los 10 más potentes. Su equipo de desarrollo fue comprado para Sun, pero aun hoy Lustre sigue funcionando solo para Linux, con promesas de llegar a funcionar sobre ZFS desde 2007 (puede que se convierta en realidad con Lustre 2.0, que está en versión Alpha).

Como consecuencia (dejando de lado otras ventajas de Linux, como su soporte de Infiniband anterior al de otros sistemas), de los 5 equipos que Sun tiene en el TOP500 (más dos compartidos con Dell), todos excepto uno son Linux. No sé si se capta la ironía: Sun mantiene en nómina a los desarrolladores de Lustre, venden 5+2 equipos que entren en el TOP500 (fuera de esa lista habrá más, claro), todos excepto uno sin su SO, mientras que sus competidores venden alrededor de 330 sistemas con ese mismo software. Hasta desarrollar de cero un sistema de archivos distribuido sobre ZFS les hubiera salido más barato y rápido.

19 de junio de 2009

La insoportable levedad de Mono (I)

Un post sobre Mono ha vuelto a reavivar en el mundo del software libre la eterna polémica de siempre. Tiene Mono un no-se-qué de pretendiente carlista, de eterno sucesor a la corona.

A Mono le basta con ser lo que es -clon de C#/.NET- para justificar su existencia, sin embargo no es ningún secreto que sus creadores siempre quisieron que fuera la futura plataforma de desarrollo para Gnome. Pero sus pretensiones siempre han chocado frontalmente con una parte importante del resto de desarrolladores. Por si solo esto ya es un síntoma que esas pretensiones son una quimera, porque por muy razonable que sea su propuesta, sin el apoyo del resto de la comunidad no se va a ningún lado, y mucho menos si a la ausencia de apoyos se suma cierta oposición férrea.

Los Moneros, como primero de los argumentos, suelen decir que no debemos tener complejos en usar cosas buenas de Microsoft, que si .NET es bueno es estúpido no usarlo. Que se deseche el "reinventar la rueda". El problema de esta afirmación, dejando de lado el hecho indiscutible de que .NET viene a ser un clon de Java (tal vez algo mejorado, pero clon), es que quien ciertas personas del entorno de Mono parecen alabar casi sistemáticamente casi todo lo que venga de Microsoft, sea bueno o no. Sus blogs tienen, algunas veces, cierto parecido al material de marketing orientado a desarrolladores de la compañía. Esto por si solo no tiene nada de malo, las plataformas de desarrollo de Microsoft serán buenas o malas, pero se pueden usar y clonar bajo una licencia libre, faltaría más. No tiene nada de malo, muchas partes de KDE tambien son clones de ideas de Windows, ej el antiguo DCOP.

No, el problema no es clonar, ni usar ideas de Microsoft. El problema es clonar y tragarse todas las ideas de Microsoft, como, por ejemplo, tragarse el kool-aid de Silverlight como plataforma web del futuro y correr a clonarlo a toda prisa nada más presentado. Eso no es tan razonable para la comunidad del software libre, que ve en estas acciones una creciente dependencia tecnológica, y quien no es razonable consigo mismo no puede esperar que la gente lo sea con ellos. Como decía un comentarista de slashdot, parece más bien que esa gente "follows, not lead", o sea, que siguen la corriente, en vez de crear y dirigir la corriente ( y está pero que muy equivocado quien piense que Linux puede vencer a Windows siguiendo su corriente).

Pero es que liderar no significa renunciar a las buenas ideas, significa simplemente tener ideas propias y buenas, y no conformarse con las ideas de los demás. Un buen ejemplo: el lenguaje Vala. Con toda la cutrez y fealdad que puedan achacársele, creo que Vala tiene más de "lead" que Mono, porque en vez de copiar literalmente la idea de .NET, coge una idea -C#- y trata de aplicarla para las necesidades concretas de Gnome y de Linux, trata de tener ideas propias, ideas tal vez no bellas, pero si muy prácticas. Se trata de una criatura controlada por gnomeros -una importantísima ventaja que da mucha confianza a la gente-, tiene una magnífica compatibilidad -todo el código Vala puede reutilizarse en C mediante GObject, y por ende en el resto de lenguajes que tienen bindings con gnome-, y tambien tiene... (sorpréndanse) mejor rendimiento (de hecho parece ser que fue el rendimiento de mono lo que ha causado el nacimiento de Vala). En resumen, tratan de combinar lo mejor de todos los mundos, y parecen estar lográndolo.

Las otras razones que se suelen oir para defender a Gnome son bastante curiosas. Se alaban las virtudes de Mono como plataforma, pero se olvidan y relativizan las de otras. ¿Acaso no tiene Java muchas de las mismas ventajas que Mono? ¿Y qué decir de la crítica de velocidad a Python? Si el problema de Python es la velocidad, tambien es una opción acelerar python, como está haciendo Google. Y luego está lo de las patentes y asuntos legales, que Mono insiste en negar en que no son un problema, pero la realidad es que hay patentes (de aquellas referidas a C# Microsoft da permiso para usarlas más o menos libremente, las referidas a las librerias .NET no), Microsoft es Microsoft, y todos sabemos como son estas cosas: las patentes son absurdas y pueden crear problemas absurdos con sorprendente facilidad.

(continuará)

15 de junio de 2009

Desconectando HAL

HAL fue una de las piezas claves de esos mecanismos que consiguieron, hace unos años, que el escritorio Linux fuera capaz de hacer cosas como detectar y auto-montar CDs y discos externos, o que X.org fuera capaz de autodetectar dispositivos de entrada sin necesidad de reiniciar. O que NetworkManager detecte dispostivos de red externos. Sin embargo, en estos momentos los desarrolladores están intentando eliminar HAL, pues lo consideran una carga. Las futuras versiones de Fedora y Ubuntu puede que ya ni lo tengan.

Lo más sorprendente es que quien dio el primer paso ha sido el propio desarrollador de HAL, David Zeuthen, concretamente en este email. Y es sorprendente porque es frecuente encontrarse con gente incapaz de ser crítica con la obra de sus manos (y no necesariamente tiene que tratarse de que sea un mal programador, sino que al crear el programa no pudo predecir como iba a evolucionar), lo más normal es que piense que su programa funciona bien y que, si acaso, algunos pequeños problemas -que siempre los cree poco importantes- se pueden arreglar con un par de parches. Quizás llegue a admitir que su programa tiene grandes defectos, pero no mueve ni un solo dedo para ayudar a solucionar el problema, dejando la "revolución" en manos de quien tenga ganas de molestarse. Mucho más dificil es que el creador de algo como HAL, tras haber introducido su programa en todos los escritorios Linux y haber hecho que Gnome y KDE dependan intrínsicamente de él para funcionar correctamente, admita que su programa está mal, y diga a la gente que tiene que reescribir su código para adaptarlo a un nuevo programa que acaba de hacer aprendiendo de los errores del anterior. Y, sin embargo, esto es lo que ha hecho este señor. Aprender de los errores de HAL, reescribir una alternativa mejor de cero.

El invento que sustituirá a HAL parece consistir en udev + DeviceKit. Y se me hace muy dificil distinguir en detalle cuales son los cambios, porque de cara a las aplicaciones es prácticamente el mismo modelo con una API diferente (en los dos últimos enlaces explican los principales cambios). Al final la diferencia está en la implementación interna del asunto. No se trata de un cambio "revolucionario" -aunque por si solo reescribir un programa de cero si que lo sea- sino de uno evolutivo.

10 de junio de 2009

Las novedades de Linux 2.6.30

Este es un resumen de las novedades más importantes de Linux 2.6.30. Esta vez he querido publicarlo tras el anuncio oficial, y no algunos días antes. Lista completa de cambios en inglés aquí.

· NILFS2: Se trata de un nuevo sistema de archivos contribuido por la NTT (Nippon Telegraph and Telephone Corporation). Ha sido desarrollado de cero y está diseñado con "estructura de log" (log-structured). Lo que diferencia a los sistemas de archivos normales de los de diseño de log es que éstos tratan el disco como una lista linear de bloques (llamada log). Todas las operaciones añaden datos a los bloques situados al final del log, nunca se reescriben bloques ya escritos (excepto cuando no queda espacio libre, en ese caso se utilizan los bloques situados al principio). Las ventajas de este diseño es que todas las modificaciones al sistema de archivos se convierten en escrituras secuenciales, que en los discos duros tradicionales son muy eficientes comparadas con las aleatorias. Los cuelgues no pueden corromper el sistema de archivos. Al ser montado, el sistema de archivo encuentra el final real del log, y las modificaciones continuan a partir de ese punto.

Otra ventaja de este diseño es que el log ofrece una visión histórica coherente de todas las operaciones que se hayan hecho en el disco en el pasado, llamados "snapshots continuos", pues implica que se automáticamente, sin intervención de ningún administrador, se crean snapshots de todas las modificaciones del sistema de archivo en cualquier momento a medida que se van añadiendo datos al log, con el tamaño del disco como único límite. NILFS2 permite acceder a esos snapshots e incluso montarlos (de momento, solo en modo de solo-lectura).

· POHMELFS y DST: Ambos han sido contribuidos por por Evgeniy Polyakov.

POHMELFS ("Parallel Optimized Host Message Exchange Layered File System") es un sistema de archivos de red distribuido y de alto rendimiento. Tiene la habilidad de poder leer o escribir datos de/hacia múltiples nodos simultaneamente, manteniendo además un caché local de datos y metadatos, lo cual acelera bastante muchas operaciones de IO. Gana a NFS por un margen amplio en muchas operaciones, si no es en todas. Puedes encontrar más detalles y benchmarks sobre él en su página web. POHMELFS está ublicado en la sección "staging" del kernel, aunque es un proyecto bastante maduro.

DST (Distributed (network) STorage) permite crear redes de almacenamiento de datos de alto rendimiento de un modo fiable y sencillo. DST permite crear un dispositivo de almacenamiento utilizando para ello nodos remotos y locales y combinarlos en una configuración espejo, que posteriormente puede exportarse a otros nodos remotos. Se trata de un equivalente de gran parte de la funcionalidad ofrecida por el gestor de volúmenes, iSCSI y el dispositivo de bloque de red (NBD). Funciona por encima de cualquier red y protocolo. DST puede encriptar los datos en caso de tener un canal de datos no fiable, así como hacer checksums de los datos transferidos. DST se encuentra en la sección "staging" del kernel.

· Soporte del protocolo Reliable Datagram Sockets (RDS): Contribuido por www.openfabrics.org (particularmente, Oracle).

RDS es un protocolo de comunicación entre procesos de alto rendimiento, baja latencia, y fiable, diseñado para ser utilizado entre los servidores de un cluster. Ofrece una conexión fiable entre dos nodos cualesquiera del cluster. Esto permite a las aplicaciones utilizar un solo socket para hablar con cualquier otro proceso que se esté ejecutando en el cluster - asi que en un cluster con N procesos necesitas N sockets, en contraste con los N*N sockets si se utilizan protocolos de transmisión orientado a conexión como TCP. En beta testing, RDS funcionando enlaces Infiniband es un 60% más rápido que Gigabit Ethernet. RDS ya está en uso en algunos productos como Oracle y QuickSilver de SilverStorm.

· Inicio rápido: Contribuido por Intel. Algunas partes del inicio del kernel pueden retrasar el resto del inicio durante demasiado tiempo (demasiado según los estándares de un kernel): por ejemplo, escanear en búsqueda de discos conectados a un controlador, y buscar las particiones de esos disco, puede ser bastante lento. Y como el escaneo es síncrono, solamente se puede escanear un dispositivo a la vez, y el kernel tiene que esperar a que terminen de analizarse todos para continuar cargando. Con el inicio rápido, esos pasos se hacen asíncronamente, asi que el kernel puede continuar iniciando el resto del sistema mientras el kernel escanea los dispositivos de almacenamiento en paralelo. Esta característica reduce el tiempo que toma cargar el kernel significativamente.

· IEEE 802.11w (wireless management frame protection): Contribuido por Atheros. El estándar IEEE 802.11w es una propuesta, aun no aprobada, de mejora del estándar IEEE 802.11 y que supuestamente incrementa la seguridad de sus "management frames" (no me pregunten qué significa). En esta versión, Linux añade soporte preliminar de este futuro estandar, desarrollado de acuerdo con los borradores existentes.

· Llamadas al sistema preadv()/pwritev(): Contribuidas por Red Hat. Estas llamadas al sistema son una forma muy sencilla de combinar pread/pwrite y readv/pwrite. Los sistemas BSD tambien tienen estas llamadas al sistema desde hace tiempo, por ejemplo NetBSD

· EXOFS, un sistema de archivos para almacenamiento basado en objetos: Contribuido por Panasa. Los dispositivos de almacenamiento tradicionales ofrecen una interfaz basada en bloques. Sin embargo, hay una nueva generación de dispositivos de almacenamiento experimentales que están tratando de descargar parte del trabajo del hosty trasladarlo a las unidades de almacenamiento, ofreciendo una interfaz de más alto nivel: un array de objetos. El sistema operativo interactua con los objetos, y el disco hace el resto del trabajo, eliminando gran parte de los detalles de bajo nivel del sistema de archivos. Se puede implementar fácilmente un sistema de archivos encima de estos objetos. La interfaz OSD funciona encima de la pila SCSI.

En esta versión, Linux añade soporte para el protocolo OSD en la pila SCSI, y además añade exofs, una implementación de un sistema de archivos unix tradicional que funciona sobre dispositivos de almacenamiento OSD.

· Soporte preliminar de NFS 4.1: Contribuidores: Panasas, Netapp and IBM.NFS 4.1 está siendo desarrollado en el IETF. De las muchas nuevas características de NFSv4.1, esta versión de Linux añade soporte de las mandatorias "sesiones NFSv4.1". Otras características, en particular Parallel NFS, están usiendo desarrolladas y serán añadidas en posteriores versiones. Para activar este nuevo protocolo (que está desactivado por defecto) necesitas unas nfs-utils actualizadas.

· FS-Cache, un sistema de archivos de cacheado: Contribuido por Red Hat. FS-Cache es la implementación de Linux de una capa de cacheado para sistemas de archivos de red, similar al CacheFS de otros Unix. Con FS-Cache, los datos del sistema de archivos de red pueden ser cacheados localmente, acelerando las operaciones.

Esta versión de Linux añade soporte de FS-Cache para NFS y AFS, pero es una capa genérica que puede ser utilizara por cualquier otro sistema de archivos de red (o incluso no de red, como ISO9660)

· Tomoyo, un sistema de seguridad MAC alternativo: Contribuido por NTT. Hay en Linux dos subsistemas de seguridad: SELinux y Smack. Tomoyo es el tercer sistema, y es un sistema de control de acceso basado en nombres de archivo. Sitio web: http://tomoyo.sourceforge.jp/wiki-e/

· Mejoras de rendimiento de los sistema de archivos: Tras la publicación de Linux 2.6.29, hubo muchas discusiones en la LKML sobre la E/S de disco (resumen disponible en LWN), sobre como y por qué una llamada fsync() puede tomar minutos en completarse, y el efecto de quedarse con un archivo de tamaño cero cuando se reinicia justo despues de usar truncate/rename en ext4. Se han hecho varios cambios para solucionar esos problemas: fsync() implícito del archivo tras un truncate/rename en ext3, ext4 y btrfs, cambio al modo data=writeback por defecto en ext3, y mejoras a CFQ. El flame tambien ha resucitado el tema de las actualizaciones de atime, y ha desembocado en la inclusión de relatime y su activación por defecto

· Compresión de la imagen del kernel con LZMA/BZIP2: Contribuidor: Alain Knaff. El kernel comprime sus imágenes con GZIP, pero esta version añade soporte para comprimirla con LZMA o BZIP2. El tamaño de la imagen es aproximadamente un 10% más pequeñas con bzip2 en comparación con gzip, y un 33% en el caso de lzma.

· Arquitectura Microblaze: Contribuidor: Michal Simek, con donaciones de PetaLogix y Xilinx. Esta versión añade soporte para la CPU sin MMU Microblaze CPU architecture.

·Integrity Management Architecture: Contribuidor: IBM. La Integrity Measurement Architecture(IMA) mantiene una lista de hashes de ejecutables y otros archivos importantes. Si un atacante consigue cambiar los contenidos de uno de esos archivos, con la ayuda de un chip TPM, se puede detectar.

Y eso es todo por esta versión. Ya saben, lean la lista completa aquí.

9 de junio de 2009

¿Ataque de Firefox a la Intranet?

Con frecuencia los desarrolladores de Firefox cuentan en el planet que IE es en realidad un "navegador de intranet". Es decir, que es un navegador sobre el que la mayoría de empresas del mundo desarrolla parte de su software interno. No complicar la vida a esa gente es una de las grandes obsesiones de microsoft, probablemente mayor que la de satisfacer a los usuarios caseros, ya que hay más dinero de por medio.

Firefox no tiene gran uso en esos sitios. Las modas "ajax" y eso de funcionar correctamente en múltiples navegadores es algo bastante secundario. Se diseñan las cosas para que funcionen en el navegador que traiga por defecto la versión de Windows en cuestión (y hasta la aparición de IE7, todas las versiones de Windows usaban IE6, dando lugar a una gran uniformidad) y punto. Prefieren la ubicuidad y estabilidad de las "interfaces" de IE a complicarse la vida con otras cosas. Y hacen bien. Usar Firefox en una empresa supone instalar, configurar mediante directivas de grupo y mantener actualizado un paquete de software más, e históricamente Firefox no ha puesto sencillo hacer esas cosas. Hasta ahora, se ha conformado con atraer la atención de los usuarios normales y corrientes, no de estas intranets.

Sin embargo, si esta noticia es cierta, la situación podría empezar a cambiar. Esta noticia informa de un proyecto, apodado "constrúyete tu propio navegador", cuyo propósito es precisamente a solucionar los problemas de Mozilla en este area. El objetivo, es, sin duda, conseguir que usar Firefox en esas intranets sea tan sencillo como lo es IE hoy, o al menos lo más sencillo posible. Y si lo consigue, el uso de Firefox sin duda aumentará.

Pero además, Firefox tiene, opino yo, una ventaja adicional, que es la ventaja de no ser parte del SO. Mientras que a Microsoft su (estúpida) decisión de hacer IE parte inexpugnable del SO les impide, por ejemplo, instalar IE6 en Vista, o IE7 en Windows 7, forzando a las empresas a considerar ese factor a la hora de migrar una oficina a futuras versiones de Windows (de aquí vienen esas pretensiones de Microsoft de conservar la compatibilidad con IE6 en las versiones modernas de IE), Firefox puede instalar cualquiera de sus versiones en cualquier versión de Windows. Es decir, Firefox puede ofrecer a todas las versiones relevantes de Windows una uniformidad que Microsoft no puede con IE, uniformidad que además se extiende a otros sistemas operativos. Un servidor piensa que Firefox puede tener cierto éxito con este nuevo proyecto.

4 de junio de 2009

¿Intel, cada vez más distante de Windows?

Está visto que estos tiempos de crisis son tambien tiempos de rebajas para los magnates con pasta en el bolsillo, y que nos esperan aun muchas compras y fusiones. Como Intel, que acaba de comprar Wind River.

A quien no recuerde quienes son, Wind River les sonará porque hace unos cuantos añitos eran una especie de Red Hat en versión BSD, quizás el mayor exponente del espíritu BSD en su día, espíritu que les invadió tras comprar BSDi, que eran quienes hacían el sistema operativo BSD/OS. Éste era un derivado propietario de los BSD que como otros miembros menores de la familia trataba de sobrevivir más de orgullo genealógico (es decir, aristocracia) que de hechos. Wind River se dedicaba más bien a sistemas embebidos, y solía bramar mucho contra Linux y vomitar FUD contra la GPL, hasta que tuvieron que dejar el desarrollo de BSD/OS y tuvieron que empezar a vender productos Linux. Tambien les sonará, y seguramente mucho más, por Vxworks, el sistema operativo de tiempo real que utilizan los robotitos de la NASA en Marte.

El caso es que la compra de esta compañía por parte de Intel llama la atención. Intel ya ha creado su propio equipo de expertos en Linux, y creando hasta su propia distribución Linux -Moblin- para los sistemas que ellos llaman "MID", que no sé lo que significa oficialmente pero si sé que en realidad se puede traducir a "Mimicking Iphone Devices". Y ahora se compran otra compañía especializada últimamente en meter Linux en sistemas embebidos, y en un sistema operativo de tiempo real que es líder de su campo, y vaya a saber usted que cosas más, porque por $884 millones tambien hará más cosas.

Todo esto tiene una nota de discordancia, como uno de esos juegos en los que hay que adivinar el elemento que no encaja con el resto. Y es que son todas cosas relacionadas con software, y hasta hace poco, Intel solía dedicarse a hacer CPUs y chips variados: hardware. Su único software eran los compiladores, herramientas de desarrollo, y drivers para sus chips wifi/sata/etc. El tema de los sistemas operativos se lo dejaban a Microsoft, de hecho no falta gente que opine que se compincharon para montar el imperio windows-x86. Y ahora, en estos últimos años, vemos que Intel no solamente se dedica a crear distros Linux que compiten directamente con Microsoft, sino que tambien está adquiriendo empresas con la aparente intención de hacerlo mejor. No sé a ustedes, pero a mi da la impresión de que Intel pretende plantar cara a Microsoft. Y sabemos, por los emails publicados en juicios en los que se acusa de a ésta de monopolio, que a Steve Ballmer no le hace gracia tener a este otro gigante en contra. Las luchas entre titanes suelen ser espectaculares.