Apple, Adobe y el Flash ★

Monday, 25 January 2010

En mi artículo titulado “Reflexiones sobre el Tablet” de hace dos semanas, especulaba que el inminente tablet de Apple posiblamente no tendría soporte para Flash, por las mismas razones por las que el iPhone tampoco lo tiene. Las reacciones a esta suposición fueron muy extremas — la mayoría eran “bah, claro que no tendrá” o bien “para nada, tiene que tener soporte para Flash”. Se pueden ver ambas reacciones representadas en la discusión sobre mi artículo en Hacker News. Uno de estos grupos va a quedar muy sorprendido el miércoles.

Llevo dos años escribiendo sobre esta saga. Mi fascinación con el tema la alimenta el hecho de que polarice tantísimo la opinión de la gente, y que además tienes implicaciones tanto técnicas como políticas.

Acerca de Flash y los cuelgues de las aplicaciones en Mac OS X

Hace dos semanas escribí lo siguiente:

Por lo que sé, Apple controla todo el código fuente del sistema operativo del iPhone. Eso no quiere decir que lo hayan escrito todo desde cero. Muchos componentes de bajo nivel del sistema operativo son open source. Pero tienen el código fuente. Si hay un fallo, pueden arreglarlo. Si algo va lento, pueden optimizarlo o volverlo a escribir. Esto no pasa con Mac OS X, y Flash es el ejemplo perfecto. La principal causa del cuelgue de aplicaciones en Mac OS X es un componente que Apple no puede arreglar.

Varios lectores me pidieron que citara la fuente en la que me basaba para hacer la acusación de la última frase, que Flash es “la principal causa del cuelgue de aplicaciones en Mac OS X”. (Y hacen bien en preguntarme; no sé en qué pensaba al incluir esa frase sin citar la fuente).

Pues aquí está. En el escenario durante la conferencia de presentación del WWDC 2009 el pasado mes de Junio, el vicepresidente en jefe de ingeniería de software de Apple, Bertrand Serlet, explicaba el nuevo mecanismo de plugins de contenidos para Safari bajo Snow Leopard. En lugar de ejecutarse dentro del proceso de la aplicación Safari, los plugins de contenido web se ejecutan ahora en sus propios procesos, de modo que si se cuelgan, (normalmente) no hacen que Safari se cuelgue. Te aparece un pequeño rectángulo roto en la página en la que el plugin se estaba ejecutando, pero el propio navegador sigue funcionando.

Apple hizo esto por dos motivos. La razón explicada por Serlet al público fue la “resistencia a los cuelgues”, como acabo de explicar. En cuanto al motivo por el que merecía la pena implementar tal sistema resistente a los cuelgues, Serlet explicó que, basándose en datos de la aplicación Crash Reporter que incluye Mac OS X — lo que te pide que envíes datos a Apple después de que haya ocurrido un cuelgue — la causa más frecuente de cuelgues en todo Mac OS X son (o al menos eran, antes de la aparición de Snow Leopard) los “plugins”.

Serlet no nombró a ningún plugin culpable de forma específica. Simplemente los “plugins”. Pero durante el resto de la semana del WWDC, lo confirmé con varias fuentes de Apple que están familiarizadas con los datos acumulados por Crash Reporter, y corroboraron que “plugins” era un eufemismo de “Flash”.

Dicho de otro modo, en la enorme montaña de informes de cuelgues acumulados por Apple — de todas las aplicaciones que experimentan un cualgue en todos los Macs de todos los usuarios que hacen clic en el botón para enviar estos informes a Apple — Flash se lleva la mayor tajada. Eso no quiere decir que de algún modo Flash provoque cualgues en cualquier aplicación. Es lógico suponer que casi siempre se tratará de Safari o de otro navegador que ejecuta contenido Flash. Y hay que recordar que esto no quiere decir necesariamente que Flash tenga una tendencia especial a colgarse o que esté mal programado. Pensad en él en términos de una fórmula como esta:

número total de cuelgues = (bugs fatales) × (uso real)

Es muy posible que la cantidad y gravedad de los bugs de Flash que provocan cuelgues sea escasa, pero aún así supondrían una gran parte del número total de cuelgues porque realmente está siempre en uso — por cualquier usuario de Mac con una página web abierta que tenga contenido Flash reproduciéndose. Y si el reproductor de Flash para Mac OS X realmente está mal programado y con un código fuente lleno de bugs, pues incluso peor.

