A Ubuntu le está cayendo una buena tormenta de críticas por hacer que Unity integre por defecto búsquedas en la tienda de Amazon. ¿La razón? Privacidad del usuario. Mark Shuttleworth ha salido a defenderlo, argumentando que no afecta a la privacidad porque las búsquedas no se hacen directamente a Amazon sino a través de los servidores de Canonical, tras filtrar los detalles de los usuarios; o que se puede eliminar esta funcionalidad eliminado un paquete, pero no le ha servido de mucho.
A mi esta tormenta me parece una reacción exagerada. Si están preocupados por su privacidad, creo que se han perdido una noticia bastante aterradora: Ubuntu utiliza Firefox con Google como buscador por defecto, a cambio de dinero por cada búsqueda. Si tienen remordimientos por enviar información personal a empresas, deberían preocuparse bastante más por Google que por unas búsquedas de Amazon anonimizadas de antemano. Y si no utilizan complementos como ghostery (firefox, chrome), directamente deberían ponerse a correr en círculos dando gritos.
Más allá de la cuestión de la privacidad, insertar estos resultados no me parece una una mala idea. En un mundo ideal, la gente debería poder comprar contenidos multimedia legalmente a golpe de click y sin demasiados mareos. Aunque esta funcionalidad no llega tan lejos, lo acerca considerablemente, y aunque a mucha gente "geek" no le guste, es la clase de cosas que a la gente "normal" -la mayoría de la población- si que puede gustarle. La idea de tener una especie de Google bien integrado en el sistema operativo para facilitar la vida a la gente es muy atractiva y abre la puerta a muchas posibilidades.
En resumen, que Ubuntu está intentando simplificar el acceso a contenidos y no ha empeorado la privacidad más de lo que ya lo hace, pero aun así no dejarán de caerle críticas. Estoy seguro que dentro de un año nadie se acordará de estas cosas.
24 de septiembre de 2012
1 de septiembre de 2012
Lo que no mató a Linux en el escritorio
Miguel de Icaza ha escrito un post, titulado "What killed the Linux Desktop", que ha hecho cierto ruido. Como me va la marcha, voy a comentarlo un poco.
El post comienza contando la instalación de un nuevo disco duro. Llegado al punto de conectar a los altavoces, Icaza piensa esto:
"[...] when I got to the speakers cable, I just skipped it. Why bother setting up the audio? It will likely break again and will force me to go on a hunting expedition to find out more than I ever wanted to know about the new audio system and the drivers technology we are using"
Tan autocríticos somos en el mundo del software libre, que no contentos con quejarnos de los problemas que tenemos, también nos quejamos de los problemas que sospechamos que podríamos tener. ¿No enchufar el cable de sonido sólo porque "probablemente" no funcionará?
La verdad es que nunca he entendido la obsesión que hay con el tema del sonido y su supuesta inestabilidad. Linux 2.6.0 incorporó ALSA hace ya casi 9 años, que además se proporcionaba compatibilidad con la anterior API, OSS. ¿Dónde está el infierno de cambios y reescrituras? Desde aquello el único gran cambio ha sido Pulseaudio, que causó cierto impacto, fundamentalmente por la baja calidad de drivers y de la implementación de sonido del plugin de Flash, que ya han sido resueltos. Pero de eso ya han pasado 4 años y medio. A día de hoy hay gente que usa cascos bluetooth en Linux sin muchos más problemas que los que sufren algunos usuarios de Windows cuando tienen que andar lidiando con software de bluetooth de escandalosamente baja calidad proporcionado por el fabricante. Pero sigamos:
"Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers."
Este mito estúpido de que en el kernel la compatibilidad binaria no importa empieza a ser cansino. Linux mantiene la compatibilidad binaria en las llamadas al sistema. Que es, al fin y al cabo, lo que tiene que ofrecer todo sistema operativo al mundo, y que es lo que verdaderamente importa. Es más, no sólo la mantiene, sino que la mantiene mejor que las librerías. En todos estos años, Linux no ha cambiado la compatibilidad binaria de las llamadas al sistema ni una sola vez.
Existe cierta obsesión con que esto mismo debería aplicarse con los drivers, que son en realidad plugins del kernel, y no aplicaciones construidas encima de una libreria. La verdad, no entiendo por qué. Desdeñar la participación privativa en materia de drivers fue algo arriesgado, pero ha tenido éxito. Linux tiene un soporte de hardware de consumo muy bueno, hay varios fabricantes importantes que facilitan ellos mismos los drivers libres, y el hardware que no se soporta es minoría. ¿A alguien le parece razonable obsesionarse con facilitar el trabajo de los drivers propietarios para agradar a minorías, en lugar de apostar por el sistema que ha proporcionado mejores resultados hasta hoy? Eso por no mencionar las consecuencias para el kernel de limitar su capacidad de evolución interna.
"The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees"
No deja de ser curioso que esto lo diga alguien que ha dedicado muchos años a implementar una tecnología que en el universo Microsoft representa exactamente ese espíritu de mandarlo todo a paseo y empezar de cero, como bien dijo Joel Spolski. ¿Recuerdan Silverlight y su intento de reinventar nada menos que la web, recuerdan como Mono lo copio con su Moonlight, y como ahora han tenido que dejar de darle soporte porque ni Microsoft apuesta por ello? Es una definición perfecta de reinventar por reinventar. Por no hablar de Windows Phone 7, que mandó a paseo gran parte del software disponible para Windows CE sólo para mayor gloria del imperio C#.
Pero respecto a Linux, al margen de que eso de que la compatibilidad se rompe constantemente y es imposible desarrollar nada está muy exagerada, lo cierto es que la búsqueda de la excelencia técnica fue, es y seguirá siendo una característica muy deseable, muchas veces por encima de la compatibilidad. Linux ha sido un sistema operativo retrasado técnicamente en lo que al escritorio se refiere, por lo que la mejora técnica a base de reescrituras puede dar sensación de inestabilidad, pero también lo es de evolución. En realidad nadie puede evitarlo, incluso Microsoft rompió la compatibilidad binaria de los drivers de tarjetas de vídeo para rediseñar de cero un nuevo subsistema gráfico.
Si se paran a pensar, se darán cuenta que muchas de esas "obsesiones técnicas" nos han proporcionado beneficios a largo plazo. ¿Dónde estarían KDE y GNOME de haber tenido que conservar la compatibilidad con sus versiones 1.0? Además, dado que en Linux casi todo es software abierto, romper la compatibilidad es mucho más sencillo, y si una aplicación deja de poder usarse porque nadie se molesta en portarla a nuevas APIs, se puede afirmar que hay muchas posibilidades de que esa aplicación no merezca la pena y esté completamente desmantenida. Icaza menciona que en Windows 8 será posible utilizar el Photoshop que se publicó hace 8 años, pero cabría preguntarse si tiene tanto sentido dar prioridad a los que quieren utilizar software de hace 8 años.
The second dimension to the problem is that no two Linux distributions agreed on which core components the system should use
Red Hat tampoco se ha puesto de acuerdo con nadie para decidir qué componentes usar, y no parece haberles afectado demasiado. Una vez que una distro se hace un hueco en su campo, los fabricantes de software privativo no tienen problema en prestarle atención.
We alienated every third party developer in the process. The ecosystem that has sprung to life with Apple's OSX AppStore is just impossible to achieve with Linux today.
Quizás porque, en realidad, Linux nunca ha pretendido ser una plataforma donde el software propietario pudiese hacer su agosto, salvo excepciones. Siempre ha sido una plataforma en el que la prioridad la tiene el software libre. Si Linux ha de tener éxito entre desarrolladores de código propietario, no lo hará porque el ambiente de los proyectos libres sea tal o cual o la compatibilidad se rompa mucho o poco, lo hará gracias a que una empresa haga lo que Red Hat hizo en los servidores. Es decir, gracias a algo como Ubuntu/Canonical.
Y para terminar, hay que señalar que el post de Icaza habla en todo momento en un tono de "guerra perdida". Aun siendo una anécdota, el escritorio Linux nunca tuvo mejor posición que hoy, y el futuro es esperanzador. Ubuntu se ha convertido en una alternativa que la gente normal es capaz de usar e incluso disfrutar. Y aunque en materia de smartphones el software verdaderamente libre lo tiene de momento bastante negro, de cumplirse la analogía Jobsiana de los escritorios y los camiones, es previsible que las compañías comerciales se dediquen a los dispositivos móviles y que Linux empiece a campar por el escritorio con más comodidad.
El post comienza contando la instalación de un nuevo disco duro. Llegado al punto de conectar a los altavoces, Icaza piensa esto:
"[...] when I got to the speakers cable, I just skipped it. Why bother setting up the audio? It will likely break again and will force me to go on a hunting expedition to find out more than I ever wanted to know about the new audio system and the drivers technology we are using"
Tan autocríticos somos en el mundo del software libre, que no contentos con quejarnos de los problemas que tenemos, también nos quejamos de los problemas que sospechamos que podríamos tener. ¿No enchufar el cable de sonido sólo porque "probablemente" no funcionará?
La verdad es que nunca he entendido la obsesión que hay con el tema del sonido y su supuesta inestabilidad. Linux 2.6.0 incorporó ALSA hace ya casi 9 años, que además se proporcionaba compatibilidad con la anterior API, OSS. ¿Dónde está el infierno de cambios y reescrituras? Desde aquello el único gran cambio ha sido Pulseaudio, que causó cierto impacto, fundamentalmente por la baja calidad de drivers y de la implementación de sonido del plugin de Flash, que ya han sido resueltos. Pero de eso ya han pasado 4 años y medio. A día de hoy hay gente que usa cascos bluetooth en Linux sin muchos más problemas que los que sufren algunos usuarios de Windows cuando tienen que andar lidiando con software de bluetooth de escandalosamente baja calidad proporcionado por el fabricante. Pero sigamos:
"Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers."
Este mito estúpido de que en el kernel la compatibilidad binaria no importa empieza a ser cansino. Linux mantiene la compatibilidad binaria en las llamadas al sistema. Que es, al fin y al cabo, lo que tiene que ofrecer todo sistema operativo al mundo, y que es lo que verdaderamente importa. Es más, no sólo la mantiene, sino que la mantiene mejor que las librerías. En todos estos años, Linux no ha cambiado la compatibilidad binaria de las llamadas al sistema ni una sola vez.
Existe cierta obsesión con que esto mismo debería aplicarse con los drivers, que son en realidad plugins del kernel, y no aplicaciones construidas encima de una libreria. La verdad, no entiendo por qué. Desdeñar la participación privativa en materia de drivers fue algo arriesgado, pero ha tenido éxito. Linux tiene un soporte de hardware de consumo muy bueno, hay varios fabricantes importantes que facilitan ellos mismos los drivers libres, y el hardware que no se soporta es minoría. ¿A alguien le parece razonable obsesionarse con facilitar el trabajo de los drivers propietarios para agradar a minorías, en lugar de apostar por el sistema que ha proporcionado mejores resultados hasta hoy? Eso por no mencionar las consecuencias para el kernel de limitar su capacidad de evolución interna.
"The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees"
No deja de ser curioso que esto lo diga alguien que ha dedicado muchos años a implementar una tecnología que en el universo Microsoft representa exactamente ese espíritu de mandarlo todo a paseo y empezar de cero, como bien dijo Joel Spolski. ¿Recuerdan Silverlight y su intento de reinventar nada menos que la web, recuerdan como Mono lo copio con su Moonlight, y como ahora han tenido que dejar de darle soporte porque ni Microsoft apuesta por ello? Es una definición perfecta de reinventar por reinventar. Por no hablar de Windows Phone 7, que mandó a paseo gran parte del software disponible para Windows CE sólo para mayor gloria del imperio C#.
Pero respecto a Linux, al margen de que eso de que la compatibilidad se rompe constantemente y es imposible desarrollar nada está muy exagerada, lo cierto es que la búsqueda de la excelencia técnica fue, es y seguirá siendo una característica muy deseable, muchas veces por encima de la compatibilidad. Linux ha sido un sistema operativo retrasado técnicamente en lo que al escritorio se refiere, por lo que la mejora técnica a base de reescrituras puede dar sensación de inestabilidad, pero también lo es de evolución. En realidad nadie puede evitarlo, incluso Microsoft rompió la compatibilidad binaria de los drivers de tarjetas de vídeo para rediseñar de cero un nuevo subsistema gráfico.
Si se paran a pensar, se darán cuenta que muchas de esas "obsesiones técnicas" nos han proporcionado beneficios a largo plazo. ¿Dónde estarían KDE y GNOME de haber tenido que conservar la compatibilidad con sus versiones 1.0? Además, dado que en Linux casi todo es software abierto, romper la compatibilidad es mucho más sencillo, y si una aplicación deja de poder usarse porque nadie se molesta en portarla a nuevas APIs, se puede afirmar que hay muchas posibilidades de que esa aplicación no merezca la pena y esté completamente desmantenida. Icaza menciona que en Windows 8 será posible utilizar el Photoshop que se publicó hace 8 años, pero cabría preguntarse si tiene tanto sentido dar prioridad a los que quieren utilizar software de hace 8 años.
The second dimension to the problem is that no two Linux distributions agreed on which core components the system should use
Red Hat tampoco se ha puesto de acuerdo con nadie para decidir qué componentes usar, y no parece haberles afectado demasiado. Una vez que una distro se hace un hueco en su campo, los fabricantes de software privativo no tienen problema en prestarle atención.
We alienated every third party developer in the process. The ecosystem that has sprung to life with Apple's OSX AppStore is just impossible to achieve with Linux today.
Quizás porque, en realidad, Linux nunca ha pretendido ser una plataforma donde el software propietario pudiese hacer su agosto, salvo excepciones. Siempre ha sido una plataforma en el que la prioridad la tiene el software libre. Si Linux ha de tener éxito entre desarrolladores de código propietario, no lo hará porque el ambiente de los proyectos libres sea tal o cual o la compatibilidad se rompa mucho o poco, lo hará gracias a que una empresa haga lo que Red Hat hizo en los servidores. Es decir, gracias a algo como Ubuntu/Canonical.
Y para terminar, hay que señalar que el post de Icaza habla en todo momento en un tono de "guerra perdida". Aun siendo una anécdota, el escritorio Linux nunca tuvo mejor posición que hoy, y el futuro es esperanzador. Ubuntu se ha convertido en una alternativa que la gente normal es capaz de usar e incluso disfrutar. Y aunque en materia de smartphones el software verdaderamente libre lo tiene de momento bastante negro, de cumplirse la analogía Jobsiana de los escritorios y los camiones, es previsible que las compañías comerciales se dediquen a los dispositivos móviles y que Linux empiece a campar por el escritorio con más comodidad.
Suscribirse a:
Entradas (Atom)