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.

¿Puede una 'Java Store' resucitar Java en el escritorio?

Si bien Java es un lenguaje muy importante en ciertos sectores, no se puede afirmar que en lo que a aplicaciones de escritorio se refiere sea lo mismo. A día de hoy en Windows es bastante más fácil (de acuerdo con mi propia experiencia) encontrar una aplicación que requiera .NET que con una que necesite Java. Y las de .NET tienen una UI con bastante mejor aspecto que las de Java. Por no hablar de la quimera de los applets: Quitando la página de una universidad, donde a veces se introduce java en los cerebros estudiantes con calzador, hace años que no veo una página con applets. Google utiliza Java para hacer gmail, con gran éxito, pero gmail en si mismo es javascript, esto da una idea de como anda la cosa.

La novedad es que Jonathan Schwartz se va a sacar de la manga una Java Store, evidentemente inspirada por la Store de aplicaciones para iPhone, a la que ya llama antes de existir, muy de acorde con el estilo grandilocuente de la compañía, "la tienda de aplicaciones más grande del mundo". Sun es una compañía de máximos o de mínimos. Y la pregunta que cabe hacerse es: ¿Puede una Store resucitar a Java en el escritorio?

Mi opinión es que es muy dificil aventurarse a jugar una partida donde todas las cartas están ya echadas y jugadas. ¿Cuando fue la última vez que alguien vió aparecer una aplicación de escritorio revolucionaria? A veces ocurre, pero es raro. Aparecen, revuelven los espíritus de los bloggers, se pasa la moda y vuelve la quietud. Y la mayor parte de las veces son reescrituras mejoradas de aplicaciones que ya existían previamente; por ejemplo, Firefox. La everfescente fiebre aplicacionera de la década de los 90 ya pasó. ¿Qué revolucionarias aplicaciones Java existen o pueden llegar a existir? Por si eso fuera poca dificultad, en Windows la plataforma de desarrollo de Microsoft es omnipotente. Hay quien sueña (soñamos) con el derrumbe de todo el imperio Windows volviéndolo irrelevante, pero penetrar en el fuerte de Microsoft y luchar contra el Imperio desde dentro es una idea suicida.

La propia descripción que hace Jonathan Schwartz de la Store, hablándo de ella como un recurso para quienes quieran "ir más allá de los navegadores", suena ridículo. Que yo sepa, a día de hoy no se ven muchos programadores que huyan del navegador. Más bien hay hordas de programadores que migran hacia el navegador, encuentran dificultades y con sus quejas los hacen avanzar aun más. Y quienes no huyen del navegador, ¿por qué iban a abandonar C++ o C# por Java?

Supuestamente Sun quiere intentar alcanzar el éxito de Apple con su Store para el iPhone. Pero hay mucho que decir aquí, pues el éxito del iPhone no es tanto el de la Store sino el del teléfono. De no tener una App Store, el éxito de sus aplicaciones sería el mismo. Además, Apple no hace mucho dinero vendiendo aplicaciones, sino iPhones. ¿De dónde sacaría Sun beneficios? ¿Del mayor uso de Java, Netbeans? De ahí tampoco sacan mucho dinero (comparado con el que tienen que sacar para sustentar la compañía). Entonces, ¿montan este invento por amor al arte? Pues eso parece.

Yo diría que se trata de otro infructuoso intento más de explotar Java, y a pesar de que está más que demostrado que es muy difícil y a menudo contraproducente intentar sacar grandes cantidades de dinero de un lenguaje de programación, Sun parece seguir creyendo que con Java puede hacerse, porque ellos lo valen. ¿Acaso saca Microsoft beneficios de .NET? No, los saca de Windows, las licencias de MSDN no creo que cubran ni una mínima parte de lo que les cuesta desarrollar todo el entorno. ¿Y apple de Objective-C? Tampoco. Entonces, ¿por qué hace Sun tantísimos esfuerzos en favorecer un lenguaje que no ha logrado darles de comer en una década y media? Por amor o por caridad, desde luego no por dinero.