Pero hay otro motivo para que Apple creara esta nueva arquitectura de para la ejecución de plugins de contenido web como procesos externos en Snow Leopard: era la única forma que tenían de hacer que Safari y WebKit fueran ejecutables de 64 bits. El reproductor Flash sólo está disponible como un ejecutable de 32 bits (esto también ocurre con otros plugins de contenido web, como Silverlight, pero Flash es el único que va incluido con el sistema operativo). Las aplicaciones de 64 bits no pueden ejecutar plugins de 32 bits. Apple no tiene el código fuente de Flash, así que solamente Adobe puede hacer que el reproductor Flash sea compatible con ejecutables de 64 bits. Aún no lo han hecho. Así que, si Apple quería que Safari fuera un ejecutable de 64 bits en Snow Leopard (cosa que finalmente hicieron), necesitaban poder ejecutar plugins de 32 bits, como Flash, en un proceso independiente.

Quizá no creáis a Apple cuando asegura que los plugins de contenido web son la causa más frecuente de cuelgues en Mac OS X. Quizá no me creáis a mí y a mis fuentes no citadas de Apple cuando digo que Flash es el principal responsable de estos cuelgues. Me parece bien, el escepticismo es bueno. Siendo así, a lo mejor Bertrand Serlet habló de la “resistencia a los cuelgues de plugins” por razones políticas, sólo para clavarle un cuchillo en la espalda a Adobe, y la única razón por la que Apple implementó esta arquitectura de procesos externos fuera la incompatibilidad entre ejecutables de 64 y 32 bits.

Pero eso no hace sino resaltar que Flash sigue siendo un ejecutable de 32 bits a pesar de que Apple quiere que todo el sistema sea de 64 bits. Flash sigue siendo de 32 bits y no hay nada que Apple pueda hacer al respecto. En lugar de poder hace ellos mismos que Flash sea de 64 bits, Apple tuvo que desarrollar toda una nueva arquitectura de plugins.

Por esto es por lo que Apple quiere controlar el código fuente de todo el sistema operativo. Si quieren que el sistema operativo del iPhone sea de 64 bits, tienen la capacidad de hacerlo. Y, ¿qué ocurre si Apple elige una nueva arquitectura de procesador? Para los componentes cuyo código fuente controla Apple, pueden volver a compilar este código para la nueva arquitectura. Si el sistema entero no se recompila bien para la nueva arquitectura, pueden retocarlo hasta que funcione. Para un componente como Flash, con el que Adobe controla el código fuente, lo único que Apple puede hacer es esperar.

¿Qué situación creéis que satisface más a Apple? ¿Mac OS X, para el que tuvieron que desarrollar una nueva arquitectura de plugins de contenido web porque Flash se cuelga frecuentemente y no es de 64 bits? ¿O el sistema operativo del iPhone, para el que controlan en código fuente de cada componente individual, y con el que pueden hacer lo que quieran y cuando quieran?

El caso es que, aunque creáis que el reproductor Flash de Mac OS X es el mejor software del mundo y que un reproductor Flash para el iPhone funcionaría bien — nadie puede negar que los ejecutivos de Apple han dicho, y siguen diciendo, cosas negativas sobre Flash en público. Apple no habla mucho sobre Flash, pero lo que dice no suena a lo que dirían si estuvieran deseando mejorar el soporte en lugar de reducirlo.

La Web privativa

Probablemente los lectores habituales de Daring Fireball ya sepan que me da igual Flash, y que espero que Apple nunca lo incluya en el sistema operativo del iPhone. Creía que debía dejar eso claro.

¿Por qué? En el fondo, porque Flash es el único estándar web basado en una tecnología privativa. Existen muchos plugins privativos de contenido web — incluido el QuickTime de Apple — pero Flash es el único tan omnipresente que se ha convertido en un estándar de hecho. Flash es el modo en que se transmite vídeo por la web, y Adobe controla totalmente Flash. Ningún otro aspecto de la web funciona así. HTML, CSS y JavaScript son todos estándares abiertos, con numerosas implementaciones, incluyendo varias de código abierto.

El argumento más sencillo a favor del soporte de Flash en el iPhone (y el Tablet, y cualquier aparato) es que Flash es, por pura popularidad y omnipresencia, parte de la web. Pero el mejor argumento en contra del soporte de Flash que es dañino para la web en conjunto que algo tan importante como el vídeo esté en manos de una sola empresa, y el único modo en que esto va a cambiar es si una alternativa a Flash abierta se convierte en un medio atractivo para los creadores de contenido para la web.

