Nuevas cosas extrañas en Gnome 3

Como cualquier otro aficionado, sigo la evolución de Gnome por pura curiosidad, y a veces a uno le viene un extraño espíritu conciliador y piensa que, a pesar de todo van mejorando y quizás merezcan una oportunidad. No todo es malo, etc etc. Pero no pasa mucho tiempo hasta que ese espíritu desaparece instantáneamente al leer ciertas cosas sobre la próxima versión que le hacen pensar "qué caraj...".

Hoy le ha tocado la oportunidad a dos cosas. La primera, este bug (que continúa en este). ¿En que consiste? En que si uno se conecta con una conexión de red cableada, no verá ningún icono en la barra superior que indique si la red está conectada o no, a diferencia de lo que ocurre con las conexiones wifi. ¿Un error, quizás? Para nada:

"After talking to mclasen in #fedora-desktop, indeed, what I suspected is true: the design is not to have any kind of indicator for a wired network connection, on the basis that it's not really necessary. The assumption is that a wired network pretty much ought to work so long as it's plugged in; an indicator just doesn't provide much actual usefulness. The design might change if someone can point out a case where an indicator is actually useful, but for now this is the intended behaviour"

Si, los diseñadores de Gnome han decidido que ocupar parte del Sagrado Espacio Vacío del panel principal con cosas inútiles tales como iconos que muestren el estatus de redes cableadas es una equivocación, como también lo es facilitar el cambio de parámetros de la red mediante ese icono. No, claro que no hay opción para configurar esta parte de la interfaz.

Ya en el bugzilla de Gnome, los desarrolladores de Gnome Shell tratan de interesarse por las incomprensibles quejas de sus usuarios:

Why do you need to see the status of your wired connection in the top bar? Why do you need to access wired network settings from the menu?

Más adelante, tras comprender las atribuladas necesidades de los usuarios, el desarrollador procede a explicar la decisión:

For machines that are permanently connected to a wired connection, that icon is mostly noise. In most cases you are always connected, and the status never changes. The icon is uninteresting and gets in the way of the information that has utility. There are many cases where a wired connection comes very close to being a physical part of the machine itself (eg. computer labs, etc). With the new model, every icon in the top bar has an associated submenu with options. However, in the case of wired, there are no options that are of use to the vast majority of users. The proportion of people needing to turn off their wired connection is very small indeed.

Y algo más adelante añade:

This bugs makes it clear that there are other cases which aren't catered for so well by the new design, including allowing wired profiles to be changed, or disabling of wired connections. However, at this point in time I am not convinced that those cases are common enough to fundamentally alter the design to better suit them.

Algunos usuarios informan de que necesitan conocer el estatus de la red para conectarse a VPN, otros para poder funcionar con normalidad en la red de su empresa, otros cuentan casos en que necesitan un icono para poder cambiar entre diferentes perfiles de su red o para cambiar entre redes más rápidas y más lentas...

Dejando aparte las quejas, la lógica del desarrollador de Gnome es profundamente errónea. Basa su decisión en el hecho de que la mayor parte de los usuarios de redes cableadas no cambian nunca su estatus de red, y por tanto no necesitan notificación visual permanente. Este razonamiento es absurdo por dos razones:

• Como informan varios usuarios, no todas las redes cableadas del mundo corresponden a equipos fijos, existen en este mundo portátiles que se conectan y desconectan ocasionalmente a redes cableadas; para ellos el ser notificados de la conexión cableada es tan esencial como ser notificado de las conexiones inalámbricas -el estatus de las redes inalámbricas si que se muestra en todo momento-.
• Existen muchos usuarios de redes inalámbricas conectados a redes inalámbricas en su casa de las que jamás se desconectan, es decir, hay muchas conexiones inalámbricas que no cambian nunca su estatus de red y, por tanto, no deberían necesitar notificación visual permanente, según la propia lógica del desarrollador.

Como tantas otras cosas en Gnome, este problema acabará siendo solucionado tal y como es la tradición:

This seems like it might be an appropriate place for a shell extension.

Y procediendo a tratar todos los reportes de bug, muchos de ellos de gente que cree genuinamente que la ausencia de icono es un fallo, con hermosos duplicados remitiendo al bug principal.

Hay una segunda cosa que me ha llamado la atención sobre Gnome estos días, se trata de este comentario de reddit en el cual un usuario informa de sus pruebas de distribuciones de Linux habituales en una tableta. El comentario sobre Gnome 3 es el siguiente, negrita mía:

Gnome3 works OK in tablet mode, but the severely limited config options means you pretty much get what you get and can't easily tweak it for tablet sizing. The result is that many of the controls are too small to be used. I found Gnome3 works best if I ran only one app at a time and didn't try to multi-task. Onscreen keyboards are an issue here - just as with KDE4

¿Recuerdan que uno de los objetivos de Gnome 3 era funcionar bien en interfaces táctiles?

Los PCs se desangran, y los informáticos tienen propensión a ignorarlo

Matthew Yglesias se hace eco de la monumental caída prevista en las ventas de 2013 de PCs tradicionales, nada menos que de un 10.1% respecto al año anterior, una caída nunca vista en el sector. El dato es significativo porque los PCs siempre fueron el icono de la vanguardia tecnológica; de hecho aumentaron sus ventas, aunque fuera levemente, durante lo peor de la recesión mundial. Sin embargo, están empezando a venderse menos ahora, cuando la situación económica está mejorando en muchos países; ya en 2012 hubo una caída minúscula. Y si bien cabe esperar una estabilización, los grandes aumentos parecen descartados, ya que las ventas se limitan a renovar equipos actuales.

La causa obvia de este cambio son los dispositivos portáctiles, que dispararon sus ventas en paralelo al estancamiento de ventas del PC, y que van camino de superarlo en ventas en poco tiempo. ¿Por qué aun hay quien que discute que vayan a reemplazar a los PCs en la mayoría de casos, a pesar de que los datos son indiscutibles y todo parece apuntar a que es cierta la afirmación Jobsiana de que los PCs se convertirán en los camiones de la computación, usados por una minoría de expertos? Yglesias da en el clavo: La mayor parte de quienes discuten que vayamos a ver una revolución portáctil son, precisamente, quienes trabajan con PCs. Son los camioneros tecnológicos, en su mayor parte informáticos y profesionales que seguirán utilizando PCs por razones laborales o de afición, quienes tienen propensión a creer que el mundo va a seguir dando vueltas a su alrededor.

Se hace necesario recordar ahora la presentación del iPad, que inauguró el formato de tableta actual (no, los antiguos tablet pc de Microsoft no cuentan). Las muy, muy, muy, abundantes críticas, entre las que se incluyen las del ex-CEO de Google Eric Schmidt o las de Bill Gates, son comprensibles ahora teniendo en cuenta que quienes las hicieron son, en su mayor parte, camioneros. Recuerden las críticas por la ausencia de puerto USB: olvidaban que para la mayor parte de la población el puerto USB no era un requisito importante, por mucho que lo sea para los aficionados a la tecnología (aun existen personas que afirman que el éxito comercial del iPad es mera cuestión de fanbois que compran cualquier cosa de Apple para estar a la moda). Uno de mis mayores orgullos en este blog es haber sido optimista respecto al iPad y señalar sus ventajas respecto al Slate PC, un engendro con interfaz de Windows 7 que fue presentado 20 días antes que el iPad por el propio Steve Ballmer, y del que ya nadie se acuerda.

Esto también recuerda lo mucho que se ha criticado a Steve Jobs últimamente cuando Steve Wozniak reveló que nunca programó nada de los equipos Apple, siendo reducido por la opinión popular de muchos foros a un mero mercader cuyo éxito se basa en la publicidad. Lo cierto es que no ser programador y limitarse a ver la tecnología desde el punto de vista del consumidor probablemente le ayudó a no confundir las necesidades de quienes programan con las de la gente de a pie.

Volviendo un poco más cerca al mundo del software libre, es evidente que es un universo excesivamente predispuesto a seguir enganchado a la mentalidad PC. Es comprensible, dado el perfil de sus componentes y sus necesidades; quizás incluso podríamos hablar de la desventaja del modelo software libre, en el que la gente programa para cubrir sus necesidades, frente al software comercial, que trata de cubrir necesidades comerciales de la población. Sin embargo, esta desventaja tiene una gran ventaja potencial, que es la de llegar a dominar el sector camionero. Aunque el software libre debería intentar mejorar su oferta portáctil más allá de Android, creo que no se debe olvidar que el PC, aunque minoritario, seguirá existiendo y va a seguir siendo un sector importante, al que las compañías comerciales no prestarán tanta atención como antes por simples requisitos de los accionistas.

¿Estamos en 1999? Probablemente no

Desde hace un tiempo se llevan viendo por ahí artículos que argumentan que el mercado bursátil del sector tecnológico está viviendo una nueva burbuja, como la que explotó en el 2000. El último periódico con renombre que se ha apuntado a la teoría es el New York Times. El motivo de las teorías es que hay varias empresas de Silicon Valley que están valoradas por las nubes, a pesar de que sólo tienen pérdidas y perspectivas dudosas de generar grandes beneficios a largo plazo. El ejemplo canónico, Twitter.

Si bien es cierto que muchas de esas empresas tienen pinta de estar muy sobrevaloradas, me cuesta mucho creer que estemos ante una burbuja tecnológica similar a la del 2000.

En primer lugar, el alza de la bolsa no es exclusivo al sector tecnológico. Durante el 2013 ha habido un alza generalizada en las bolsas, uno de los temas que no dejan de repetirse en los medios es que los valores de la bolsa están muy sobrevalorados. Un crash no sería, por tanto, un crash del sector tecnológico en particular, sino de la economía en general, como lo fue el del 2008-2009.

En segundo lugar, las huchas de las compañías estadounidenses están a rebosar, en récords históricos. Y de todas las compañías estadounidenses, las del sector tecnológico -Apple, Microsoft, Google, Cisco, Oracle, Qualcomm- dominan la lista de los 10 primeros. Que yo sepa, esto no fue así en la anterior burbuja. Si hubiera un nuevo crash tecnológico la cabeza del sector se mantendría en pie, y tiene dinero de sobra para aguantar una tormenta, comprar compañías interesantes en quiebra y reestructurar el sector por si misma.

