Valve revela más detalles sobre las distros que usan actualmente Steam

Hace unos días Valve publicó los resultados de una encuesta que permitió conocer qué sistemas operativos y plataformas eran las más populares en el uso de Steam, y en ellas pudimos comprobar como el uso de Linux era de alrededor del 2%, una cifra destacable para el poco tiempo que este cliente llevaba disponible.

Ahora han aparecido más datos de esa encuesta, y es posible conocer qué distribuciones Linux hacen uso del cliente en mayor cantidad, algo que se puede desglosar en la propia encuesta al hacer clic en la barra titulada «February 2013 (click line item to see more detail)«. Al hacerlo aparecen todas las versiones de los sistemas operativos participantes.

En Phoronix se han dado cuenta de ello y han extraído los datos de las distribuciones Linux, que son los siguientes:

  • Ubuntu 12.10 64 bit: 0.71%
  • Ubuntu 12.10: 0.38%
  • Ubuntu 12.04.2 LTS 64 bit: 0.31%
  • Ubuntu 12.04.2 LTS: 0.20%
  • Linux Mint 14 Nadia 64 bit: 0.17%
  • Linux 64 bit: 0.14%
  • Ubuntu 12.04.1 LTS 64 bit: 0.11%
  • Ubuntu 12.04.1 LTS: 0.06%
  • Linux Mint 14 Nadia: 0.05%
  • «Arch Linux» 64 bit: 0.05%
  • Linux Mint 13 Maya 64 bit: 0.04%
  • Debian GNU/Linux 7.0 (wheezy) 64 bit: 0.03%
  • «Fedora release 18 (Spherical Cow)» 64 bit: 0.03%
  • «openSUSE 12.2 (x86_64)» 64 bit: 0.03%
  • Ubuntu Raring Ringtail (development branch) 64 bit: 0.02%
  • Linux: 0.02%
  • Linux Mint 13 Maya: 0.02%
  • «Gentoo Base System release 2.1» 64 bit: 0.01%
  • «Fedora release 17 (Beefy Miracle)» 64 bit: 0.01%
  • elementary OS Luna 64 bit: 0.01%
  • Ubuntu 12.04 LTS: 0.01%
  • Debian GNU/Linux 7.0 (wheezy): 0.01%
  • Ubuntu Raring Ringtail (development branch): 0.01%
  • Ubuntu 12.04 LTS 64 bit: 0.01%
  • «Gentoo Base System release 2.2» 64 bit: 0.01%
  • «Arch Linux»: 0.01%
  • «openSUSE 12.2 (i586)»: 0.01%
  • Linux 3.2 64 bit: 0.00%
  • «Manjaro Linux» 64 bit: 0.00%
  • Linux 3.2: 0.00%
  • elementary OS Luna: 0.00%
  • «NAME=Gentoo» 64 bit: 0.00%
  • Ubuntu-Secure-Remix 12.10 30nov2012 64 bit: 0.00%
  • «Chakra Linux» 64 bit: 0.00%
  • «Fedora release 18 (Spherical Cow)»: 0.00%
  • «Chakra» 64 bit: 0.00%
  • «Fedora release 17 (Beefy Miracle)»: 0.00%
  • Zorin OS 6 64 bit: 0.00%
  • Debian GNU/Linux testing (wheezy) 64 bit: 0.00%
  • «Sabayon Linux amd64 11» 64 bit: 0.00%
  • «Manjaro Linux»: 0.00%
  • Linux Mint 12 Lisa 64 bit: 0.00%

Como era de esperar, Ubuntu es la clara referencia, y el total ronda el 2,5% pero a buen seguro veremos muchos cambios y más y más cuota de Linux en este terreno en los próximos meses.

Preparándonos para la muerte de Google Reader: Lectores RSS para Linux

Probablemente hayáis leído algo sobre el anuncio de Google, que ha decidido cerrar más servicios que no considera útiles o rentables, y que en esta ronda (ya lleva 70 desde que inició este tipo de acciones) eliminará Google Reader el próximo 1 de julio de 2013. Los usuarios tienen acceso a alternativas desde hace mucho tiempo, pero con la noticia de que Google Reader dejará de estar disponible es el momento de refrescarlas.