La App Store de Android tiene más perspectivas de futuro que esto...

Ubuntu 9.10 Alpha 1 y GCC 4.4

Aun quedan muchos meses para Ubuntu 9.10, pero ya está la Alpha 1, y en Phoronix la han pasado su suite de benchmarks.

No soy un gran fan de los benchmarks de Phoronix (a veces han hecho cosas ridículas, como pasar benchmarks de disco en comparativas de diferentes drivers gráficos, o hacer tests de compresión mp3 para comparar sistemas de archivos), pero mejoran poco a poco, y, además, es la única web que se preocupa de hacerlos. Y los de esta comparativa son bastante curiosos: Ubuntu 9.10 Alpha 1 bate a Ubuntu 9.04 en prácticamente todos los benchmarks, no solo en los de disco (y a pesar de usar Ext3 como sistema de archivos), sino tambien en los de compresión con 7zip, compresión mp3 con Lame, ripeado con ffmpeg...

Que éstos últimos tengan alguna mejora es particularmente interesante. Se trata de programas que en los benchmarks se pasan casi todo el tiempo ejecutando los algoritmos de compresión/ripeado/cifrado, es decir, código propio. Como no hacen muchas llamadas ni al kernel ni a otras librerías (aparte de algunas como libc, supongo), ni son capaces de acercarse ni remotamente a saturar el sistema de archivos, se benchmarkean a si mismos, no al resto del sistema, asi que no son muy aptos para comparar distribuciones. Además phoronix utiliza su propia versión de los programas que utiliza para el benchmark.

Sin embargo, si que hay un componente vital del sistema que puede afectar a estos benchmarks, y es el compilador. En Ubuntu 9.10 Alpha 1 se incluye el muy reciente GCC 4.4, y sin duda es a él a quien se deben en gran medida las ganancias del 4% en 7zip y crafty y 3% en LAME y ffmpeg. No es precisamente una gran mejora, pero hay que tener en cuenta que el compilador tampoco puede hacer magia con los algoritmos utilizados, y teniendo en cuenta que el resultado depende en gran medida de ellos un 4% no está nada mal.

Observando la lista de cambios de GCC 4.4, uno de los más interesantes es un nuevo "register allocator". Si uno busca el paper de la conferencia de GCC donde se daban detalles de este nuevo asignador de registros, en casi todos los benchmarks que presentan hay mejoras decentes, asi que no parece arriesgado decir que parte de las mejoras que Phoronix ha visto se deben a este nuevo componente. He oido a veces (a mi no me pregunten) que el "asignador de registros" de GCC era malo, lo cual afecta particularmente a las arquitecturas con pocos registros como x86-32. El benchmark de phoronix usa x86-64, asi que si el benchmark se hubiera hecho en un x86-32, las mejoras de GCC 4.4 quizás serían aun más visibles.

En cualquier caso, parece que Ubuntu 9.10 va a ser una buena version (y aun no han terminado de actualizar el servidor X, versiones de drivers, Mesa, libc, etc etc, que darán mejoras en otras áreas)

RCU en espacio de usuario

Los intentos de portar RCU a espacio de usuario (urcu) no eran nuevos, pero por lo visto se ha conseguido el detallazo final de licenciarlo bajo la LGPL.

RCU es una técnica de sincronización patentada por IBM e introducida por ellos mismos en Linux. El código es GPL, pero el permiso concedido por IBM para utilizar la patente es otro tema, e IBM solamente concedía permiso para utilizar esa patente bajo código GPL, lo cual imposibilitaba una reimplementación LGPL o propietaria. Pero los creadores de urcu sabían que en espacio de usuario la GPL es un gran inconveniente, asi que por lo visto se han puesto en contacto con IBM para conseguir permiso para usar la LGPL, y se lo han concedido.