En tercer lugar, los datos anteriores demuestran que el sector tecnológico es uno de los sectores clave de la economía estadounidense, ya no es un sector que sólo ofrece promesas vagas de beneficios a largo plazo fundamentadas en expectativas sacadas de películas de ciencia ficción, sino uno que ofrece resultados. No es un mero castillo en el aire, es un sector con gente que sabe hacer dinero.

En cuarto lugar, hoy en día Internet permite ganar dinero. Uno de los grandes cuellos de botella de Internet son las limitaciones para ejercer la oferta y la demanda. Es una de las razones por las que actualmente predominan los servicios gratuitos financiados con publicidad. Sin embargo, la publicidad ha demostrado su viabilidad. Se dijo de Facebook que no sería capaz de financiar sus gastos, pero lo cierto es que parece irles bastante bien. No hay razones para creer a estas alturas que un sistema de financiación que funciona bien para unas compañías de Internet no vaya a funcionar para otras. Y además de los anuncios, queda el comercio online mediante pago con tarjeta de crédito, paypal, bitcoin, app stores, etc; que ha aumentado significativamente en los últimos años. Sigue faltando flexibilidad para ejercer la oferta y la demanda, pero no estamos en los extremos de la burbuja anterior, donde tanto el comercio online como la financiación mediante anuncios estaban en pañales.

En resumen, que algunas compañías sobrevaloradas tendrán que reajustarse y a nadie le cabe duda de que hay especulación rampante (¿hay algún rincón del mundo donde no lo haya?), pero no creo que estemos al borde de una burbuja tecnológica que amenace con arrasar el sector.

La burocracia debianera

Como ya sabrán, Debian está planteándose cambiar de sistema de inicio. Las alternativas al sistema vigente son systemd, upstart u openrc; o una combinación de ambos. Como ha ocurrido con prácticamente cualquier cosa relacionada con systemd, se ha generado un gran debate.

Pero lo que más me interesa no es tanto la decisión, que tratándose de Debian puede ser cualquiera -incluyendo el seguir utilizando sysvinit para el resto de la eternidad-, sino cómo este asunto muestra las particularidades de sus procesos de toma de decisiones. Fui usuario de Debian durante cinco años, y alguna vez un comentario me pidió que explicara por qué no me gustaba Debian. Vaya por delante que Debian es una gran distro para lo que está orientado, simplemente no me gusta como distribución de escritorio, cada uno tiene sus gustos.

Cuando usaba Debian, hubo un retraso enorme en la actualización de los paquetes de Xfree86, que se quedaron atascados en la versión 4.2 durante una barbaridad de tiempo y obligó a usuarios normales a recurrir al repositorio experimental para poder tener escritorio gráfico en ordenadores recién comprados, además de incitar a un miembro de la "X Striking Force" a saltarse los protocolos de Debian y colar la versión 4.3 en unstable un año después de su publicación, cansado ya de esperar.

La razón por la que surgió ese atasco fue que Xfree86 no compilaba para todas las arquitecturas que soportaba Debian, y Debian tenía la política de que tenía que compilar para todas las arquitecturas. Era algo absurdo, se penalizaba al 99.9% de los usuarios de Debian, casi todos x86 (excepto algún ppc de Apple, que en aquel entonces estaba de moda) para satisfacer a arquitecturas exóticas como mips o s390. Era un caso claro de dictadura de las minorías y, por tanto, en parte una ruptura del punto 4 del contrato social. Posteriormente creo recordar que cambiaron el modo de gestionar esta clase de situaciones.

Esta anécdota viene a cuento porque me ha sorprendido encontrar de nuevo esta clase de dictadura de minorías presente en el debate sobre el sistema de inicio. Aunque no existe un veto explícito de las versiones de Debian con kernels alternativos (Debian GNU/kFreeBSD y Debian GNU/Hurd fundamentalmente), ha habido gente que ha defendido las necesidades de estos proyectos como vitales para Debian, y el hecho de que haya estado tan presente en la discusión hace evidente que existe cierto secuestro de voluntades.

Y es realmente absurdo: Debian GNU/kFreeBSD siempre va a ser un proyecto experimental y algo estrafalario que sólo van a usar cuatro gatos, y que pueda tener alguna capacidad de influencia en la evolución de Debian no hace más que evidenciar el conservadurismo y desarrollo glacial de Debian (aunque, por otra parte, es lo que requiere su base de usuarios actual).

De hecho, es desconsolador que Debian sea noticia por esta clase de debates, debates que el resto de las distribuciones tuvieron ya hace tiempo. Se puede afirmar incluso que Debian tiene limitada su capacidad para tomar una decisión, porque resto de las distribuciones ya han marcado camino, y la vía de los hechos presiona a Debian para que se conformen con seguir los caminos existentes. No en vano una de las opciones de reemplazo del sistema de inicio es upstart, una de sus distros derivadas.

En general, fue esta burocracia y conservadurismo lo que me hizo dejar de usarla. Hace 7 años que upstart fue incluido en Ubuntu, y dos y medio desde que Fedora empezó a utilizar systemd. Incluso Red Hat Enterprise Linux utiliza upstart en la versión 6, lanzada hace 3 años. Llega un punto en que usar Debian implica ponerse al margen del resto de universo Linux, al menos que uno decida usar testing, un repositorio sin identidad bien definida y que es sometido a una congelación durante un buen montón de meses previos al lanzamiento de una versión...naturalmente, la mayoría de gente prefiere usar Ubuntu.

Las novedades de Linux 3.12

Ya se ha anunciado la versión 3.12 de Linux. Esta versión incorpora soporte para desduplicación en Btrfs, cambio automático de GPU en portátiles con GPUs duales, mejora del rendimiento en GPUs AMD Radeon, mejor rendimiento multicore de RAID-5, mejor gestión de las situaciones en las que se acaba la memoria (OOM), mejora de la escalabilidad de la resolución de rutas de archivo en el VFS, mejoras al modo de multitarea sin temporizador, nodos de dispositivo separados para la configuración de modo gráfico y la renderización gráfica, mejora del rendimiento de los bloqueos en huéspedes virtualizados, mejoras en la escalabilidad del acceso recursivo a directorios en XFS, mejoras en la escalabilidad del IPC y mejoras en el bloqueo de la capa tty. 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.

· Soporte de desduplicación offline en Btrfs: El sistema de archivos Btrfs ha incorporado soporte para desduplicación de datos, es decir, encontrar porciones de datos duplicadas y eliminar las copias redundantes para dejar solamente una. En ciertos casos, como máquinas virtuales que contienen copias duplicadas de sistemas operativos enteros, o copias de seguridad que contienen datos redundantes, el ahorro de espacio puede ser considerable.

Este sistema de desduplicación es "offline", es decir, no se desduplican los datos en tiempo real, sino que lo invoca el administrador cuando lo desea para que escanee parte o la totalidad del sistema de archivos en busca de copias. La desduplicación en tiempo real será añadida en futuras versiones.

· Aumento notable de rendimiento en tarjetas gráficas AMD Radeon: La web Phoronix.com notó en unas comparativas que el rendimiento gráfico de las GPUs AMD Radeon había aumentado notoriamente en Linux 3.12. Sin embargo, no ha habido en esta versión ninguna gran mejora en los controladores que pueda justificar esa diferencia. Tras investigar, Phoronix halló que el responsable del aumento de rendimiento no estaba en el controlador de GPUs Radeon, sino en un cambio en el algoritmo del gobernado de cpufreq "ondemand". En apariencia, el gobernador "ondemand" oscilaba entre frecuencias excesivamente, y esta oscilación dañaba el rendimiento de las GPUs Radeon. El nuevo algoritmo elimina ese problema.

· Cambio automático de GPU en equipos con GPUs duales: El hardware de algunos portátiles, como los basados en la plataforma Nvidia Optimus, incluyen dos GPUs, una optimizada para el rendimiento y otra para el bajo consumo. Hasta ahora, había sido necesario utilizar algunos hacks para cambiar entre una GPU y otra. En esta versión, el driver gestiona el cambio automáticamente.

· Separación de los nodos de dispositivo para configuración de modo gráfico y para renderizado: La evolución del hardware (especialmente en ARM) muestra que el renderizado (via GPU) y la configuración de modo gráfico (vía controlador de pantalla) no están necesariamente ligados al mismo dispositivo gráfico. Esta versión incorpora soporta para separar en /dev los nodos de dispositivo para la configuración de modo gráfico y para el renderizado. El uso principal de esta separación es otorgar diferentes modos de acceso a los compositores gráficos (que requieren la API de configuración de modo gráfico) y el renderizado de clientes o GPGPU (que requieren la API de renderizado). Para más información, vea este post.

· Mejora de modo de multitarea sin temporizador: Linux 3.10 añadió soporte para la multitarea sin temporizador, es decir, la habilidad de ejecutar procesos sin necesidad de activar el temporizador que se usaba tradicionalmente para implementar la multitarea. Este soporte, sin embargo, tenía algunos problemas: Se podía desactivar el temporizador en todas las CPUs excepto una, que requería tener el temporizador activado continuamente. En esta versión se ha añadido soporte para que, mientras todas las CPUs del sistema no estén haciendo nada, esta CPU pueda desactivar también el temporizador. Artículo LWN recomendado: Is the whole system idle?

· Multitarea en RAID5: Esta versión añade la capacidad de esparcir el trabajo requerido para gestionar stripes del RAID5 de MD en múltiples CPUs, lo que permite aumentar la cantidad de ES/segundo en hardware veloz (SSD)

· Mejora del rendimiento de los bloqueos en huéspedes virtualizados: El sistema operativo que se ejecuta en cada huésped virtualizado también tiene sus propios bloqueos. Algunos bloqueos, como los "spinlocks", causan problemas cuando hay muchos huéspedes ejecutándose, ya que gastan CPU inútilmente mientras siga "girando" el bloqueo. Esta versión reemplaza los spinlocks paravirtualizados actuales como "ticket spinlocks", que tiene mejores características de rendimiento en huéspedes virtualizados. Informe recomendado: Prevent Guests from Spinning Around.