Es lo que he hecho en Incognitosis, donde he recopilado algunos detalles sobre 53 de esas alternativas a Google Reader divididas en distintos grupos, como clientes de escritorio, clientes para móviles o servicios que debemos hospedar en nuestros servidores. En algunos blogs ya han hecho recopilatorio de clientes para Linux (que además pueden estar disponibles para otras plataformas), así que si estáis interesados, una buena lista de opciones para Linux es la siguiente:

Clientes Linux de escritorio

  1. Liferea
  2. Lightread
  3. Newsbeuter (consola)
  4. Snownews (consola)
  5. Canto (consola)
  6. Emacs con Gnus RSS (consola)
  7. Akregator
  8. QuiteRSS
  9. Raggle
  10. Rawdog
  11. RSSOwl
  12. Straw
  13. Plasma Widgets (el widget News soporta RSS)
  14. Blam
  15. Syndigator
  16. Krss
  17. Thunderbird

Extensiones para navegadores

  1. Brief (Firefox)
  2. Safe (Firefox)
  3. Feedly (Chrome, Firefox)
  4. Opera (el propio navegador)

Servicios a hospedar en tu servidor

  1. rss2email
  2. Tiny Tiny RSS
  3. Selfoss
  4. Lilina
  5. Managing News
  6. FreshRSS
  7. Leed

Si tenéis curiosidad, instalar esos servicios no es nada complicado, y podéis ver un ejemplo en mis pruebas preliminares, que también he publicado en Incognitosis. El resto de clientes son fácilmente configurables salvo quizás en soluciones de consola como Newsbeuter, Canto y Emacs con Gnus RSS. En el primer caso hay suerte, porque un usuario ha publicado un post para sacarle todo el partido a este lector de RSS desde la terminal de comandos.

Day of Defeat, Day of Defeat: Source, Half-Life 2: Deathmatch y Counter Strike Source, ¡en Steam para Linux!

El cliente de Steam para Linux desarrollado por Valve sigue dando grandes noticias a todos los linuxeros aficionados a los videojuegos, y poco a poco su catálogo se va llenando con nuevos títulos que cada vez son más importantes.

Así, en primer lugar tenemos como destacado a Counter Strike: Source (14,99 €), que apareció a finales del mes pasado en Steam y que por fin lleva toda la potencia del motor Source a este juego que tantas y tantas horas de entretenimiento ha proporcionado a sus millones de fans.

A él se le suman las incorporaciones de última hora: Half-Life 2: Deathmatch (3,99 €) también ha aparecido en la tienda, también basado en el motor Source (necesita Half-Life 2, eso sí), y también están en versión beta tanto Day of Defeat (3,99 €) como Day of Defeat: Source (7,99 €), los FPS ambientados en la segunda guerra mundial y que también se encuentran entre los más esperados entre los amantes del género.

Sigue así, Valve, sigue así 😉

 

Canonical y la comunidad de Ubuntu: ¿una relación condenada al fracaso?

Estas últimas semanas están pasando muchas cosas importantes en el seno de Canonical, la empresa responsable del desarrollo de Ubuntu. La comunidad no está contenta, y no lo está desde hace tiempo. El primer signo de ese descontento llegó con Unity, una interfaz que por primera vez hizo sentirnos incómodos. Entonces no sabíamos a qué venía ese cambio. Puede que ni siquiera Shuttleworth y sus chicos lo supieran. Y entonces llegó el anuncio:

Cuando llegue la 14.04 LTS Ubuntu se usará en tablets, móviles, TVs y pantallas inteligentes que van del coche a la cocina, y conectará esos dispositivos de forma limpia y transparente al escritorio, el servidor y la nube.

Aquella fue la expresión de la epifanía de Shuttleworth. De su visión de futuro. Una visión que parecía ambiciosa, pero no tan ambiciosa como ha resultado ser gradualmente. Porque esa vocación de Ubuntu de convertirse en algo que pudiéramos usar en todo tipo de dispositivos no era lo único importante. La otra parte de la ecuación era aún más significativa.

Que la versión de Ubuntu que usásemos en un dispositivo sería exactamente igual al resto.

Eso era (es) lo realmente importante. Ubuntu permitirá que tu smartphone basado en esta distribución se convierta de buenas a primeras en tu PC. Misma plataforma, misma interfaz (que eso sí, aprovechará la resolución de pantalla), y sobre todo, mismo catálogo de aplicaciones. Una idea genial que hasta ahora nadie había enfocado con tanta claridad.