Sobresaltos en la libc de la FSF

Via LWN me he encontrado este blog, donde cuentan como Debian va a subir a sus archivos una libc alternativa optimizada para sistemas embebidos y derivada de la glibc de GNU. Lo interesante es que debian no planea ofrecerla como opción, sino ¡usarla como libc estándar y abandonar la de GNU!

La verdad es que no es tan sorprendente. Quien a lo largo de los años haya estado atento a los chascarrillos del mundillo, sabía que este día tenía que llegar. El mantenedor de la glibc, Ulrich Dreeper (empleado de Red Hat) es un pésimo mantenedor y lo lleva siendo muchos años. Es bruto y arrogante, capaz de rechazar código útil por razones caprichosas. Se trata del típico líder de proyecto que acaba creyéndose dueño absoluto no solo de todas y cada una de las líneas de código, sino de los caminos por los que ha de avanzar el proyecto.

Su gestión del proyecto excluye a gente competente, impide que se cree una "comunidad", con lo cual, aunque él sea un magnífico programador, la libc va acumulando deficiencias técnicas que tardan en resolverse por falta de gente. Desgraciadamente, su situación recuerda a otros proyectos que acabaron en forks, como Xfree86. Si piensan que exagero, echen un ojo a los enlaces al bugzilla que incluyen en el post: 1, 2, 3, 4. No son una excepción, creanme.

En cuanto a las deficiencias técnicas, la implementación de malloc ha tenido durante muchos años un pésimo rendimiento multihilo, que solamente se ha solucionado muy recientemente, en glibc 2.10 (que es tan reciente que ni Ubuntu la usa aun, aunque si Fedora 11). Mientras tanto, la gente, por ejemplo muchos usuarios de mysql, han tenido recurrido durante años al tcmalloc de google, que es capaz de doblar el rendimiento del benchmark sysbench en ciertos casos. Tal vez tampoco se habría solucionado ese problema con un buen mantenedor, pero es seguro que hubiera habido más posibilidades. Tambien es sabido que se ha negado a permitir la optimización la libc para sistemas embebidos por la simple razón de que él no las tiene simpatía y las considera irrelevantes, aunque sean tan utilizadas como ARM -la segunda plataforma más utilizada en Linux despues de x86, y quizás pronto sea la primera-, negando cosas tan comprensibles como hacer opcional la compilación de ciertas partes de la librería, respondiendo a quien estuviera en desacuerdo que la glibc era para sistemas grandes, y que como es para sistemas grandes no merece la pena preocuparse de los sistemas pequeños, y que quien necesite una libc para sistemas embebidos que use una de las muchas que hay especializadas en esos entornos. Por supuesto, es cierto que esas libcs especializadas son imbatibles en uso de memoria, pero no por eso parece lógico prohibir mejorar la libc en ese aspecto. El kernel Linux las ha permitido y, a pesar de no ser un SO embebido está empezando a ser más utilizado en esos sistemas más que los propios SOs especializados, porque ante la desventaja del mayor uso de memoria está la enorme ventaja de ser tecnológicamente superior. Según el post, la glibc oficial no permite hacer cosas tan esperadas como permitir utilizar otras shells aparte de bash o ser compilado con la opción -Os (optimización de tamaño). Muchos dispositivos embebidos usarían encantados la glibc si pudieran, pero al no facilitarles las cosas les han obligado a recurrir a libcs alternativas que a pesar de ser eficientes en uso de memoria, tienen otras desventajas.

El proyecto en cuestión, eglibc, no es un fork, sino una "rama" de la glibc a la que añaden ciertas opciones para sistemas embebidos. Gracias a eso a debian le resulta muy fácil sustituir una glibc por otra, ya que debería ser totalmente compatible. Incluso parece que les resulta ventajoso, porque Debian soporta muchas arquitecturas y esta eglibc facilita el trabajo con ellas.