· Nuevo sistema de bloqueo "lockref", mejoras de bloqueo en el VFS: Se incorpora un nuevo sistema de bloqueo, "lockref". La estructura "lockref" es una combinación de bloqueo y contador de referencias que permite accesos optimizados al conteo de referencias. En concreto, garantiza que el contador de referencias se actualiza como si el spinlock estuviera tomado, pero al utilizar accesos atómicos que cubren tanto el contador de referencia como el spinlock, a menudo puede hacerse la actualización sin tener que tomar el spinlock. Esto permite evitar los peores casos de contención de spinlock en sistemas con muchos procesadores. En esta versión ya se utiliza este bloqueo para mejorar la escalabilidad de la resolución intensa de rutas de archivo en esos sistemas. Artículo de LWN recomendado: Introducing lockrefs

· Mejor gestión del estado OOM: El estado "Out-Of-Memory" es aquel en el que el sistema se queda sin memoria tanto RAM como de intercambio, y Linux intenta matar un proceso para liberar memoria. Esta versión incluye cambios importantes en la gestión de este estado, haciéndolo más fiable y enviando más errores de falta de memoria a los programas que requirieron la memoria, en lugar de recurrir a matar procesos con tanta frecuencia. Artículo de LWN recomendado: Reliable out-of-memory handling

· Mejora de la escalabilidad de recursión de directorios en XFS, soporte de espacios de nombre: XFS ha añadido soporte para un tipo de archivo directorio, con el propósito de que readdir pueda devolver a espacio de usuario el tipo de inodo al que apunta la estructura dirent sin tener que leer el inodo del disco. El rendimiento de la recursión en directorios mejora notablemente. Un benchmark consistente en hacer búsquedas paralelas de 50 millones de entradas de directorio en cientos de directorios mejoró de aproximadamente 500 getdents() por segundo y 250.000 búsquedas de inodo por segundo para determinar el tipo de inodo con aproximadamente 17.000 operaciones de ES por segundo; a 3.500 getdents() por segundo a 16.000 operaciones de ES por segundo, sin búsquedas de inodo.

Esta versión también incorpora soporte para espacios de nombre en XFS, y ha reincorporado el soporte de defragmentación en el nuevo formato de archivos con CRCs.


· Mejora del bloqueo en la capa tty: La capa tty ha sido mejorada y en el proceso gran parte del bloque ha sido convertido a bloqueos para-cada-tty, que mejoran el rendimiento en algunos casos.


· Mejoras en el bloqueo IPC: Esta versión incluye mejoras en la contención que se impone al bloqueo de IPC (kern_ipc_perm.lock). Estos cambios mejoran sobre todo las operaciones de memoria compartida, anteriormente ya se habían mejorado los semáforos en 3.10 y colas de mensajes en 3.11. Con estos cambios, un microbenchmark de memoria compartida que se centra en el uso de shmctl haciendo IPC_STAT con 4 hilos millones de veces, reduce el tiempo de ejecución un 50%. Una prueba similar con IPC_SET reduce el tiempo de ejecución de 3 minutos y 35 segundos a 27 segundos.

Y eso es todo. La lista completa de cambios en inglés, aquí.

"De propósito general" es algo más que una definición

La mayoría de sistemas operativos predominantes que utilizamos a diario son considerados "de propósito general", es decir, no están diseñados y optimizados para una tarea específica, sino que intentan abarca un rango muy amplio de funcionalidades, a diferencia de los de propósito específico, diseñados para tareas muy concretas.

El hecho de que un sistema operativo sea "de propósito general" es algo que se suele pasar por alto, pero que a veces tiene un coste, aunque por la regla general es muy positivo. Y no todos entienden o se acuerdan de que pensar en el "propósito general" fuerza a pensar los problemas de una manera diferente: recuerden los flamewars en los que se ha acusado a Linux de centrarse demasiado en servidores y estar condenado por ello a no ser óptimo en el escritorio, por ejemplo.

El caso es que hoy nos encontramos con un ejemplo de libro de las ventajas de un diseño de "propósito general": Acaba de publicarse Android 4.4 "Kitkat". En su esfuerzo por reducir la patética y negada hasta la saciedad brutal fragmentación de Android y por adaptar a relojesotro tipo de formatos con hardware menos potente, Google se ha esforzado por reducir los requisitos de memoria del sistema operativo. Y la lista de técnicas que han usado para lograr reducción de uso de memoria es curiosa:

OEMs building the next generation of Android devices can take advantage of targeted recommendations and options to run Android 4.4 efficiently, even on low-memory devices. Dalvik JIT code cache tuning, kernel samepage merging (KSM), swap to zRAM, and other optimizations help manage memory

"Kernel Samepage Merging (KSM)", es desduplicación de memoria, es decir, si dos páginas de memoria tienen el mismo contenido, el sistema operativo borra una copia y referencia a sus usuarios a la otra. Fue introducido incluido en 2.6.32, hace casi 4 años. Pero lo curioso es que es una técnica típicamente de virtualización que fue desarrollada en Linux por Red Hat. Cuando se tienen en memoria varias VMs virtualizadas de un mismo sistema operativo, la desduplicación puede ahorrar cantidades de memoria considerables.

Lo bueno de que Linux sea un sistema operativo de propósito general es que Android puede usar ahora ese mismo sistema de desduplicación. ¿Quien podría haber predicho hace cuatro años que un sistema pensado para servidores acabaría siendo utilizado en teléfonos móviles de última generación?

La buena estrategia de exigir que todos los drivers sean de código abierto

Desde sus inicios se ha criticado a Linux el hecho de no facilitar la creación de drivers propietarios. No sólo porque la propia licencia hace que cualquier driver propietario sea probablemente ilegal, sino por el hecho de no tener una API/ABI estable. Desde sus inicios hay gente que ha predicho que Linux no conseguiría buena compatibilidad de hardware hasta que abandonara esa senda de despreocupación de aficionados y espíritu hacker y se pusieran a hacer las cosas en serio, con profesionalidad, preocupándose por las peticiones de los fabricantes de hardware.

Sin embargo, tras tantos años sin hacer ni caso a esas exigencias, el soporte de hardware es cada vez mejor y más completo, un curioso hecho fácil de constatar al que que los críticos rara vez prestan atención.

Hasta Nvidia está cediendo últimamente y publicando cada vez más información sobre sus tarjetas para ayudar a los desarrolladores del driver libre Nouveau, a pesar de que es el mejor driver propietario para Linux. Los drivers para tarjetas gráficas de AMD cada vez tienen mejor rendimiento, e Intel sigue invirtiendo tiempo y dinero en los suyos. Mesa va a introducir soporte de OpenGL 3.2 y 3.3 en la próxima versión. Se ha tardado, pero están ahí, y una vez que se ponga al día -ahora mismo Mesa tiene que desarrollarse con rapidez sólo para ir disminuyendo la distancia-, soportar hardware de última generación será más fácil.

La guinda del pastel puede ponerla Steam OS: Al igual que ocurrió con los servidores, una vez que Linux se populariza en un sector, los fabricantes de hardware de ese sector tienen la necesidad de que su hardware funcione sin problemas en Linux.

Al final, tras tantos años, no facilitar la creación de drivers propietarios no sólo no ha causado los problemas que muchos predecían, sino que además ha traído ventajas. La ventaja de la portabilidad, o de que los drivers tengan tiempos de soporte y mantenimiento mucho más largos (mucho hardware antiguo que funcionan sobre Linux sin problemas dejaron de hacerlo hace años en versiones modernas de Windows). La ventaja de que no se eliminen características por capricho de un directivo. Y, sobre todo, la ventaja de que no mantener una ABI interna ha permitido a Linux evolucionar con flexibilidad todos estos años para llegar a todos los rincones donde ahora llega.

Y es que los críticos de la ausencia de una ABI de drivers estable, como por ejemplo, Miguel de Icaza, olvidan que los drivers no son un especie de programa que utiliza el kernel como quien utiliza una librería, sino que son parte misma del kernel; y olvidan que los drivers no deberían ser un asunto de fabricantes de hardware, que por definición sólo piensan en vender hardware nuevo y siempre les pesa gastar dinero en soportar el viejo, sino de programadores, a quienes les pagan por soportarlo lo máximo posible.

Noticias Wayland (II)

El 11 de Agosto hice una lista de noticias recientes relacionadas con Wayland. Con la publicación de Wayland/Weston 1.3 hoy se hace necesaria otra recopilación de noticias nuevas aparecidas desde entonces:

• Wayland/Weston 1.3, por supuesto: Entre otras mejoras, Wayland incorpora soporte para bindings. Según el desarrollador principal, Kristian Høgsberg no hay muchas novedades en Wayland esta vez, algo interpreta como un signo de madurez. Weston, por su lado, añade soporte para funcionar sobre los drivers gráficos de Android. También añade soporte para hacer captura de escritorio y comprimir el resultado a h.264 usando aceleración de hardware; algo que podría utilizarse en el futuro para hacer streaming del escritorio. También se ha mejorado el soporte táctil y la gestión de dispositivos de entrada en general, que permite el funcionamiento correcto de WebKitGTK+ y Clutter-GTK+. Para XWayland, mejor soporte del modo a pantalla completa y soporte para drag-and-drop de X a Wayland.
• WebKitGTK+ 2.2 incorpora soporte nativo de Wayland.
• Hawaii Shell 0.1.92. Se trata de un shell de escritorio basado en Wayland+Qt5, las actualizaciones se tratan mejoras básicas en el shell. También han implementado el shell como un plugin de Weston. Su consumo de memoria es bastante bajo. Podría estar disponible en Fedora 22.
• Tras publicarse SDL 2.0, el port a Wayland podría incluirse oficialmente en SDL 2.1.0/2.0.1.
• Se publicó Gnome 3.10, con soporte experimental de Wayland.
• Se publicó KDE 4.11. El gestor de ventanas, kwin, incluyó soporte experimental de Wayland en el que kwin dibuja a un buffer Wayland y las aplicaciones vía xwayland (el soporte nativo de wayland vendrá en KDE 5, con Qt5)
• Aparecieron en Youtube vídeos de Nemoshell, un gestor de ventanas/compositor Wayland. Aparte de los vídeos no parece saberse más.
• En la GUADEC 2013 hubo una charla sobre Wayland, el vídeo puede verse aquí.
• El progreso de Enlightenment 19 como compositor Wayland sigue avanzando.
• Una propuesta de un shell para ser utilizado en coches.
• Fedora podría considerar usar Wayland por defecto en Fedora 21; aunque es un objetivo algo ambicioso. En Fedora 20, habrá una opción experimental de Gnome+Wayland.
• Google Chrome/ChromeOS ha sido portado a Wayland.
• LibreOffice funcionando en XWayland.
• En la XDC2013, el autor de Wayland y Daniel Stone dieron esta charla.
• Un nuevo driver xf86-video-glamor para que XWayland utilice la librería GLAMOR (es decir, OpenGL).
• Systemd 208 incorpora en logind soporte para facilitar el uso de servidores Wayland como programas ejecutándose en la cuenta del usuario, sin privilegios.
• Nvidia ha publicado una actualización de su driver propietario que incluye soporte de EGL, lo cual facilitará el uso de Wayland/Mir en sus drivers en el futuro.
• Tizen mejora en su "QT Tizen Integration 1.0 Alpha 4" el soporte para Wayland, que es utilizado como servidor gráfico por defecto.