Pero las visiones tienen un problema: que no todos las comparten. Ubuntu nació con aquella frase autodefinitoria: «Linux for Human Beings«, pero poco a poco fue desmarcándose de algunos de sus principios. Hoy en día es difícil encontrar la palabra «Linux» en el sitio web de Canonical (salvo cuando hablan del kernel Linux en su sección de soporte), y muchos vemos sombras en la filosofía de esta empresa. Su inclusión de los resultados de búsqueda de Amazon, el hecho de que Unity no se use en ninguna otra distribución Linux, o de que Ubuntu One tenga clientes para Windows y Mac OS X pero no para otras distribuciones Linux (de nuevo) genera dudas. Sombras.

Esas sombras crecían. Y distribuciones como Linux Mint aprovechaban el momento para convencer a ubunteros despechados con una distribución que mantenía y mejoraba todo lo que esos usuarios echaban de menos en Ubuntu. Canonical ya no molaba tanto. No parecía escuchar a la comunidad. Y aquel comentario de Shuttleworth en marzo de 2010 dejaba las cosas claras:

Esto no es una democracia. Bienvenidos sean los buenos comentarios y los buenos datos. Pero no estamos votando sobre decisiones de diseño..

El creador de Canonical y de Ubuntu, que se había proclamado como «dictador benévolo» de su proyecto, ya no parecía tan benévolo. Y lo confirmaba en los términos oficiales de gobierno de Ubuntu:

Esto no es una democracia. Es una meritocracia. Tratamos de operar más sobre el consenso que sobre las votaciones, buscando que la gente que se encargará de hacer el trabajo esté de acuerdo.

Y en esas estábamos cuando a principios de año en Canonical anunciaban la llegada de Ubuntu for phones y, pocas semanas después, de Ubuntu on tablets. Dos patas de esa mesa que también estaría sostenida por Ubuntu en el escritorio (la distro actual para PCs y portátiles) y por Ubuntu en la televisión, à la Google TV, la única que aún queda por mostrar más sobre sí misma. Pero ni siquiera hace falta que muestren esta última pata. Canonical y Shuttleworth ya han comenzado a convencer a los que no teníamos esa visión tan clara. El problema no está en que uno comparta (como es mi caso) o no esa visión. El problema es que para hacerla realidad han fallado en algunas cosas. Y probablemente una de ellas ha sido la forma de comunicarselo a la comunidad.

De ello no solo se han quejado los usuarios, sino que la tormenta se ha producido por las quejas de gente importante en la comunidad de Ubuntu. Gente que ha trabajado mucho y muy duro tanto en el proyecto matriz como en proyectos derivados. Los mejores ejemplos los tenemos en algunos de los principales implicados en el desarrollo de KDE y de Kubuntu. Aaron Seigo (leyenda en KDE) ha criticado desde hace semanas los fallos en la forma de comunicar sus novedades que tiene Canonical y su dudosa nueva (¿o vieja?) forma de hacer las cosas:

El mayor problema que veo es que van a ir a por ello [esa plataforma única] por su cuenta y van a diferenciarse del resto del ecosistema del software libre con una pila software que han estado desarrollando en secreto y que te obligará a aceptar sus términos para que puedas contribuir a ella. 

De hecho han cerrado las puertas al resto del mundo del software libre. Asumirán que tienen que trasladar y mantener cosas como Qt, Gtk+, XUL, etc a su sistema. Asumirán que tienen que trasladar aplicaciones a ciertos puntos de integración (la mayoría de los cuales serán ofrecidos en aplicaciones Qt). No compartirán la infraestructura del shell de escritorio con nadie más, y usar su software libre en otras plataformas se convertirá en algo cada vez más difícil.

A ese comentario en su cuenta de Google+ se le suman otros, pero las críticas de Seigo son claras: la decisión de Canonical de desarrollar su propio servidor gráfico, Mir, en lugar de usar Wayland o el actual X.Org, -el otro anuncio relevante de estos días- es errónea desde el punto de vista técnico (un servidor gráfico es uno de los componentes más complejos que existen), pero es aún más errónea desde el punto de vista de la comunicación y la actitud de una empresa que parece contar cada vez menos con la comunidad.

