Anandtech ha hecho un análisis del primer smartphone basado en la plataforma de hardware Medfield de Intel, que usa los últimos procesadores Atom. Y los resultados son sorprendentemente buenos: consumo energético tolerable y buen rendimiento en varios benchmarks.
Ha tardado unos cuantos años, pero Intel por fin tiene algo con lo que plantar cara a ARM, y en mejores condiciones de las que se esperaba. En cierto modo no es sorprendente, Intel es un competidor temible que ha sabido recuperarse de grandes reveses en varias ocasiones. Recuerden la época de dominio tecnológico del AMD Opteron, con su subsistema de memoria NUMA y su x86-64, y de cómo Intel decidió adoptar el x86-64 (en lugar de pretender que Itanium tenía futuro) y pasar a luchar contra su competidor en su propio terreno.
Y no lo digo por hacerles la pelota: hace pocos años era utópico imaginarse un smartphone con procesador x86 que no se quedara sin batería en lo que tardabas en sacarlo del bolsillo; que este SoC Medfield sea competitivo con teléfonos a la venta en el mercado es prueba suficiente de que no son una de esas multinacionales gordas y torpes que se quedan obsoletas de la noche a la mañana sin darse cuenta (ejem, Nokia).
Así que es a partir de ahora cuando va a empezar la verdadera batalla comercial x86 vs ARM. Es una batalla desigual, porque partimos de un práctico monopolio de ARM. Pero la batalla es a largo plazo, y un contrincante llamado "departamento y presupuesto de R&D de Intel" no es alguien a quien se pueda despreciar. Intel tiene además ventajas tal vez injustas, pero existentes, como es la enorme cantidad de "deuda técnica" acumulada en x86 y hacer caer al mundo entero en su imperio. Pero en todo caso es batalla en la que los procesadores no tendrán la última palabra. Una vez que ambos sean equiparables, la clave estará en el consumo conjunto del sistema: la memoria, gráficos y chips varios.
Es ahí donde Intel puede encontrar más oportunidades. El principal defecto de ARM (y, a la vez, su principal ventaja) es la fragmentación: Existen montones de SoCs ARM para smartphones y tablets diferentes, pero esos formatos se van uniformizando, y la diferenciación es cada vez menos necesaria. Intel ofrecerá estandarización, centrará todos sus esfuerzos e inversión en unos pocos SoCs. Por esta razón creo que uno de los efectos de la entrada de Intel en el mercado será la salida del mercado de los SoCs ARM de fabricantes más débiles, y la concentración alrededor de unos pocos que estén mejor respaldados, sobre todo alrededor de Samsung y Apple, que tienen mayor capacidad de mantener vivo el ecosistema con su caudal de dinero.
Veremos cómo acaba la batalla, pero no será raro que Intel se haga para empezar con una pequeña parcela del mercado, algo de esperar y no muy preocupante partiendo de prácticamente un monopolio. A partir de ahí, ya se verá. Esto no es como la historia de los sistemas operativos móviles, Android es una VM java independiente de plataforma (para aplicaciones NDK se hace una traducción de código nativo a x86, realizada subiendo el ejecutable ARM a servidores de Intel en la "nube", los cuales devolverán el ejecutable x86), así que los ensambladores de móviles podrán escoger plataforma sin grandes obstáculos. Competencia pura y dura.
26 de abril de 2012
23 de abril de 2012
La "nube" como objetivo militar
A estas alturas, la cosa de la "nube" está tan consolidada que ya ni es controvertida. Siguen escuchándose, por supuesto, quejas: la intromisión de las empresas en la privacidad de sus usuarios, las leyes estadounidenses que permiten al gobierno de allí echar un ojo a los datos de un usuario (o del departamento de defensa de un país estúpido), el riesgo de un fallos de seguridad que afecte a miles de usuarios simultáneamente, o sin ir más lejos las quejas de GNU. Existe un peligro adicional para las "nubes", que es la posible ocupación de su infraestructura física en caso de conflicto militar o dictador chalado.
Seguramente las motivaciones variarían enormemente dependiendo del tipo de conflicto. El caso más extremo y quizás más fácil de imaginar sería el de un intento de imponer un régimen totalitario al estilo norcoreano/granhermanista. Tras alcanzar el poder, el dictador loco de turno querría asegurar la sumisión con purgas, y el control físico de un centros de datos le permitiría "googlear" información sobre todos los usuarios, en busca de pruebas de afiliación ideológica. Y estas búsquedas podrían llegar a ser muy sofisticadas, se podría buscar logotipos de partidos en las fotos, usar reconocimiento facial para buscar a gente que se haya hecho fotos junto a un sospechoso, o utilizarse software de procesamiento de lenguaje tipo Siri para analizar los correos y textos de las redes sociales.
Otros escenarios podrían ser menos extremos, por ejemplo, un bando del ejército defendiendo la democracia. En estos casos quizás no se intentaría llegar al nivel de control paranoico anterior, pero se utilizarían las mismas técnicas para lograr información de inteligencia sobre sospechosos determinados. Los movimientos de familiares y amigos podrían dar pistas. O simplemente se podría ejercer algún tipo de censura para prohibir los vídeos y textos de propaganda enemiga, o limitar la difusión de información sobre una batalla perdida para no bajar la moral a la población.
En este sentido cabría pensar también el uso como herramienta de propaganda no sólo en conflictos internos sino en guerras extranjeras y países lejanos. La mayoría de los grandes centros de datos de redes sociales o buscadores está situado en territorio estadounidense o controlado desde allí, lo cual daría a ese país en caso de guerra severa la capacidad de controlar propaganda. El único recurso de un país enemigo sería cortar el acceso a Internet, algo muy eficaz y posible pero también cada vez más notorio y molesto a medida que se expande el uso de Internet. En Túnez pudimos ver algo de este estilo: el gobierno intervino los ISPs para que modificaran la página web de facebook e insertaran código que les permitiera conseguir las contraseñas de todos los ciudadanos (facebook respondió activando login con SSL por defecto).
En cualquier caso, el interés de un ejército para hacerse con el control de un centro de datos siempre va a estar ahí. Puede que no tenga mucha utilidad para ganar o perder una guerra directamente, pero algo que contiene un montón de información potencialmente útil siempre será atractivo. Y no hay mucho que la empresa dueña pueda hacer frente a un tanque. Además, gracias a que los Estados requieren legalmente a las compañías la habilidad de acceder a la información de los usuarios en caso de juicios o por motivos de (ejem) "seguridad nacional", la capacidad de acceder a los datos esta ahí. Y un programador con una pistola apuntándole en la cabeza podría ser muy imaginativo.
Quizás todo esto parezca demasiado de ciencia-ficción, debido a que todos rechazamos intuitivamente la posibilidad de que surja una guerra dentro los países que albergan la mayoría de las nubes: EEUU o Europa. Y es cierto que aunque nada asegura que un día de estos algún país salte por los aires (Yugoslavia), es bastante difícil que ocurra. Pero no deja de ser una posibilidad real a largo plazo, y un riesgo para otros países. Los grandes centros de datos de una nube suelen estar distribuidos por varios -cada vez más- lugares del mundo, y no necesariamente estables: por ejemplo, uno de los centros de datos de Google está en Taiwan, potencial fuente de conflicto con China.
Además, cuando hablamos de nubes no me refiero en particular a Google o Amazon, sino a las potenciales nubes locales que puedan surgir a lo largo y ancho del mundo a medida que la tecnología se abarate y extienda. No es cierto que Google/Amazon/Apple/Microsoft vayan a acaparar todo: el número de centros de datos empresariales o gubernamentales a medida se expandirá, así como los servicios que se ofrezcan y el número de usuarios que los usen. Imaginemos que Libia hubiera existido algún centro de datos con un "tuenti" local. ¿Se habrían privado los rebeldes de tomarlo por la fuerza y sacar toda la información que pudieran sobre el bando de Gaddafi?
En fin, no es que haya concretado muchas cosas en este post, pero creo que se entiende. Todo avance tecnológico que se utiliza para el bien puede utilizarse también para el mal, y eso incluye a las "nubes". Confiemos en que nunca tengamos que comprobarlo personalmente.
Seguramente las motivaciones variarían enormemente dependiendo del tipo de conflicto. El caso más extremo y quizás más fácil de imaginar sería el de un intento de imponer un régimen totalitario al estilo norcoreano/granhermanista. Tras alcanzar el poder, el dictador loco de turno querría asegurar la sumisión con purgas, y el control físico de un centros de datos le permitiría "googlear" información sobre todos los usuarios, en busca de pruebas de afiliación ideológica. Y estas búsquedas podrían llegar a ser muy sofisticadas, se podría buscar logotipos de partidos en las fotos, usar reconocimiento facial para buscar a gente que se haya hecho fotos junto a un sospechoso, o utilizarse software de procesamiento de lenguaje tipo Siri para analizar los correos y textos de las redes sociales.
Otros escenarios podrían ser menos extremos, por ejemplo, un bando del ejército defendiendo la democracia. En estos casos quizás no se intentaría llegar al nivel de control paranoico anterior, pero se utilizarían las mismas técnicas para lograr información de inteligencia sobre sospechosos determinados. Los movimientos de familiares y amigos podrían dar pistas. O simplemente se podría ejercer algún tipo de censura para prohibir los vídeos y textos de propaganda enemiga, o limitar la difusión de información sobre una batalla perdida para no bajar la moral a la población.
En este sentido cabría pensar también el uso como herramienta de propaganda no sólo en conflictos internos sino en guerras extranjeras y países lejanos. La mayoría de los grandes centros de datos de redes sociales o buscadores está situado en territorio estadounidense o controlado desde allí, lo cual daría a ese país en caso de guerra severa la capacidad de controlar propaganda. El único recurso de un país enemigo sería cortar el acceso a Internet, algo muy eficaz y posible pero también cada vez más notorio y molesto a medida que se expande el uso de Internet. En Túnez pudimos ver algo de este estilo: el gobierno intervino los ISPs para que modificaran la página web de facebook e insertaran código que les permitiera conseguir las contraseñas de todos los ciudadanos (facebook respondió activando login con SSL por defecto).
En cualquier caso, el interés de un ejército para hacerse con el control de un centro de datos siempre va a estar ahí. Puede que no tenga mucha utilidad para ganar o perder una guerra directamente, pero algo que contiene un montón de información potencialmente útil siempre será atractivo. Y no hay mucho que la empresa dueña pueda hacer frente a un tanque. Además, gracias a que los Estados requieren legalmente a las compañías la habilidad de acceder a la información de los usuarios en caso de juicios o por motivos de (ejem) "seguridad nacional", la capacidad de acceder a los datos esta ahí. Y un programador con una pistola apuntándole en la cabeza podría ser muy imaginativo.
Quizás todo esto parezca demasiado de ciencia-ficción, debido a que todos rechazamos intuitivamente la posibilidad de que surja una guerra dentro los países que albergan la mayoría de las nubes: EEUU o Europa. Y es cierto que aunque nada asegura que un día de estos algún país salte por los aires (Yugoslavia), es bastante difícil que ocurra. Pero no deja de ser una posibilidad real a largo plazo, y un riesgo para otros países. Los grandes centros de datos de una nube suelen estar distribuidos por varios -cada vez más- lugares del mundo, y no necesariamente estables: por ejemplo, uno de los centros de datos de Google está en Taiwan, potencial fuente de conflicto con China.
Además, cuando hablamos de nubes no me refiero en particular a Google o Amazon, sino a las potenciales nubes locales que puedan surgir a lo largo y ancho del mundo a medida que la tecnología se abarate y extienda. No es cierto que Google/Amazon/Apple/Microsoft vayan a acaparar todo: el número de centros de datos empresariales o gubernamentales a medida se expandirá, así como los servicios que se ofrezcan y el número de usuarios que los usen. Imaginemos que Libia hubiera existido algún centro de datos con un "tuenti" local. ¿Se habrían privado los rebeldes de tomarlo por la fuerza y sacar toda la información que pudieran sobre el bando de Gaddafi?
En fin, no es que haya concretado muchas cosas en este post, pero creo que se entiende. Todo avance tecnológico que se utiliza para el bien puede utilizarse también para el mal, y eso incluye a las "nubes". Confiemos en que nunca tengamos que comprobarlo personalmente.
19 de abril de 2012
Corre la sangre
Que Nokia no pasa por sus mejores momentos es algo sabido, pero creo que
ni los más críticos esperábamos un hundimiento como este:
"Nokia lost €1.34bn on net sales of €7.35bn in the first three months of this year [...] Nokia's phones division saw revenue collapse from €7bn from the year-ago first quarter to €4.2bn in Q1 2012, and down 30 per cent from Q4 2011. Smartphone sales fell from 24.2 million a year ago to 11.2 million in Q1 2012."
¿Qué justificación da la compañía a estos resultados? En el caso de smartphones, se debe a "lower Symbian volumes in all regions, as well as lower seasonal demand for our products, which more than offset the sequential increase in Nokia Lumia device volumes". En el caso de teléfonos móviles normalitos, el reino de Symbian, a "increased competition from more affordable smartphones and competitors with broader portfolios of feature phones with more smartphone-like experiences, such as full touch devices".
Es decir, han vendido la mitad de smartphones que el mismo trimestre del año pasado, a pesar de que en este trimestre tenían ya a la venta dos teléfonos Lumia y en el anterior no - y esos eran el plan de rescate de emergencia.
Pero lo que más impresiona es la velocidad a la que está desapareciendo su bastión Symbian, que se mantenía fuerte en países en vías de desarrollo que no podían permitirse teléfonos caros: En China, han pasado de vender 23 millones de dispositivos en el primer trimestre del año pasado a 9 en este. Y estamos hablando de un país con 1.300 millones de habitantes, con pobres de sobra entre los que expandirse. Señal de que los teléfonos Android baratos (y cutres) son ya una realidad muy extendida y que Symbian puede darse por enterrado.
La conclusión de todas estas cifras es clara: Nokia se juega su existencia con el Lumia 900, el futuro 610, y los que vengan este año. Y lo malo es que, aunque tengan cierto éxito, es muy probable que no sea suficiente para sostener su actual estructura, que tendrá que reducirse para adaptarse a su papel de empresa finlandesa con muchas patentes que pone software estadounidense a hardware chino.
Y que conste que no negaré que es muy posible que Meego no hubiera evitado esta misma catástrofe.
"Nokia lost €1.34bn on net sales of €7.35bn in the first three months of this year [...] Nokia's phones division saw revenue collapse from €7bn from the year-ago first quarter to €4.2bn in Q1 2012, and down 30 per cent from Q4 2011. Smartphone sales fell from 24.2 million a year ago to 11.2 million in Q1 2012."
¿Qué justificación da la compañía a estos resultados? En el caso de smartphones, se debe a "lower Symbian volumes in all regions, as well as lower seasonal demand for our products, which more than offset the sequential increase in Nokia Lumia device volumes". En el caso de teléfonos móviles normalitos, el reino de Symbian, a "increased competition from more affordable smartphones and competitors with broader portfolios of feature phones with more smartphone-like experiences, such as full touch devices".
Es decir, han vendido la mitad de smartphones que el mismo trimestre del año pasado, a pesar de que en este trimestre tenían ya a la venta dos teléfonos Lumia y en el anterior no - y esos eran el plan de rescate de emergencia.
Pero lo que más impresiona es la velocidad a la que está desapareciendo su bastión Symbian, que se mantenía fuerte en países en vías de desarrollo que no podían permitirse teléfonos caros: En China, han pasado de vender 23 millones de dispositivos en el primer trimestre del año pasado a 9 en este. Y estamos hablando de un país con 1.300 millones de habitantes, con pobres de sobra entre los que expandirse. Señal de que los teléfonos Android baratos (y cutres) son ya una realidad muy extendida y que Symbian puede darse por enterrado.
La conclusión de todas estas cifras es clara: Nokia se juega su existencia con el Lumia 900, el futuro 610, y los que vengan este año. Y lo malo es que, aunque tengan cierto éxito, es muy probable que no sea suficiente para sostener su actual estructura, que tendrá que reducirse para adaptarse a su papel de empresa finlandesa con muchas patentes que pone software estadounidense a hardware chino.
Y que conste que no negaré que es muy posible que Meego no hubiera evitado esta misma catástrofe.
8 de abril de 2012
Microsoft da una lección: confía en iOS y Android
El New York Times se hace eco de la táctica que Microsoft está empleando para intentar atraer aplicaciones a Windows Phone: Sacar la abultada billetera y pagar a empresas para que porten aplicaciones exitosas de iPhone y Android a su sistema operativo.
Esta curiosa forma de ser premiado es una gran noticia para los desarrolladores...que desarrollan para iOS/Android. Si en cambio usted portó un programa exitoso a Windows Phone por iniciativa propia, no le agradará saber que por adelantarse ha perdido la oportunidad de recibir dinero. Y si está planeando portar una aplicación exitosa, pare y espere a ver si Microsoft le alarga un cheque. Y si es usted uno de los muchos que programaron en código nátivo (una manera de decir "no-.NET") para Windows Mobile, no sólo no recibirá ni un duro, sino que el código nativo sigue estando prohibido. ¡Quienes no confiaron en Microsoft han salido beneficiados!
Y claro, ¿en qué se invertirán los beneficios una vez terminado el port a Windows Phone? ¿En mejorar las aplicaciones de Android/iOS, que son las que más dinero no subvencionado les proporcionan, o las de Windows Phone? La moraleja de la historia está clara: La prioridad de un desarrollador debe ser Android/iOS, donde ganará dinero usando sus plataformas, y si tiene éxito le pagarán también por usar las de la competencia.
Una vez más, hay que recalcar la increíble estupidez que Microsoft cometió al crear un sistema operativo para móviles que prohibía con bastante arbitrariedad la reutilización de las enormes masas de código nativo de Windows Mobile y escritorio. Ahora, años después, parece que están cambiando de opinión, y debido al clamor popular empiezan a plantearse soportarlo. Resulta que existen motores gráficos de juegos, códecs y librerías varias que lo necesitan. ¡Oh, sorpresa! ¡Quien podría haber sospechado que habría desarrolladores para quienes esas cosas eran importantes!
Fíjense que entre las peticiones de los desarrolladores de Windows Phone más votadas está el soporte de QT. Ya saben, ese toolkit que su principal partner, Nokia, sigue usando como toolkit de referencia para Symbian. Uno esperaría que fuese Nokia la primera en solicitar esa funcionalidad en nombre de quienes aun confían en su plataforma. Incluso esperaría que lo hiciera la propia Microsoft por iniciativa propia, para atraer más aplicaciones. En cambio, son los programadores los que tienen que pedirlo de rodillas, y además de ser ignorados ahora tienen que contemplar como Microsoft regala dinero a los que apostaron por otras plataformas.
En fin, dentro de poco se pondrá a la venta el Lumia 900. Prácticamente todos los análisis que he leído lo ponen por las nubes, alabando la enorme calidad de Windows Phone y poniéndolo en muchos aspectos por delante de Android. Seguramente tienen razón. El problema es que eso también se decía con los anteriores Lumia, y no importó. El Lumia 900 no cambiará el panorama, porque con un sólo procesador, 512 MB de RAM y resolución baja comparada con otros móviles, está claro que es un teléfono que, sabiendo que no puede competir con los mejores teléfonos, intenta competir en precio con los del segmento medio. Y aunque por esa razón se venderá razonablemente bien, siempre habrá Androids más baratos que tienen más aplicaciones, y Androids e iPhones más caros que, por tener mejor hardware, ejecutan con más fluidez los juegos y aplicaciones más complejas. ¿Cree Microsoft que podrá encontrar un hueco en el mercado usando la billetera?
Esta curiosa forma de ser premiado es una gran noticia para los desarrolladores...que desarrollan para iOS/Android. Si en cambio usted portó un programa exitoso a Windows Phone por iniciativa propia, no le agradará saber que por adelantarse ha perdido la oportunidad de recibir dinero. Y si está planeando portar una aplicación exitosa, pare y espere a ver si Microsoft le alarga un cheque. Y si es usted uno de los muchos que programaron en código nátivo (una manera de decir "no-.NET") para Windows Mobile, no sólo no recibirá ni un duro, sino que el código nativo sigue estando prohibido. ¡Quienes no confiaron en Microsoft han salido beneficiados!
Y claro, ¿en qué se invertirán los beneficios una vez terminado el port a Windows Phone? ¿En mejorar las aplicaciones de Android/iOS, que son las que más dinero no subvencionado les proporcionan, o las de Windows Phone? La moraleja de la historia está clara: La prioridad de un desarrollador debe ser Android/iOS, donde ganará dinero usando sus plataformas, y si tiene éxito le pagarán también por usar las de la competencia.
Una vez más, hay que recalcar la increíble estupidez que Microsoft cometió al crear un sistema operativo para móviles que prohibía con bastante arbitrariedad la reutilización de las enormes masas de código nativo de Windows Mobile y escritorio. Ahora, años después, parece que están cambiando de opinión, y debido al clamor popular empiezan a plantearse soportarlo. Resulta que existen motores gráficos de juegos, códecs y librerías varias que lo necesitan. ¡Oh, sorpresa! ¡Quien podría haber sospechado que habría desarrolladores para quienes esas cosas eran importantes!
Fíjense que entre las peticiones de los desarrolladores de Windows Phone más votadas está el soporte de QT. Ya saben, ese toolkit que su principal partner, Nokia, sigue usando como toolkit de referencia para Symbian. Uno esperaría que fuese Nokia la primera en solicitar esa funcionalidad en nombre de quienes aun confían en su plataforma. Incluso esperaría que lo hiciera la propia Microsoft por iniciativa propia, para atraer más aplicaciones. En cambio, son los programadores los que tienen que pedirlo de rodillas, y además de ser ignorados ahora tienen que contemplar como Microsoft regala dinero a los que apostaron por otras plataformas.
En fin, dentro de poco se pondrá a la venta el Lumia 900. Prácticamente todos los análisis que he leído lo ponen por las nubes, alabando la enorme calidad de Windows Phone y poniéndolo en muchos aspectos por delante de Android. Seguramente tienen razón. El problema es que eso también se decía con los anteriores Lumia, y no importó. El Lumia 900 no cambiará el panorama, porque con un sólo procesador, 512 MB de RAM y resolución baja comparada con otros móviles, está claro que es un teléfono que, sabiendo que no puede competir con los mejores teléfonos, intenta competir en precio con los del segmento medio. Y aunque por esa razón se venderá razonablemente bien, siempre habrá Androids más baratos que tienen más aplicaciones, y Androids e iPhones más caros que, por tener mejor hardware, ejecutan con más fluidez los juegos y aplicaciones más complejas. ¿Cree Microsoft que podrá encontrar un hueco en el mercado usando la billetera?
6 de abril de 2012
Netcraft lo confirma, IIS lo está pasando mal
Hace bastante tiempo que no menciono las encuestas de Netcraft sobre el reparto de la tarta de los servidores web. Aquellos tiempos (2007) eran preocupantes porque Apache estaba sufriendo unas pérdidas que presagiaban el fin de su liderazgo: En sólo un par de años había pasado del 70% al 50% de cuota de mercado, con IIS como gran ganador, que en aquellos tiempos había empezado a dejar atrás su historial de patito feo en términos de rendimiento y seguridad.
La última encuesta muestra que las aguas acabaron volviendo a su cauce: IIS aguantó un par de años y desde entonces ha tenido una caída notablemente pronunciada y muy preocupante, hasta niveles de 1997, en tiempos de NT 4.0. Es más, en la categoría de "Sitios activos" fue sobrepasado por nginx en Enero.
Claro que esto puede que no preocupe demasiado a Microsoft que cada vez se centra más en las grandes compañías "Windows Shops" que pueden permitirse contratos suculentos, y cada vez menos en el pueblo llano, que no tiene ni un duro.
Por cierto, que algo interesante a observar a largo plazo será la evolución de nginx, a ver lo que vale el muy reciente Apache 2.4 y su Event MPM.
La última encuesta muestra que las aguas acabaron volviendo a su cauce: IIS aguantó un par de años y desde entonces ha tenido una caída notablemente pronunciada y muy preocupante, hasta niveles de 1997, en tiempos de NT 4.0. Es más, en la categoría de "Sitios activos" fue sobrepasado por nginx en Enero.
Claro que esto puede que no preocupe demasiado a Microsoft que cada vez se centra más en las grandes compañías "Windows Shops" que pueden permitirse contratos suculentos, y cada vez menos en el pueblo llano, que no tiene ni un duro.
Por cierto, que algo interesante a observar a largo plazo será la evolución de nginx, a ver lo que vale el muy reciente Apache 2.4 y su Event MPM.
3 de abril de 2012
Nuevos vientos en la glibc
LWN tiene un magnífico artículo (que no podrán leer hasta la semana que viene si no están suscritos, algo que recomiendo) sobre los cambios profundos que están teniendo lugar en la glibc. Básicamente, a partir de ahora van a ser un proyecto de software libre real, y no la dictadura de Ulrich Dreeper.
Ulrich Dreeper es un tipo paradójico: Es un genio en su campo, como lo demuestra este documento (que honra con creces su título), o sus artículos (varios publicados en las revistas de la ACM). Sin duda, uno de los grandes fichajes de Red Hat. Sin embargo, su actitud en la gestión de la comunidad hace que Jörg Schilling y Theo de Raadt parezcan gente simpática. Echen un ojo a este y este otro reporte de bug, ya considerados míticos. ¡Incluso hay un bug sobre su actitud!
La incapacidad de estos "genios desagradables" para colaborar con otros no sería un problema si se limitara a eso. El problema es que su infinito ego les lleva a tomar decisiones técnicas completamente estúpidas. Por ejemplo, Ulrich Dreeper es un fan del buen hardware y desprecia otras arquitecturas hasta el punto de llamar a ARM "embedded crap" y no aceptar parches que la soporten mejor, no soportar shells que no sean bash, no permitir la compilación cruzada, o negarse a incluir funciones que faciliten la creación de software más seguro, porque un buen programador debería ser capaz de vivir sin ellas.
Quizás su mayor error haya sido su negativa a permitir la adaptabilidad de la glibc a sistemas embebidos, a los cuales simplemente despreciaba. Y no estamos hablando de cosas excéntricas, sino de compilar la libc sin soporte de NIS, RPC, locales de idiomas que no se necesitan, soporte de red o APIs que existen por motivos de compatibilidad; o simplemente compilar con optimizaciones de tamaño -Os: ni tan siquiera estas cosas permitía Dreeper, para él sólo existían los servidores y escritorios potentes, y no tenías derecho a opinar otra cosa. Existen unas cuantas libcs optimizadas para sistemas embebidos (empezando por la de Android), sólo para suplir las carencias de la glibc. No existía ninguna razón para que fuese así, si Linux se adapta a sistemas embebidos bien puede hacerlo la glibc.
En fin, ahora Ulrich Dreeper se ha marchado a Goldman Sachs, como vicepresidente de su división de tecnología, seguramente a trabajar en high-frecuency trading, esa técnica oscura que consiste en poner montones de ordenadores que ejecutan órdenes de venta y compra automáticamente para forrarse. Es un campo donde la latencia es crítica: las firmas financieras se han gastado 300$ millones en instalar un cable entre la City y Wall Street para ganar cinco míseros milisegundos. Los profundos conocimientos de bajo nivel de Ulrich Dreeper les vendrán de perlas, sin duda.
Vaticino, por tanto, que se avecinan buenos tiempos para una de las piezas más críticas de un sistema Linux. De momento, parece que eglibc -proyecto que nació para proporcionar funcionalidad que Dreeper prohibía- será incluido en la libc principal. Esperemos que la FSF -a la que Dreeper odia, y que ha intentado arrebatarle el control del proyecto en el pasado- no cometa una de sus tradicionales meteduras de pata intentando entrometerse en la gestión de proyectos para cambiar las licencias o cosas así sin contar con los desarrolladores.
Ulrich Dreeper es un tipo paradójico: Es un genio en su campo, como lo demuestra este documento (que honra con creces su título), o sus artículos (varios publicados en las revistas de la ACM). Sin duda, uno de los grandes fichajes de Red Hat. Sin embargo, su actitud en la gestión de la comunidad hace que Jörg Schilling y Theo de Raadt parezcan gente simpática. Echen un ojo a este y este otro reporte de bug, ya considerados míticos. ¡Incluso hay un bug sobre su actitud!
La incapacidad de estos "genios desagradables" para colaborar con otros no sería un problema si se limitara a eso. El problema es que su infinito ego les lleva a tomar decisiones técnicas completamente estúpidas. Por ejemplo, Ulrich Dreeper es un fan del buen hardware y desprecia otras arquitecturas hasta el punto de llamar a ARM "embedded crap" y no aceptar parches que la soporten mejor, no soportar shells que no sean bash, no permitir la compilación cruzada, o negarse a incluir funciones que faciliten la creación de software más seguro, porque un buen programador debería ser capaz de vivir sin ellas.
Quizás su mayor error haya sido su negativa a permitir la adaptabilidad de la glibc a sistemas embebidos, a los cuales simplemente despreciaba. Y no estamos hablando de cosas excéntricas, sino de compilar la libc sin soporte de NIS, RPC, locales de idiomas que no se necesitan, soporte de red o APIs que existen por motivos de compatibilidad; o simplemente compilar con optimizaciones de tamaño -Os: ni tan siquiera estas cosas permitía Dreeper, para él sólo existían los servidores y escritorios potentes, y no tenías derecho a opinar otra cosa. Existen unas cuantas libcs optimizadas para sistemas embebidos (empezando por la de Android), sólo para suplir las carencias de la glibc. No existía ninguna razón para que fuese así, si Linux se adapta a sistemas embebidos bien puede hacerlo la glibc.
En fin, ahora Ulrich Dreeper se ha marchado a Goldman Sachs, como vicepresidente de su división de tecnología, seguramente a trabajar en high-frecuency trading, esa técnica oscura que consiste en poner montones de ordenadores que ejecutan órdenes de venta y compra automáticamente para forrarse. Es un campo donde la latencia es crítica: las firmas financieras se han gastado 300$ millones en instalar un cable entre la City y Wall Street para ganar cinco míseros milisegundos. Los profundos conocimientos de bajo nivel de Ulrich Dreeper les vendrán de perlas, sin duda.
Vaticino, por tanto, que se avecinan buenos tiempos para una de las piezas más críticas de un sistema Linux. De momento, parece que eglibc -proyecto que nació para proporcionar funcionalidad que Dreeper prohibía- será incluido en la libc principal. Esperemos que la FSF -a la que Dreeper odia, y que ha intentado arrebatarle el control del proyecto en el pasado- no cometa una de sus tradicionales meteduras de pata intentando entrometerse en la gestión de proyectos para cambiar las licencias o cosas así sin contar con los desarrolladores.
Suscribirse a:
Entradas (Atom)