Se ha insistido mucho aquí que el cambio de X.org a Wayland no consiste tanto en que Wayland/Weston evolucionen, sino en que otros proyectos adopten Wayland. Como puede comprobarse, Wayland está en plena efervescencia.

¿Cómo será recordado Steve Ballmer? El fin del "Embrace, extend and extinguish"

El anuncio de salida de Microsoft de Steve Ballmer desató una serie de resúmenes sobre sus años de CEO. Se ha destacado el aumento de recaudación la brutal caja registradora de la compañía, de 20 mil a 70 mil millones anuales, el éxito de la Xbox, la silenciosa y sorprendentemente poco comentada consolidación de sus plataformas para servidores. Pero se han recordado sobre todo sus fallos, sobre todo su incapacidad para anticipar la revolución portáctil.

Y este es un punto en el que no estoy de acuerdo, porque supone olvidar cuál fue el rasgo identitario fundamental de Microsoft en los 90: Embrace, extend and extinguish. El Microsoft pre-Ballmer, además de ser una definición académica de monopolio, era una máquina de desplazar a competidores, cuando no de llevarlos a la bancarrota.

Ganó a Digital Research y DR-DOS, ganó a Apple e IBM(!) la carrera por convertirse en el principal sistema operativo gráfico, ganó la batalla a Novell por las redes, ganó a Borland/Delphi, Wordperfect, Lotus, Netscape; cada una de esas empresas ocupaban nichos que han generado montones de millones de dólares, cuando no plataformas sobre las que han creado industrias. Intentaron parar los pies a Java como lenguaje para aplicaciones de escritorio con extensiones propietarias y con ActiveX en la web. Su desviación de los estándares de internet hizo que, durante años, fuese imposible usar la web a diario sin encontrarse con páginas que sólo eran compatibles con Internet Explorer.

Eran los tiempos en que Bill Gates aun no gastaba sus rentas en ayudar a países pobres, por aquel entonces era profundamente odiado por representar la cara más salvaje y avasalladora del capitalismo. Y no sin razón: recuerden que la publicación de correos de la compañía en un caso anticompetencia revelaron textos suyos tan constructivos como este:

"One thing we have got to change in our strategy—allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows"

O este:

"One thing I find myself wondering about is whether we shouldn't try and make the "ACPI" extensions somehow Windows specific. If seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work. Maybe there is no way Io avoid this problem but it does bother me. Maybe we couid define the APIs so that they work well with NT and not the others even if they are open. Or maybe we could patent something relaled to this"

Las empresas que fueron arrolladas por la apisonadora de Redmond fueron, por lo general, iniciativas de gente que tuvo una idea brillante e intentó comercializarla. Microsoft no se destacó por generar esa clase de ideas, sino por intuir la relevancia de las ideas de otros, copiarlas y ser mejores que el original, ser muy agresivo comercialmente, y vencer a su competidor. Una habilidad que, aunque no tenga tanto aura, tiene mucho mérito. En los cursos que Microsoft impartía a los nuevos trabajadores enseñaban que su táctica a la hora de afrontar a un nuevo competidor empezaba por simplemente anunciar que entraban a competir con ellos, el mero anuncio hacía que el competidor se pusiera nervioso y cometiera errores estratégicos, que Microsoft aprovechaba para entrar a rematar.

Volviendo a Ballmer, decía que no estaba de acuerdo con que se le recuerde por haberse perdido la revolución de los dispositivos portáctiles. Como acabo de recordar, Microsoft por regla bastante general llegó tarde a todo: llegó tarde a los sistemas operativos gráficos, a los procesadores de texto, a Internet, a los navegadores web. Que Microsoft perdiera el tren de los dispositivos portáctiles no es, por tanto, nada nuevo; lo relevante es que, esta vez, ha sido incapaz de identificar la tendencia, crear rápidamente un producto alternativo mejor, y competir agresivamente hasta batir a sus competidores.

También ha sido incapaz de competir -y sorprende que, entre tanta moda portáctil, casi se olvide- con Google. Casi se diría que no les interesa: recuerden que tuvieron, por ejemplo, una web de vídeos análoga a youtube y una red social. En ambos casos se dieron por vencidos y cerraron, una actitud aletargada inimaginable en la antigua Microsoft. Windows Phone surgió mal, tarde, y se desarrolla a velocidad glacial. Internet Explorer tiene un desarrollo lento y está siendo incapaz de frenar su caída. Messenger fue eliminado sin intentar hacer algo decente con él, prefiriendo pagar una millonada por Skype.

En suma, Microsoft se ha convertido en una multinacional aburguesada que es incapaz de seguir el hilo de sus competidores, que en muchos casos directamente desiste de hacerles frente, y si lo intenta es recurriendo a su multimillonaria, pero no infinita, billetera; una compañía que, según sus trabajadores, está plagada de la clase de reuniones inútiles y entorpecimientos burocráticos de los que se burlan las tiras cómicas de Dilbert. Una compañía que cada vez es más un fantasma lejano de la Microsoft agresiva que se comía el mundo. El responsable de ese cambio es Steve Ballmer, y por ello es por lo que debería ser recordado.

Las novedades de Linux 3.11

Ya se ha anunciado la versión 3.11 del kernel Linux. Esta versión incorpora soporte para una nueva bandera O_TMPFILE en open(2) que permite la creación sencilla de archivos temporales seguros, soporte de gestión de energía dinámica para todas las GPUs Radeon desde la r600, soporte preliminar de NFS 4.2 y de etiquetado SELinux en NFS, soporte experimental de clientes del sistema de archivos distribuido Lustre, seguimiento detallado de las páginas a las que escribe un proceso, soporte de huge pages en ARM y soporte de KVM y Xen en ARM64, mejoras de escalabilidad de la cola de mensajes SYSV IPC, polling de tarjetas de red con latencia baja y un cache de swap comprimido. 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.


· Nueva flag O_TMPFILE para open(2) para reducir las vulnerabilidades de archivos temporales

O_TMPFILE es una flag nueva para open(2)/openat(2) que facilita la creación de archivos temporales seguros. Los archivos que sean abiertos con O_TMPFILE son creados, pero no son visibles en el sistema de archivos. Y tan pronto como se cierre el descriptor de archivo, es eliminado, al igual que ocurriría con un archivo que hubieras abierto y desenlazado.

Hay dos usos para este tipo de archivos. El primero es la creación de archivos temporales sin condiciones de carrera (se elimina cuando se cierra; nunca es accesible desde ningún directorio, no hay necesidad de crearlos con un nombre de archivo único - básicamente, un tmpfile(3) bien hecho). Otro uso es crear un archivo inicialmente imposible de acceder, escribir lo que quieras en él, hacer fchmod()/fchown()/fsetxattr() como desees, y entonces enlazarlo al sistema de archivos atómicamente, ya preparado.

 · Soporte experimental de gestión de energía dinámica en tarjetas gráficas AMD Radeon

Los drivers para tarjetas gráficas AMD han incorporado soporte para la gestión dinámica de energía para todas sus GPUs, de la r600 hasta el día de hoy. Este código es experimental, y está desactivado por el momento. Para activarlo es necesario pasar el parámetro radeon.dpm=1 al módulo.

· Soporte experimental como cliente del sistema de archivos Lustre

Lustre es un sistema de archivos distribuido que soporta múltiples clústers de computación con cientos de miles de nodos clientes, decenas de Petabytes de almacenamiento en cientos de servidores, y más de un Terabyte por segundo de E/S agregada. Es el sistema de archivos para clusters más popular en la computación de alto rendimiento: seis de los 10 mejores y 60 de los 100 mejores supercomputadores del mundo usan Lustre.

Esta versión añade soporte como cliente, pero es experimental, el código no está muy limpio y necesita estar un tiempo en drivers/staging. Ver drivers/staging/lustre/TODO para más detalles. Para más detalles sobre Lustre, visitar http://lustre.org.

· Soporte preliminar de NFS 4.2 y SELinux Labeled NFS

Esta versión incorpora soporte preliminar para clientes de NFS 4.2, una nueva versión del estándar NFS que está siendo desarrollada. Para más detalles sobre qué novedades incorpora este nuevo estándar, vea este post.

Esta versión también ha incorporado soporte para Labeled NFS, que añade soporte completo de SELinux a NFS. Hasta ahora, los montajes NFS eran tratados como una única etiqueta de SELinux, típicamente nfs_t; o como mucho permitían al administrador cambiar la etiqueta por defecto con la opción --context de mount. Con Labeled NFS, es posible tener muchas etiquetas diferentes. Esto es útil para asegurar las aplicaciones de virtualización con una etiqueta en la imagen virtualizada. También es útil para exportar directorios home desde NFS, y así poder confinar aplicaciones para que sólo puedan escribir en ciertos lugares, en lugar de tener permisos para escribir en cualquier directorio.

· Seguimiento detallado de qué páginas escribe una aplicación


Esta versión incorpora un mecanismo que ayuda a seguir qué páginas escribe una aplicación. Esta característica es utilizada principalmente por el proyecto checkpoint-restore, pero puede ser usado para conseguir mejores estadísticas y construir mejores aplicaciones de profiling. Para más detalles, ver Documentation/vm/soft-dirty.txt