Ese desmarque por la banda de Canonical también ha sido criticado por uno de los responsables del desarrollo de KWin (el gestor de ventanas de KDE). Martin Gräßlin escribía en su propio blog un post al respecto del de Shuttleworth y su «All the faces of Ubuntu«. Allí el creador de Canonical aseguraba que KWin funcionaría perfectamente en Mir, como señalando implícitamente que los desarrolladores de Kubuntu se pondrían manos a la obra. Pero Gräßlin tenía otra opinión, y la expresó claramente en su post, con algunos puntos aplastantes:

  • No tienen ni idea de cómo implementar KWin
  • Actualmente el número de commits a KWin por empleados de Canonical es 0
  • Ningún empleado de Canonical ha contactado a estas alturas con el equipo de KWin sobre cómo podríamos integrar Mir o si estaríamos interesados en ello.
  • Debo cuestionar la capacidad de Canonical para juzgar lo que otro software puede o no puede hacer después de los inexistentes problemas que Canonical afirma que tiene Wayland y que Mir no tendrá.

Y a esas se suman también las de Jonathan Ridell, principal responsable de Kubuntu, que tras tantos cambios y tantas decisiones tomadas a espaldas de la comunidad se ha hartado y ha dejado claro opinaba como Martin Owens (otro desarrollador de Ubuntu) que a estas alturas será mejor que muchos usuarios de Ubuntu pasen de una Canonical que a su vez pasa de ellos, aunque luego clarificó ese primer post con otro en el que, eso sí, se mantenía en sus trece sobre sus conclusiones originales:

Si quieres tener un papel importante como coaborador entonces Ubuntu Unity no es el mejor proyecto al que dedicarte. Es perfecto puesto que hay muchos proyectos que están esperando que más gente ayude, yo recomiendo Kubuntu pero hay docenas de otras variantes [distribuciones] y sub-proyectos esperandoos con los brazos abiertos.

Y en respuesta, Shuttleworth escribió a su vez un post en el que con un tono algo menos distendido le explicaba a Ridell que su actitud cizañera (mis palabras, no las suyas) no ayudaba demasiado:

Canonical, como depositaria de la comunidad Ubuntu, está invirtiendo un montón de energía en evaluar como sus acciones pueden afectar al resto de depositarios, y en ofrecerles formas de ayudar con su trabajo a las necesidades del resto de depositarios del proyecto.

Tú, como depositario de la comunidad Ubuntu, estás invitando ala gente a colaborar menos con este proyecto general, y colaborar más con un único depositario [con Kubuntu].

Hmm. Que no consigas lo que quieres no debería hacer que promociones un liderazgo dividido.

Ese ha sido uno de los primeros momentos en los que se ha visto a Shuttleworth perder un poquito los nervios. El otro, escrito justo después en respuesta a otro desarrollador de Kubuntu que apoyaba a Ridell, lo dejaba aún más claro. Y cito de nuevo a Shuttleworth:

Así que antes de marcharte furioso, tómate una taza de té y piensa sobre lo que das y recibes de nuestra relación. De verdad. 

Los calentones parecen estar siendo numerosos en toda la comunidad, aunque parece que han sido los desarrolladores de Kubuntu los que más se han esforzado en expresarlos, pero al rescate trataba de llegar Jono Bacon, community manager de Ubuntu, que se ponía en su papel y lanzaba hoy mismo un mensaje conciliador pero en el que dejaba claro que Canonical se quiere diferenciar de lo que existía hasta ahora en el mundo Linux:

Necesitamos cuestionar constantemente nuestro statu quo… no por el simple hecho de ser distintos, sino por el hecho de no ceñirnos únicamente a la tradición, ayudándonos a nosotros mismos a ser mejores en lo que hacemos, y en último término a conseguir el objetivo de llevar Ubuntu a las manos de más gente.

Ese párrafo de Bacon resumen en mi opinión algo que muchos no saben o no quieren ver. Ubuntu no quiere ser una distribución Linux. Quiere ser mucho más. Y si para ello tiene que iniciar proyectos propios, adoptar una filosofía «menos abierta» y provocar que parte de su comunidad abandone el barco, que así sea.

