Del mismo modo que Intel es un ejemplo de multinacional letalmente competitiva, capaz de cometer errores mastodónticos y corregirlos sin perder el liderazgo, AMD ha acabado convirtiéndose en ejemplo de lo contrario. El único buen momento de AMD en la última década fue el Opteron, una joya que no supieron capitalizar y que se ha convertido en una excepción en su historia. Hoy, en un mundo en el que la eficiencia de un procesador importa a veces más que su rendimiento bruto, han decidido no enfrentarse al mundo y pasar a usar ARM en servidores.
Que AMD recurra a procesadores ARM para algo es equivalente a reconocer que no son capaces de crear procesadores x86 de bajo consumo equivalentes. Es más, probablemente una de las razones que les ha impulsado a tomar esta decisión es que ARM iba a acabar comiéndose parte de su mercado de servidores, y han preferido unirse a otro bando antes que perder la guerra x86 vs ARM. Intel, por su parte, ha empezado con desventaja, pero al menos tienen intención de presentar batalla y ganarla.
Tras esta reorganización de bandos en el campo de procesadores de bajo consumo, prácticamente todos los competidores de Intel en el campo de semiconductores se han unido en el lado de ARM, e incluso algunos aliados tradicionales en otros campos, como Microsoft, han declarado su neutralidad. La pelea será cruel.
30 de octubre de 2012
23 de octubre de 2012
Curiosidades de Flash en Linux
No sólo el soporte de Flash en Linux está en vía muerta, sino que el que hay es difícil de usar. Como ejemplo, me encuentro con este vídeo, imposible de encontrar en otro lado, así que intento descargármelo.
Para ello intento buscar en la fuente de la página el enlace al vídeo en la página, pero el que supuestamente se usa como fuente no existe o no funciona. Dejo que se descargue entero y procedo a buscar el archivo del vídeo en el caché de Firefox, algo que solía funcionar. Pero en el caché de Firefox no hay nada, ni en el cache del disco ni el cache de la memoria. Parece que intentan hacer desaparecer los vídeos y evitar que la gente se los descargue (lo cual sorprende tratándose de una URL terminada en .ru).
Sin embargo, el vídeo está evidentemente en mi sistema: lo estoy viendo. En alguna parte debe estar. Como último recurso, recurro a echar un ojo a los descriptores de archivos del proceso aislado en el que Firefox pone al reproductor (/proc/PID/fd/). En él, encuentro que el proceso tiene el descriptor 20 apuntando a un archivo curioso:
20 -> /tmp/FlashXXsKXrQ0 (deleted)
El archivo asociado el descriptor, /tmp/FlashXXsKXrQ0, ha sido borrado, pero como es norma en sistemas Unix, los procesos que lo tenían abierto siguen podiendo acceder a él. Ese archivo ya no existe, no puedo acceder directamente a él, pero si que puedo hacerlo mediante /proc. Con un simple "cp /proc/PID/fd/20 ~/archivo" recupero el archivo y, efectivamente, es el vídeo que quería descargar.
Aparentemente, Adobe quería dificultar la descarga de vídeos, como una especie de DRM simplista. Para ello decidieron crear un archivo en /tmp/ y abrirlo, proceder inmediatamente después a borrarlo para que nadie lo viese, y seguir trabajando internamente con ese descriptor asociado a un archivo "oculto".
Para ello intento buscar en la fuente de la página el enlace al vídeo en la página, pero el que supuestamente se usa como fuente no existe o no funciona. Dejo que se descargue entero y procedo a buscar el archivo del vídeo en el caché de Firefox, algo que solía funcionar. Pero en el caché de Firefox no hay nada, ni en el cache del disco ni el cache de la memoria. Parece que intentan hacer desaparecer los vídeos y evitar que la gente se los descargue (lo cual sorprende tratándose de una URL terminada en .ru).
Sin embargo, el vídeo está evidentemente en mi sistema: lo estoy viendo. En alguna parte debe estar. Como último recurso, recurro a echar un ojo a los descriptores de archivos del proceso aislado en el que Firefox pone al reproductor (/proc/PID/fd/). En él, encuentro que el proceso tiene el descriptor 20 apuntando a un archivo curioso:
20 -> /tmp/FlashXXsKXrQ0 (deleted)
El archivo asociado el descriptor, /tmp/FlashXXsKXrQ0, ha sido borrado, pero como es norma en sistemas Unix, los procesos que lo tenían abierto siguen podiendo acceder a él. Ese archivo ya no existe, no puedo acceder directamente a él, pero si que puedo hacerlo mediante /proc. Con un simple "cp /proc/PID/fd/20 ~/archivo" recupero el archivo y, efectivamente, es el vídeo que quería descargar.
Aparentemente, Adobe quería dificultar la descarga de vídeos, como una especie de DRM simplista. Para ello decidieron crear un archivo en /tmp/ y abrirlo, proceder inmediatamente después a borrarlo para que nadie lo viese, y seguir trabajando internamente con ese descriptor asociado a un archivo "oculto".
16 de octubre de 2012
Por qué Haiku/BeOS es un sistema operativo desfasado
Es inevitable: cada cierto tiempo, se publica en alguna parte de Internet un artículo en el que se relata la eterna historia de BeOS y su reencarnación Haiku, el sistema operativo que nos rescatará de todos los quebraderos de cabeza que nos causan los sistemas operativos modernos. Es comprensible que los periodistas tecnológicos hacen sitio a cosas llamativas como estas, pero va siendo hora de enumerar los defectos, mitos y exageraciones varias sobre el utopismo de Haiku, que alguna vez han sido mencionadas en este blog pero que nunca han sido analizadas a fondo.
· Sistema operativo de escritorio: BeOS se hizo famoso en su día por la interactividad de su interfaz, rapidez en la respuesta a las acciones del teclado y ratón, y poder reproducir varios vídeos simultaneamente sin ningún problema. Algo que puede resultar poco sorprendente hoy en día, pero que entonces Windows, Linux, y Mac OS no podían hacer.
Sin embargo, trasladar el argumento al presente sería una locura y un olvido de la realidad de mediados-finales de los 90. En aquellos tiempos los sistemas operativos bien diseñados se encontraban en los servidores, los escritorios vivían en una realidad alternativa y eran, por lo general, bastante cutres. Los Windows de la época eran los 9x, ese engendro demoniaco que se iniciaba a partir de MS-DOS, y en el que un proceso cualquiera podía colgar el sistema. Mac OS no tuvo multitarea apropiativa ("preemptive") hasta la versión 9.0, sólo dos años antes de la aparición de OS X. Respecto a Linux, sus características de servidor eran sólidas, pero su implementación interna no era nada óptima para un escritorio. Estamos hablando de los tiempos de Linux 2.0, la primera versión que soportaba SMP y que, desde luego, no soportaba ninguna clase de "preemptitividad": Cuando un proceso hacía una llamada al sistema, el resto de procesos tenían que esperar a que terminara si ellos querían hacer otra. Para un sistema de escritorio algo así era monstruoso.
Que BeOS fuese un buen sistema de escritorio y otros muy malos no tiene nada de sorprendente, como tampoco lo tiene que los que fueron malos se hayan convertido a base de trabajo en buenos, mientras que BeOS y Haiku han ido empeorando debido a las exigencias elementales del hardware moderno: Haiku carece de capacidades elementales de gestión de energía y ni tan siquiera puede suspender a memoria, por ejemplo.
· Sistema gráfico: El subsistema gráfico de BeOS era excelente, pero fue diseñado para un mundo 2D, pre-GPU, donde las cosas eran muy diferentes a lo que son hoy. El soporte 3D sólo existió como algo experimental y, desde luego, no tomaba parte en los gráficos de la interfaz.
Todos los sistemas operativos llevan varios años rediseñando por entero sus subsistemas gráficos -arquitectura de los drivers del kernel, servidor gráfico, toolkits- para adaptarse a la nueva realidad de la potencia de las GPUs, y aunque ya se usa todo este trabajo en los toolkits para pantallas táctiles, aun no hemos empezado a ver de verdad los resultados visuales de todo esto (imagínense un escritorio donde los iconos no sean simples imágenes a los cuales el diseñador pinta un sombreado para dar sensación de profundidad, sino objetos 3D con sombra generada por la GPU y capaces de reaccionar con animaciones complejas, como en un juego).
Haiku lleva mucho retraso frente a los toolkits actuales. Aun no implementa la capacidad de "compositing" que les permitiría soñar con imitar los efectos que Compiz hacía hace años, no digamos ya frente a cosas como Wayland + QML.
· Multithreading: Una de las decisiones que hicieron los diseñadores de BeOS fue optimizar para ordenadores con múltiples procesadores: aunque su predicción se retrasó una década, está claro que acertaron en su visión.
Sin embargo, existe mucha mitificación al respecto de lo que BeOS llamó "Pervasive Multithreading". En realidad, se reducía a utilizar threads por doquier (una solución inferior a la de Grand Central Dispatch en iOS), sobre una base de código fundamentalmente en C++. En los 90, el soporte de threads en Linux era patético y lo de BeOS podía resultar llamativo, pero hoy en día no tiene nada de particular. De hecho, un escritorio Linux moderno utiliza bastantes threads: Mi firefox usa nada menos que 31, el lector de correo 3, el programa de música 12, el lector de feeds 2. A veces echo de menos que los programadores no aprovechen más otras CPUs, pero es una cuestión de vagancia, más que de incapacidad técnica.
Bien es cierto que BeOS tiene el mérito de haber usado threads como parte fundamental del diseño de las librerías básicas del sistema, y que varios objetos de la API de BeOS usan threads, de modo que las aplicaciones los utilizan automáticamente. Esto no es necesariamente malo, pero requerir a los programadores utilizar threads y usar bloqueos correctamente como parte normal de su rutina, y forzarles a ello no porque exista necesidad de paralelizar algo sino "por diseño", no tiene porque ser la mejor decisión del mundo.
En este post, un tipo cuenta como el toolkit gráfico java AWT fue diseñado en un principio como multihilo, al igual que BeOS, pero luego acabaron moviendose a un loop de eventos, porque complicaba las cosas, fomentaba la aparición de fallos y no era necesario. BeOS tenía problemas de estabilidad debido a los fallos derivados de la complejidad de su GUI multihilo, e incluso hubo empresas que paralizaron ports de aplicaciones por los problemas que esto causaba.
En esencia, Haiku no tiene nada especial que lo haga más apto para el aprovechamiento masivo de multiprocesadores. Más allá del soporte de SMP y de threads en el kernel, las capacidades de programación multihilo podrían ser, en todo caso, ser consideradas como una problema del lenguaje: usar threads en C++ viene a ser lo mismo tanto en BeOS como en Linux, y aprovechar las capacidades de concurrencia masiva de Erlang viene a ser lo mismo en ambos sistemas.
· Microkernel: Hay gente que cree que BeOS era un microkernel. Lo cierto es que no lo fue, ni tampoco lo es Haiku. Los drivers, el sistema de archivos, el vfs, la pila de red...todos están en el mismo espacio de direcciones que el kernel. No entiendo de la gente de llamar a esto "microkernel híbrido" o cosas así: en realidad, en este punto BeOS y Haiku vienen a ser similares a Linux.
· Sistema de archivos de 64 bits, con journaling y base de datos: BFS era un buen sistema de archivos en su día, pero el journaling ha dejado de usarse en los sistemas de archivos de última generación, la amplitud del direccionamiento de datos de 64 bits no tiene nada de especial, y le falta la capacidad de comprobar checksums y la gestión de volúmenes integrado para estar al día con ZFS y Btrfs.
Respecto a los índices de atributos que lo convertían en una pseudo base de datos, me parece la característica más importante de BeOS y su innovación más relevante. Sin embargo, lo mismo se puede decir de otros sistemas de archivos que han intentado mezclar sistemas de archivo con bases de datos, como WinFS o Reiser4 (aunque estos fracasaron por aspirar a demasiado, a diferencia de BFS).
Lo cierto es que aunque los índices de atributos eran muy prácticos, no eran una solución completa para una búsqueda integral del sistema: por ejemplo, no podían buscar palabras dentro de un archivo de texto. Para implementar algo como Spotlight, los índices de atributos de Haiku serían útiles, pero no suficientes.
Resumiendo
Si, BeOS fue muy innovador, y si hubiera tenido éxito y se hubiese invertido en él, hubiese sido un gran sistema operativo. Desgraciadamente eso no ocurrió, y el desfase tecnológico pesa demasiado. No tengo nada en contra de Haiku, en contra, me parece interesante, pero de ahí a decir que el escritorio Linux es una castaña y que sólo nos salvaremos con la Segunda Venida de BeOS en forma de Haiku va una gran distancia.
· Sistema operativo de escritorio: BeOS se hizo famoso en su día por la interactividad de su interfaz, rapidez en la respuesta a las acciones del teclado y ratón, y poder reproducir varios vídeos simultaneamente sin ningún problema. Algo que puede resultar poco sorprendente hoy en día, pero que entonces Windows, Linux, y Mac OS no podían hacer.
Sin embargo, trasladar el argumento al presente sería una locura y un olvido de la realidad de mediados-finales de los 90. En aquellos tiempos los sistemas operativos bien diseñados se encontraban en los servidores, los escritorios vivían en una realidad alternativa y eran, por lo general, bastante cutres. Los Windows de la época eran los 9x, ese engendro demoniaco que se iniciaba a partir de MS-DOS, y en el que un proceso cualquiera podía colgar el sistema. Mac OS no tuvo multitarea apropiativa ("preemptive") hasta la versión 9.0, sólo dos años antes de la aparición de OS X. Respecto a Linux, sus características de servidor eran sólidas, pero su implementación interna no era nada óptima para un escritorio. Estamos hablando de los tiempos de Linux 2.0, la primera versión que soportaba SMP y que, desde luego, no soportaba ninguna clase de "preemptitividad": Cuando un proceso hacía una llamada al sistema, el resto de procesos tenían que esperar a que terminara si ellos querían hacer otra. Para un sistema de escritorio algo así era monstruoso.
Que BeOS fuese un buen sistema de escritorio y otros muy malos no tiene nada de sorprendente, como tampoco lo tiene que los que fueron malos se hayan convertido a base de trabajo en buenos, mientras que BeOS y Haiku han ido empeorando debido a las exigencias elementales del hardware moderno: Haiku carece de capacidades elementales de gestión de energía y ni tan siquiera puede suspender a memoria, por ejemplo.
· Sistema gráfico: El subsistema gráfico de BeOS era excelente, pero fue diseñado para un mundo 2D, pre-GPU, donde las cosas eran muy diferentes a lo que son hoy. El soporte 3D sólo existió como algo experimental y, desde luego, no tomaba parte en los gráficos de la interfaz.
Todos los sistemas operativos llevan varios años rediseñando por entero sus subsistemas gráficos -arquitectura de los drivers del kernel, servidor gráfico, toolkits- para adaptarse a la nueva realidad de la potencia de las GPUs, y aunque ya se usa todo este trabajo en los toolkits para pantallas táctiles, aun no hemos empezado a ver de verdad los resultados visuales de todo esto (imagínense un escritorio donde los iconos no sean simples imágenes a los cuales el diseñador pinta un sombreado para dar sensación de profundidad, sino objetos 3D con sombra generada por la GPU y capaces de reaccionar con animaciones complejas, como en un juego).
Haiku lleva mucho retraso frente a los toolkits actuales. Aun no implementa la capacidad de "compositing" que les permitiría soñar con imitar los efectos que Compiz hacía hace años, no digamos ya frente a cosas como Wayland + QML.
· Multithreading: Una de las decisiones que hicieron los diseñadores de BeOS fue optimizar para ordenadores con múltiples procesadores: aunque su predicción se retrasó una década, está claro que acertaron en su visión.
Sin embargo, existe mucha mitificación al respecto de lo que BeOS llamó "Pervasive Multithreading". En realidad, se reducía a utilizar threads por doquier (una solución inferior a la de Grand Central Dispatch en iOS), sobre una base de código fundamentalmente en C++. En los 90, el soporte de threads en Linux era patético y lo de BeOS podía resultar llamativo, pero hoy en día no tiene nada de particular. De hecho, un escritorio Linux moderno utiliza bastantes threads: Mi firefox usa nada menos que 31, el lector de correo 3, el programa de música 12, el lector de feeds 2. A veces echo de menos que los programadores no aprovechen más otras CPUs, pero es una cuestión de vagancia, más que de incapacidad técnica.
Bien es cierto que BeOS tiene el mérito de haber usado threads como parte fundamental del diseño de las librerías básicas del sistema, y que varios objetos de la API de BeOS usan threads, de modo que las aplicaciones los utilizan automáticamente. Esto no es necesariamente malo, pero requerir a los programadores utilizar threads y usar bloqueos correctamente como parte normal de su rutina, y forzarles a ello no porque exista necesidad de paralelizar algo sino "por diseño", no tiene porque ser la mejor decisión del mundo.
En este post, un tipo cuenta como el toolkit gráfico java AWT fue diseñado en un principio como multihilo, al igual que BeOS, pero luego acabaron moviendose a un loop de eventos, porque complicaba las cosas, fomentaba la aparición de fallos y no era necesario. BeOS tenía problemas de estabilidad debido a los fallos derivados de la complejidad de su GUI multihilo, e incluso hubo empresas que paralizaron ports de aplicaciones por los problemas que esto causaba.
En esencia, Haiku no tiene nada especial que lo haga más apto para el aprovechamiento masivo de multiprocesadores. Más allá del soporte de SMP y de threads en el kernel, las capacidades de programación multihilo podrían ser, en todo caso, ser consideradas como una problema del lenguaje: usar threads en C++ viene a ser lo mismo tanto en BeOS como en Linux, y aprovechar las capacidades de concurrencia masiva de Erlang viene a ser lo mismo en ambos sistemas.
· Microkernel: Hay gente que cree que BeOS era un microkernel. Lo cierto es que no lo fue, ni tampoco lo es Haiku. Los drivers, el sistema de archivos, el vfs, la pila de red...todos están en el mismo espacio de direcciones que el kernel. No entiendo de la gente de llamar a esto "microkernel híbrido" o cosas así: en realidad, en este punto BeOS y Haiku vienen a ser similares a Linux.
· Sistema de archivos de 64 bits, con journaling y base de datos: BFS era un buen sistema de archivos en su día, pero el journaling ha dejado de usarse en los sistemas de archivos de última generación, la amplitud del direccionamiento de datos de 64 bits no tiene nada de especial, y le falta la capacidad de comprobar checksums y la gestión de volúmenes integrado para estar al día con ZFS y Btrfs.
Respecto a los índices de atributos que lo convertían en una pseudo base de datos, me parece la característica más importante de BeOS y su innovación más relevante. Sin embargo, lo mismo se puede decir de otros sistemas de archivos que han intentado mezclar sistemas de archivo con bases de datos, como WinFS o Reiser4 (aunque estos fracasaron por aspirar a demasiado, a diferencia de BFS).
Lo cierto es que aunque los índices de atributos eran muy prácticos, no eran una solución completa para una búsqueda integral del sistema: por ejemplo, no podían buscar palabras dentro de un archivo de texto. Para implementar algo como Spotlight, los índices de atributos de Haiku serían útiles, pero no suficientes.
Resumiendo
Si, BeOS fue muy innovador, y si hubiera tenido éxito y se hubiese invertido en él, hubiese sido un gran sistema operativo. Desgraciadamente eso no ocurrió, y el desfase tecnológico pesa demasiado. No tengo nada en contra de Haiku, en contra, me parece interesante, pero de ahí a decir que el escritorio Linux es una castaña y que sólo nos salvaremos con la Segunda Venida de BeOS en forma de Haiku va una gran distancia.
Suscribirse a:
Entradas (Atom)