· Soporte de huge pages en ARM, soporte de KVM y Xen en ARM64

La arquitectura ARM ha incorporado soporte de huge pages tanto para las CPUs de 32 bits como para las de 64 bits. Esta implementación permite el mapeado de secciones de 2MB; la configuración de páginas de 64K no está soportada. También añade soporte para huge pages transparentes; cuando estén activadas, el kernel intentará mapear páginas anónimas en secciones de 2MB cuando sea posible.

Esta versión también incorpora soporte de virtualización KVM y Xen para la arquitectura ARM64.

· Mejoras de escalabilidad de la cola de mensajes SYSV IPC

Esta mejora continúa el trabajo que comenzó con las mejoras de escalabilidad en los semáforos SYSV que fue incluído en Linux 3.10.

Como los semáforos, la lista de mensajes también abusa del bloqueo utilizado por el código SYSV IPC, sosteniéndolo para operaciones como comprobaciones de seguridad y de permisos, lo que daña la escalabilidad y el rendimiento. En esta versión, se han utilizado una mezcla de algoritmos sin bloqueos, secciones críticas acortadas, estadísticas individuales para cada semáforo y ajustes del uso del caché de CPU para hacer la lista de mensajes más veloz y escalable.

· Polling de red con baja latencia

Los drivers de Linux modernos no notifican al sistema de la llegada de nuevos paquetes con interrupciones, porque con los actuales requisitos de ancho de banda se generarían cientos de miles de interrupciones por segundo, que no pueden gestionarse sin degradación del rendimiento. Por esa razón se utiliza un sondeo periódico a la tarjeta (polling), llamado NAPI en Linux. Sin embargo, el intervalo del sondeo añade latencia. Esta versión permite a las aplicaciones requerir en cada socket un intervalo de sondeo menor.

· Zswap: un caché de swap comprimido

Citando de este artículo de LWN recomendado:

"Zswap es un caché para páginas de swap. Toma las páginas que están en proceso de ser enviadas al espacio de intercambio e intenta comprimirlas en un espacio de memoria RAM. Si este proceso tiene éxito, se retrasa el proceso de escritura al espacio de intercambio y, en muchos casos, se evita completamente. Las consecuencias son una reducción de E/S y ganancias de rendimiento en los sistemas que utilizan a menudo el espacio de intercambio". Para mas detalles y mediciones, ver el artículo de LWN recomendado. (Nota: esto viene a ser el equivalente Linux de la compresión de memoria de OS X 10.9)

Y eso es todo. La lista completa de cambios en inglés, aquí.

El fallido crowdfunding del Ubuntu Edge

Ya ha finalizado el plazo del crowdfunding de Ubuntu Edge , y el resultado, como ya sabemos todos, ha sido un fracaso, tan sólo se han recaudado 12 de los 32 millones que se fijaron como objetivo. Por mucho que Canonical intente relativizarlo con el record de recaudación, se trataba de reunir 32 millones o nada, y en nada se ha quedado.Y la verdad, no es de extrañar. Como ya ha contado mucha gente en otros sitios, esta colecta no ha estado terriblemente bien gestionada.

En los primeros días se evidenció que las opciones disponibles eran confusas y no dejaban claro de qué iba el proyecto. Se podían donar pequeñas cantidades (20$ y 50$) a cambio de regalos simbólicos como una camiseta y, al mismo tiempo, se podía pagar más de $600 por un teléfono. Pero la compra de un teléfono tampoco era exactamente una "compra", a medida que se vendían más teléfonos subía progresivamente el precio. El rango de extremos de precios iba desde los primeros 5.000 teléfonos a 600$, a los $830 que habría que pagar una vez se hubieran vendido 33.500 teléfonos. Una diferencia de nada menos que 230$ dólares.

Al poco tiempo se dieron cuenta de lo enormemente absurdo de este esquema de precios, y lo sustituyeron por un único precio de $695 sin límite, pero para entonces el desconcierto ya había calado. ¿De verdad esperaban que la gente donara 230$ dólares extra, en lugar de simplemente esperar a comprarlo más barato de segunda mano en Ebay? Y todo eso para un teléfono que estaba por construir y que, en todo caso, no se empezarían a enviar a los compradores hasta Mayo del 2014, suponiendo que se cumplan los plazos.

Otro problema fue el teléfono en si mismo. Con 128 GB de almacenamiento y 4GB de RAM, estaba claro que se apuntaba hacia un teléfono de altas prestaciones (en parte, se justificaba con que era necesario para poder ejecutar el Ubuntu desktop tradicional). Pero a medida que el mercado de smartphones de última generación se generaliza como nuevo normal, aumenta el interés por los teléfonos simplemente baratos, como bien está aprendiendo Apple. Para vender un teléfono de altas prestaciones por un precio elevado hace falta algo más que un toolkit gráfico e interfaz de usuario alternativas.

A Ubuntu Edge le faltaba un modelo opcional con peores prestaciones y mas barato. Preguntado por ello, Canonical respondió "we firmly believe that to offer a fully converged experience you need 128GB. Cutting down the specs goes against the ethos of the campaign". El énfasis en "you need" es mío: En su actual fase adolescente de querer imitar a Steve Jobs (que esperamos pase pronto), Canonical pretende tener "visiones" de que la gente "necesita" 128 GB. Lo cual es una falacia, empezando porque aunque se justifiquen los 128 GB por el modo de Ubuntu Desktop (conectar al móvil un monitor, teclado y ratón y usarlo como PC con el Ubuntu de escritorio tradicional), hay mucha gente que no va a estar interesada.

Pero el punto más flojo de todo este invento es que Canonical pidiera 32$ millones a la gente y vendiera teléfonos en una página de colectas, en lugar de simplemente poner ellos los 32$ millones; o buscar inversores interesados y vender los teléfonos en una tienda online propia normalita, directamente. Como mucha gente señaló, resultaba algo insultante que una empresa privada como Canonical pidiera que el público financie con donaciones sus proyectos de I+D. Mark Shuttleworth tuvo en su día más de 500$ millones; se hace difícil de creer que se haya gastado todo, y si él mismo no está dispuesto a arriesgar en un proyecto que, de ser bueno, debería dar beneficios, ¿por qué debería hacerlo yo?

Al final, lo único positivo de todo esto es la publicidad conseguida. Y, de hecho, observando la reacción de Canonical (que da mucha importancia a la atención de la prensa en sus comunicados), es muy posible que todo este invento tuviese como único objetivo el generar atención mediática para que algún gran directivo de una empresa fabricante de teléfonos o de telecomunicaciones considere Ubuntu Mobile como opción. Desde ese punto de vista puede decirse que Ubuntu Edge ha sido un gran éxito, pero para lograrlo habrían necesitado mentir a la gente, ilusionarlos y hacerles considerar el disponer de una generosa parte de sus ingresos para un proyecto que era mentira desde un principio.

Las noticias sobre Wayland del último mes

En un post anterior, se defendía el argumento de que Wayland está bastante más avanzado de lo que la gente cree debido a la amplia aceptación del proyecto en la comunidad. Desde que se escribió ese post -más o menos un mes- ha habido unas cuantas noticias que han confirmado esa teoría, y me parece que son dignos de mención.

• Jolla, la empresa finlandesa formada por ex trabajadores de Nokia que quiere hacer teléfonos basados en MeeGo, anunció que sus teléfonos usarán Wayland. Esto se confirmó hace unos días, cuando una actualización del SDK empezó a soportar Wayland.
• XMBC ha implementado soporte nativo de Wayland, en lugar de recurrir al port de SDL a Wayland.
• Kubuntu ha detallado sus planes a largo plazo para pasar a usar Wayland.
• Hay pequeños programas para X11 que tienen requerimientos muy simples, limitados a "dibujar rectángulos" y "escribir texto". Un tipo ha intentado portar dos de esos programas a Wayland, y como usar los grandes toolkits le parecía demasiado para tan poca cosa, ha escrito una pequeña librería para hacer esas funciones en Wayland.
• Dos juegos, Neverball y Neverputt (que comparte motor gráfico con el anterior), soportan Wayland con la ayuda del port a Wayland de SDL.
• Gente de Gnome ha implementado un "wrapper del sistema de ventanas" que soporta varios backends, pero el primero implementado ha sido Wayland.
• En la última GUADEC, la gente de Gnome pasó mucho tiempo hablando de Wayland. Entre varios detalles técnicos, destaca que, aunque incompleta, habrá una versión de prueba de Gnome Shell portado a Wayland en 3.10 (previsto para finales de Septiembre).
• Se ha creado en el wiki de Fedora una propuesta para adoptar Wayland.
• Hay soporte experimental para PRIME en Wayland.
• Mate, el fork de Gnome 2, planea usar Wayland.
• Se ha creado un shell para Weston basado en QT5 llamado Orbital

 Como argumentaba en el post citado al principio, se puede observar que la mayoría de estas noticias no tienen que ver con modificaciones en Wayland/Weston mismo, sino en que software variado relacionado con gráficos está adoptando Wayland en sus repositorios e infraestructuras.

El servidor gráfico ya no importa

Hay un punto de vista sobre el debate Wayland vs Mir que hasta cierto punto contradice el artículo anterior, pero que me gustaría contar porque es igualmente válido (y también por la manía de intentar buscarle tres pies al gato). Ese punto de vista consiste en que, en realidad, tanto Wayland como Mir son relativamente irrelevantes, y no importa quien gane o quien pierda.

Se fundamenta en que la característica principal de estos servidores gráficos de nueva generación es que, en realidad, no hacen prácticamente nada comparado con lo que solían hacer sus antecesores. En los 80 y 90, el servidor X dibujaba los caracteres de las fuentes en la pantalla directamente. En el 2000, el servidor X ofrecía una serie de operaciones de renderizado elementales, y las aplicaciones las utilizaban para dibujar ellas mismas las fuentes. Con Wayland y Mir, el servidor gráfico simplemente ofrece un buffer de memoria, las aplicaciones dibujan en él lo que les de la gana y notifican al servidor cuando terminan. No es muy complicado, por eso es que los toolkits y las aplicaciones han sido portados con relativa facilidad.