Es como el problema del huevo y la gallina. Los creadores de contenidos usan Flash para el vídeo en la web porque está instalado en un altísimo porcentaje de ordenadores clientes; los clientes soportan Flash porque un gran número de creadores de contenidos usan Flash para el vídeo en la web. Con el iPhone, Apple está solucionando el problema del huevo y la gallina. Por primera vez, hay una gran cantidad, y cada vez mayor, de usuarios demográficamente interesantes que no tienen Flash instalado. Si quieres suministrar vídeo a los usuarios de iPhone, tienes que usar H.264.

Apple no intenta sustituir a Flash con su propio sistema privativo. Lo están sustituyendo con H.264 y HTML5. Es algo bueno para todo el mundo menos para Adobe.

Y sí, sé que Flash hace muchas más cosas que reproducir vídeo. Pero eso es lo primero en lo que piensa todo el mundo al hablar de que Flash no funciona en el iPhone — vídeo. Y al hablar de otros usos para Flash, estaríamos hablando de que funcione como un intérprete de software, y nos guste o no, Apple se opone claramente a la existencia de intérpretes de software (runtimes) para iPhone OS, una postura que parece estar yéndoles muy bien.

Lo siguiente es un e-mail que me envió un lector de DF:

Estaba haciendo cola en una cafetería el día de Navidad. Delante de mí había un niño, de unos nueve o diez años, que tenía un iPhone. Estaba claro que se lo habían regalado aquella mañana. No dejaba de pulsar insistentemente una caja blanca en una página web con el símbolo de un plugin roto. Lo estaba intentando estirar, desplazar, pulsar. Estaba frustrado y a punto de cabrearse con su nuevo juguete. Parecía que intentaba usar una página de juegos online, posiblemente una con la que solía jugar en el PC de casa. Al final no pude aguantarlo más. Me acerqué y le dije “No carga Flash. No ejecuta los juegos Flash”. Su madre, que no le había hecho caso hasta aquel momento, empezó a prestar atención al ver que un extraño hablaba con su hijo. “No pasa nada, cariño”, dijo, “te compraremos un juego del App Store”. ¿Cómo reaccionó el niño ante esto? Se puso a intentar hacer funcionar con más insistencia la página Flash. No quería un juego del App Store; quería su juego Flash. Y aquel iPhone de repente le pareció mucho menos interesante.

Le guste o no a Apple, debería poner solución a esto. Aunque sea por los niños.

Creo que esta anécdota, y la conclusión que sacó este lector de ella, representa con precisión la opinión que existe de que “al final, Apple tendrá que ceder en esto”.

Pero pensemos en ello desde el punto de vista de Apple. ¿Cómo creéis que acabó la situación de la anécdota al final? ¿Creéis que el niño le dijo a su madre que devolviera el iPhone? ¿O creéis que volvieron a casa y empezaron a comprar juegos del App Store? Que hubiera una fase inicial de frustración debido a que no funcionaban los juegos Flash no cambia el hecho de que (a) compraron un iPhone y (b) estaban dispuestos a comprar juegos del App Store.

No estoy diciendo que la aparente antipatía hacia Flash de los ejecutivos de Apple no sea en interés de la compañía. (Sí que creo, no obstante, que el equipo de WebKit en Apple tiene un concepto de la web realmente idealista).

Pero aunque Apple podría estar actuando por el gusto de fastidiar, no se están perjudicando a ellos mismos. La asuencia de Flash en el iPhone no le ha perjudicado en lo más mínimo. Quizás esto cambie en el futuro, si algún día Flash llega a popularizarse en otras plataformas móviles, pero yo esperaría sentado.

El rendimiento de Flash en Mac OS X

Además de las justificadas preocupaciones explicadas más arriba sobre el hechod e que Flash sea un sistema privativo, también hay consideraciones prácticas. En primer lugar, la ya mencionada tendencia de Flash a sufrir cuelgues en Mac OS X. En segundo lugar y dejando al lado lo de los cuelgues, el rendimiento en Mac OS X no es tan bueno como en Windows. Y concretamente con la reproducción de vídeo, el rendimiento de Flash palidece en comparación con la reproducción de vídeos en formato H.264 mediante QuickTime. No es algo subjetivo. Mi máquina es un MacBook Pro de dos años de antigüedad. Reproduce vídeos H.264 mediante QuickTime sin problema alguno. Al reproducir vídeos Flash a pantalla completa, el ventilador del equipo empieza a funcionar a los pocos segundos, y lo hace siempre.