Sin embargo, no parecen tener interés en "asesinar" a la glibc. De hecho, requieren la asignación de copyright a la FSF a pesar de no ser un proyecto de la FSF, con el claro objetivo de que la glibc oficial pueda incluir cualquier parte de su código. Por eso, es de esperar que a largo plazo la situación de la glibc de la FSF mejore, de una manera u otra. Pero si no lo hace, es de esperar que eglibc prospere, al igual que lo hizo X.org, y acabe siendo mejor que la propia glibc. De momento, Ubuntu probablemente esté interesada en esta eglibc para su distro para sistemas embebidos, que usa ARM...

Windows en la encrucijada de los teléfonos "modernos"

Aunque repita la misma introducción mil veces en este blog, insisto en que Apple ha dado un vuelco a los móviles no solo por su interfaz y la pantalla táctil, sino tambien por haber sido la primera compañía que ha introducido todo un SO tradicional dentro de un móvil. Si, ya había teléfonos con Linux, pero la mayoría de ellos lo utilizaban solo como un kernel embebido regordete pero potente y gratuito: ha sido el iPhone quien ha terminado adelantándose a todos.

Debido a las restricciones tecnológicas, los móviles empezaron su andadura con SOs embebidos que eran tan cutres como el hardware en el que corrían. Llegó un punto en que empezaron a resultar económico los móviles con procesador y RAM capaces de albergar versiones reducidas de los SOs tradicionales, es decir, dejaron de ser "dispositivos embebidos" para ser simplemente PCs portátiles, aunque fueran basados en ARM. Pero los fabricantes siguieron, por inercia, y porque no tenían otra cosa, con sus SOs embebidos, incapaces de explotar toda la capacidad de las cada vez más potentes generaciones de hardware.

Fue entonces cuando Apple halló el hueco para colarse, creando una versión reducida de OS X para ARM que era capaz de funcionar en hardware que tenía un precio aceptable y que lo tendrá aun más en el futuro. Usar su propio SO les permitió centrarse en lo que verdaderamente ha dado el éxito al iPhone: la pantalla pluritáctil (reconozcan que suena más cool que "multitáctil") y el software. Y reducir costes y tiempo, pues solo mantienen una base de código, y no varias. Vi una vez una comparativa de velocidad del navegador del iPhone con otro móvil con un SO embebido. El iPhone le daba mil vueltas. ¿Por qué? Porque el iPhone estaba usando exactamente la misma pila TCP/IP que usa en sus ordenadores de escritorio y en sus servidores, el mismo navegador web, la misma implementación wifi. El otro teléfono, basado en un SO embebido, tenía una pila TCP/IP y wifi propia, no optimizadas para los ratios de transferencia de las conexiones 3G y las redes Wifi. Y su navegador web era una versión embebida limitadísima y con un motor javascript lentísimo.

Android siguió los pasos del iPhone (aunque han tenido que reinventar el entorno de programación de cero, basándolo en Java) y se está incorporando poco a poco a su estela, igual que Palm. ¿Y qué ocurre con Windows? Pues tienen un problema, porque para seguir la tendencia necesitarían una versión reducida de XP. Bien, esa versión existe, pero...es solo para x86, lo cual obliga a Microsoft a seguir en móviles con Windows CE. Y así van a tener que seguir como mínimo durante 2 ó 3 años, pues hasta entonces Intel no tendrá nada (recordar que vendieron su plataforma ARM, Xscale) que pueda utilizarse en móviles sin fundir la batería a velocidades alarmante. Esta es la encrucijada de Microsoft.