Eso por el lado de los clientes. Por el lado de la interacción con las tarjetas gráficas, hemos pasado de un servidor X que ejecutaba drivers 2D, configuraba el modo del monitor, leía el bus PCI directamente e incluso tenía un emulador de BIOS, todo ello en espacio de usuario; a un mundo donde los drivers están en el kernel y se ocupan de todas esas cosas por si mismos. La parte compleja de la aceleración 3D se abstrae en Mesa.

En otras palabras, se han adelgazado considerablemente los servidores gráficos, tanto por el lado de las aplicaciones clientes como por el lado de la interacción con el hardware gráfico. Wayland y Mir son simple pegamento de ambas partes que se ocupa de coordinar el acceso de las aplicaciones a un recurso común (la imagen final que se ve en pantalla). De hecho, una de las cosas más complejas para Wayland y Mir van a ser cosas no directamente relacionadas con gráficos, como la estandarización de la coordinación entre aplicaciones (ej: que la barra de tareas sepa qué ventanas están en un escritorio virtual y cuáles en otro).

La mejor prueba de que los servidores gráficos se han vuelto irrelevantes es que estemos teniendo la discusión Wayland vs Mir: es relativamente sencillo crear un servidor gráfico alternativo, ya que casi todas las piezas del puzzle ya están ahí, sólo hay que unirlas. De hecho, tanto Wayland como Mir no son demasiado grandes. Es decir, no sería un terremoto que alguien apareciera con un tercer servidor gráfico, ya que el coste de oportunidad es mucho menor. Y lo bueno de todo esto es que, como la mayor parte del stack gráfico está fuera del servidor, la mayor parte del trabajo es común y beneficia a ambos servidores.

¿Por qué Canonical avanza tan rápido con Mir? ¿Qué hay de Wayland?

Desde que Canonical anunció que usará Mir por defecto en Ubuntu 13.10, he leído varios comentarios en la tubosféra de gente que se ha sorprendido de que Mir haya avanzado tanto e incluso titulares que hablan de sustitución de X.Org, sin olvidar el qué-hay-de-wayland. La mayoría de personas no conoce gran cosa de cómo funcionan los gráficos en Linux (no les culpo), y los anuncios de Canonical (especialmente los peculiares posts de Mark Shuttleworth) no ayudan demasiado a comprenderlo.

XMir en Ubuntu 13.10

Resumiendo, el servidor gráfico que Canonical va a usar en 13.10 es XMir, lo cual quiere decir que el verdadero servidor gráfico es X.org. Mir se utilizará para dibujar la imagen en la pantalla, funcionando en la práctica como un driver de X.org, que dibujará lo que le piden vía EGL (en el hardware que lo soporte, en el que no lo soporte no se usará XMir). Lo de que el servidor gráfico seguirá siendo en realidad X.org no es menosprecio: será X.org, y no Mir, quien gestione las ventanas, quien comunique a las aplicaciones los eventos de fuentes de entrada, quien las avise de la necesidad de redibujarse, etc.

De ahí que decir que Ubuntu 13.10 usará Mir "en lugar de X" sea una estupidez. X.org no sólo va a estar presente, sino que va a seguir en el centro, e imponiendo sus limitaciones habituales.

Dada la arquitectura e historial de X.org, es fácil prever que haya benchmarks en los que XMir sea más rápido que los drivers "2D" de X.org, pero también otros donde no lo sea (porque para las operaciones "2D" que usan los toolkits de escritorio tradicionales, la aceleración "3D" vía Mesa a veces es más lenta que la aceleración "2D" del driver, o que hacerlo en la CPU). Hace años que existen intentos similares de utilizar aceleración GL en X.org: Xgl, glucose, o más recientemente Glamor. En Phoronix (y si, ya se que sus benchmarks no son los mejores del mundo) han concluído que XMir es más lento que X.org. Y el programador de kwin ya ha avisado de que Xmir causa pequeños defectos en kwin en ocasiones.

Una de cal y otra de arena, pero a Canonical no le preocupa demasiado porque quiere avanzar rápido con Mir para la siguiente versión, 14.04, que es LTS. Me temo que los usuarios de 13.10 van a hacer un poco de conejillos de indias, aunque lo más probable es que la mayoría no tenga problemas o no note diferencias de velocidad ni en un sentido ni en otro, más allá del placebo.

Wayland

Respecto a Wayland, hay gente que a la luz de esta noticia se congratula que Ubuntu se libre tan rápido de X.org (falso, como ya hemos visto), y se queja de que, a pesar de todo este tiempo de ventaja, Wayland sigue sin ver la luz y de que se esté desarrollando a velocidad glacial. Afirmar tal cosa es no comprender lo que es Wayland, lo que pretende, y la diferencia que lo separa de Mir.

Wayland hace tiempo que está "preparado". Por ejemplo, el equivalente a XMir que Ubuntu usará en 13.10, XWayland, existe hace tiempo y se puede usar. Respecto al reemplazo completo de X.org, si esperan a que Wayland "progrese" y pueda usarse como servidor gráfico, pueden esperar sentados, porque eso no va a ocurrir. Ni tan siquiera Weston, que es el servidor gráfico de ejemplo de Wayland, va a mejorar en el sentido de llegar a ser usado como reemplazo de X.org, ya que, como digo, es tan sólo de ejemplo. No veremos jamás una versión de Wayland/Weston que las distros adopten como reemplazo de X.org, sino una versión de GNOME o KDE en la que sus gestores de ventanas empiecen a utilizar Wayland. La próxima versión de GNOME ya añade soporte de Wayland en gnome-shell, kwin también está en ello.

Y ahí, diminuta pero presente e importante, está la diferencia fundamental con Mir. Como aspirante a reemplazar X.org, Wayland es algo más que la creación de un servidor gráfico alternativo. En realidad, es un meta-proyecto colaborativo que involucra a toda la comunidad gráfica libre para coordinarse y establecer estándares y mejorar el protocolo a la vez que se porta software a la API de Wayland. Aunque XWayland exista y esté soportado, no es el centro de atención; para un proyecto que aspira a reemplazar X.org, limitarse a XWayland no es atractivo, su objetivo es proporcionar un escritorio Wayland puro. Y esta exaltación comunitaria no es un capricho, el mundo gráfico es muy extenso y complejo y para hacer las cosas bien es imprescindible escuchar a todos (personalmente creo que el mayor fallo de Mir es el hecho de ser una solución autista, diseñada por y para satisfacer los caprichos de un solo software, Unity).

La manera correcta de medir el progreso de Wayland, por tanto, no es la evolución de Wayland, que por mucho que evolucione no va a sustituir a X.org por si mismo, sino 1) la aparición de servidores gráficos / gestores de ventana que implementen la API de Wayland (y hay unos cuantos en camino, incluyendo algunos muy psicodélicos) 2) la migración a APIs Wayland de aplicaciones con "propósito gráfico especial" (que no se porten automáticamente con el port de un toolkit: ej, reproductores de vídeo).

Desde esta perspectiva las cosas son bastante diferentes. GTK y QT tienen soporte de Wayland, y de Mir también gracias a parches de Canonical, y bien es cierto que con eso se soportan casi todas las aplicaciones. Pero Wayland, además también está soportado en Clutter, en EFL (Enlightenment), en SDL, en mplayer, en XBMC, en Chromium, en WebkitGTK, en bindings para Java. En la próxima versión, Wayland incluirá en el protocolo soporte de gestión de color, soporte de sub-superficies (útil para implementar plugins dentro del navegador como dios manda,), pantallas de alta resolución, soporte de "multi-asiento". Algunas de esas cosas son mejoras del protocolo, otras características de Weston, algunas son ambas cosas. Pero todas ellas están a un nivel completamente diferente de XMir, o XWayland: se trata de reemplazar a X.org todo lo que se pueda, no de satisfacer una visión particular con un entorno de escritorio.

Concurso de aplicaciones para Tizen

El otro decía que Tizen es una de las pruebas de que los fabricantes quieren intentar fabricarse alternativas a Android a largo plazo, de no ser así nadie se gastaría un sólo dólar en mantenerlo vivo. Como complemento, hoy se ha sabido que la Linux Foundation ha anunciado el concurso Tizen App Challenge con el que premiarán a las mejores aplicaciones. Total de fondos del concurso: 4 milloncejos de nada. Además, parece que están moviéndose por conferencias e incluso escribiendo libros. Si uno echa un ojo a la documentación parece que el proyecto ha montado incluso un entorno nativo propio bastante completo, que curiosamente se parece mucho al de Bada, incluso el navegador web de la documentación es el mismo. Lo dicho, mucho dinero.

Canonical encuentra su oportunidad

El intento de Mark Shuttleworth de crear su propio campo de distorsión de la realidad Jobsiano tiene sus consecuencias negativas, como por ejemplo, Mir. Pero también tiene su lado positivo; este blog ha aplaudido los intentos de Canonical de innovar de verdad, como el HUD o Ubuntu TV:

"Incluso si fracasa estrepitosamente y Ubuntu TV desaparece, el mero hecho de haber intentado anticiparse marca una diferencia fundamental con la que ha sido la tradición linuxera en la informática de consumo, que consistía en llegar mal y tarde a las novedades tecnológicas, y lloriquear porque las multinacionales privativas acaparaban todo"

El mayor esfuerzo de Canonical en los últimos tiempos se centra en Ubuntu Phone. Shuttleworth no se resigna a usar Ubuntu en el PC y la TV y Android en su casa, quiere un entorno digital integrado, y hace bien. Sin embargo, durante un tiempo parecía que el destino de Ubuntu Phone iba a ser el mismo de Ubuntu TV: muchas presentaciones, vídeos y enlaces en la página web para fabricantes de hardware interesados, pero poco interés de dichos fabricantes en la práctica.

Todo este tiempo me ha intrigado esta falta de interés en Ubuntu Phone. Es falso que en materia de sistemas operativos portáctiles está todo el pescado vendido, puede estarlo para los grandes jugadores, pero hay sitio de sobra para minorías: los smartphones no han superado las ventas de teléfonos móviles "tradicionales" hasta prácticamente ahora, estamos aun en los inicios del sector. Recuerden que en los 90 nacieron cosas como BeOS, a pesar de que las dificultades para ser una alternativa en aquel entonces eran mucho mayores que las de hoy.

