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?
8 de abril de 2012
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)