Los comentarios en ese mismo post de Jono Bacon son igualmente esclarecedores. En uno de ellos, un usuario apunta a una primera verdad evidente:

Uno de los problemas de construir una gran comunidad diversa es que esa comunidad que construyes es grande y diversa. Cuando más grande y más diversa es esa comunidad, más intentan los extremos desplazar al centro de esa comunidad. 

Pero el mejor comentario, que traduzco íntegramente a continuación, es especialmente brillante, y en realidad serviría como auténtico corolario de todo lo que ha pasado estas últimas semanas:

El problema, al menos para mi, es que todas las «grandes» decisiones se están realizando en secreto y de forma externa a la comunidad de desarrolladores que ha ayudado a que Ubuntu crezca y sea lo que es hoy. 

Cada pocas semanas hay una polémica porque se ha tomado una decisión que no tiene sentido, y las razones que se dan para haberla tomado solo suenan a excusa. Si se toma una decisión por dinero, dilo, no te enrolles y no trates de engañarnos. 

No me sorprendería que Mir fuese un prerequisito para algún producto de Canonical aún sin anunciar en el que están trabajando – y por supuesto solo lo sabremos cuando sea demasiado tarde para dar cualquier tipo de opinión. 

Básicamente, Canonical necesita darse cuenta de que no puedes dejar fuera del ciclo a la comunidad si quieres que la comunidad esté contenta. Eso solo resulta en una falta de confianza entre Canonical y todo el resto de la comunidad Open Source. 

Así es. La comunidad se siente excluida del proceso de toma de decisiones de Canonical, y eso les jode. Lógicamente. A mi también me provocaría ese sentimiento. Y sin embargo, ¿podría una visión como la de Mark Shuttleworth avanzar si la comunidad tuviera poder de decisión sobre la forma de trabajar en Ubuntu?

Lo dudo. Shuttleworth siempre ha tenido cierto tinte ‘stevejobsiano‘, pero comparto con él la mayor parte de su forma de hacer las cosas. Lamentablemente, la comunicación con la comunidad dista mucho de ser perfecta. Y ese es probablemente el único gran problema que sí podrían resolver en Canonical. El resto, que a ciertos miembros de la comunidad no les guste Mir, o Unity, o el ciclo de desarrollo de Ubuntu, no es algo sobre lo que realmente puedan opinar. Porque si lo hiciesen Ubuntu no iría a ninguna parte. Se quedaría como está. Y eso es lo que precisamente Shuttleworth y Canonical no quieren.

Miguel de Icaza se pasa al Mac, so what?

Probablemente todos los que uséis Linux hayáis leído algo u oído hablar de Miguel de Icaza, un desarrollador software que creó proyectos como GNOME junto a Federico Mena y que también ha sido el responsable de la creación de la plataforma Mono, la implementación Open Source del framework .NET de Microsoft.

De Icaza escribió hace un par de días un artículo en su blog en el que explicaba cómo a pesar de haber invertido «años de mi vida en el escritorio Linux» ha tomado la decisión de dejar en segundo plano Linux para centrar toda su actividad diaria en los Mac y en Mac OS X.

Las razones de De Icaza son claras, y explicaba cómo en un viaje de vacaciones que hizo a Brasil en 2008 se llevó un Mac para comprobar cómo se comportaría. Y parece que no le defraudó en absoluto:

«En lo que respecta a la informática, resulta que esas tres semanas fueron muy relajantes. La máquina entraba en suspensión y reiniciaba la sesión sin problemas, la conectividad WiFi funcionaba sin más, el sonido no dejaba de funcionar, y pasé tres semanas sin tener que recompilar el kernel o ajustar esto o lo otro, sin tener que luchar con los controladores gráficos, o luchar con la extraña y aleatoria degradación de potencia que sufría mi ThinkPad«.

Aquel experimento le hizo usar el Mac cada vez más a menudo, y en octubre de 2012, tras mudarse a su nuevo apartamento, ni siquiera volvió a conectar el ordenador que usaba con Linux. «Para mi la fragmentación de Linux como plataforma, las múltiples e incompatibles distribuciones, y las incompatibilidades que existen en distintas versiones de la misma distro se convirtieron en mi Isla de las Tres Millas/Chernobyl«, añadía en su blog.