Respecto a Windows CE, no es que sea mal SO, pero en realidad es un descendiente de los SOs embebidos equivalentes a los que se utilizaban cuando los móviles no tenían muchos recursos. CE es el SO que dominaba en los Pocket PCs, PDAs y demás artefactos hace casi una década: artefactos hoy desfasados. Es útil para dispositivos con pocos recursos, y sigue siendo muy útil en esos dispositivos, pero no en los móviles modernos, que han dejado de ser embebidos, y que necesitan un kernel como el de Windows XP, Vista o 7, donde MS mantiene una inversión mucho más alta y que, exceptuando algunos aspectos específicos como las capacidades como SO de tiempo real, está más evolucionado tecnológicamente. Sin embargo, como ya está dicho, ese kernel no está portado a ARM, al menos públicamente, y no parecen tener intención de cambiar la situación, asi que de momento no tienen otra elección que CE.

En cuanto al entorno de programación, a diferencia otros SO embebidos, de esos raros que tienen sus propias APIs y su propia manera de hacer las cosas y tienen POSIX solo como una "capa de compatibilidad" y no como algo nativo (como $DEITY manda), el CE si que tiene compatibilidad con su POSIX particular, es decir, Win32, las MFC y todo el universo Windows. Es, por así decirlo, una implementación reducida de Windows sobre el kernel de CE del mismo modo que XP lo es sobre NT y el 98 lo era sobre W9X. La diferencia es que mientras que entre XP/Win 2000/NT 4.0 había mucha compatibilidad con Windows 9x, en CE no tenían que preocuparse por eso, y han desarrollado un sub-mundo alternativo más incompatible, pero no hasta el punto de ser completamente diferente. Además, tambien se puede utilizar .NET, que es multiplataforma (al igual que las aplicaciones java de Android, y a diferencia de iPhone, que apuesta claramente por ARM). Asi que en este aspecto, aunque haya pequeñas diferencias, se podría decir que Windows CE está bastante preparado para acoger hordas de programadores experimentados en plataformas Microsoft.

Sin embargo, ciertas partes del entorno Windows de CE son una vulgar imitación, o mejor dicho reimplementación, de sus equivalentes de escritorio. Mientras que Apple utiliza el mismo Safari para el escritorio y para el iPhone, Microsoft tiene un IE de escritorio y, aparte, el IE Mobile, que está obsoleto excepto para navegación básica, y que ni tan siquiera es compatible en cuanto estándares con su hermano mayor ni con muchas páginas modernas. ¿Dónde vas con un móvil de última generación sin navegador decente? En este aspecto, hay que decir que Opera ha salvado el culo a Microsoft.

La situación de Microsoft en la encrucijada de los móviles es por tanto dificil: Por una parte Microsoft debería tener interés, como lo están teniendo Apple y Google, en usar un kernel y entorno base -y aquí se incluye el navegador- para ordenadores DE VERDAD, y no versiones embebidas, aunque solo sea por unificar todo en una sola base de código, pero les limita su dependencia de x86 por el momento, hasta que Intel pueda competir con ARM. Competencia en la que es de suponer que estén muy interesados, pero que va a dejar 2 ó 3 años de superioridad y libre albedrío a iPhone y Android. Por otra parte, su entorno de programación no ofrece gran dificultad de adaptación a los programadores Windows, pero se encuentra con un gran problema adicional: la falta de uniformidad. Mientras que en el iPhone los desarrolladores saben exactamente para qué dispositivo están desarrollando, saben que el dispositivo es pluritáctil, saben la potencia de la CPU, saben las capacidades de su chip gráfico, en Windows tienen que soportar aplicaciones diseñadas para todo tipo de dispositivos con diferentes tipos de entradas, algunos táctiles, otros no, unos con un buen chip gráfico, otros no....

En resumen, que veo a Windows bloqueado en el mundo de los móviles. Previsiblemente invertirán toneladas de recursos en modernizar Windows CE y su entorno, intentarán portar el IE real de escritorio a Windows CE (probablemente su mayor problema en estos momentos: así de importante se han vuelto los navegadores)...pero será poner parches a un viejo neumático, mientras que iPhone y Android (y Palm) tendrán terreno libre para dominar a sus anchas.