Además, es bien sabido que hay fabricantes de portáctiles que, conscientes que el hardware hoy en día es el mismo para todos y que lo que diferencia a una plataforma es el software, andan buscando disimuladamente una plataforma que les permita librarse de las garras de Google y de la competencia de los grandes jugadores de Android (o la amenaza de competencia de los pequeños, respectivamente). No es casualidad que tanto fabricantes de móviles como fabricantes de componentes muestren interés por Firefox OS, por ejemplo. O que Tizen, a pesar de su fracaso e irrelevancia, siga recibiendo financiación de alguien y no haya desaparecido.

De ahí que durante mucho tiempo me hiciera la pregunta: ¿Por qué ningún fabricante de teléfonos hace la prueba con Ubuntu Phone? Es más, puestos a intentar montar una alternativa seria, ¿por qué nadie intenta comprar Canonical?

Al final, lo inevitable tenía que suceder, y hace unas semanas Ubuntu anunció un Ubuntu Carrier Advisory Group con varias operadoras interesadas en probar suerte con Ubuntu Phone. Si, seguramente se trata de esas multinacionales de telecomunicaciones fustradas por no poder controlar ni los teléfonos de sus clientes ni los sitios web que visitan, pero al menos Canonical tiene una buena oportunidad de construir una alternativa, y de poder introducir libertad de elección y software libre en un mundillo que lo necesita. A mi, por ejemplo, me da la oportunidad de instalar Ubuntu Phone en el Nexus4, en lugar de limitarme a meras personalizaciones de Android. Ya es hora de que los portáctiles empiecen a plataformizarse, como hicieron los PCs.

Las novedades de Linux 3.10

Ya se ha anunciado la versión 3.10 del kernel Linux. Esta versión incluye soporte para bcache, que permite usar discos SSDs como cache de discos duros tradicionales; una mejora del formato de Btrfs que reduce el tamaño del árbol dedicado a mantener la información sobre extents un 30-35%; soporte para checksums de metadatos en XFS; multitarea sin temporizador; mejoras de escalabilidad y rendimiento en SySV IPC y los sistemas de bloqueos rwsem y mutex; soporte del sistema de virtualización KVM en la arquitectura MIPS, soporte de la arquitectura ARM big.LITTLE que mezcla CPUs de diferentes tipos; y snapshots de trazas en la funcionalidad de trazado. 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.  

 · Multitarea sin temporizador: En la prehistoria de la computación, los ordenadores sólo podían tener una tarea ejecutándose, para iniciar otra había que esperar a que terminase la primera. Pero la gente quería poder arrancar varias tareas sin esperar a que terminase la primera, e incluso cambiar entre tareas, y así fue como nació la multitarea. Al principio la multitarea fue "colaborativa", un proceso se ejecutaba hasta que decidía, voluntariamente, dar paso a otras tareas. Pero era posible implementar la multitarea mejor: el hardware podía incluir un temporizador que se despertase a intervalos regulares; este temporizador podría parar cualquier tarea y ejecutar una rutina del sistema operativo que decidiera qué tarea debía ejecutarse a continuación. Esto se llama multitarea apropiativa, y es lo que hacen los sistemas operativos modernos.

Pero la multitarea apropiativa tiene algunos efectos secundarios en el hardware moderno. Las CPUs de portátiles y teléfonos requieren inactividad para entrar en modos de consumo reducido. Como la multitarea apropiativa activa el temporizador a menudo -1000 veces por segundo en Linux normalmente-, la CPU no podía entrar en esos modos de consumo reducido tanto como quisiera. En 2.6.21, publicado en Abril de 2007, Linux resolvió este problema: el temporizador se activaría 1000 veces por segundo cuando el sistema estuviese ejecutando tareas, pero lo pararía cuando el sistema no estuviese haciendo nada. Pero esto no es suficiente. Hay actividades, como el cálculo científico intensivo, o los usuarios de los parches de tiempo real, cuya latencia y rendimiento sufre daños por el hecho de tener que ser pausados 1000 veces por segundo.

Esta versión de Linux añade soporte para no activar el temporizador incluso cuando se están ejecutando tareas. Con algunas notas: en esta versión aun se sigue activando el temporizador una vez por segundo; el modo sin temporizador sólo se activa cuando hay una sola tarea, cuando hay varias se vuelve al modo normal; y se debe mantener una CPU funcionando normalmente con temporizador para que el resto pueda funcionar sin temporizadores. Para más detalles, este artículo de LWN y la documentación.

 · Bcache, un cache para acelerar el rendimiento utilizando discos SSD como cache: Desde que los dispositivos SSD se volvieron populares, mucha gente los ha utilizado como caché para los discos mecánicos tradicionales. Bcache es una implementación de esta funcionalidad, permitiendo usar SSDs como caché de otros dispositivos de bloque. Para más detalles ver la documentación, visitar el wiki o leer este artículo de LWN.

 · Btrfs: árbol de extents más pequeño y eficiente: Btrfs ha incorporado a su formato de disco un nuevo tipo de clave para la gestión de extents  que usa el espacio más eficientemente, reduciendo el tamaño de las referencias de extents de 51 a 33 bytes. En la práctica, esto implica una reducción del tamaño del b-tree de extents en un 30-35%, lo cual significa menos operaciones de copy-on-write, más referencias de extents en memoria y mayor eficiencia en las operaciones de metadatos.

Este cambio de formato no es automático, debe ser activado en tiempo de mkfs

o con btrfstune -x.

 · Checksums de metadatos en XFS: En esta versión, XFS tiene una implementación experimental de checksums CRC32c de metadatos. Estos checksums son parte de un proyecto más ambicioso que pretende implementar lo que los desarrolladores de XFS llaman "metadatos auto-descriptivos", que tiene como objeto resolver el problema de la escalabilidad de la verificación del sistema de archivos (fsck necesita demasiado tiempo para verificar sistemas de archivos de varios petabytes). Esto requiere un cambio de formato que añadirá a cada objeto de metadatos de XFS cierta información que permitirá determinar si el metadato está intacto y puede ser ignorado para propósitos de análisis forense.

Esta característica es experimental y requiere el uso de una versión experimental de xfsprogs. Para más información, puedes leer la documentación sobre metadatos auto-descriptivos.

 · Mejoras de escalabilidad de SysV IPC: La escalabilidad de los semáforos IPC de Linux era lamentable. En esta versión se han añadido varias mejoras de escalabilidad al código, como consecuencia algunos microbenchmarks muestran mejoras mayores del 10x en algunos casos.

 · Mejoras de escalabilidad del sistema de bloqueo rwsem: rwsem es un sistema de bloqueo utilizado en muchas partes del kernel que tenía problemas de escalabilidad por una serialización FIFO estricta de los usuarios del bloqueo. En Linux 3.9, se añadió una mejora llamada "robo oportunista del bloqueo", pero sólo en la ruta de código lenta. En esta versión se ha añadido un cambio similar en la ruta de código rápida, mejorando el rendimiento de pgbench con dos digitos en algunos casos.

 · Mejoras de escalabilidad del sistema de bloqueo mutex: El sistema de bloqueo mutex, utilizado ampliamente en el kernel, ha mejorado su rendimiento gracias al menor uso de operaciones atómicas y algunos cambios en el encolamiento que reducen la contención en líneas de caché de la CPU.

 · Optimización de TCP: Tail Loss probe: Esta versión añade el algoritmo TCP Tail loss probe. Su objetivo es reducir la latencia de transacciones cortas. Lo logra convirtiendo timeouts de retransmisión (RTOs) que ocurren al final de una transacción en una recuperación rápida. Más detalles sobre el algoritmo aquí.

 · Soporte de la arquitectura ARM big.LITTE: La arquitectura big.LITTLE es una solución SMP que, en lugar de añadir varios procesadores similares, avanza hacia un nuevo concepto uniendo dos sistemas SMP: uno compuesto de procesadores grandes y rápidos y otro de procesadores pequeños y energéticamente eficientes. Artículo LWN recomendado.

 · Soporte de KVM para MIPS: Otra arquitectura Linux ha añadido soporte para el sistema de virtualización KVM. En este caso se trata de MIPS. Se soportan los chips a partir del MIPS32R2.

 · tracing: snapshots de trazas, trazas de pila: El sistema de trazado/tracing ha incorporado la capacidad de tener varios buffers de traceo, lo cual permite crear snapshots del buffer de trazado principal. Estos snapshots pueden ser activados manualmente o con sondas en funciones. Es también posible obtener un volcado de pila cuando se llame a una determinada función.

Y eso es todo. La lista completa de cambios en inglés, aquí.

Red Hat piensa que XFS es mejor sistema de archivos que Ext4

Hace cosa de un año escribí una entrada sobre el renacer de XFS. Hace unos días se supo que Red Hat no sólo va a soportar XFS en RHEL 7, sino que planea usarlo como sistema de archivos por defecto.

Retomando la cuestión, si dejamos a un lado los de última generación (ZFS/Btrfs), XFS es el mejor sistema de archivos. La razón por la que la familia Ext ha tenido mayor protagonismo en Linux es que, como se ha recalcado aquí, los sistemas de archivo son como los navegadores web: la calidad de la implementación importa mucho más que el formato o estándar a implementar. Hasta el punto de que un sistema de archivos obsoleto, como Ext4, es uno de los mejores por tener una buena implementación, mientras que Reiserfs v3 tienen un formato mejor, pero una implementación desfasada.

XFS tiene un buen diseño, y, en parte, una buena implementación. Su problema fue que al pasar de Irix a Linux, la implementación no encajó demasiado bien. Tardaron años en adaptarlo. Pero ese inconveniente ya está superado, se ha solucionado la lentitud del journaling con archivos pequeños, y por otra parte Ext4 tiene defectos de diseño que cada vez cuesta más superar, y que ni tan siquiera una buena implementación puede evitar. Ext4 ya no tiene la ventaja y no hay razones para no usar XFS.