He sido duro con el reproductor de Flash para Mac OS X, pero este problema de rendimiento no es totalmente culpa de Adobe. En Windows, Flash utiliza decodificación por hardware para reproducir H.264, si es que está disponible. En Mac OS X no. Esta es una de las razones por las que la reproducción de vídeo en Flash tiene mayor rendimiento en Windows en en Mac OS X, y también por las que la reproducción de vídeos H.264 en Mac OS X es mucho mejor con QuickTime (que sí usa decodificación por hardware).

Según Adobe, no obstante, esto es así porque no pueden. Veamos parte de sus Preguntas frecuentes sobre el reproductor Flash:

P. ¿Por qué la decodificación por hardware de vídeos H.264 sólo funciona en las plataformas Windows?

R. En Flash Player 10.1, la aceleración por hardware de H.264 no funciona bajo Linux y Mac OS. Linux carece actualmente de un API estándar que soporte decodificación de vídeo H.264 por hardware, y Mac OS X no permite el acceso a las APIs necesarias. Seguiremos atentos para poder añadir esta funcionalidad a las plataformas Mac y Linux en futuras versiones.

El promotor de plataformas de Adobe Lee Brimelow publicó hace poco un artículo en su weblog hablando sobre el tema:

Pero hablemos más sobre el reproductor Flash para Mac. Si no funciona igual de bien que el reproductor para Windows la gente asume que es culpa nuestra. Los hechos demuestran que no es así. Tomemos por ejemplo la función de aceleración por hardware de vídeo H.264, que incluimos en el reproductor Flash 10.1. Aquí se pueden ver resultados publicados que muestran lo mucho que la situación ha mejorado en Windows. Por desgracia no pudimos añadir esta aceleración al reproductor para Mac porque Apple no proporciona una API pública que lo permita. Se puede confirmar fácilmente preguntándole a Apple. Me alegra poder decir que conseguimos hacer algunas mejoras de la reproducción de vídeo en la versión para Mac, pero la verdad es que no pudimos implementar la aceleración por hardware. Es un problema al que nos enfrentamos cuando se trata de Apple.

No podría desmentir esto. Windows es más amigable a intérpretes o runtimes de terceros, como Flash, que Mac OS X. Creo que la mayoría estaríamos de acuerdo en que Apple es una empresa muy dogmática (como mínimo), y crean productos dogmáticos. Los intérpretes que importan a Apple son Cocoa y WebKit. La forma que tiene Apple de reproducir vídeos H.264 es mediante las APIs de QuickTime (y a partir de Snow Leopard las nuevas APIs de QuickTime X), no escribir tu propio código de reproducción de H.264 que intente acceder de forma directa a los sistemas de aceleración hardware.

Se puede discutir el motivo de que Apple haya adoptado esta postura. Se podría plantear que es una postura pragmática — que Apple no permite que software de terceros acceda a cosas como la aceleración H.264 por hardware porque intentan mantener un nivel de abstracción entre el software de terceros y el hardware que hay por debajo. Se podría decir que es una decisión polític — que a Apple le gusta hace que Flash quede mal en términos de rendimiento porque compite con Apple en varios campos. (por ejemplo, uno podría desear que Hulu, que está basado totalmente en Flash, funcionara en el iPhone y que funcionara mejor en el Mac. A Apple le gustaría que los contenidos de Hulu estuvieran únicamente disponibles en el iTunes Store).

Mi opinión es que se trata de ambas cosas — que lo poco que el reproductor Flash le gusta a Apple está motivado a la vez por razones de programación (que el software de terceros únicamente debería tener acceso a las APIs de alto nivel) y por motivos políticos. Pero siendo objetivos, y sin importar lo que uno desee que Apple haga respecto a Flash, si Adobe necesita que Apple les conceda un mayor acceso al hardware para mejorar la versión de Mac del reproductor Flash, ¿qué posibilidades tienen de lograr ese nivel de acceso de bajo nivel al hardware en el sistema operativo del iPhone? (Pista: cero).

Dejaré que la última palabra la tenga el jefe de operaciones de Apple, Tim Cook, que hace un año dijo lo siguiente: “Creemos en lo simple no en los complejo. Creemos que necesitamos ser los dueños y tener el control de las tecnologías principales de los productos que fabricamos, y participar únicamente en mercados en los que podamos contribuir de forma significativa”.

Adobe es el dueño de Flash y quien lo controla.