Un desarrollador de Gnome ha hecho un ruido considerable con un post donde se queja de lo que el entiende como un decaimiento de la comunidad de Gnome por una serie de motivos. A riesgo de parecer arrogante, diré que parece que estén empezando a descubrir que la tierra es redonda. Incluso en este blog se habló de lo absurdo que es que en Gnome sigan a lo suyo, haciendo como que Unity es el shell por excelencia de los escritorios basados en Gnome.
Lo que me sorprende es que siga saliendo gente a desmentir todo esto basándose en que a ellos y a otra gente les gusta Gnome 3. No lo pongo en duda, pero que haya gente a la que le gusta Gnome 3 no quita para que haya mucha gente descontenta.
Mucho más me ha sorprendido la afirmación de que GTK sólo tiene a un programador trabajando a tiempo completo, que parece ser él. QT lo ha pasado mal con su compra por Nokia y posterior abandono y conversión en proyecto comunitario, pero sigue teniendo bastante más actividad que GTK (en parte, porque es bastante más que un toolkit gráfico).
28 de julio de 2012
22 de julio de 2012
Las novedades de Linux 3.5
Ya se ha anunciado la versión 3.5 del kernel Linux. Esta versión incluye soporte de checksums de los metadatos en Ext4, "sondas" de rendimiento en programas de espacio de usuario (uprobes), un mecanismo simple para construir sandboxes filtrando llamadas al sistema, un nuevo algoritmo de gestión de la cola de red diseñado para luchar contra el mal de las redes llamado "bufferbloat", soporte para detener y restaurar conexiones TCP, soporte del RFC 5827 ("TCP early retransmit"), soporte para la "suspensión del sistema oportunista" al estilo de Android, conteo de las estadísticas de fallos de E/S en Btrfs, y la capacidad de usar SCSI sobre Firewire y USB. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.
· Checksums en los metadatos de Ext4: Los sistemas de archivo como ZFS y Btrfs han probado que asegurar la integridad del sistema de archivos mediante checksums es algo que merece la pena. Así que Ext4 ha añadido la capacidad de almacenar checksums para todos los metadatos del sistema de archivos (no cubre los datos, ni tiene capacidades de "auto-curación").
Cualquier sistema de archivos Ext4 puede ser actualizado para aprovechar esta nueva característica utilizando el comando "tune2fs -O metadata_csum", o "mkfs -O metadata_csum" cuando se crea. Una vez que esta característica sea activada, los kernels antiguos que no la soportan sólo podrán montar el archivo en modo de sólo lectura.
Respecto al rendimiento, no es notable en la mayoría de casos comunes, sólo en casos orientados exclusivamente al manejo de metadatos, que son muy poco comunes.
· uprobes ("sondas" en espacio de usuario): uprobes es la contraparte de kprobes en espacio de usuario. Este sistema permite colocar "sondas" en cualquier dirección de memoria de un programa, y coleccionar información para encontrar problemas de rendimiento o para hacer simples mediciones. Estas sondas pueden colocarse dinamicamente en cualquier proceso, no se necesita reiniciar el programa ni modificar los binarios. Las sondas normalmente son gestionadas con herramientas de instrumentación como "perf probe", systemtap o LTTng. Un ejemplo de uso de uprobes con perf podría ser medir el uso de las llamadas a malloc() en la libc:
Se ha colocado una sonda en la dirección de la función malloc. Ahora, vamos a grabar el uso global de malloc en todo el sistema durante un segundo:
$ perf record -e probe_libc:malloc -agR sleep 1
Ahora puedes ver los resultados con la interfaz TUI con el comando "$ perf report", o ver una salida en texto plano en la salida estándar con "$ perf report -g flat --stdio". Si no sabes qué función quieres sondear, puedes conseguir una lista de las funciones sondeables en librerías y ejecutables usando el parámetro -F, por ejemplo: "$ perf probe -F -x /lib64/libc.so.6" o "$ perf probe -F -x /bin/zsh". Se pueden utilizar múltiples sondas y mezclaras con kprobes y con los eventos PMU del hardware o los tracepoints del kernel.
El código de uprobes es uno de los parches que más tiempo lleva fuera del kernel. Se originó a partir de SystemTap, y se ha incluido durante años en los kernels de Red Hat y Fedora.
· Filtrado de llamadas al sistema basado en seccomp: seccomp (alias de "secure computing") es un sistema simple para sandboxear procesos que fue añadido en 2.6.12 y que permite que los procesos puedan cambiar a un estado en el que sólo pueden usar un conjunto de llamadas al sistema muy limitado (exit, sigreturn, y read y write para descriptores de archivo ya abiertos). Seccomp ha sido extendido, y ahora permite construir filtros arbitrarios de llamadas al sistema, lo cual permite implementar diferentes tipos de mecanismos de seguridad. Por ejemplo, el navegador Chromium soporta esta característica para ejecutar plugins en una sandbox.
El demonio de inicio de sistema SystemD ha añadido soporte para esta característica. Un archivo de una unidad puede usar SystemCallFilter para especificar una lista de las únicas llamadas al sistema que podrán ser utilizadas, por ejemplo:
· Lucha contra el bufferbloat: gestion de cola CoDel: CoDel (alias de "controlled delay") es un algoritmo de gestión de cola de red que ha sido diseñado para luchar contra los problemas de exceso de buffering a lo largo de toda una ruta de red, problemas conocidos como "bufferbloat". De acuerdo con Jim Gettys, que fue quien acuñó ese término, "este trabajo es la culminación de tres intentos para resolver los problemas de los algoritmos de gestión de colas durante los últimos 14 años".
· Reparación de conexiones TCP: Como parte de los esfuerzos para implementar el checkpointing/restauración de procesos, Linux añade soporte para parar una conexión TCP y reiniciarla en otro host. Las implementaciones de virtualización ligera de contenedores usan esto para migrar toda una conexión de un host a otro de forma transparente, sin que lo note la otra parte de la conexión. Esto se consigue poniendo al socket en un modo de "reparación" que permite conseguir la información necesaria para restaurar ese estado en un socket nuevo.
· TCP Early Retransmit (RFC 5827): Esta funcionalidad permite activar la "retransmisión rápida" de paquetes en ciertas condiciones, para reducir el número de ACKs duplicados. En otras palabras, las conexiones se recuperan de paquetes perdidos antes, lo cual mejora la latencia.
· Suspensión oportunista del sistema al estilo Android: El problema más controvertido en la inclusión de código de Android en Linux es la funcionalidad llamada "suspend blockers" o "wakelocks". Son parte de una aproximación a la gestión de energía consistente en suspender el sistema lo más posible. El estado natural del sistema es la suspensión, utilizando energía sólo para refrescar la memoria y para poder volver a despertar de nuevo. El sistema sólo se activa de verdad cuando tiene trabajo que hacer, y en cuanto termina, vuelve a suspenderse.
Esta es una buena idea, pero a los desarrolladores del kernel no les gustó la implementación de Android (se puede encontrar un análisis técnico del problema aquí). Ha habido muchos flames, y poco progreso, lo cual es un gran problema porque los drivers de Android usan las APIs de los "suspend blockers", y la ausencia de dichas APIs hacía imposible incluir el código en Linux. Pero en esta versión, el kernel incorpora una funcionalidad similar llamada "autosleep y wake locks". Se espera que pueda servir a Android y que la inclusión de drivers de él se acelere.
· Estadísticas de fallos de E/S en Btrfs y mejoras de latencia: Se ha añadido soporte para la recolección de estadísticas de fallos de E/S en Btrfs para cada unidad. El comando de Btrfs para recabar esa información, que será incluido en futuras versiones de btrfs-progs, es "btrfs device stats".
Esta versión de Btrfs también incluye cambios que hacen que Btrfs sea mucho más amigable con el reclamado de memoria, y reduce bastante las latencias para E/S síncrono.
· SCSI sobre Firewire y USB: Esta versión incluye un driver que permite usar una conexión Firewire como transporte SCSI. Esto permite exponer dispositivos SCSI a otros nodos en el bus Firewire: por ejemplo, discos duros. Es una funcionalidad similar al Target Disk mode de los ordenadores Apple.
Esta versión también incluye un driver usb-gadget que hace lo mismo con USB. El driver soporta dos protocoloes USB: BBB/BOT (Bulk Only Transport) y UAS (USB Attached SCSI).
Y eso es todo. La lista completa de cambios en inglés, aquí.
· Checksums en los metadatos de Ext4: Los sistemas de archivo como ZFS y Btrfs han probado que asegurar la integridad del sistema de archivos mediante checksums es algo que merece la pena. Así que Ext4 ha añadido la capacidad de almacenar checksums para todos los metadatos del sistema de archivos (no cubre los datos, ni tiene capacidades de "auto-curación").
Cualquier sistema de archivos Ext4 puede ser actualizado para aprovechar esta nueva característica utilizando el comando "tune2fs -O metadata_csum", o "mkfs -O metadata_csum" cuando se crea. Una vez que esta característica sea activada, los kernels antiguos que no la soportan sólo podrán montar el archivo en modo de sólo lectura.
Respecto al rendimiento, no es notable en la mayoría de casos comunes, sólo en casos orientados exclusivamente al manejo de metadatos, que son muy poco comunes.
· uprobes ("sondas" en espacio de usuario): uprobes es la contraparte de kprobes en espacio de usuario. Este sistema permite colocar "sondas" en cualquier dirección de memoria de un programa, y coleccionar información para encontrar problemas de rendimiento o para hacer simples mediciones. Estas sondas pueden colocarse dinamicamente en cualquier proceso, no se necesita reiniciar el programa ni modificar los binarios. Las sondas normalmente son gestionadas con herramientas de instrumentación como "perf probe", systemtap o LTTng. Un ejemplo de uso de uprobes con perf podría ser medir el uso de las llamadas a malloc() en la libc:
$ perf probe -x /lib64/libc.so.6 malloc Added new event: probe_libc:malloc (on 0x7eac0)
Se ha colocado una sonda en la dirección de la función malloc. Ahora, vamos a grabar el uso global de malloc en todo el sistema durante un segundo:
$ perf record -e probe_libc:malloc -agR sleep 1
Ahora puedes ver los resultados con la interfaz TUI con el comando "$ perf report", o ver una salida en texto plano en la salida estándar con "$ perf report -g flat --stdio". Si no sabes qué función quieres sondear, puedes conseguir una lista de las funciones sondeables en librerías y ejecutables usando el parámetro -F, por ejemplo: "$ perf probe -F -x /lib64/libc.so.6" o "$ perf probe -F -x /bin/zsh". Se pueden utilizar múltiples sondas y mezclaras con kprobes y con los eventos PMU del hardware o los tracepoints del kernel.
El código de uprobes es uno de los parches que más tiempo lleva fuera del kernel. Se originó a partir de SystemTap, y se ha incluido durante años en los kernels de Red Hat y Fedora.
· Filtrado de llamadas al sistema basado en seccomp: seccomp (alias de "secure computing") es un sistema simple para sandboxear procesos que fue añadido en 2.6.12 y que permite que los procesos puedan cambiar a un estado en el que sólo pueden usar un conjunto de llamadas al sistema muy limitado (exit, sigreturn, y read y write para descriptores de archivo ya abiertos). Seccomp ha sido extendido, y ahora permite construir filtros arbitrarios de llamadas al sistema, lo cual permite implementar diferentes tipos de mecanismos de seguridad. Por ejemplo, el navegador Chromium soporta esta característica para ejecutar plugins en una sandbox.
El demonio de inicio de sistema SystemD ha añadido soporte para esta característica. Un archivo de una unidad puede usar SystemCallFilter para especificar una lista de las únicas llamadas al sistema que podrán ser utilizadas, por ejemplo:
[Service] ExecStart=/bin/echo "I am in a sandbox" SystemCallFilter=brk mmap access open fstat close read fstat mprotect arch_prctl munmap write
· Lucha contra el bufferbloat: gestion de cola CoDel: CoDel (alias de "controlled delay") es un algoritmo de gestión de cola de red que ha sido diseñado para luchar contra los problemas de exceso de buffering a lo largo de toda una ruta de red, problemas conocidos como "bufferbloat". De acuerdo con Jim Gettys, que fue quien acuñó ese término, "este trabajo es la culminación de tres intentos para resolver los problemas de los algoritmos de gestión de colas durante los últimos 14 años".
· Reparación de conexiones TCP: Como parte de los esfuerzos para implementar el checkpointing/restauración de procesos, Linux añade soporte para parar una conexión TCP y reiniciarla en otro host. Las implementaciones de virtualización ligera de contenedores usan esto para migrar toda una conexión de un host a otro de forma transparente, sin que lo note la otra parte de la conexión. Esto se consigue poniendo al socket en un modo de "reparación" que permite conseguir la información necesaria para restaurar ese estado en un socket nuevo.
· TCP Early Retransmit (RFC 5827): Esta funcionalidad permite activar la "retransmisión rápida" de paquetes en ciertas condiciones, para reducir el número de ACKs duplicados. En otras palabras, las conexiones se recuperan de paquetes perdidos antes, lo cual mejora la latencia.
· Suspensión oportunista del sistema al estilo Android: El problema más controvertido en la inclusión de código de Android en Linux es la funcionalidad llamada "suspend blockers" o "wakelocks". Son parte de una aproximación a la gestión de energía consistente en suspender el sistema lo más posible. El estado natural del sistema es la suspensión, utilizando energía sólo para refrescar la memoria y para poder volver a despertar de nuevo. El sistema sólo se activa de verdad cuando tiene trabajo que hacer, y en cuanto termina, vuelve a suspenderse.
Esta es una buena idea, pero a los desarrolladores del kernel no les gustó la implementación de Android (se puede encontrar un análisis técnico del problema aquí). Ha habido muchos flames, y poco progreso, lo cual es un gran problema porque los drivers de Android usan las APIs de los "suspend blockers", y la ausencia de dichas APIs hacía imposible incluir el código en Linux. Pero en esta versión, el kernel incorpora una funcionalidad similar llamada "autosleep y wake locks". Se espera que pueda servir a Android y que la inclusión de drivers de él se acelere.
· Estadísticas de fallos de E/S en Btrfs y mejoras de latencia: Se ha añadido soporte para la recolección de estadísticas de fallos de E/S en Btrfs para cada unidad. El comando de Btrfs para recabar esa información, que será incluido en futuras versiones de btrfs-progs, es "btrfs device stats".
Esta versión de Btrfs también incluye cambios que hacen que Btrfs sea mucho más amigable con el reclamado de memoria, y reduce bastante las latencias para E/S síncrono.
· SCSI sobre Firewire y USB: Esta versión incluye un driver que permite usar una conexión Firewire como transporte SCSI. Esto permite exponer dispositivos SCSI a otros nodos en el bus Firewire: por ejemplo, discos duros. Es una funcionalidad similar al Target Disk mode de los ordenadores Apple.
Esta versión también incluye un driver usb-gadget que hace lo mismo con USB. El driver soporta dos protocoloes USB: BBB/BOT (Bulk Only Transport) y UAS (USB Attached SCSI).
Y eso es todo. La lista completa de cambios en inglés, aquí.
21 de julio de 2012
Steam y Mesa
Creo que soy una de las pocas personas del mundo Linux que no se ha emocionado demasiado tras anunciarse que Valve va a portar Steam a Linux. Aparte de algunas excepciones en Flash, los videojuegos no me atraen demasiado. Aunque desde luego es una gran noticia, los juegos son una de las últimas grandes funcionalidades genéricas que fuerza a mucha gente que empieza a usar Linux a rearrancar de vez en cuando Windows.
Sin embargo, saber que la gente de Valve se está reuniendo con programadores de Intel para mejorar aspectos concretos de sus drivers o de Mesa me ha parecido tremendamente importante, quizás porque además de a Steam, beneficiará enormemente al resto del ecosistema.
Y es que Linux sigue teniendo grandes problemas con la calidad de su implementación de OpenGL en Mesa. El estado actual no es nada envidiable: OpenGL 3.0 está, por fin, soportado en los drivers más importantes, pero se ha tardado una barbaridad. Para la 3.1 aun tienen que implementar el soporte de GSGL 1.40. De las versiones 4.x, prácticamente no se soporta nada. Bien es cierto que a Valve no le interesan tanto las últimas versiones, sino el soporte de calidad de las versiones más extendidas (la versión de "Left 4 Dead 2" para OS X usa OpenGL 3, es más, OS X tampoco soporta la versión 4), pero es que la calidad de la implementación de OpenGL 3 en los drivers abiertos, particularmente los Intel y AMD, también deja que desear, a pesar de que 3.0 es un estándar de hace cuatro años y a estas alturas la implementación debería estar bien madura.
¿Por qué Linux no tiene una implementación OpenGL de más calidad? Parte del problema está en la carencia de un ecosistema de juegos saludable, que deja a los programadores gráficos en minoría. Ante los problemas de calidad de Mesa suelen optar por atajar los problemas por la vía de las listas negras de hardware o directamente no utilizar las funciones avanzadas que causan problemas y conformarse con menos (véase: compositores de escritorio), o ignorar el hardware mal soportado, o directamente no soportar Linux. Los problemas se evitan en lugar de enfrentarse, los desarrolladores de drivers no tienen presiones para resolverlos, y todo el mundo se adapta y se siente más o menos cómodo dentro de esta mediocridad.
Lo bueno de la llegada de Steam es que se centran en algo muy concreto, en "Left 4 Dead 2", es decir, tratan de optimizar un caso de uso real, no un mero estándar de papel. Gracias a la colaboración con Intel, los programadores de los controladores tienen acceso al código fuente del juego, ven exactamente lo que ocurre, y pueden optimizar el driver para lo que realmente importa e implementar las cosas que verdaderamente son necesarias. Dado que la versión de Linux de Steam va a tener popularidad, la demanda de buen rendimiento para Left 4 Dead 2 se va a convertir en la prioridad principal para todos los desarrolladores de Mesa y de todos los drivers. Tal vez esto sea lo que Linux necesita para tener, por fin, buen rendimiento gráfico. Y claro, esto beneficiará a los compositores de escritorio y a toolkits como QT/QML (que es lo que a mi me interesa).
Sin embargo, saber que la gente de Valve se está reuniendo con programadores de Intel para mejorar aspectos concretos de sus drivers o de Mesa me ha parecido tremendamente importante, quizás porque además de a Steam, beneficiará enormemente al resto del ecosistema.
Y es que Linux sigue teniendo grandes problemas con la calidad de su implementación de OpenGL en Mesa. El estado actual no es nada envidiable: OpenGL 3.0 está, por fin, soportado en los drivers más importantes, pero se ha tardado una barbaridad. Para la 3.1 aun tienen que implementar el soporte de GSGL 1.40. De las versiones 4.x, prácticamente no se soporta nada. Bien es cierto que a Valve no le interesan tanto las últimas versiones, sino el soporte de calidad de las versiones más extendidas (la versión de "Left 4 Dead 2" para OS X usa OpenGL 3, es más, OS X tampoco soporta la versión 4), pero es que la calidad de la implementación de OpenGL 3 en los drivers abiertos, particularmente los Intel y AMD, también deja que desear, a pesar de que 3.0 es un estándar de hace cuatro años y a estas alturas la implementación debería estar bien madura.
¿Por qué Linux no tiene una implementación OpenGL de más calidad? Parte del problema está en la carencia de un ecosistema de juegos saludable, que deja a los programadores gráficos en minoría. Ante los problemas de calidad de Mesa suelen optar por atajar los problemas por la vía de las listas negras de hardware o directamente no utilizar las funciones avanzadas que causan problemas y conformarse con menos (véase: compositores de escritorio), o ignorar el hardware mal soportado, o directamente no soportar Linux. Los problemas se evitan en lugar de enfrentarse, los desarrolladores de drivers no tienen presiones para resolverlos, y todo el mundo se adapta y se siente más o menos cómodo dentro de esta mediocridad.
Lo bueno de la llegada de Steam es que se centran en algo muy concreto, en "Left 4 Dead 2", es decir, tratan de optimizar un caso de uso real, no un mero estándar de papel. Gracias a la colaboración con Intel, los programadores de los controladores tienen acceso al código fuente del juego, ven exactamente lo que ocurre, y pueden optimizar el driver para lo que realmente importa e implementar las cosas que verdaderamente son necesarias. Dado que la versión de Linux de Steam va a tener popularidad, la demanda de buen rendimiento para Left 4 Dead 2 se va a convertir en la prioridad principal para todos los desarrolladores de Mesa y de todos los drivers. Tal vez esto sea lo que Linux necesita para tener, por fin, buen rendimiento gráfico. Y claro, esto beneficiará a los compositores de escritorio y a toolkits como QT/QML (que es lo que a mi me interesa).
8 de julio de 2012
¿Meego está muerto, o está muy vivo?
Me ha sorprendido encontrarme hoy con está noticia sobre una nueva empresa que tiene el propósito declarado de fabricar teléfonos basados en derivados de Meego. Lo que hace relevante a esta empresa es que al parecer está formada por algún ex trabajador de Nokia que trabajó en productos Meego. En concreto, su fundador fue en Nokia el "Principal Engineer" de productos Meego desde 2006 hasta hace poco.
A estas alturas, hay que dejar claro que no hay ninguna esperanza para Meego -o para cualquier otro aspirante- como competidor de Android o iOS: la guerra fría de patentes de software garantiza por si sola que ningún pequeño jugador pueda entrar a competir. Sin embargo, eso no excluye la viabilidad de ciertos nichos. Creo que el monopolio de pocas empresas relevantes de software (Microsoft y un raquítico Apple en los 90) es una anomalía histórica de un sector muy nuevo con barreras de entrada -implementar un SO completo- enorme, pero el software libre ha bajado la barrera, y eso debería permitir la viabilidad de nichos.
Ahora bien, tampoco hay que precipitarse. Esta nueva compañía -Jolla- por no tener no tiene ni página web, sólo un twitter y un Linkedin. Le queda mucho para dejar de ser vaporware, pero el hecho de estar formado por gente que creó Meego le da más credibilidad: no se trata de alguien advenedizo con ilusiones de grandeza, sino alguien con un producto terminado en su currículum.
Pero lo que me llama la atención de todo esto es que a pesar de que el Meego oficial es un proyecto muerto y bien muerto tras haber sido abandonado por Intel y por Nokia, no está desapareciendo con el silencio que se le supone a los cadáveres. Al contrario, este muerto hace bastante ruido. Está Tizen, que aunque sigue sin oler bien, Samsung ha anunciado recientemente -por fin- un futuro teléfono basado en él. Está el proyecto Mer, que es una especie de Tizen pero gestionado abiertamente por la comunidad -es el que utilizará Jolla- y que ha sido capaz de crear builds de Mer para varios dispositivos. Está Vivaldi, la tableta basada en Mer creada por desarrolladores de KDE. Está cloudberrytec, una compañía creada también hace poco por ex desarrolladores de Meego, que se han marchado de Nokia tras publicar la última actualización del N9. Y está Jolla.
En definitiva, existe una serie de proyectos o empresas empeñadas en hacer todo lo posible por crear un sistema operativo móvil derivado de Meego. Individualmente, esas iniciativas nunca me parecieron esperanzadoras -algunas siguen sin parecermelo-; por si sola una empresa de ex trabajadores de Meego empeñada en resucitar un producto muerto y con escasas probabilidades de éxito parece algo más nostálgico que esperanzador. Pero la variedad de empresas comprometidas con los mismos "ideales técnicos", por llamarlos de algún modo, es una confirmación de que el futuro de los descendientes de Meego, haber, tiene que haber. Tanto empeño empleado en lo mismo al final ha de dar algún fruto.
A estas alturas, hay que dejar claro que no hay ninguna esperanza para Meego -o para cualquier otro aspirante- como competidor de Android o iOS: la guerra fría de patentes de software garantiza por si sola que ningún pequeño jugador pueda entrar a competir. Sin embargo, eso no excluye la viabilidad de ciertos nichos. Creo que el monopolio de pocas empresas relevantes de software (Microsoft y un raquítico Apple en los 90) es una anomalía histórica de un sector muy nuevo con barreras de entrada -implementar un SO completo- enorme, pero el software libre ha bajado la barrera, y eso debería permitir la viabilidad de nichos.
Ahora bien, tampoco hay que precipitarse. Esta nueva compañía -Jolla- por no tener no tiene ni página web, sólo un twitter y un Linkedin. Le queda mucho para dejar de ser vaporware, pero el hecho de estar formado por gente que creó Meego le da más credibilidad: no se trata de alguien advenedizo con ilusiones de grandeza, sino alguien con un producto terminado en su currículum.
Pero lo que me llama la atención de todo esto es que a pesar de que el Meego oficial es un proyecto muerto y bien muerto tras haber sido abandonado por Intel y por Nokia, no está desapareciendo con el silencio que se le supone a los cadáveres. Al contrario, este muerto hace bastante ruido. Está Tizen, que aunque sigue sin oler bien, Samsung ha anunciado recientemente -por fin- un futuro teléfono basado en él. Está el proyecto Mer, que es una especie de Tizen pero gestionado abiertamente por la comunidad -es el que utilizará Jolla- y que ha sido capaz de crear builds de Mer para varios dispositivos. Está Vivaldi, la tableta basada en Mer creada por desarrolladores de KDE. Está cloudberrytec, una compañía creada también hace poco por ex desarrolladores de Meego, que se han marchado de Nokia tras publicar la última actualización del N9. Y está Jolla.
En definitiva, existe una serie de proyectos o empresas empeñadas en hacer todo lo posible por crear un sistema operativo móvil derivado de Meego. Individualmente, esas iniciativas nunca me parecieron esperanzadoras -algunas siguen sin parecermelo-; por si sola una empresa de ex trabajadores de Meego empeñada en resucitar un producto muerto y con escasas probabilidades de éxito parece algo más nostálgico que esperanzador. Pero la variedad de empresas comprometidas con los mismos "ideales técnicos", por llamarlos de algún modo, es una confirmación de que el futuro de los descendientes de Meego, haber, tiene que haber. Tanto empeño empleado en lo mismo al final ha de dar algún fruto.
7 de julio de 2012
Steve Ballmer y el futuro de su pequeño imperio
Cuando Microsoft dijo que se jugaba el futuro de la compañía a la carta de Internet, mucho creíamos que eran sinceros. Cuando empezó a enfrentarse a Google en serio, mucho creíamos que era verdaderamente en serio, y que aunque Google llevaba las de ganar, veríamos una pelea encarnizada. Veía como inevitable la aparición de algún servicio web revolucionario de mano de Redmond, algo que les metiera en la competición. La realidad en estos últimos años ha sido que no sólo no han cumplido mis expectativas, sino que han logrado perder las fortalezas que tenían anteriormente. Las excepciones están contadas.
Habría que empezar señalando que Microsoft era la compañía mejor situada para ser dueña y señora de Internet. Hubo un tiempo en el que Messenger era (con el perdón de AIM) poderoso; una de las preguntas inevitables que hacía todo nuevo usuarios de Linux era dónde encontrar algo comparable al Messenger. En cuando a correo web, Hotmail tenía una posición muy sólida. Ambos atributos eran útiles para intentar competir con Facebook, Twitter u otros servicios, de haberlo intentado en serio; algo que no hicieron.
El cliente de Messenger fue dejado de lado y ha acabado perdiendo su base de usuarios y convirtiéndose en un chiste. A pesar de estar gastándose cientos de millones en su "estrategia online", pensaron que Messenger debía dar dinero y en lugar de mejorarlo se centraron en meterle publicidad por todos los rincones, para luego intentar convertirlo, ya tarde, en un engendro de pseudo red social. A día de hoy sigue existiendo esa pseudo red en el cliente (horroroso) y en live.com, tan pobre que debería producir sonrojo. Respecto a Hotmail, parece ser que Gmail ya le ha pasado en número de usuarios, lo cual no es sorprendente. Soapbox, un competidor de Youtube, acabó siendo cerrando. Microsoft Spaces, su servicio de blogging, fue cerrado y se dio a los usuarios opción de migrar a wordpress. Respecto a la versión web de Office que hay en Skydrive, no tiene frente a Google Docs que tiene Office en el escritorio contra el resto de suites ofimáticas. ¿Este es el panorama de una compañía que quiere ser fuerte en la web? Y mejor no recordar ese asuntillo llamado Silverlight...
Bing merece mención especial. Durante un tiempo hizo mucho ruido, y las noticias contaban la mucha cuota de uso que estaba ganando en Estados Unidos. Incluso hoy en día siguen viéndose noticias sobre esas subidas. Sin embargo, ¿en qué se queda el balance de tres años de vida de Bing? Cuando se anunció, Google tenía un 64% de cuota de mercado global. Hoy, tiene un 65%. Ha parado el ascenso de Google, que hasta podría parecer meritorio si no fuese porque Bing es el motor de búsqueda por defecto del navegador web por defecto del sistema operativo utilizado por defecto en prácticamente todos los PCs del mundo. Mucho bombo y pandereta, pero mientras que en este tiempo Google ha añadido "universal search" y "instant search", bing no ha cambiado sustancialmente. Y ahora que Chrome es o está cerca de convertirse en el navegador más usado del mundo, y los productos Apple podría venderse más que los PCs windows, las ventajas de ser el buscador-por-defecto se debilitan.
A pesar de que su trayectoria no ha sido precisamente una estela de éxitos,, la división interna que se ocupa de todo esto, "online services" (que clasifiquen lo "online" como un ente aparte dice más de lo que parece), ha devorado capital a espuertas. Concretamente, en sus últimos resultados trimestrales, perdió 479$ millones. Si tenemos en cuenta que los ingresos fueron de 707$ millones, nos salen unos gastos de entre 12 y 13 millones al día, es decir, aproximadamente medio millón a la hora. ¿En qué demonios gastan todo ese dinero? Sin duda, no en proyectos web. Probablemente se haya gastado casi todo en montar Azure, su "nube".
No todo les va mal, claro. Mientras que su posición web es pobre y el imperio Windows es atacado por iOS y Android, sus divisiones "Server and Tools" y "Bussiness" son cada vez más exitosas y se han convertido, de hecho, en las más importantes y las que más dinero generan. Es previsible que, poco a poco, Microsoft se convierta en una empresa dedicada a dar servicios empresariales y gubernamentales. De la web, mejor olvidarse. Ni Windows 8 ni la tableta Surface ni el enésimo envoltorio puesto a .NET harán desaparecer a Google y a Facebook.
Habría que empezar señalando que Microsoft era la compañía mejor situada para ser dueña y señora de Internet. Hubo un tiempo en el que Messenger era (con el perdón de AIM) poderoso; una de las preguntas inevitables que hacía todo nuevo usuarios de Linux era dónde encontrar algo comparable al Messenger. En cuando a correo web, Hotmail tenía una posición muy sólida. Ambos atributos eran útiles para intentar competir con Facebook, Twitter u otros servicios, de haberlo intentado en serio; algo que no hicieron.
El cliente de Messenger fue dejado de lado y ha acabado perdiendo su base de usuarios y convirtiéndose en un chiste. A pesar de estar gastándose cientos de millones en su "estrategia online", pensaron que Messenger debía dar dinero y en lugar de mejorarlo se centraron en meterle publicidad por todos los rincones, para luego intentar convertirlo, ya tarde, en un engendro de pseudo red social. A día de hoy sigue existiendo esa pseudo red en el cliente (horroroso) y en live.com, tan pobre que debería producir sonrojo. Respecto a Hotmail, parece ser que Gmail ya le ha pasado en número de usuarios, lo cual no es sorprendente. Soapbox, un competidor de Youtube, acabó siendo cerrando. Microsoft Spaces, su servicio de blogging, fue cerrado y se dio a los usuarios opción de migrar a wordpress. Respecto a la versión web de Office que hay en Skydrive, no tiene frente a Google Docs que tiene Office en el escritorio contra el resto de suites ofimáticas. ¿Este es el panorama de una compañía que quiere ser fuerte en la web? Y mejor no recordar ese asuntillo llamado Silverlight...
Bing merece mención especial. Durante un tiempo hizo mucho ruido, y las noticias contaban la mucha cuota de uso que estaba ganando en Estados Unidos. Incluso hoy en día siguen viéndose noticias sobre esas subidas. Sin embargo, ¿en qué se queda el balance de tres años de vida de Bing? Cuando se anunció, Google tenía un 64% de cuota de mercado global. Hoy, tiene un 65%. Ha parado el ascenso de Google, que hasta podría parecer meritorio si no fuese porque Bing es el motor de búsqueda por defecto del navegador web por defecto del sistema operativo utilizado por defecto en prácticamente todos los PCs del mundo. Mucho bombo y pandereta, pero mientras que en este tiempo Google ha añadido "universal search" y "instant search", bing no ha cambiado sustancialmente. Y ahora que Chrome es o está cerca de convertirse en el navegador más usado del mundo, y los productos Apple podría venderse más que los PCs windows, las ventajas de ser el buscador-por-defecto se debilitan.
A pesar de que su trayectoria no ha sido precisamente una estela de éxitos,, la división interna que se ocupa de todo esto, "online services" (que clasifiquen lo "online" como un ente aparte dice más de lo que parece), ha devorado capital a espuertas. Concretamente, en sus últimos resultados trimestrales, perdió 479$ millones. Si tenemos en cuenta que los ingresos fueron de 707$ millones, nos salen unos gastos de entre 12 y 13 millones al día, es decir, aproximadamente medio millón a la hora. ¿En qué demonios gastan todo ese dinero? Sin duda, no en proyectos web. Probablemente se haya gastado casi todo en montar Azure, su "nube".
No todo les va mal, claro. Mientras que su posición web es pobre y el imperio Windows es atacado por iOS y Android, sus divisiones "Server and Tools" y "Bussiness" son cada vez más exitosas y se han convertido, de hecho, en las más importantes y las que más dinero generan. Es previsible que, poco a poco, Microsoft se convierta en una empresa dedicada a dar servicios empresariales y gubernamentales. De la web, mejor olvidarse. Ni Windows 8 ni la tableta Surface ni el enésimo envoltorio puesto a .NET harán desaparecer a Google y a Facebook.
Suscribirse a:
Entradas (Atom)