Por otro lado tenemos a Btrfs. Es el futuro a largo plazo, pero recuerden que, en realidad, las principales novedades de estos sistemas de archivos de próxima generación no son mejoras para el rendimiento y la escalabilidad de operaciones cotidianas, sino mejoras en la gestión de almacenamiento: expansión a múltiples discos, snapshots, subvolumes, checksums (las mejoras puntuales del modelo copy-on-write y el RAID integrado son más bien una consecuencia de lo anterior). En materia de rendimiento y escalabilidad pura y dura, ni ZFS ni Btrfs dan miedo a XFS; de hecho a menudo tiene algunas ventajas sobre ellos. Hacer copias redundantes de los metadatos, por ejemplo, da seguridad, pero escribir al disco dos veces los mismos datos siempre va a ser más lento que no hacerlo, y para quienes llevan la capacidad de los discos al límite, eso importa.

De ahí que el panorama linuxero de sistemas de archivos esté evolucionando hacia una dualidad: XFS para servidores "serios" que necesitan el máximo rendimiento (bases de datos, virtualización, etc), Btrfs para lo demás, Ext4 como opción estable y segura. Y el peso de Red Hat tras esta decisión va a consolidar definitivamente este panorama.

Curiosidades de OS X 10.9 "Mavericks"

No es ningún secreto que desde que Apple se centró en los dispositivos portáctiles, lo relacionado con el escritorio ha pasado a ser secundario. OS X ha pasado de ser el centro de atención de todo el desarrollo a ser un segundón que de vez en cuando recibe actualizaciones desarrolladas en iOS. Lo cual tiene sentido, al fin y al cabo todos sabemos con qué productos gana Apple casi todo su dinero.

Sin embargo, pasar a ser el sistema operativo de "camiones" post-pc tiene sus ventajas. Por ejemplo, pueden permitirse tratar a OS X como un sistema operativo más orientado hacia sectores profesionales, "camioneros informáticos". Aunque eso no libra a nadie de los feroces ataques del infantil departamento de marketing de Apple, si que añade cosas interesantes, como una página dedicada a "tecnologías avanzadas" y un enlace a un PDF titulado "OS X Mavericks Core Technologies overview".


"Timer coalescing"

La primera gran novedad que se anuncia es algo llamado "Timer coalescing", fusión de temporizadores (por cierto, la palabra coalescencia existe en español). Esta técnica tiene como objetivo mantener la CPU ociosa y que se mantenga en modos de ahorro de energía el máximo tiempo posible. Para ello, se minimiza el número de activaciones de temporizadores activados por las aplicaciones en el sistema. El modo de minimizarlo es agrupar los temporizadores no-críticos más cercanos en el tiempo. Por ejemplo, si hay 10 temporizadores fijados para activarse en el plazo de un mismo segundo, en lugar de sacar la CPU 10 veces del modo ocioso, se activan todos de una sola vez. Linux tiene algo similar desde hace más de 6 años.



Compresión de memoria

La segunda, la compresión de la memoria RAM de las aplicaciones menos utilizadas en caso de falta de memoria. Esta es una buena idea, en Linux hay planes para la incorporación de algo similar, aunque lo de Apple parece más completo y añade, de paso y prácticamente "gratis", compresión de swap (si tienes la memoria de un programa comprimida, ¿por qué no almacenarla en swap directamente en ese formato?). Ahora bien, Apple afirma varias veces que este sistema puede reducir el tamaño de una aplicación en memoria hasta en un 50%, lo cual es una falacia descomunal. El ratio de compresión siempre depende del tipo de datos que se quieran comprimir.

Me ha llamado la atención que en las imágenes de marketing de Apple que muestran las mejoras de rendimiento de esta compresión se vea, además de una barra de "respuesta bajo carga", otra que dice "Wake from Standby". Sorprende, porque la compresión no debería afectar de ningún modo al regreso del modo de suspensión-a-memoria. Seguramente tenga que ver con la hibernación implícita que los Mac hacen con cada suspensión.

App Nap

Otra curiosidad es algo llamado "App Nap". Consiste en que, cuando a una aplicación no es visible en el escritorio y no está reproduciendo sonido, se le reducen la prioridad de los temporizadores (es decir, el periodo de tiempo para hacer coalescencia de temporizadores es mayor que lo habitual), la del I/O de disco y la prioridad del proceso.

...en definitiva, ahorro de energía

Estas tres características tienen una cosa en común: Tienen como objeto principal el ahorro de energía. Es decir, no son demasiado útiles para los Mac de escritorio. Al menos las dos primeras tienen toda la pinta de haber sido desarrolladas para iOS e incorporadas posteriormente a OS X.

Otras características de ahorro de energía menos interesntes son que hará falta hacer click en contenido flash para poder verlo cuando el contenido no esté en el centro de la página, y aceleración por hardware en la reproducción de video.


Tags

Otra característica interesante es el uso de tags en los archivos. Lo interesante no son los tags en sí mismos (¿hace cuántos años los soporta KDE?) sino el cómo están implementados, ya que el tagging es el primer paso para quienes quieren librarse de la estructura jerárquica y la anidación excesiva de directorios. Y parece ser que están implementados como atributos extendidos. Es decir, no se han roto demasiado la cabeza - por el momento (se rumorea hace tiempo que Apple trabaja en un nuevo sistema de archivos).

OpenGL

Una de las características menos publicitadas de OS X Mavericks es la muy reivindicada actualización de su OpenGL. Pasan del OpenGL 3.2 de los OS X actuales, cuya especificación fue publicada en 2009 (!) a soportar OpenGL 4.1 (y algo de 4.2). Que fue publicado en 2010, pero al menos se trata de una versión 4.x, que tiene mejor soporte para hardware diseñado para Direct3D 11. Será interesante ver los resultados del cambio.

Conservadurismo unixero, versión anti-wayland

Algunos desarrolladores de X.org/Wayland han escrito para Phoronix un buen artículo enumerando, una vez más, las razones por las que X.org es un artefacto espantoso y como Wayland lo soluciona. A pesar de ello, la reacción en algunos foros vuelven a ser los comentarios de gente que, en el mismo tono escéptico de siempre, vuelven a preguntarse sobre la necesidad de reemplazar una cosa tan sólida y funcional como X.org.

Mención especial merecen quienes siguen mencionando la transparencia de red como motivo fundamental para defender a X.org frente a Wayland. A pesar de que el artículo describe con elocuencia qué:
  · X.org hoy en día no tiene verdadera transparencia de red (las extensiones modernas han distorsionado el concepto original)
 · La que tiene es bastante deficiente (que hayan surgido empresas que hacen dinero mejorándola debería dar una pista)
 · Wayland no sólo permitirá usar X.org dentro de Wayland, sino que tendrá soporte nativo de transparencia de red mejor que el de X.org (ya se ha incluido soporte de FreeRDP en Weston 1.1).

A pesar de ello, como digo, no hay manera de que en cada hilo de Wayland aparezcan inevitablemente esos comentarios. No es sólo que haya gente que no lee el artículo, es que se niegan a leer e intentar comprender a quienes les responden.

Llegados a este punto, los desarrolladores de Wayland probablemente pierden el tiempo escribiendo esas cosas. A estas alturas, está claro que estamos ante ejemplos de ultraconservadurismo unixero. Suelen abundar en estos casos las opiniones que, mostrando un considerable desfase respecto a la realidad tecnológica actual, defienden que el uso de "3D" en los escritorios es innecesario. Salgan de mi patio y no pisen mi cesped. Resumiendo, que no merecen demasiada atención.

Dramas de Windows 8

A estas alturas no es ningún secreto que en el escritorio Windows 8 ha tenido bastante menos éxito que el que se presupone a un nuevo sistema operativo de Microsoft debería conseguir. Su cuota de uso en la web es peor que la de Vista, y Vista ya de por si no fue precisamente popular. Pero el caso de Windows 8 no se queda ahí, hay varias historias entrecruzadas rondando internet -no todas negativas- que dan para hablar largo y tendido.

Uno de mis favoritos son este o este, en los que se argumenta que la culpa de los malos resultados de Windows 8 la tienen los vendedores de PCs tradicionales, por querer seguir vendiendo....PCs tradicionales, y por no querer seguir las indicaciones de Microsoft. Lo cierto es que son hipótesis creíbles, teniendo en cuenta la existencia de Surface como supuesta muestra de lo que Windows 8 debería ser.

Uno de los últimos dramas ocurrió hace unos días, en un post del "Corporate Vice President of Corporate Communications" de Microsoft. Este responsable de comunicación decidió utilizar una técnica comunicativa muy común, consistente en acusar a los medios de comunicación de sensacionalismo. Es decir, echar balones fuera. Lo cómico es que esos medios sensacionalistas coinciden al señalar lo que todos sabemos: Imposibilidad de arrancar en el escritorio clásico, ausencia de botón de inicio. Pero está previsto que la próxima actualización de Windows, 8.1 "Blue", restaure precisamente ese funcionalidad. El responsable de "comunicaciones corporativas" puede decir lo que quiera, pero con los hechos Microsoft da la razón a los medios a quienes acusan de sensacionalistas.

Y, por supuesto, repite una y mil veces aquello de que ellos escuchan atentamente a sus clientes. Sin embargo, todos recordamos que la ausencia del botón de inicio y la imposibilidad de iniciar en el escritorio clásico fueron mencionados repetidamente en los análisis de todas las versiones preliminares de Windows 8. Surgieron varios programas para añadir de nuevo el botón de inicio, y en lugar de escuchar a los clientes, Microsoft intentó activamente hacer difícil la creación de esos programas.

Otro drama interesante es la curiosa persistencia de gente que sigue afirmando en serio que la(s) interfaz(ces) de Windows no tienen ningún problema, que es mejor que Windows 7 y que es cosa de acostumbrarse. Como ya mencioné, a la dualidad de interfaces de Windows 8 sólo cabe acostumbrarse como uno se acostumbra en Linux a las diferencias entre aplicaciones GNOME y KDE, es decir, educando al cerebro para que ignore los problemas.

Pero no todo es malo. Poca, muy poca gente menciona que Windows 8 está teniendo cierto éxito en las tabletas, pasando en un año de una cuota de mercado del 0% al 7.8%. Teniendo en cuenta que se trata de la entrada de un jugador nuevo en medio de una competencia feroz entre iPad y Android, me parecen cifras más que respetables. Puede que Windows 8 haya causado un lío tremendo en el escritorio con su mezcla de interfaces, pero está claro que obtienen un beneficio de todo eso, que es ser un buen sistema operativo para tabletas.