Lo cierto es que las razones de Icaza son perfectamente respetables: Linux no es perfecto. Pero tampoco lo es OS X. O como diría Robin Williams en «El Indomable Will Hunting»

You’re not perfect, sport.
And let me save you the suspense. This girl you met, she isn’t perfect either.
But the question is: whether or not you’re perfect for each other. That’s the whole deal.

Así es. Lo importante es que sea perfecto para ti (aunque sea un sistema operativo, o una máquina). ¿Hay fragmentación en Linux? Por supuesto. Precisamente esa fragmentación es una seña de su identidad, consecuencia directa de la filosofía Open Source, del hágaselo usted mismo. ¿Me gusta que haya 500 distribuciones Linux, cada una de su padre y de su madre? No, porque creo sinceramente que la unión (al menos, cierta unión) hace la fuerza. Pero eso no significa que cada una de ellas no tenga sentido para quienes las han creado. Esa gente que ha tenido la posibilidad de coger una idea, adaptarla a sus necesidades, y compartirla por si alguien más quería aprovecharse de ese esfuerzo. Intente hacer eso con OS X o Windows, Sr. De Icaza.

Por supuesto que los Mac funcionan razonablemente bien. Hay un escaso puñado de configuraciones hardware posibles que controlar, una sola plataforma software, y una filosofía en la que salirse de lo establecido se paga con el ostracismo. Y eso no quiere decir que los Mac y OS X sean el demonio. Yo mismo tengo un MacBook Air con el que estoy encantado y que efectivamente funciona fantásticamente. Pero lo uso de forma indistinta con otros equipos con Linux o con Windows, según la ocasión y según mis preferencias en cada momento. Y me parece perfecto hacerlo así, como me parece perfecto que De Icaza explique sus argumentos que se resumen en una sola cosa.

Que el Mac le simplifica la vida. Punto pelota. So what?

Este post está dedicado especialmente a mi hasta hace poco compañero de batalla Metalbyte, que recibió una crítica muy poco educada de Miguel de Icaza a su algo desafortunado (por algún que otro desliz) post en MuyLinux.

Pero como corregirse es de sabios, Metalbyte no solo editó el artículo, sino que escribió una carta abierta a este desarrollador con toda la educación que le faltó a este último. Se puede estar equivocado, y se puede no estar de acuerdo con las ideas de los demás, pero lo que no se puede hacer es caer en la descalificación y la mala educación, algo que es especialmente más peligroso cuando alguien es relativamente conocido como el Sr. De Icaza. Minipunto y punto para mi compi. Bien por ti, Metalbyte.

(Créditos de la imagen: Brad Wilson en Flickr)

Linus Torvalds: «Esto no es un concurso de chupar p*****»

No hace falta desvelar lo que esconden los asteriscos, porque viniendo de Linus Torvalds estas declaraciones son ya algo habitual. El creador del kernel Linux no suele cortarse a la hora de expresar sus opiniones allá donde interviene, y en esta ocasión ha realizado un comentario tajante al entrar en una discusión sobre la forma de dar soporte a la tecnología Secure Boot.

Como señalan en Muktware, Uno de los desarrolladores de Red Hat le preguntó a Linus si podría incluir un parche para dar soporte a la tecnología Secure Boot:

«¿Puedes hacer un pull de este conjunto de parches, por favor?

Proporcionan la capacidad por la cual las claves se pueden añadir de forma dinámica a un kernel que esté funcionando en modo Secure Boot. Para permitir que se cargue una clave en tales condiciones, necesitamos que la clave esté firmada a su vez por otra clave que ya tenemos (y en la que confiamos), donde las claves que «ya tenemos» podrían incluir las que están embebidas en el kernel, las que están en la base de datos UEFI y las que están en el hardware criptográfico». 

Pero Linus le contestó afirmando que el parche no podía ser incluido:

«No sin un montón de debate adicional. Francamente, esto es jodidamente estúpido. Todo esto parece estar diseñado sobre una serie de estúpidas interfaces por razones completamente tontas. ¿Por qué deberíamos hacer esto? Ni siquiera me gusta nuestro parser X.509. Y eso hace que las interfaces sean complicadas e idiotas, y ya han llegado a ser 11».

Matthew Garret, ex-empleado de Red Hat y autor del controlador universal de los PCs con UEFI Secure Boot, entró también a comentar:

«Solo hay una autoridad que firma esas claves, y solo firma binarios PE».

Lo que hizo que Linus explotara del todo (con razón, tal y como revelan en Muktware), ya que dejó claro lo que opinaba sobre este tema:

«Chicos, este no es un concurso de chupar p*****. Si quieres parsear binarios PE, adelante. 

Si Red Hat quiere hacerle una m**** a Microsoft, es vuestro problema. No tiene nada que hacer con las tareas de mantenimiento del núcleo. Para vosotros es trivial tener una máquina que firme y haga el parsing del binario PE, verifique las firmas, y firme las claves resultantes con vuestra propia clave. Ya habéis escrito el código para ello, por dios bendito, es lo que hay en esa jodida petición de pull.

¿Por qué debería importarme? ¿Por qué debería el kernel ocuparse de esa estupidez del «Solo firmamos binarios PE»? Damos soporte a X.509, que es el estándar para las firmas digitales.

Haced esto en el espacio de usuario en una máquina en la que confiéis. No hay excusa para hacerlo en el kernel».

Otros desarrolladores veteranos como Theodore Ts’o (responsable de ext4) apoyaron a Linus en el debate, y dejaron claro que este tipo de parches no deberían aplicarse al kernel. Ahora queda por ver cuál es la decisión final, pero todo apunta a que los parches propuestos no formarán parte del núcleo Linux.

Chrome OS estaba originalmente basado en… Firefox

Curiosas las declaraciones del ex-ingeniero de Google, Jeff Nelson, que ya hace unos meses publicó un post en su blog en el que da muchos detalles sobre los orígenes de Chrome OS, el sistema operativo de Google que está totalmente enfocado en la nube y que está presente en los equipos Chromebooks de algunos fabricantes.

Es bien sabido que tanto Chromium OS como Chrome OS se basan en Linux, y de hecho incluso Canonical ayudó a sentar las bases del sistema operativo de Google, pero entre los detalles que destaca Nelson destaca uno: que las primeras versiones de Chrome OS estaban basadas en Mozilla Firefox.

«Google OS no se escribió originalmente para Chrome ni se llamó ‘Chrome OS’. Todas las primeras versiones estaban basadas en Firefox. Cuando escribí la primera versión en 2006, Google aún no había comenzado a desarrollar un navegador propio, ni tenía ‘Chrome’ como nombre para ningún producto. Las versiones con Chrome comenzaron a aparecer en 2007, después de que las primeras versiones beta de pruebas de Chrome comenzaran a extenderse internamente en Google».

Otra de las curiosidades fue la que afecta a los Chromebooks, un concepto de portátiles «siempre conectados» que no tuvo un buen recibimiento en Google. El jefe de Nelson indicó que un Chromebook «no se podría usar en un avión», pero como señala Nelson «en realidad, sí que podrías, ya que bajo la cubierta seguía siendo una distribución Linux y podías ejecutar cualquier programa Linux instalado en él».

Una interesante visión por alguien que estuvo totalmente implicado en el proyecto, desde luego. Tenéis el post completo aquí.

Bienvenidos a Osphérica

Hoy sale a la luz Osphérica, un pequeño proyecto personal en el que trataré de mantener la línea que seguía en mi querido MuyLinux -que queda en buenas manos- y en el que si todo va como espero podré aportar unas cuantas ideas que por falta de tiempo o recursos nunca he podido hacer que cristalizasen. Mi cambio de rumbo personal y profesional ha motivado este pequeño experimento, y si la cosa sale la mitad de bien de lo que salió con ML estaré encantado.

Osphérica nace de forma modesta, y de hecho al blog aún le quedan muchos ajustes finos, así que si detectáis cualquier fallo o tenéis sugerencias sobre el sitio o sobre los contenidos a cubrir, os ruego que me las comuniquéis a traves de la página de contacto o del sencillo formulario de la barra lateral («Qué se nos ha pasado?»). La idea es ir puliendo todos esos fallos y convertir a Ospherica en un buen punto de encuentro para todos los que sois usuarios o como mínimo observadores de lo que ocurre en el mundo Open Source y en el mundo de GNU/Linux y del software libre.

Asi pues, ¡bienvenidos a Osphérica!