En general, aplaudo cuando un gobernante defiende el uso de software libre en las administraciones: al fin y al cabo, todos sabemos a qué bolsillos van los ingresos de Microsoft u Oracle, y a nadie le gusta que un país tenga un déficit tecnológico horroroso. Y cuando se utiliza software libre en las clases de informática de los institutos, mi alegría se torna en éxtasis: ya he defendido aquí que el modelo actual por el que se dan clases de informática pagando licencias de Windows y Office es, sencillamente, una estafa. La educación pública se convierte así (y permítanme la diatriba) en un centro de formación de productos de empresas privadas financiado con dinero público, y del que se benefician, sobre todo, los accionistas de multinacionales extranjeras. Ya que se beneficiarán de que los alumnos sean educados para usar sus productos, como mínimo deberían regalar todas las licencias a los institutos, pero ni eso les exigen los gobernantes.
Dejando al lado este asunto, hay algo que cada vez me huele peor en el tema de las distribuciones regionales. Me refiero a esas distribuciones que tanto abundan en España. Y lo que huele mal es, precisamente, que haya tantas.
Es evidente que con semejante fragmentación, esto no avanza hacia ningún sitio. Hay gente que, por ejemplo, pretende en serio que los vendedores de ordenadores preinstalen Linex, la distribución de Extremadura, una región de poco más de 1 millón de habitantes. Si ya de por si resulta difícil que compañías como Dell lo hagan con Ubuntu para un mercado mundial, imagínense con Linex.
Otro argumento muy común a favor de estas distribuciones es que gracias al software libre se pueden contratar programadores y compañías locales, en lugar de depender de los de la multinacional de turno. Si bien esto es cierto (y es una de las mayores ventajas del software libre), es obvio que la fragmentación juega muy en contra de la estandarización. Ejemplo, pongamos que es usted un programador y crea un magnífico programa que por alguna razón la administración quiere comprar, pues si quiere extenderse a administraciones de más allá de su terruño tendrá que soportar todas distribuciones. Que puede merecer la pena económicamente, pero es un obstáculo más. Otro ejemplo: Trisquel, la distro de Galicia, tiene la particularidad de estar dirigidas por fanáticos del FSF que eliminan todo software que no cumpla las cuatro sagradas reglas de Stallman. Y olvidémonos de soporte comercial para el mercado de usuarios de escritorio.
Existe un espacio donde tal vez las distribuciones regionales tengan sentido, y es en la administración de sistemas de la administración (valga la redundancia). Los gobiernos regionales tienen sistemas informáticos propios lo suficientemente extensos y complejos como para poder beneficiarse de tener todo bajo control, sin embargo, este es un uso a nivel interno que a los ciudadanos no importa.
Más allá de este caso, ¿de verdad necesitan las escuelas de cada región una distribución educativa distinta?
Diría que hemos llegado a un punto en el que las distribuciones
regionales, más que un beneficio están suponiendo un obstáculo para el
progreso del software libre. En lugar de crear y mantener distribuciones onanistas, las administraciones deberían optar por cosas como debianedu, edubuntu, o directamente Ubuntu, o cosas así. No se trata de eliminar su inversión en software libre, sino de dirigirlo a proyectos más grandes, donde se pueda aunar esfuerzos con muchas otras personas, con muchas otras administraciones. Entre ayuntamientos, provincias, regiones y estados hay en Europa unas 200.000 administraciones, algo en común se podrá tener.
27 de diciembre de 2011
3 de diciembre de 2011
Trapos sucios de Unix: readdir()
Una de las cosas más curiosas de los sistemas Unix es cómo han ido cambiando su propia imagen a lo largo de los años. Hoy Unix se entiende como sinónimo de fiable, eficiente, buen diseño, profesional, etc; a pesar de que Unix era un sistema operativo muy simplista, con importantes fallos y carencias que tuvieron que arreglarse o añadirse posteriormente, a menudo no de la mejor manera. Un buen ejemplo de ello es la historia de readdir(), una función que devuelve la lista de archivos y/o subdirectorios presentes dentro de un directorio.
Uno de los principios fundamentales de la filosofía Unix es el de "Todo es un archivo", es decir, la unificación de toda clase de I/O sobre un sistema de archivos jerárquico en el que los archivos, además de archivos, pueden representar a dispositivos de hardware. Tal fuerza dogmática tiene este principio que cuando se diseñó Unix se decidió, o se asumió de manera natural, que los directorios también eran archivos normales y corrientes. Así que las primeras versiones de Unix no tenían llamadas al sistema para algo tan común como listar un directorio.
¿Cómo averiguaba entonces un programa, como por ejemplo ls, los contenidos de un directorio? Pues tratándolos literalmente como archivos. Se abría el directorio con fopen() y se leía el contenido con fread(). El contenido de los archivos de tipo directorio era simplemente una lista consecutiva de parejas nombre/número de inodo, cada una representando un archivo y/o subdirectorio. Y el programa tenía que echar un ojo a esas estructuras e interpretarlas él mismo para saber qué había dentro del directorio, no existía ninguna llamada al sistema que lo hiciera por ti.
Por esa razón, la primera función readdir() no fue una llamada al sistema, sino una función implementada dentro de los programas que lo necesitaban. Si no lo creen, pueden verlo ustedes mismos en la función readdir() del ls.c de Unix Version 7, de 1979. Cuando los diferentes sistemas Unix fueron incorporando características que hacían de esta manera de trabajar con directorios un inconveniente, acabaron añadiendo llamadas al sistema (getdents()) que sirvieran de ayuda para implementar readdir(), la cual se acabaría incorporando a la libc.
Como prueba de esta herencia, han quedado ciertos retazos en algunos sistemas Unix (por ejemplo, FreeBSD), en los que el comando cat directorio es un comando válido, que se ejecuta sin errores, e imprime en la pantalla algo que parece "basura" sin formato del tipo de /dev/random pero que, en realidad, es el contenido del directorio, tal y como ocurría en los Unix originales (en Linux esto no ocurre, se ha asumido que los directorios son directorios, y tratar de leer un directorio como archivo devuelve el error EISDIR).
Pero no se acaba aquí esta historia. Que el diseño original de Unix tuviera estos entresijos acabaría teniendo consecuencias que se heredaron con el tiempo, hasta llegar a hoy.
El hecho de que los directorios originales de Unix fueran simples concatenaciones lineales de parejas nombre/númerodeinodo hizo que las interfaces asumieran que el contenido de un directorio sería siempre lineal. De ese modo surgieron APIs como telldir(), la cual obtiene la posición de un elemento dentro del listado de un directorio. Esta posición puede utilizarse en seekdir() para mover un listado a una posición determinada del directorio. Es decir, se trata a un directorio como un archivo en el que un programa puede moverse de un lado a otro sin problemas.
Esto causó un gran problema con el advenimiento de los sistemas de archivos modernos, basados en estructuras de árbol. Las estructuras de árbol utilizadas en sistemas de archivo (B-Tree y similares) tienen como una de sus características fundamentales el rebalanceo para redistribuir los nodos del árbol a medida que se crean o eliminan archivos. Este rebalanceo puede cambiar el orden en el que un determinado elemento aparece en un listado de directorio, es decir, no se garantiza que usar seekdir() en una posición determinada dos veces consecutivas nos lleve al mismo elemento.
¿Que han hecho los sistemas de archivo Unix basados en B-Trees para lidiar con este problema? Esencialmente, tratar de parchear el problema (resolverlo no es posible, siempre habrá que mantener la compatibilidad con la tradición Unix). Por ejemplo, JFS tiene un B-Tree extra exclusivamente dedicado a mantener una doble indexación que permita satisfacer las garantías de readdir() y compañía. Btrfs, un sistema de archivos de última generación, también mantiene una doble indexación, por cada elemento añadido a un directorio se crean dos items: uno ordenado por hash y otro ordenado secuencialmente. Ext3/4 por su parte sólo ordena los elementos por hash, pero trata de mantener la secuencialidad leyendo los contenidos del directorio por el orden de hash.
Estas técnicas suponen, por supuesto, un trabajo y E/S extra que tiene un impacto en el rendimiento. ¡Ah, y por supuesto, la concepción lineal de los directorios implica que listarlos con readdir() y operar con ellos puede tener una complejidad algorítmica lineal! Así que resulta que Unix, culmen del buen diseño de sistemas operativos, implementa los directorios de una forma verdaderamente patética, y nos hacer pagar sus errores con impacto en el rendimiento (hay software que usa diferentes trucos para evitar acumular miles de archivos en un mismo directorio).
La lección de toda esta historia es que por muy genial que sea el diseño de tu software, obsesionarse con abstracciones perfectas e intentar imponerlas bajo la creencia de que su pureza es la única forma decente de hacer las cosas puede llegar a ser un gran error.
Uno de los principios fundamentales de la filosofía Unix es el de "Todo es un archivo", es decir, la unificación de toda clase de I/O sobre un sistema de archivos jerárquico en el que los archivos, además de archivos, pueden representar a dispositivos de hardware. Tal fuerza dogmática tiene este principio que cuando se diseñó Unix se decidió, o se asumió de manera natural, que los directorios también eran archivos normales y corrientes. Así que las primeras versiones de Unix no tenían llamadas al sistema para algo tan común como listar un directorio.
¿Cómo averiguaba entonces un programa, como por ejemplo ls, los contenidos de un directorio? Pues tratándolos literalmente como archivos. Se abría el directorio con fopen() y se leía el contenido con fread(). El contenido de los archivos de tipo directorio era simplemente una lista consecutiva de parejas nombre/número de inodo, cada una representando un archivo y/o subdirectorio. Y el programa tenía que echar un ojo a esas estructuras e interpretarlas él mismo para saber qué había dentro del directorio, no existía ninguna llamada al sistema que lo hiciera por ti.
Por esa razón, la primera función readdir() no fue una llamada al sistema, sino una función implementada dentro de los programas que lo necesitaban. Si no lo creen, pueden verlo ustedes mismos en la función readdir() del ls.c de Unix Version 7, de 1979. Cuando los diferentes sistemas Unix fueron incorporando características que hacían de esta manera de trabajar con directorios un inconveniente, acabaron añadiendo llamadas al sistema (getdents()) que sirvieran de ayuda para implementar readdir(), la cual se acabaría incorporando a la libc.
Como prueba de esta herencia, han quedado ciertos retazos en algunos sistemas Unix (por ejemplo, FreeBSD), en los que el comando cat directorio es un comando válido, que se ejecuta sin errores, e imprime en la pantalla algo que parece "basura" sin formato del tipo de /dev/random pero que, en realidad, es el contenido del directorio, tal y como ocurría en los Unix originales (en Linux esto no ocurre, se ha asumido que los directorios son directorios, y tratar de leer un directorio como archivo devuelve el error EISDIR).
Pero no se acaba aquí esta historia. Que el diseño original de Unix tuviera estos entresijos acabaría teniendo consecuencias que se heredaron con el tiempo, hasta llegar a hoy.
El hecho de que los directorios originales de Unix fueran simples concatenaciones lineales de parejas nombre/númerodeinodo hizo que las interfaces asumieran que el contenido de un directorio sería siempre lineal. De ese modo surgieron APIs como telldir(), la cual obtiene la posición de un elemento dentro del listado de un directorio. Esta posición puede utilizarse en seekdir() para mover un listado a una posición determinada del directorio. Es decir, se trata a un directorio como un archivo en el que un programa puede moverse de un lado a otro sin problemas.
Esto causó un gran problema con el advenimiento de los sistemas de archivos modernos, basados en estructuras de árbol. Las estructuras de árbol utilizadas en sistemas de archivo (B-Tree y similares) tienen como una de sus características fundamentales el rebalanceo para redistribuir los nodos del árbol a medida que se crean o eliminan archivos. Este rebalanceo puede cambiar el orden en el que un determinado elemento aparece en un listado de directorio, es decir, no se garantiza que usar seekdir() en una posición determinada dos veces consecutivas nos lleve al mismo elemento.
¿Que han hecho los sistemas de archivo Unix basados en B-Trees para lidiar con este problema? Esencialmente, tratar de parchear el problema (resolverlo no es posible, siempre habrá que mantener la compatibilidad con la tradición Unix). Por ejemplo, JFS tiene un B-Tree extra exclusivamente dedicado a mantener una doble indexación que permita satisfacer las garantías de readdir() y compañía. Btrfs, un sistema de archivos de última generación, también mantiene una doble indexación, por cada elemento añadido a un directorio se crean dos items: uno ordenado por hash y otro ordenado secuencialmente. Ext3/4 por su parte sólo ordena los elementos por hash, pero trata de mantener la secuencialidad leyendo los contenidos del directorio por el orden de hash.
Estas técnicas suponen, por supuesto, un trabajo y E/S extra que tiene un impacto en el rendimiento. ¡Ah, y por supuesto, la concepción lineal de los directorios implica que listarlos con readdir() y operar con ellos puede tener una complejidad algorítmica lineal! Así que resulta que Unix, culmen del buen diseño de sistemas operativos, implementa los directorios de una forma verdaderamente patética, y nos hacer pagar sus errores con impacto en el rendimiento (hay software que usa diferentes trucos para evitar acumular miles de archivos en un mismo directorio).
La lección de toda esta historia es que por muy genial que sea el diseño de tu software, obsesionarse con abstracciones perfectas e intentar imponerlas bajo la creencia de que su pureza es la única forma decente de hacer las cosas puede llegar a ser un gran error.
27 de noviembre de 2011
Estupidez artificial
En los últimos meses se han visto un par de cosas muy interesantes hechas con ordenadores que a mi juicio tienen una gran importancia. Me refiero a la victoria del ordenador de IBM "Watson" en un concurso de Jeopardy, y "Siri", el asistente de voz del iPhone.
Y si, sé que, además del tradicional reconocimiento de voz, existen programas como las acciones de voz de Android y aplicaciones análogas. Pero les desafío a encontrar alguien que diga en serio que Siri no está bastante más refinado, basta echar un ojo a los vídeos donde se comparan a ambos. Siri no sólo reconoce lo dicho sino que capta el contexto de las conversaciones y las intenciones con una calidad envidiable, y está perfectamente integrado con el resto del sistema. Para la gente no interesada en la tecnología, poder decir a un teléfono "recuerdame que tengo que comprar leche cuando salga del trabajo" es muy llamativo, y para bien o para mal Apple va a ser considerado por el público como la primera compañía que fue capaz de hacer semejantes operaciones con cierta dignidad y sin instalar ningún extra. Fanboysmo no, gracias.
La relevancia de Watson y Siri es que, en el espacio de unos pocos meses, han mostrado al mundo que comunicarse a los ordenadores mediante voz ha dejado de ser una cosa de ciencia ficción o de programas de reconocimiento de voz, la charla puede ser un medio habitual para comunicarse con ordenadores. Ejemplo, búsqueda. Aunque la afirmación que se ha leído por ahí sobre que Siri es un "google killer" es una clara exageración, no excluye la realidad de que buscar mediante voz -entender lo que se pregunta, no simplemente sintetizar la búsqueda en texto- va a ser algo cada vez más importante para los motores de búsqueda. Wolfram Alpha -utilizado por Siri para responder algunas preguntas- parece cada vez más interesante.
Todo lo dicho en este artículo es obvio y lo habrán leído ya en otros lados. Sin embargo, en este humilde blog he decidido ponerme mi sombrero futurista e intentar ir más allá. Watson usa 2.880 Power7, 16 TB de RAM y 4 TB de almacenamiento. ¿Que ocurrirá el día en el que el progreso del hardware y la mejora y "comoditización" de esta clase de software ponga esa misma capacidad de procesamiento en un puñetero teléfono móvil? Quizás lleguemos a descargarnos toda la literatura médica vigente hasta la fecha y la base de datos de Wikipedia, y podremos obtener diagnósticos médicos preliminares -Watson ya está en ello- o información de cualquier concepto histórico. ¿Por qué no? De hecho, llegaríamos a tener cosas así en la nube antes de que los móviles lleguen a ese punto.
También es interesante plantearse los retos que este tipo de juguetes planteará a los programadores. Tradicionalmente, los programadores se relacionan con sus usuarios mediante interfaces de usuario. Pero visto lo visto, no es ninguna quimera plantearse un mundo en el que los usuarios quieran usar programas hablando.
Lo más curioso de esto es que la sociedad mitificó durante años la "inteligencia artificial". En realidad no necesitamos inteligencia, nos basta con un cierto nivel de estupidez artificial que sea capaz de buscar dentro de bases de datos y entender órdenes simples, algo así ya sobra para causar una revolución social. Piensen en puestos de asistencia al cliente, ciertas clases de funcionarios. ¿Cuánto tardaremos en ver Siris y Watsons por las esquinas?
Y si, sé que, además del tradicional reconocimiento de voz, existen programas como las acciones de voz de Android y aplicaciones análogas. Pero les desafío a encontrar alguien que diga en serio que Siri no está bastante más refinado, basta echar un ojo a los vídeos donde se comparan a ambos. Siri no sólo reconoce lo dicho sino que capta el contexto de las conversaciones y las intenciones con una calidad envidiable, y está perfectamente integrado con el resto del sistema. Para la gente no interesada en la tecnología, poder decir a un teléfono "recuerdame que tengo que comprar leche cuando salga del trabajo" es muy llamativo, y para bien o para mal Apple va a ser considerado por el público como la primera compañía que fue capaz de hacer semejantes operaciones con cierta dignidad y sin instalar ningún extra. Fanboysmo no, gracias.
La relevancia de Watson y Siri es que, en el espacio de unos pocos meses, han mostrado al mundo que comunicarse a los ordenadores mediante voz ha dejado de ser una cosa de ciencia ficción o de programas de reconocimiento de voz, la charla puede ser un medio habitual para comunicarse con ordenadores. Ejemplo, búsqueda. Aunque la afirmación que se ha leído por ahí sobre que Siri es un "google killer" es una clara exageración, no excluye la realidad de que buscar mediante voz -entender lo que se pregunta, no simplemente sintetizar la búsqueda en texto- va a ser algo cada vez más importante para los motores de búsqueda. Wolfram Alpha -utilizado por Siri para responder algunas preguntas- parece cada vez más interesante.
Todo lo dicho en este artículo es obvio y lo habrán leído ya en otros lados. Sin embargo, en este humilde blog he decidido ponerme mi sombrero futurista e intentar ir más allá. Watson usa 2.880 Power7, 16 TB de RAM y 4 TB de almacenamiento. ¿Que ocurrirá el día en el que el progreso del hardware y la mejora y "comoditización" de esta clase de software ponga esa misma capacidad de procesamiento en un puñetero teléfono móvil? Quizás lleguemos a descargarnos toda la literatura médica vigente hasta la fecha y la base de datos de Wikipedia, y podremos obtener diagnósticos médicos preliminares -Watson ya está en ello- o información de cualquier concepto histórico. ¿Por qué no? De hecho, llegaríamos a tener cosas así en la nube antes de que los móviles lleguen a ese punto.
También es interesante plantearse los retos que este tipo de juguetes planteará a los programadores. Tradicionalmente, los programadores se relacionan con sus usuarios mediante interfaces de usuario. Pero visto lo visto, no es ninguna quimera plantearse un mundo en el que los usuarios quieran usar programas hablando.
Lo más curioso de esto es que la sociedad mitificó durante años la "inteligencia artificial". En realidad no necesitamos inteligencia, nos basta con un cierto nivel de estupidez artificial que sea capaz de buscar dentro de bases de datos y entender órdenes simples, algo así ya sobra para causar una revolución social. Piensen en puestos de asistencia al cliente, ciertas clases de funcionarios. ¿Cuánto tardaremos en ver Siris y Watsons por las esquinas?
19 de noviembre de 2011
Glamor, el nuevo Glucose
En 2006, Zack Russin, trabajador en QT en el área de gráficos, hizo unos parches muy interesantes llamados "Glucose", que consistían en una nueva arquitectura alternativa para X.org en la que todas las operaciones gráficas del servidor (desde las más básicas a las de la extensión Xrender) se realizaban vía OpenGL. Su objetivo era que los drivers de X.org desaparecieran, y fueran sustituidos por una especie de driver único OpenGL. De ese modo todos los flujos de código se unificarían en una sola ruta gráfica, y la hierba verde brillaría bajo los rayos del Sol. Desgraciadamente, Glucose no llegó a ningún lado (al igual que Xgl, con el cual estaba relacionado, y que desapareció para dar paso a AIXGL).
En las últimas semanas se ha oído hablar, vía Phoronix, de Glamor, un proyecto de gente de Intel para hacer algo esencialmente similar a Glucose.
A primera vista, esto podría parecerles un buen paso. Pero eso sería porque no conocen a fondo el maravilloso mundo gráfico linuxero, que a pesar de los grandes cambios logrados en los últimos años sigue en continua batalla consigo mismo:
· Intel está trabajando en una nueva arquitectura de aceleración para su driver optimizada para plataformas SandyBridge y posteriores. De tener éxito, Glamor haría que todo ese trabajo fuera obsoleto.
· Intel no está interesado en Gallium3D. Siguen trabajando con su modelo Mesa de-toda-la-vida porque opinan que reescribir el driver de nuevo daría mucho trabajo.
· Pero hay un driver Gallium3D para chips Intel no oficial, desarrollado por VMWare, Google y otras compañías interesadas en ello.
Con lo cual, el plan de Glamor consistiría, en un principio, en cambiar el driver X.org actual de Intel, ya sea con la arquitectura de aceleración normal o con la nueva optimizada para Sandybridge, por un modelo OpenGL, pero no con un driver Gallium3D, que se supone que es el futuro de Mesa, sino con el tradicional soportado por Intel. O con el de Gallium3D, si a alguna distro le parece más bonito.
Y si lo anterior les resulta complicado, recuerden que las GPUs programables modernas, a pesar de todo su poderío, no siempre son rápidas con operaciones 2D tradicionales, lo cual quiere decir que aunque mover todo el flujo de operaciones gráficas a OpenGL acelerará muchas cosas, habrá operaciones en los que no será tan competitivo, y menos con el modelo de dibujado no-QML + X11/Xrender.
Lo que quiero decir con todo esto es que espero que un día Wayland venga, arrase con todo, y todo rastro de existencias pasadas quede erradicada de la faz de Internet.
En las últimas semanas se ha oído hablar, vía Phoronix, de Glamor, un proyecto de gente de Intel para hacer algo esencialmente similar a Glucose.
A primera vista, esto podría parecerles un buen paso. Pero eso sería porque no conocen a fondo el maravilloso mundo gráfico linuxero, que a pesar de los grandes cambios logrados en los últimos años sigue en continua batalla consigo mismo:
· Intel está trabajando en una nueva arquitectura de aceleración para su driver optimizada para plataformas SandyBridge y posteriores. De tener éxito, Glamor haría que todo ese trabajo fuera obsoleto.
· Intel no está interesado en Gallium3D. Siguen trabajando con su modelo Mesa de-toda-la-vida porque opinan que reescribir el driver de nuevo daría mucho trabajo.
· Pero hay un driver Gallium3D para chips Intel no oficial, desarrollado por VMWare, Google y otras compañías interesadas en ello.
Con lo cual, el plan de Glamor consistiría, en un principio, en cambiar el driver X.org actual de Intel, ya sea con la arquitectura de aceleración normal o con la nueva optimizada para Sandybridge, por un modelo OpenGL, pero no con un driver Gallium3D, que se supone que es el futuro de Mesa, sino con el tradicional soportado por Intel. O con el de Gallium3D, si a alguna distro le parece más bonito.
Y si lo anterior les resulta complicado, recuerden que las GPUs programables modernas, a pesar de todo su poderío, no siempre son rápidas con operaciones 2D tradicionales, lo cual quiere decir que aunque mover todo el flujo de operaciones gráficas a OpenGL acelerará muchas cosas, habrá operaciones en los que no será tan competitivo, y menos con el modelo de dibujado no-QML + X11/Xrender.
Lo que quiero decir con todo esto es que espero que un día Wayland venga, arrase con todo, y todo rastro de existencias pasadas quede erradicada de la faz de Internet.
18 de noviembre de 2011
Y ahora, syslog
A Lennart Poettering y Kay Sievers les ha dado por reinventar syslog. El invento se llama "journal", almacena los datos en formato binario y forma parte de systemd.
Aunque parece que no intentará "ocupar" las APIs propias de syslog() (syslog será una fuente de información, pero journal tendrá sus propias APIs), no cabe duda que Lennart acaba de garantizarse una vez más el odio eterno del conservadurismo unixero (¡no almacena la información en texto plano, a la hoguera!)
Aunque parece que no intentará "ocupar" las APIs propias de syslog() (syslog será una fuente de información, pero journal tendrá sus propias APIs), no cabe duda que Lennart acaba de garantizarse una vez más el odio eterno del conservadurismo unixero (¡no almacena la información en texto plano, a la hoguera!)
5 de noviembre de 2011
Canonical se pone serio
En los últimos tiempos se ha hablado mucho de esta magnífica noticia: Ubuntu quiere estar presente en teléfonos de última generación, tabletas y televisiones inteligentes.
No está nada mal que una de las grandes distros Linux asuma que la sobremesa no lo es todo: el mundo post-PC, como lo llamó Steve Jobs (que pueden criticarle lo que quieran, pero tenía más razón que un santo), es cada vez más real. Hasta los hackers de software libre más renombrados están usando smartphones en los que las distros convencionales tienen un papel casi nulo: ¿por qué tendría que conformarse alguien al mando de una compañía Linux, como Shuttleworth, con Android?
La impasibilidad del mundo linuxero ante las nuevas costumbres tecnológicas ha sido bastante sangrante. Cuando el iPad vio la luz, el comentario generalizado fue predecir su rotundo fracaso, ahora todo el mundo se preocupa de los bloqueos fronterizos de Apple relacionados (por cierto, se están ganando a pulso una imagen pública horrible). Y es triste, porque el software libre tiene muchas ventajas que explotar en un mundo en el que cada persona pueda tener 2 ó 3 dispositivos y no hay nadie en la familia que no los tenga. Me refiero a "integración": eso que al software libre se le da tan mal a pesar de qué, en teoría, debido a la posibilidad de modificar cualquier parte del sistema, debería ser sencillo. A los linuxeros debería sonrojarnos que Microsoft tenga cosas como el nuevo Homegroup de Windows 7 (digno de aplauso, dicho totalmente en serio) o que Apple tenga cosas como AirDrop mientras que la comunicación entre distros Linux es tan...sin comentarios.
Queda por saber con qué fabricante pretende aliarse Shuttleworth y qué nivel de compromiso y cuota de mercado pretende alcanzar. En esto de las tabletas y smartphones, la integración entre hardware y software es un requisito, y estando ya casi todo el pescado vendido a favor de Apple y Android (y Nokia&Microsoft gastando millonadas para ocupar cualquier resquicio restante), resulta poco creíble que ni Ubuntu ni nadie pueda tener posibilidad de éxito notable. Sin embargo, da una pista: "From the industry viewpoint, Google acquisition Of Motorola Mobility has shook up the hardware vendors, so some of them are looking for non-Android alternatives".
Que es una manera de decir: "Estamos trabajando con un fabricante de hardware rebotado por el tema de Motorola, pero de momento no podemos decir quien para que no se enfaden". Es decir, espero que se refiera a eso. Porque si está diseñando un SO para ese tipo de dispositivos sin tener en dónde instalarlo, lo lleva claro. En cualquier caso, seguro que le va mejor que MeeGo/Tizen.
Por cierto, ¿saben qué nueva información hay de Tizen? Nada: la única información disponible sigue siendo el (único) post de blog del anuncio inaugural. Sólo hay una empresa llamada Nomovok montando un summit bastante poco sugerente, y publicando noticias cortas de Tizen. Se dedicaban a ofrecer servicios a empresas de hardware que quisieran usar Meego y ahora pretenden lo mismo con Tizen, por desgracia con aparente poco éxito tras la desbandada de Intel y Nokia. Más allá delo que Nokia haga con el N9, MeeGo parece estar completamente muerto.
28 de octubre de 2011
ARM v8
Una de las consecuencias más importantes, pero menos mencionadas, de la desaparición de MeeGo es que a Intel le ha salido por la culata su plan de luchar contra ARM en cacharros portables, plan en el que Nokia ocupaba, sin ninguna duda, un lugar importante. Tanto como el que ocupa para Microsoft hoy.
La batalla ARM vs x86 acaba de calentarse de nuevo tras la aparición de ARM v8. Si ya de por si ARM estaba empezando a hacerse un pequeño hueco en el universo de los servidores (resulta que la misma eficiencia que les da dominio en dispositivos móviles puede ayudar a reducir la factura de la electricidad en datacenters), el hecho de que hayan (¡por fin!) diseñado una arquitectura con soporte de 64 bits se lo va a poner más fácil. Es para destacar que la primera plataforma basada en ARMv8 sea una plataforma para servidores, y no para teléfonos móviles o routers.
(Por cierto, adivinen qué famoso sistema operativo propietario para servidores no tiene soporte de ARM ni piensa añadirlo)
Han hecho un documento con los detalles de la nueva arquitectura que merece la pena comentar. Recordemos que cuando AMD creó x86-64 el número de registros de propósito general aumentó de los ridículos 8...¡a 16! (los procesador RISC de los 90 ya solían tener 32). ARM sigue sin ser x86, y eso quiere decir que son algo menos chapuceros, así que ya que han creado un nuevo conjunto de instrucciones, han decidido incrementar el número de registros de propósito general a 31 (antes tenía un número parecido pero sólo se podían acceder a 15 al mismo tiempo). Respecto a SIMD, tendrá 32 registros de 128 bits (SSE4 sólo tiene 16; aunque todo sea dicho, en AVX se han ampliado a 256 bits).
Y no es que tener más registros les haga más veloces, pero un servidor recuerda haber leído algún documento que tras un análisis concluía que en en plataformas x86-32, con sus ridículos 8 registros de propósito general, el código se pasaba un 20% del tiempo reubicando datos de registros a un lado y a otro para hacer sitio. Seguramente ARM no llegue a utilizar los 31 registros la mayor parte del tiempo, pero es una de esas cosas que nunca está de más tener, por si a algún compilador le da por sentirse inspirado.
En fin, habrá que ver como evoluciona ARM, a ver si de verdad consigue arrodillar Intel, o es Intel el que consigue expandir x86 a otro sector.
La batalla ARM vs x86 acaba de calentarse de nuevo tras la aparición de ARM v8. Si ya de por si ARM estaba empezando a hacerse un pequeño hueco en el universo de los servidores (resulta que la misma eficiencia que les da dominio en dispositivos móviles puede ayudar a reducir la factura de la electricidad en datacenters), el hecho de que hayan (¡por fin!) diseñado una arquitectura con soporte de 64 bits se lo va a poner más fácil. Es para destacar que la primera plataforma basada en ARMv8 sea una plataforma para servidores, y no para teléfonos móviles o routers.
(Por cierto, adivinen qué famoso sistema operativo propietario para servidores no tiene soporte de ARM ni piensa añadirlo)
Han hecho un documento con los detalles de la nueva arquitectura que merece la pena comentar. Recordemos que cuando AMD creó x86-64 el número de registros de propósito general aumentó de los ridículos 8...¡a 16! (los procesador RISC de los 90 ya solían tener 32). ARM sigue sin ser x86, y eso quiere decir que son algo menos chapuceros, así que ya que han creado un nuevo conjunto de instrucciones, han decidido incrementar el número de registros de propósito general a 31 (antes tenía un número parecido pero sólo se podían acceder a 15 al mismo tiempo). Respecto a SIMD, tendrá 32 registros de 128 bits (SSE4 sólo tiene 16; aunque todo sea dicho, en AVX se han ampliado a 256 bits).
Y no es que tener más registros les haga más veloces, pero un servidor recuerda haber leído algún documento que tras un análisis concluía que en en plataformas x86-32, con sus ridículos 8 registros de propósito general, el código se pasaba un 20% del tiempo reubicando datos de registros a un lado y a otro para hacer sitio. Seguramente ARM no llegue a utilizar los 31 registros la mayor parte del tiempo, pero es una de esas cosas que nunca está de más tener, por si a algún compilador le da por sentirse inspirado.
En fin, habrá que ver como evoluciona ARM, a ver si de verdad consigue arrodillar Intel, o es Intel el que consigue expandir x86 a otro sector.
27 de octubre de 2011
Nokia y WP7
Con tanto proselitismo de MeeGo y tanta crítica a Nokia, podría parecer que creo ciegamente que se van a hundir irremediablemente. Pero ahora que ya ha salido a la venta su primer teléfono con WP7, me gustaría aclarar con una nota rápida que personalmente creo que se venderá como rosquillas.
Sin embargo, de venderse bien a rivalizar con Android hay una gran diferencia. Y no por falta calidad (en realidad, poco a poco Microsoft está convirtiéndo WP7 en un SO atractivo), sino por algo parecido a lo que Apple sufría (y sigue sufriendo) en el mercado de ordenadores escritorio: Por muy superior que fuera OS X frente a Microsoft (recordemos los días oscuros de Windows Vista, cuando se vieron forzados a reiniciar el desarrollo del SO a mitad del proyecto), Windows simplemente era el estándar y no había (ni hay) sitio para otro SO de escritorio.
En los smartphones Android es el estándar, y por mucho que mejore Windows Phone eso no va a cambiar. Y Android tampoco es, ni mucho menos, Windows. Aun.
Sin embargo, de venderse bien a rivalizar con Android hay una gran diferencia. Y no por falta calidad (en realidad, poco a poco Microsoft está convirtiéndo WP7 en un SO atractivo), sino por algo parecido a lo que Apple sufría (y sigue sufriendo) en el mercado de ordenadores escritorio: Por muy superior que fuera OS X frente a Microsoft (recordemos los días oscuros de Windows Vista, cuando se vieron forzados a reiniciar el desarrollo del SO a mitad del proyecto), Windows simplemente era el estándar y no había (ni hay) sitio para otro SO de escritorio.
En los smartphones Android es el estándar, y por mucho que mejore Windows Phone eso no va a cambiar. Y Android tampoco es, ni mucho menos, Windows. Aun.
24 de octubre de 2011
Las novedades de Linux 3.1
Ya se ha anunciado la disponibilidad de la versión 3.1 del kernel Linux. Novedades: soporte para el procesador de software libre OpenRISC, mejor rendimiento del proceso de escritura de memoria a disco, mayor velocidad del asignador de memoria "slab", una nueva implementación de iSCSI, soporte para chips NFD "Near-Field Communication" para pagos mediante teléfonos, gestión de bloques estropeados en la capa de RAID por software, barreras activadas por defecto en Ext3, un controlador para el Wii Remote, una herramienta "cpupowerutils" para la gestión de energía, y muchos otros drivers y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.
· Nueva arquitectura: OpenRISC: OpenRISC es una CPU de "código abierto" que es parte del proyecto OpenCores. El objetivo es crear una plataforma de computación completamente libre y disponible bajo licencia (L)GPL, así como un conjunto completo de herramientas de desarrollo, librerías, soporte de sistemas operativos y aplicaciones igualmente libres. La implementación incluida en esta versión es la familia de procesadores de 32 bits OpenRISC 1000 (or1k). Hay más detalles sobre este procesador en esta página.
· Regulación dinámica del writeback: "Writeback" es el proceso de escribir datos de la RAM al disco, y regular en este contexto significa bloquear procesos temporalmente para evitar que creen nuevos datos que escribir, hasta que los datos actuales hayan sido escritos en el disco. El código de writeback era subóptimo, porque en ciertas situaciones forzaba a varios procesos a escribir sus datos al disco simultáneamente, lo cual creaba patrones de escritura aleatoria que no son buenos para el rendimiento. El nuevo código evita esas situaciones, lo cual ayuda a crear patrones de escritura más lineales. El nuevo código también intenta detectar el ancho de banda del disco, un dato que es utilizado para mejorar las heurísticas que deciden qué procesos deben ser bloqueados. El acoplamiento entre sistemas de archivo y el sistema de writeback también ha sido mejorado, y se ha solucionado un problema de escalabilidad.
· Barreras activadas por defecto en Ext3: Los discos duros tienen un buffer de memoria donde se almacenan las instrucciones y datos enviados por el SO. El software interno de los discos modernos cambia el orden de las instrucciones para mejorar el rendimiento, lo cual significa que las instrucciones pueden o no pueden escribirse al disco en el mismo orden en el que el SO las envió. Esto rompe las reglas que el SO necesita para implementar cosas como journaling o COW, de manera que los discos proporcionan una instrucción "vaciado de cache" que no puede ser reordenada y que ordena escribir el buffer a disco. En el mundo de Linux, cuando un sistema de archivos envía esa instrucción, se le llama "barrera". Sistemas de archivos como Ext4, XFS o Btrfs activan el uso de barreras por defecto; Ext3 las soporta pero hasta esta versión no han sido activadas por defecto: las garantías de seguridad de los datos son más altas, pero el impacto en el rendimiento de Ext3 es muy notorio, y se consideró que era una regresión de rendimiento inaceptable para muchos usuarios. Sin embargo, distribuciones como Red Hat activan el uso de barreras en Ext3 desde hace mucho tiempo, y ahora el valor por defecto para Linux también ha sido cambiado.
En otras palabras: Si usas Ext3 y notas una regresión en el rendimiento con esta nueva versión, intenta desactivar las barreras (opción de montaje "barriers=0").
· Soporte de chips NFC (Near-Field Communication): Los chips Near-field communication permiten comunicación inalámbrica simple entre dos dispositivos situados a unos pocos centímetros de distancia. Fueron coinventados por NXP Semiconductors y Sony en 2002, y pueden encontrarse en varios teléfonos ya disponibles en el mercado, y muchos otros están planeando añadir soporte.
Se espera que los chips NFC se conviertan en el sistema de pago por teléfono más utilizado en EEUU en los próximos años: los compradores que tienen la información de su tarjeta de crédito almacenada en sus teléfonos NFC pueden pagar pasando sus teléfonos cerca del lector, en lugar de utilizar la tarjeta de crédito. Un teléfono con NFC podría servir como DNI o tarjeta de identificación. Podría pasarse el teléfono cerca de un chip NFC para conseguir información en un museo, o en una tienda. También puede utilizarse para compartir vídeos, canciones, o fotos.
Esta versión de Linux añade un subsistema NFC y la familia de sockets NFC.
· Mejoras de rendimiento en el asignador de memoria slab: En esta versión, el asignador de memoria slab utilizado por defecto ("slub") utilizará operaciones sin bloqueos en ciertas rutas en las arquitecturas que soporten la instrucción cmpxchg. En particular, ha mejorado considerablemente el rendimiento de la parte de slub que se encarga de liberar memoria de los slabs
· Mejoras de escalabilidad en el VFS: Al igual que en versiones anteriores, hay una nueva ronda de mejoras de escalabilidad:
· El contador inode_stat.nr_unused se ha convertido a variables per-cpu.
· La lista global LRU de inodos no usados se ha convertido a una lista por cada superbloque.
· Como consecuencia del punto anterior, se elimina el semáforo iprune_sem.
· Se elimina el semáforo i_alloc_sem y se reemplaza su funcionalidad con un sistema más simple.
· Escalabilidad en el montaje de sistemas de archivos que no tienen punto de montaje (sockfs y pipefs)
· Evitar tomar el cerrojo inode_hash_locken tuberías y sockets
· Nueva implementación iSCSI: La anterior implementación iSCSI del kernel, SCST, queda obsoleta ante la inclusión del "target" SCSI de Linux-iSCSI.org, una implementación de iSCSI (RFC-3720). Más información aquí.
· cpupowerutils: cpupowerutils es un nuevo proyecto derivado de cpufrequtils y extendido con otras características, como una herramienta de monitorización de hardware. ¿Por qué una nueva herramienta? Así lo justifica el anuncio:
"El tuneado en las CPUs del consumo de energía vs rendimiento ya no consiste en cambiar de frecuencia. Características como los estados de sueño profundo, el cambio de frecuencia tradicional, y las frecuencias "turbo" ocultas dependen íntimamente las unas de las otras. Las dos primeras sólo existen en arquitecturas como PPC, Itanium y ARM, la otra sólo en x86. En x86 la APU (CPU+GPU) sólo funcionará del modo más eficiente si ambos tienen una gestión energética adecuada. Los usuarios y desarrolladores quieren tener una sola herramienta para observar su sistema y monitorizar y depurar los problemas de gestión de energía". cpupowerutils es esa herramienta.
· Raid por Software: gestión de bloques estropeados: La capa MD ("Múltiples Dispositivos", también conocida como "raid por software") tiene en esta versión capacidad de gestionar bloques estropeados: los bloques estropeados se añadirán a una lista, y el sistema intentará no utilizarlos. Esta característica necesitará una versión de mdadm actualizada.
· Personalidad para reportar números de versión 2.6.x: Algunos programas dejaron de funcionar con Linux 3.0. Algunos de ellos son binarios sin fuentes (por ejemplo, programas de gestión de software de cierto vendedor de impresoras). La variable sys.platform en Python también devuelve "linux3" en 3.0, lo cual rompe las cosas que estaban comprobando sys.platform=="linux2". Para solucionar este problema, se ha añadido una personalidad UNAME26 que reporta versiones 2.6.x.
· Soporte de controlador de Wii: Se ha añadido un driver para el Wii Remote.
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.
· Nueva arquitectura: OpenRISC: OpenRISC es una CPU de "código abierto" que es parte del proyecto OpenCores. El objetivo es crear una plataforma de computación completamente libre y disponible bajo licencia (L)GPL, así como un conjunto completo de herramientas de desarrollo, librerías, soporte de sistemas operativos y aplicaciones igualmente libres. La implementación incluida en esta versión es la familia de procesadores de 32 bits OpenRISC 1000 (or1k). Hay más detalles sobre este procesador en esta página.
· Regulación dinámica del writeback: "Writeback" es el proceso de escribir datos de la RAM al disco, y regular en este contexto significa bloquear procesos temporalmente para evitar que creen nuevos datos que escribir, hasta que los datos actuales hayan sido escritos en el disco. El código de writeback era subóptimo, porque en ciertas situaciones forzaba a varios procesos a escribir sus datos al disco simultáneamente, lo cual creaba patrones de escritura aleatoria que no son buenos para el rendimiento. El nuevo código evita esas situaciones, lo cual ayuda a crear patrones de escritura más lineales. El nuevo código también intenta detectar el ancho de banda del disco, un dato que es utilizado para mejorar las heurísticas que deciden qué procesos deben ser bloqueados. El acoplamiento entre sistemas de archivo y el sistema de writeback también ha sido mejorado, y se ha solucionado un problema de escalabilidad.
· Barreras activadas por defecto en Ext3: Los discos duros tienen un buffer de memoria donde se almacenan las instrucciones y datos enviados por el SO. El software interno de los discos modernos cambia el orden de las instrucciones para mejorar el rendimiento, lo cual significa que las instrucciones pueden o no pueden escribirse al disco en el mismo orden en el que el SO las envió. Esto rompe las reglas que el SO necesita para implementar cosas como journaling o COW, de manera que los discos proporcionan una instrucción "vaciado de cache" que no puede ser reordenada y que ordena escribir el buffer a disco. En el mundo de Linux, cuando un sistema de archivos envía esa instrucción, se le llama "barrera". Sistemas de archivos como Ext4, XFS o Btrfs activan el uso de barreras por defecto; Ext3 las soporta pero hasta esta versión no han sido activadas por defecto: las garantías de seguridad de los datos son más altas, pero el impacto en el rendimiento de Ext3 es muy notorio, y se consideró que era una regresión de rendimiento inaceptable para muchos usuarios. Sin embargo, distribuciones como Red Hat activan el uso de barreras en Ext3 desde hace mucho tiempo, y ahora el valor por defecto para Linux también ha sido cambiado.
En otras palabras: Si usas Ext3 y notas una regresión en el rendimiento con esta nueva versión, intenta desactivar las barreras (opción de montaje "barriers=0").
· Soporte de chips NFC (Near-Field Communication): Los chips Near-field communication permiten comunicación inalámbrica simple entre dos dispositivos situados a unos pocos centímetros de distancia. Fueron coinventados por NXP Semiconductors y Sony en 2002, y pueden encontrarse en varios teléfonos ya disponibles en el mercado, y muchos otros están planeando añadir soporte.
Se espera que los chips NFC se conviertan en el sistema de pago por teléfono más utilizado en EEUU en los próximos años: los compradores que tienen la información de su tarjeta de crédito almacenada en sus teléfonos NFC pueden pagar pasando sus teléfonos cerca del lector, en lugar de utilizar la tarjeta de crédito. Un teléfono con NFC podría servir como DNI o tarjeta de identificación. Podría pasarse el teléfono cerca de un chip NFC para conseguir información en un museo, o en una tienda. También puede utilizarse para compartir vídeos, canciones, o fotos.
Esta versión de Linux añade un subsistema NFC y la familia de sockets NFC.
· Mejoras de rendimiento en el asignador de memoria slab: En esta versión, el asignador de memoria slab utilizado por defecto ("slub") utilizará operaciones sin bloqueos en ciertas rutas en las arquitecturas que soporten la instrucción cmpxchg. En particular, ha mejorado considerablemente el rendimiento de la parte de slub que se encarga de liberar memoria de los slabs
· Mejoras de escalabilidad en el VFS: Al igual que en versiones anteriores, hay una nueva ronda de mejoras de escalabilidad:
· El contador inode_stat.nr_unused se ha convertido a variables per-cpu.
· La lista global LRU de inodos no usados se ha convertido a una lista por cada superbloque.
· Como consecuencia del punto anterior, se elimina el semáforo iprune_sem.
· Se elimina el semáforo i_alloc_sem y se reemplaza su funcionalidad con un sistema más simple.
· Escalabilidad en el montaje de sistemas de archivos que no tienen punto de montaje (sockfs y pipefs)
· Evitar tomar el cerrojo inode_hash_locken tuberías y sockets
· Nueva implementación iSCSI: La anterior implementación iSCSI del kernel, SCST, queda obsoleta ante la inclusión del "target" SCSI de Linux-iSCSI.org, una implementación de iSCSI (RFC-3720). Más información aquí.
· cpupowerutils: cpupowerutils es un nuevo proyecto derivado de cpufrequtils y extendido con otras características, como una herramienta de monitorización de hardware. ¿Por qué una nueva herramienta? Así lo justifica el anuncio:
"El tuneado en las CPUs del consumo de energía vs rendimiento ya no consiste en cambiar de frecuencia. Características como los estados de sueño profundo, el cambio de frecuencia tradicional, y las frecuencias "turbo" ocultas dependen íntimamente las unas de las otras. Las dos primeras sólo existen en arquitecturas como PPC, Itanium y ARM, la otra sólo en x86. En x86 la APU (CPU+GPU) sólo funcionará del modo más eficiente si ambos tienen una gestión energética adecuada. Los usuarios y desarrolladores quieren tener una sola herramienta para observar su sistema y monitorizar y depurar los problemas de gestión de energía". cpupowerutils es esa herramienta.
· Raid por Software: gestión de bloques estropeados: La capa MD ("Múltiples Dispositivos", también conocida como "raid por software") tiene en esta versión capacidad de gestionar bloques estropeados: los bloques estropeados se añadirán a una lista, y el sistema intentará no utilizarlos. Esta característica necesitará una versión de mdadm actualizada.
· Personalidad para reportar números de versión 2.6.x: Algunos programas dejaron de funcionar con Linux 3.0. Algunos de ellos son binarios sin fuentes (por ejemplo, programas de gestión de software de cierto vendedor de impresoras). La variable sys.platform en Python también devuelve "linux3" en 3.0, lo cual rompe las cosas que estaban comprobando sys.platform=="linux2". Para solucionar este problema, se ha añadido una personalidad UNAME26 que reporta versiones 2.6.x.
· Soporte de controlador de Wii: Se ha añadido un driver para el Wii Remote.
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.
23 de octubre de 2011
Perdiendo el miedo a Akonadi
Al actualizarme a Fedora 16 Beta he tenido que enfrentarme a uno de los retos que como usuario de Kmail temía: El paso a "Kmail 2", también conocido como "Kmail basado en Akonadi".
Akonadi es uno de los mayores problemas-capricho que mucha gente tiene a día de hoy con KDE. Por problema-capricho hemos de entender no un "problema" en si, sino más bien uno de esos caprichos tecno-estéticos que la gente tiene a veces (yo el primero) con el software: No se trata de que Akonadi les impida usar KDE, sino de que no les gusta, no les da la impresión de que sirva para nada, y consideran que la existencia de una instancia de mysql en un escritorio es un error intolerable que debería ser corregido.
No voy a discutir la razón de ser de Akonadi (porque hace años que tengo un borrador a medio escribir que toca el tema y quiero terminarlo algún día), pero podría simplificarlo en que todos tienen una pequeña parte de razón: si, tener una base de datos en el escritorio es algo recargado, pero también es cierto que poder programar un cliente de correo simple en 10 minutos es síntoma de que hay algo que se está haciendo bien.
En anteriores ocasiones mi experiencia con Akonadi había sido bastante negativa. Entendía la enorme utilidad de lo que querían hacer, pero el resultado final era tan desesperante que uno se lo tomaba como una empresa quijotesca sin futuro: El miedo natural a la idea de guardar todos mis correos y datos de escritorio en una base de datos mysql, unido a los fallos constantes que veía en Akonadi, me hacía huir de todo ello como la peste. Sobre todo, en lo referente a mi sagrado archivo de correos en formato maildir. No entendía porque tenía que renunciar a maildir. Tal vez para un usuario de formato mailbox sea más fácil.
Esto se debía a que no tenía ni puñetera idea. Akonadi no consiste en eso. Los correos no se guardan en mysql, siguen guardándose en formato maildir. ¿Qué demonios hace Akonadi, entonces? Podría decirse que es una especie de "cache": kmail accede a los correos a través de las interfaces de Akonadi, y es Akonadi quien lee el formato maildir y crea cachés (que se guardan en bases de datos mysql) de esas peticiones. La cuentas de correo pasan a ser parte de la configuración de Akonadi, y el proceso de bajar el correo nuevo consiste en que el recurso de akonadi pop3 descarga el correo, actualiza los caches de Akonadi y el recurso maildir sincroniza a Akonadi con mi archivo de correos, añadiendo el correo descargado. Los caches de Akonadi se van creando y destruyendo dinámicamente, pero son sólo eso, caches, pueden borrarse por completo y no pasa nada, Akonadi simplemente los reconstruirá.
El resultado final ha sido es que mi migración a Kmail2/Akonadi ha sido completamente inofensiva y ha desterrado todos mis miedos. Mi único problema fue con la migración, algo que resolví prescindiendo de la herramienta de migración (increíblemente lenta) y creando las cuentas pop3 en Akonadi de cero, y una de maildir que apuntara a mi archivo actual. La primera actualización del caché de Akonadi tardó un montón, pero una vez completada me he olvidado de todo esto. Akonadi es muy sólido, y no he tenido problemas de fiabilidad ningún tipo.
El único problema es la lentitud. Abrir una carpeta no cacheada es demasiado lento, muchas operaciones que consistan en copiar, mover o cambiar el estatus de los mensajes son lentas. A veces, el simple hecho de leer un mensaje muestra un "espere, por favor..." debido a que por alguna razón hay otras operaciones simultaneas (¿las copias de seguridad automáticas que he configurado en Akonadi?) que bloquean a las demás. Creyendo que el problema era que mysql era demasiado pesado cambié el "backend" de Akonadi a sqlite, pensando que la ligereza de sqlite era ideal para Akonadi, pero la realidad es que su rendimiento es peor (mucho peor: mysql existe por algo). No sé hasta que punto influirá el hecho de que utilizo btrfs: el fsync() en btrfs es aun algo lento, y la fragmentación de las bases de datos debido al COW es muy notoria.
Por otra parte, la operación normal de leer correos sin hacer cosas raras es instantánea. Sólo he notado lentitud y problemas al hacer cosas atípicas (copiar muchos correos de una carpeta a otra), y mi archivo de correo maildir está seguro. Está claro que Akonadi y Kmail2 son muy nuevos y tienen que mejorar, pero son perfectamente usables. Y no olvidemos que Akonadi no sólo sirve para correos, también sirve para notas, calendarios, mensajes de IM, etc.
PD: El cambio de apariencia del blog era necesario para poder usar las nuevas plantillas de blogger.
Akonadi es uno de los mayores problemas-capricho que mucha gente tiene a día de hoy con KDE. Por problema-capricho hemos de entender no un "problema" en si, sino más bien uno de esos caprichos tecno-estéticos que la gente tiene a veces (yo el primero) con el software: No se trata de que Akonadi les impida usar KDE, sino de que no les gusta, no les da la impresión de que sirva para nada, y consideran que la existencia de una instancia de mysql en un escritorio es un error intolerable que debería ser corregido.
No voy a discutir la razón de ser de Akonadi (porque hace años que tengo un borrador a medio escribir que toca el tema y quiero terminarlo algún día), pero podría simplificarlo en que todos tienen una pequeña parte de razón: si, tener una base de datos en el escritorio es algo recargado, pero también es cierto que poder programar un cliente de correo simple en 10 minutos es síntoma de que hay algo que se está haciendo bien.
En anteriores ocasiones mi experiencia con Akonadi había sido bastante negativa. Entendía la enorme utilidad de lo que querían hacer, pero el resultado final era tan desesperante que uno se lo tomaba como una empresa quijotesca sin futuro: El miedo natural a la idea de guardar todos mis correos y datos de escritorio en una base de datos mysql, unido a los fallos constantes que veía en Akonadi, me hacía huir de todo ello como la peste. Sobre todo, en lo referente a mi sagrado archivo de correos en formato maildir. No entendía porque tenía que renunciar a maildir. Tal vez para un usuario de formato mailbox sea más fácil.
Esto se debía a que no tenía ni puñetera idea. Akonadi no consiste en eso. Los correos no se guardan en mysql, siguen guardándose en formato maildir. ¿Qué demonios hace Akonadi, entonces? Podría decirse que es una especie de "cache": kmail accede a los correos a través de las interfaces de Akonadi, y es Akonadi quien lee el formato maildir y crea cachés (que se guardan en bases de datos mysql) de esas peticiones. La cuentas de correo pasan a ser parte de la configuración de Akonadi, y el proceso de bajar el correo nuevo consiste en que el recurso de akonadi pop3 descarga el correo, actualiza los caches de Akonadi y el recurso maildir sincroniza a Akonadi con mi archivo de correos, añadiendo el correo descargado. Los caches de Akonadi se van creando y destruyendo dinámicamente, pero son sólo eso, caches, pueden borrarse por completo y no pasa nada, Akonadi simplemente los reconstruirá.
El resultado final ha sido es que mi migración a Kmail2/Akonadi ha sido completamente inofensiva y ha desterrado todos mis miedos. Mi único problema fue con la migración, algo que resolví prescindiendo de la herramienta de migración (increíblemente lenta) y creando las cuentas pop3 en Akonadi de cero, y una de maildir que apuntara a mi archivo actual. La primera actualización del caché de Akonadi tardó un montón, pero una vez completada me he olvidado de todo esto. Akonadi es muy sólido, y no he tenido problemas de fiabilidad ningún tipo.
El único problema es la lentitud. Abrir una carpeta no cacheada es demasiado lento, muchas operaciones que consistan en copiar, mover o cambiar el estatus de los mensajes son lentas. A veces, el simple hecho de leer un mensaje muestra un "espere, por favor..." debido a que por alguna razón hay otras operaciones simultaneas (¿las copias de seguridad automáticas que he configurado en Akonadi?) que bloquean a las demás. Creyendo que el problema era que mysql era demasiado pesado cambié el "backend" de Akonadi a sqlite, pensando que la ligereza de sqlite era ideal para Akonadi, pero la realidad es que su rendimiento es peor (mucho peor: mysql existe por algo). No sé hasta que punto influirá el hecho de que utilizo btrfs: el fsync() en btrfs es aun algo lento, y la fragmentación de las bases de datos debido al COW es muy notoria.
Por otra parte, la operación normal de leer correos sin hacer cosas raras es instantánea. Sólo he notado lentitud y problemas al hacer cosas atípicas (copiar muchos correos de una carpeta a otra), y mi archivo de correo maildir está seguro. Está claro que Akonadi y Kmail2 son muy nuevos y tienen que mejorar, pero son perfectamente usables. Y no olvidemos que Akonadi no sólo sirve para correos, también sirve para notas, calendarios, mensajes de IM, etc.
PD: El cambio de apariencia del blog era necesario para poder usar las nuevas plantillas de blogger.
1 de octubre de 2011
Tizen y Meltemi, dos nuevas plataformas Linux
Supongo que algunos de ustedes andarán preguntándose qué pasa con la evolución de MeeGo en Tizen. Yo también me lo pregunto. La verdad es que todo esto no da ninguna impresión de solidez, y todo apunta a que lo único que se conseguirá será reforzar el dominio de Android. Pero no adelantemos acontecimientos.
Empecemos con las buenas noticias: En el anuncio oficial se habla de que Tizen estará desarrollado por Intel y Samsung. Yo dudo mucho de las intenciones de Intel, al fin y al cabo su interés está en Android, pero lo de Samsung es muy alentador: a diferencia de Intel ellos si ensamblan teléfonos móviles. A falta de la posibilidad de instalar SOs con la libertad con la que se hace en los PCs, un SO para móviles requiere el apoyo de un gran fabricante, y Samsung lo es. Parece ser por tanto que veremos móviles basados en este Tizen.
Este repentino apoyo de Samsung no es, desde luego, casualidad. Se rumorea que Samsung y Google no se llevan bien, y ha firmado un pacto con Microsoft para vender Windows Phone 7 y para poder vender Android tranquilamente. Todas estas guerras de alianzas no tienen ningún sentido, y no tienen ningún sentido porque son producto de algo ilógico como las patentes de software. No es más que una guerra fría por intentar controlar el mercado de los teléfonos móviles con tácticas anticompetitivas, Apple y Microsoft están dispuestos a usar sus patentes para detener la comercialización de productos (Apple) o cobrar suculentas licencias (Microsoft). Ningún fabricante de móviles puede meterse en el mercado seriamente sin ser atacado por ellos, aunque la base legal sea absurda. Tras la compra de Motorola, parecía que Google iba a ser el chico bueno que protegiera a todos de ese peligro, pero por alguna razón Samsung o no se fía o ha optado por otra estrategia.
(Por cierto, quien nos lo hubiera dicho hace años. Gracias al chollo de las licencias de patentes para distribuidores de Android, es decir, gracias a una plataforma basada en Linux, Microsoft se embolsará 444$ millones en 2012).
Lo más chocante (y por chocante quiero decir "deprimente") de Tizen es el aspecto técnico. Uno pensaría que Samsung simplemente renombraría MeeGo a Tizen y se liaría a vender móviles basados en QT lo más pronto posible. Pero en el anuncio se habla de crear una plataforma de desarrollo nueva, algo inexplicable que retrasará la salida de los primeros productos hasta mediados del año que viene. La nueva plataforma estará basada en un engendro basado en HTML5 llamado WAC. WAC es algo que la mayoría de ustedes no conocerá (yo tampoco), pero que está apoyado por 48 compañías de telecomunicaciones y tiene detrás una organización con CEO y todo. Es decir, tiene toda la pinta de ser una carta de los reyes magos por parte de los directivos de las telecos para intentar crear un entorno multiplataforma que haga frente a iPhone/android. Otra manera de describirlo sería "intento desesperado de las operadoras por no perder el control sobre la plataformas de desarrollo". Yo dudo mucho que tenga futuro alguno, pero como en el mundo de la programación casi todo se puede echar a andar a base de sudor, sangre, juramentos, hacks a tutiplen y reescrituras, pues nunca se sabe.
¿Y dónde queda QT en todo esto? Pues se dice que se permitirá, pero vaya a saber usted en qué situación. En realidad no se sabe demasiado aun.
Por si todo esto no fuera ya de por si extraño, resulta que se ha sabido que Nokia, si, Nokia, está preparando un SO basado en Linux para sustituir a Symbian en teléfonos de bajo coste. Después de haberse vendido a Microsoft y haber desechado MeeGo, deben haberse dado cuenta de que Android ya se está comiendo el mercado de bajo coste del tercer mundo. Y he aquí una cosa divertida: resulta que Windows Phone, el SO en el que se van a jugar todo, sólo soporta una plataforma ARM, a diferencia de Linux, que soporta de todo. Mi teoría es que al no poder usar Windows Phone en teléfonos baratos y al estar Symbian al borde de la muerte, se están viendo obligados a recurrir a adaptar Maemo/MeeGo a toda prisa para teléfonos baratos. Pero lo hacen por su cuenta, sin tener relación con Tizen, MeeGo o nada que se le parezca, a pesar de que no hace tanto que teóricamente era el mismo SO. Otro absurdo más en la larga colección de acciones absurdas cometidas en la apresurada carrera por evitar ser aplastados por Android/iPhone.
22 de septiembre de 2011
Android en MeeGo
Está claro que a estas alturas no soy muy optimista sobre el futuro de MeeGo, pero uno no puede dejar de asombrarse ante noticias como esta: una compañía ha añadido a MeeGo la capacidad de ejecutar aplicaciones Android perfectamente integradas con el resto de entorno MeeGo.
Si Nokia había perdido la esperanza de poder tener una plataforma de desarrollo propia, puestos a subirse en el carro de una plataforma ajena podría haber optado por centrarse en MeeGo, añadir a una actualización este juguetito de la noticia, y sus usuarios tendrían tropecientas mil aplicaciones. Y lo más importante, podrían comprar y usarlo hoy mismo, sin necesidad de esperar. Pero en su lugar han optado por Windows Phone, una plataforma de la que el propio Steve Ballmer confiesa que llegar a tener el tercer puesto en cuota de mercado sería algo magnífico.
Ya sé que soy muy pesado con lo de Nokia y MeeGo, pero es que me asombra su capacidad de hundir un imperio en tiempo record. El N9, a pesar de que es una primera versión y de que no va estar disponible en países importantísimos, ha sido alabado por muchos y se ha vendido razonablemente bien en algunos sitios, pero por lo visto Nokia prefiere no vender teléfonos, e incitar a la gente a comprar cosas de la competencia diciéndoles que algún día sacarán algo con Windows Phone; el cual supuestamente va a gustar muchísimo a la gente a pesar de que, hasta hoy, no lo ha hecho.
Si Nokia había perdido la esperanza de poder tener una plataforma de desarrollo propia, puestos a subirse en el carro de una plataforma ajena podría haber optado por centrarse en MeeGo, añadir a una actualización este juguetito de la noticia, y sus usuarios tendrían tropecientas mil aplicaciones. Y lo más importante, podrían comprar y usarlo hoy mismo, sin necesidad de esperar. Pero en su lugar han optado por Windows Phone, una plataforma de la que el propio Steve Ballmer confiesa que llegar a tener el tercer puesto en cuota de mercado sería algo magnífico.
Ya sé que soy muy pesado con lo de Nokia y MeeGo, pero es que me asombra su capacidad de hundir un imperio en tiempo record. El N9, a pesar de que es una primera versión y de que no va estar disponible en países importantísimos, ha sido alabado por muchos y se ha vendido razonablemente bien en algunos sitios, pero por lo visto Nokia prefiere no vender teléfonos, e incitar a la gente a comprar cosas de la competencia diciéndoles que algún día sacarán algo con Windows Phone; el cual supuestamente va a gustar muchísimo a la gente a pesar de que, hasta hoy, no lo ha hecho.
21 de septiembre de 2011
C++11
He de admitir que nunca fui un gran fan de C++, pero hay que reconocer que con C++11 se ha puesto bastante interesante. Material sobre la nueva especificación hay a patadas, pero a mi me ha gustado este vídeo titulado "Writing modern C++ code", de alrededor de 1 hora (y si, de Microsoft), que compara los viejos hábitos con la nueva manera de hacer las cosas.
15 de septiembre de 2011
MeeGo, venta o muerte
Nos guste o no, la noticia de que Intel se ha aliado con Google para hacer que Android funcione perfectamente en su hardware es un acta de defunción para MeeGo. Por mucho que digan que seguirán soportando MeeGo junto a Android, es muy difícil creérselo, tan difícil como creer que a Nokia le importará QT una vez se hayan librado por completo de Symbian. MeeGo era una plataforma que para tener éxito necesitaba un apoyo al 100% de compañías como Nokia e Intel, y la situación actual está años luz de eso. Y recordemos que, al fin y al cabo, a Intel sólo le interesa vender procesadores y ganar su lucha particular con ARM, sea con el software que sea.
Todo esto podría dar la razón a los numerosos rumores sobre la posible "venta" de MeeGo a Samsung o HTC. Y, francamente, ojalá sea así. Es lo mejor que le podía pasar a MeeGo: Ser adquirido por un fabricante de hardware que ponga a la venta, de una puñetera vez, aparatos con MeeGo a cascoporro, que quiera aspirar a ser algo más que un mero distribuidor de Android, y quiera diferenciarse de todos (e imitar a Apple) con su propia plataforma. Aunque me parece más ciencia ficción que realidad, no deja de ser una posibilidad.
Pero cuando se habla, y hablamos, de "vender MeeGo", hay que tener en cuenta que, por ser un proyecto de software libre, está sujeto a muchas más variaciones que una venta normal. Si Samsung y HTC quisieran distinguirse utilizando MeeGo, podrían haberlo hecho hace tiempo, sin comprar nada a Intel. Podría referirse a comprar el copyright del código, las marcas comerciales, el sitio y los desarrolladores, pero por otra parte, cuando Intel dice que va a colaborar con Google para optimizar Android para sus productos, es muy posible que quiera decir "utilizaremos a nuestros expertos en Linux" (e Intel tiene en nómina a una cantidad de gente importante nada despreciable) "para optimizar Android". Es decir, mandar a los actuales desarrolladores de MeeGo a Android.
Nada está claro en esta historia, excepto que no es nada descartable que MeeGo muera, porque no interesa. Por "morir" no me refiero a que se deje de usar, por supuesto (hay pequeños fabricantes y gente aficionada que lo mantendrían vivo), sino a que muera para el esquema de las grandes cosas, y se limite a ser un capricho para un grupo muy reducido de gente.
Todo esto podría dar la razón a los numerosos rumores sobre la posible "venta" de MeeGo a Samsung o HTC. Y, francamente, ojalá sea así. Es lo mejor que le podía pasar a MeeGo: Ser adquirido por un fabricante de hardware que ponga a la venta, de una puñetera vez, aparatos con MeeGo a cascoporro, que quiera aspirar a ser algo más que un mero distribuidor de Android, y quiera diferenciarse de todos (e imitar a Apple) con su propia plataforma. Aunque me parece más ciencia ficción que realidad, no deja de ser una posibilidad.
Pero cuando se habla, y hablamos, de "vender MeeGo", hay que tener en cuenta que, por ser un proyecto de software libre, está sujeto a muchas más variaciones que una venta normal. Si Samsung y HTC quisieran distinguirse utilizando MeeGo, podrían haberlo hecho hace tiempo, sin comprar nada a Intel. Podría referirse a comprar el copyright del código, las marcas comerciales, el sitio y los desarrolladores, pero por otra parte, cuando Intel dice que va a colaborar con Google para optimizar Android para sus productos, es muy posible que quiera decir "utilizaremos a nuestros expertos en Linux" (e Intel tiene en nómina a una cantidad de gente importante nada despreciable) "para optimizar Android". Es decir, mandar a los actuales desarrolladores de MeeGo a Android.
Nada está claro en esta historia, excepto que no es nada descartable que MeeGo muera, porque no interesa. Por "morir" no me refiero a que se deje de usar, por supuesto (hay pequeños fabricantes y gente aficionada que lo mantendrían vivo), sino a que muera para el esquema de las grandes cosas, y se limite a ser un capricho para un grupo muy reducido de gente.
4 de septiembre de 2011
Más de Google+
Tras unas semanas usando Google+, tengo la sensación de que la entrada que le dedique se queda muy, muy corta. Así que he aquí una continuación. Por cierto, qué bonito el nuevo Blogger. Ya era hora.
Empezaré haciendo notar que en Google+ existe una actividad notable. Muchos no la perciben porque todo el mundo sigue usando Facebook, y aunque Google+ puede suplirlo, si uno pretende usarlo para contactar con sus amigos sufrirá, mientras no haya una hipotética migración en masa desde FB (que, de ocurrir, tardaría su tiempo), una decepción, al no tener a nadie que agregar, ni nada que hacer. Pero en Google+ se puede "seguir" a gente al estilo twitter, leer sus posts abiertos al público, y comentar en ellos (comentarios de verdad, en forma de hilo), así que la mayor parte de la gente parece dedicarse a ello: es decir, lo usan como una especie de sustituto de twitter/blogger.
En cuanto al modelo de privacidad y sus implicaciones, no dejo de verle ventajas. Dependiendo de con quien lo compartas, un mensaje de Google+ puede ser blog/twitter/notificaciónfacebook/miniforo de personas aficionadas a un tema...o incluso email. Uno de los usos más sorprendentes que me he encontrado es el envío de mensajes privados: se comparte un mensaje con una sola persona (en Google+ no hay "muros", solo mensajes que se comparten con personas), y cada uno va añadiendo comentarios, como una especie de IM asíncrono (había usado los mensajes privados de FB en el pasado, pero ni de lejos eran tan cómodos).
Otra de las cosas que me ha sorprendido es el número notable de hackers de Linux y software libre que se han apuntado...y que lo usan activamente: Linus Torvalds, Ingo Molnar, David Miller (redes), Lennart Poettering (systemd), Theodore Ts'o (ext4). Esto conduce a situaciones curiosas, como ver a Linus Torvalds, con su habitual estilo, opinando sobre el papel de los grupos ultraderechistas en la matanza de Noruega, leer a Ingo Molnar un blog-ladrillo sobre teoría monetaria y Bitcoin, enterarse antes que nadie de la existencia de un backend llvm para sparse, o leer un relato corto de Ricardo Gallir, el tipo de meneame.net.
En resumen, que el futuro de Google+ lo veo brillante: ya hoy, permite cierto tipo interacciones muy curiosas. Aunque sólo sea por comodidad, una red social que es capaz de imitar a otras es bastante interesante, poder escoger el modelo de red social a imitar en cada mensaje con un par de clicks es una "killer feature". Aunque tengo la impresión de que con perspectivas al futuro, Google+ pretende convertirse no tanto en algo específicamente diseñado para matar a FB, sino en un gigantesco generador y agregador de contenidos de todo tipo, especialmente de los servicios de Google: Eso, más que otra cosa, será lo que arrebate los usuarios a FB, me temo.
Ah, y enlace a mi perfil. No es muy útil, casi no hablo públicamente en él y cuando lo hago rara vez es de informática, pero alimenta mi ego.
Empezaré haciendo notar que en Google+ existe una actividad notable. Muchos no la perciben porque todo el mundo sigue usando Facebook, y aunque Google+ puede suplirlo, si uno pretende usarlo para contactar con sus amigos sufrirá, mientras no haya una hipotética migración en masa desde FB (que, de ocurrir, tardaría su tiempo), una decepción, al no tener a nadie que agregar, ni nada que hacer. Pero en Google+ se puede "seguir" a gente al estilo twitter, leer sus posts abiertos al público, y comentar en ellos (comentarios de verdad, en forma de hilo), así que la mayor parte de la gente parece dedicarse a ello: es decir, lo usan como una especie de sustituto de twitter/blogger.
En cuanto al modelo de privacidad y sus implicaciones, no dejo de verle ventajas. Dependiendo de con quien lo compartas, un mensaje de Google+ puede ser blog/twitter/notificaciónfacebook/miniforo de personas aficionadas a un tema...o incluso email. Uno de los usos más sorprendentes que me he encontrado es el envío de mensajes privados: se comparte un mensaje con una sola persona (en Google+ no hay "muros", solo mensajes que se comparten con personas), y cada uno va añadiendo comentarios, como una especie de IM asíncrono (había usado los mensajes privados de FB en el pasado, pero ni de lejos eran tan cómodos).
Otra de las cosas que me ha sorprendido es el número notable de hackers de Linux y software libre que se han apuntado...y que lo usan activamente: Linus Torvalds, Ingo Molnar, David Miller (redes), Lennart Poettering (systemd), Theodore Ts'o (ext4). Esto conduce a situaciones curiosas, como ver a Linus Torvalds, con su habitual estilo, opinando sobre el papel de los grupos ultraderechistas en la matanza de Noruega, leer a Ingo Molnar un blog-ladrillo sobre teoría monetaria y Bitcoin, enterarse antes que nadie de la existencia de un backend llvm para sparse, o leer un relato corto de Ricardo Gallir, el tipo de meneame.net.
En resumen, que el futuro de Google+ lo veo brillante: ya hoy, permite cierto tipo interacciones muy curiosas. Aunque sólo sea por comodidad, una red social que es capaz de imitar a otras es bastante interesante, poder escoger el modelo de red social a imitar en cada mensaje con un par de clicks es una "killer feature". Aunque tengo la impresión de que con perspectivas al futuro, Google+ pretende convertirse no tanto en algo específicamente diseñado para matar a FB, sino en un gigantesco generador y agregador de contenidos de todo tipo, especialmente de los servicios de Google: Eso, más que otra cosa, será lo que arrebate los usuarios a FB, me temo.
Ah, y enlace a mi perfil. No es muy útil, casi no hablo públicamente en él y cuando lo hago rara vez es de informática, pero alimenta mi ego.
31 de agosto de 2011
La nube y la guerra
Que la progresiva centralización de Internet en grandes centros de datos o "nubes" no trae sólo cosas buenas es algo sabido, sabemos que Google está obligada por las leyes antiterroristas de EEUU a proporcionar a las agencias de inteligencia las peticiones de información que se les requiera, sabemos que puede haber fallos de seguridad -fallos de seguridad que quizás aun no sean públicos- que permitan acceder a datos personales de cualquier persona...sabemos que existen las barreras de seguridad que existen en las nubes se saltan de modos muy variopintos. Pero de momento, al menos que yo sepa, no se han dado casos de ataques militares que tengan como objetivos centros de datos, una posibilidad bastante inquietante.
Las guerras y golpes de estado suelen centrarse en los puntos estratégicos. Una de las cosas que se suelen hacer hoy en día es tomar las sedes de televisiones y radios, el control de la propaganda es importante. ¿Que tienen las nubes de valor estratégico? Es difícil de concretar, porque la cantidad de datos que van acumulando las nubes es cada vez mayor y cada año se inventan cosas nuevas. Pero un mundo donde la utopía de hacer absolutamente todo a través del navegador se haga realidad, la toma de centros de datos bien podría convertirse en un objetivo tan valuable como las mismas televisiones y radios.
Y una vez tomado, saltarse las barreras de seguridad y acceder a todo tipo de información resulta tremendamente fácil. No sé qué barreras de seguridad internas tendrán compañías como Google, pero ya se sabe que ante un acceso físico, salvo de mediar un buen cifrado, todo es posible. Se sabe que Google tiene programas automatizados que leen nuestros datos para generar anuncios personalizados, asi que ha de ser posible sustituir ese programa por otro que busque la información requerida, es especialmente posible si apuntan al que sabe hacerlo con un fusil a la cabeza. ¿Se imaginan la infraestructura de Google empleada para buscar información sobre enemigos?
Si uno quiere pistas para localizar a un fugitivo, por ejemplo, es buena idea consultar la información asociada a perfil, leer sus emails, sus conversaciones, los últimos logins. Si uno quiere tener a mano una lista de personas que podrían conocer a un sujeto determinado, nada tan sencillo como aprovecharse del taggeo automático para localizar a todas las personas que salgan a su lado en cualquier foto (y si alguien tiene desactivado el taggeo automático no importa: se puede activar por fuerza). O simplemente por si sale su escondite en algún momento, y alguien le saca en el fondo de una foto sin querer. Y si un dictador paranoico quiere simplemente saber el nombre de todo sujeto que haya alabado a un partido enemigo, puede conseguirlo fácilmente. Y, por descontado, cualquier video, fotografía o texto desagradable puede eliminarse. Puede modificarse la función de autotagging para intentar reconocer logos del partido opuesto en las fotos. O se puede insertar en cada página web generada un logo del partido afin. En toda acción militar que pretenda controlar a la gente, los centros de datos son un objetivo muy interesante.
Todo esto no importa demasiado hoy, ya que la mayoría de centros de datos parecen estar en países civilizados, muchos de ellos en EEUU, y tomar militarmente un país donde mucha gente tiene un arma en casa no es sencillo, y por otra parte todos hacemos como que no nos enteramos del preocupante número de medidas que permiten allí vigilar al ciudadano con la excusa del terrorismo ya que presuponemos que verdaderamente sólo se usa con esa intención. Pero esto de los servicios web cada vez se extiende más, y poco a poco penetrará hasta en los países más ridículos como Corea del Norte. Y, por otro lado, nadie nos ha garantizado un futuro sin guerras.
Las guerras y golpes de estado suelen centrarse en los puntos estratégicos. Una de las cosas que se suelen hacer hoy en día es tomar las sedes de televisiones y radios, el control de la propaganda es importante. ¿Que tienen las nubes de valor estratégico? Es difícil de concretar, porque la cantidad de datos que van acumulando las nubes es cada vez mayor y cada año se inventan cosas nuevas. Pero un mundo donde la utopía de hacer absolutamente todo a través del navegador se haga realidad, la toma de centros de datos bien podría convertirse en un objetivo tan valuable como las mismas televisiones y radios.
Y una vez tomado, saltarse las barreras de seguridad y acceder a todo tipo de información resulta tremendamente fácil. No sé qué barreras de seguridad internas tendrán compañías como Google, pero ya se sabe que ante un acceso físico, salvo de mediar un buen cifrado, todo es posible. Se sabe que Google tiene programas automatizados que leen nuestros datos para generar anuncios personalizados, asi que ha de ser posible sustituir ese programa por otro que busque la información requerida, es especialmente posible si apuntan al que sabe hacerlo con un fusil a la cabeza. ¿Se imaginan la infraestructura de Google empleada para buscar información sobre enemigos?
Si uno quiere pistas para localizar a un fugitivo, por ejemplo, es buena idea consultar la información asociada a perfil, leer sus emails, sus conversaciones, los últimos logins. Si uno quiere tener a mano una lista de personas que podrían conocer a un sujeto determinado, nada tan sencillo como aprovecharse del taggeo automático para localizar a todas las personas que salgan a su lado en cualquier foto (y si alguien tiene desactivado el taggeo automático no importa: se puede activar por fuerza). O simplemente por si sale su escondite en algún momento, y alguien le saca en el fondo de una foto sin querer. Y si un dictador paranoico quiere simplemente saber el nombre de todo sujeto que haya alabado a un partido enemigo, puede conseguirlo fácilmente. Y, por descontado, cualquier video, fotografía o texto desagradable puede eliminarse. Puede modificarse la función de autotagging para intentar reconocer logos del partido opuesto en las fotos. O se puede insertar en cada página web generada un logo del partido afin. En toda acción militar que pretenda controlar a la gente, los centros de datos son un objetivo muy interesante.
Todo esto no importa demasiado hoy, ya que la mayoría de centros de datos parecen estar en países civilizados, muchos de ellos en EEUU, y tomar militarmente un país donde mucha gente tiene un arma en casa no es sencillo, y por otra parte todos hacemos como que no nos enteramos del preocupante número de medidas que permiten allí vigilar al ciudadano con la excusa del terrorismo ya que presuponemos que verdaderamente sólo se usa con esa intención. Pero esto de los servicios web cada vez se extiende más, y poco a poco penetrará hasta en los países más ridículos como Corea del Norte. Y, por otro lado, nadie nos ha garantizado un futuro sin guerras.
16 de agosto de 2011
Cómo pasar una tarde entretenida
· Baja un ejecutable dudoso en Windows.
· Pásale el antivirus de Microsoft, actualizado. No detecta nada.
· Ejecuta el programa. ¡El antivirus de Microsoft detecta un nuevo virus!
· Al puñetero virus le da por infectar algún archivo relacionado con la red (parece ser que para redirigir las búsquedas de Google y lanzar popups). El antivirus procede a eliminarlo.
· Durante el proceso de eliminación, que incluye un reinicio, el antivirus parece tocar algo relacionado con ipsec .
· Los logs indican que los servicios básicos de red, empezando por IPsec y los que dependen de él, no arrancan: la conexión wireless se conecta al router pero no hay red, el navegador no funciona. Ya no hay virus, está eliminado, pero el antivirus ha roto algo. Las herramientas de sysinternals no dan pistas sobre el qué.
Tras un par de horas, me doy por vencido: reinstalación. Estoy seguro que hay gente capaz de limpiar esta basura, pero no les envidio.
PD: Por los comentarios del hilo, parece que algún alma despistada parece no darse cuenta que el virus no ha dado mayores problemas -las instrucciones para eliminarlo manualmente no pueden ser más sencillas-, ha sido el antivirus de Microsoft el que ha fastidiado el sistema.
· Pásale el antivirus de Microsoft, actualizado. No detecta nada.
· Ejecuta el programa. ¡El antivirus de Microsoft detecta un nuevo virus!
· Al puñetero virus le da por infectar algún archivo relacionado con la red (parece ser que para redirigir las búsquedas de Google y lanzar popups). El antivirus procede a eliminarlo.
· Durante el proceso de eliminación, que incluye un reinicio, el antivirus parece tocar algo relacionado con ipsec .
· Los logs indican que los servicios básicos de red, empezando por IPsec y los que dependen de él, no arrancan: la conexión wireless se conecta al router pero no hay red, el navegador no funciona. Ya no hay virus, está eliminado, pero el antivirus ha roto algo. Las herramientas de sysinternals no dan pistas sobre el qué.
Tras un par de horas, me doy por vencido: reinstalación. Estoy seguro que hay gente capaz de limpiar esta basura, pero no les envidio.
PD: Por los comentarios del hilo, parece que algún alma despistada parece no darse cuenta que el virus no ha dado mayores problemas -las instrucciones para eliminarlo manualmente no pueden ser más sencillas-, ha sido el antivirus de Microsoft el que ha fastidiado el sistema.
¿Telefonos preparados para el software libre?
A estas alturas todo el mundo estará enterado del notición bomba de la compra de Motorola Mobility por parte de Google. Como todo el mundo está opinando, yo no voy a ser menos. No me hice un blog para estar callado.
En primer lugar, creo que hay que dejar claro que esta compra es un noticia mala, pésima, para la industria del software. No por si misma, sino por lo que la motiva. Partamos de que, como ha señalado todo el mundo, el objeto de Google es poseer las 17.000 patentes + 7.000 pendientes de Motorola para proteger a Android contra ataques legales (no es sólo que resulte poco creíble que quieran pagar 12.500$ millones para vender hardware, es que lo resaltan ellos en el propio anuncio). Esto significa que Google se ha visto obligada a gastarse 12.500$ millones en actividades absurdas e improductivas como las patentes de software, unos vastísimos recursos monetarios que de otro modo se habrían utilizado en inversión productiva (o en recompensar la innovación con casinos y furcias). El talento de Google y el progreso de la informática hacen posible sobreponerse a estas penalizaciones, pero no es ni mucho menos una situación ideal. Esta industria podría progresar aun más rápido con una regulación adecuada.
Eso si, si aceptamos el juego de las patentes y pasamos por alto lo mucho que apesta, los dos Steve, Jobs y Ballmer, deben estar poco contentos. Ambos tenían montañas de millones con vocación de adquisiciones estratégicas grandiosas como la de Nortel, y ambos han dejado que su principal competidor en teléfonos se compre un magnífico escudo a prueba de patentes.
Pero intentemos ver el lado positivo: A partir de ahora Google fabricará móviles propios, y es muy posible que esto conlleve una mayor apertura en las relaciones entre hardware y software libre. Es cierto que aunque Google tiene una forma muy particular de entender el software libre, y que los fabricantes de teléfonos android tienen a veces sus cosas, las cosas no estan tan mal, pero se puede mejorar. El estado de los drivers libres de hardware Android (por no hablar de su inclusión en Linux) es mejorable, y aquí los futuros teléfonos de Google/Motorola pueden ayudar. Eso facilitaría a otras plataformas libres alternativas no-Android, o a personalizaciones variopintas de Android, producir ROMs con facilidad para estos teléfonos.
Por cierto, que una vez más no entiendo a los mercados. 12.500$ millones es una cifra obscena, dificil de apoquinar hasta para Google, que no van a recuperar a corto plazo y posiblemente ni siquiera a largo, por muchos teléfonos que vendan. Es una compra para beneficiar principalmente a terceros, pero los inversores no parecen estar furiosos, lo cual confirma que la valoración en bolsa de Google es más cuestión de fe que de otra cosa. La verdad, no me extraña que Warren Buffet no quiera invierta ni un dólar en compañías de un sector tan extravagante.
En primer lugar, creo que hay que dejar claro que esta compra es un noticia mala, pésima, para la industria del software. No por si misma, sino por lo que la motiva. Partamos de que, como ha señalado todo el mundo, el objeto de Google es poseer las 17.000 patentes + 7.000 pendientes de Motorola para proteger a Android contra ataques legales (no es sólo que resulte poco creíble que quieran pagar 12.500$ millones para vender hardware, es que lo resaltan ellos en el propio anuncio). Esto significa que Google se ha visto obligada a gastarse 12.500$ millones en actividades absurdas e improductivas como las patentes de software, unos vastísimos recursos monetarios que de otro modo se habrían utilizado en inversión productiva (o en recompensar la innovación con casinos y furcias). El talento de Google y el progreso de la informática hacen posible sobreponerse a estas penalizaciones, pero no es ni mucho menos una situación ideal. Esta industria podría progresar aun más rápido con una regulación adecuada.
Eso si, si aceptamos el juego de las patentes y pasamos por alto lo mucho que apesta, los dos Steve, Jobs y Ballmer, deben estar poco contentos. Ambos tenían montañas de millones con vocación de adquisiciones estratégicas grandiosas como la de Nortel, y ambos han dejado que su principal competidor en teléfonos se compre un magnífico escudo a prueba de patentes.
Pero intentemos ver el lado positivo: A partir de ahora Google fabricará móviles propios, y es muy posible que esto conlleve una mayor apertura en las relaciones entre hardware y software libre. Es cierto que aunque Google tiene una forma muy particular de entender el software libre, y que los fabricantes de teléfonos android tienen a veces sus cosas, las cosas no estan tan mal, pero se puede mejorar. El estado de los drivers libres de hardware Android (por no hablar de su inclusión en Linux) es mejorable, y aquí los futuros teléfonos de Google/Motorola pueden ayudar. Eso facilitaría a otras plataformas libres alternativas no-Android, o a personalizaciones variopintas de Android, producir ROMs con facilidad para estos teléfonos.
Por cierto, que una vez más no entiendo a los mercados. 12.500$ millones es una cifra obscena, dificil de apoquinar hasta para Google, que no van a recuperar a corto plazo y posiblemente ni siquiera a largo, por muchos teléfonos que vendan. Es una compra para beneficiar principalmente a terceros, pero los inversores no parecen estar furiosos, lo cual confirma que la valoración en bolsa de Google es más cuestión de fe que de otra cosa. La verdad, no me extraña que Warren Buffet no quiera invierta ni un dólar en compañías de un sector tan extravagante.
4 de agosto de 2011
Usar Linux ya no es lo que era
Mientras leo la lista de cambios a una actualización de la BIOS de una placa base de Intel (si, Intel también fabrica placas base, y no, por desgracia no es la mia) me encuentro con esto:
· Fixed issue where S3 resume fails in Linux
Para quienes conozcan los detalles del infierno de las BIOS, esto es algo así como la gloria celestial. ¡Programadores de BIOS que prueban Linux y corrigen bugs! Si a eso le unimos que los gráficos integrados de los procesadores Sandy Bridge están bien soportados, y que su rendimiento ha mejorado considerablemente respecto a anteriores generaciones (al menos para los que pasamos olímpicamente de los juegos), comprenderán por qué algunos solemos comprar Intel.
Pero si prefieren AMD, resulta que sus gráficos integrados, Fusion, también están muy bien soportados. Y, por si eso fuera poco, soportan y colaboran con Coreboot.
Por otra parte, Linux monopoliza los 500 superordenadores más grandes del planeta, y al mismo tiempo está camino de dominar ampliamente los teléfonos.
Definitivamente, usar Linux ya no es lo que era.
· Fixed issue where S3 resume fails in Linux
Para quienes conozcan los detalles del infierno de las BIOS, esto es algo así como la gloria celestial. ¡Programadores de BIOS que prueban Linux y corrigen bugs! Si a eso le unimos que los gráficos integrados de los procesadores Sandy Bridge están bien soportados, y que su rendimiento ha mejorado considerablemente respecto a anteriores generaciones (al menos para los que pasamos olímpicamente de los juegos), comprenderán por qué algunos solemos comprar Intel.
Pero si prefieren AMD, resulta que sus gráficos integrados, Fusion, también están muy bien soportados. Y, por si eso fuera poco, soportan y colaboran con Coreboot.
Por otra parte, Linux monopoliza los 500 superordenadores más grandes del planeta, y al mismo tiempo está camino de dominar ampliamente los teléfonos.
Definitivamente, usar Linux ya no es lo que era.
22 de julio de 2011
Las novedades de Linux 3.0
Ya se ha anunciado (por diferentes canales)la versión 3.0 del kernel Linux.
Aparte de un nuevo sistema de numerar versiones, este kernel tiene unas cuantas novedades: defragmentación automática y 'scrubbing' de datos en Btrfs, envío de mensajes ICMP_ECHO sin privilegios, wake on WLAN, filtrado de paquetes BFP acelerado mediante JIT, soporte de XEN dom0, un sistema a lo memcached para el caché tde páginas, la llamada al sistema sendmmsg() que envía múltiples instancias de sendmsg(), la llamada al sistema setns() para gestionar mejor los sistemas de virtualización ligera, como los contenedores, soporte de nuevo hardware como por ejemplo Microsoft Kinect y APUs AMD Llano Fusion, y muchos otros drivers y pequeños cambios. La lista completa de
cambios, en inglés, puede encontrarse aquí, como siempre.
· Btrfs: defragmentación automática, scrubbing, mejoras de rendimiento
· Defragmentación automática: Los sistemas de archivos COW (copy-on-write, copiar-al-escribir) tienen muchas ventajas, pero también algunas desventajas, como por ejemplo la fragmentación. Cuando Btrfs escribe un archivo al disco por primera vez lo hace secuencialmente, pero el diseño COW implica que cualquier modificación posterior no debe reescribir los datos antiguos, sino escribirlos en un bloque libre del disco, lo cual causa fragmentación (las bases de datos RPM son un caso común de este problema). Además, están los problemas de fragmentación comunes a todos los sistemas de archivos. Btrfs ya ofrecía algunas alternativas para luchar contra este problema. En primer lugar, soporta defragmentación en vivo utilizando el comando "btrfs filesystem defragment". En segundo lugar, tiene una opción de montaje, -o nodatacow, que desactiva el COW para los datos. Ahora se añade una tercera opción, la opción de montaje -o autodefrag. Este mecanismo detecta pequeñas escrituras aleatorias en los archivos y los defragmenta automática y transparentemente, sin intervención del usuario. Aun no funciona bien con imágenes de virtualización o grandes bases de datos, pero funciona bien para los archivos pequeños como bases de datos rpm, sqlite o bdb.
· Scrubbing
"Scrubbing", que podría traducirse como "fregar", o "restregar", consiste en comprobar la integridad de todos los datos del sistema de archivos: Se van comprobando los checksums de todos los datos, y si hay alguno erróneo, o el disco está dañado, se restaura una copia en buen estado, de haberla.
· Mayor velocidad de creación/eliminación de archivos: Btrfs tiene bajo rendimiento en la creación/eliminación de archivos, la razón es que cada creación/eliminación necesita hacer modificaciones en el b+tree, como insertar o eliminar un item de inodo, de nombre de directorio, índice de directorio, etc. Ahora btrfs puede retrasar la inserción/eliminación de items en el b+tree, lo que permite acumular modificaciones y hacerlas todas de una vez. Los microbenchmarks de creación de archivos se han acelerado un ~15%, los de eliminación un 20%.
· No escribir al disco items de checksum de datos que no han cambiado: Mejora el rendimiento de fsync. Un benchmark sysbench haciendo "escritura aleatoria + fsync" ha aumentado de 112.75 peticiones/segundo a 1216 requests/seg.
· Asignador de espacio en configuraciones con múltiples discos: El asignador de "chunks" (el que busca espacio para usar en el disco) siempre asigna el espacio en las configuraciones multidisco en el mismo orden. Esto causa una distribución de los datos subóptima, especialmente usando RAID1/10 y un número impar de dispositivos. Ahora btrfs intenta buscar espacio en primer lugar en los discos con más espacio.
· sendmmsg(): acumulación de llamadas a sendmsg():
recvmsg() y sendmsg() son las llamadas al sistema que se utilizan para recibir/enviar datos a la red. En Linux 2.6.33 se añadió recvmmsg(), una llamada al sistema que permite recibir en una sola llamada al sistema los datos de varias llamadas recvmsg(), lo cual mejora el rendimiento y la latencia en muchos casos. Ahora, se ha añadido su equivalente sendmmsg(). Los microbenchmarks muestran una mejora de ancho de banda en el envío de tráfico UDP del 20% y un 30% en sockets raw.
· Soporte de Xem Dom0: Por fin, Linux tiene soporte del modo Dom0 de Xen, requisito para poder funcionar como host Xen sin parches.
· Cleancache: Cleancache es algo opcional que permite aumentar el rendimiento del caché de páginas del kernel. Podría describirse como algo análogo a memcached, pero para páginas de cache. Proporciona un almacenamiento no directamente direccionable por el kernel, que no garantiza que los datos que se escriban en él no desaparecerán. Puede ser usado por sistemas de virtualización para mejorar la gestión de memoria de las VMs, pero también puede usarse para implementar un caché comprimido.
· Filtrado de paquetes BPF mediante JIT: El filtrado de Berkeley Packet Filter, que es lo que utilizan herramientas como libpcap/tcpdump, normalmente se hace con un intérprete. En esta versión se ha añadido un JIT que genera código nativo para los filtros, y hace que el filtrado sea mucho más rápido. Aunque pueda parecer una exageración tener un JIT en el kernel, lo cierto es que se trata de un JIT muy, muy simple, y es algo que otros sistemas operativos, como FreeBSD, tienen desde hace años.
· Wake on WLAN: Wake-on-LAN es la capacidad de que un sistema dormido pueda ser "despertado" por un paquete de red especial. En esta versión se añade en la implementación 802.11 la misma capacidad, pero para tarjetas de red inalámbricas.
· Mensajes ICMP_ECHO sin privilegios: Esta versión permite enviar mensajes ICMP_ECHO (es decir, un ping) sin necesidad de privilegios de root, lo cual permite que la herramienta ping no requiera setuid.
· Llamada al sistema netns(): Linux soporta diferentes espacios de nombre para los diferentes recursos que gestiona; por ejemplo, las formas ligeras de virtualización, como los contenedores o systemd-nspaw, muestran a los procesos virtualizados un PID virtual en lugar del PID real. Lo mismo puede hacerse con la estructura de directorios del sistema de archivos, los recursos de red, IPC, etc. La única manera de configurar diferentes espacios de nombre es usar diferentes flags en la llamada al sistema clone(), pero ese método no permite hacer cierto tipo de cosas, como permitir que un proceso acceda al espacio de nombres de otro proceso. La llamada al sistema setns() resuelve ese problema.
· Temporizadores-alarma: Los temporizadores-alarma son temporizadores híbridos, similares a los temporizadores de alta resolución, sólo que cuando se suspende el sistema, se activa el RTC para que se dispare y despierte el sistema.Este concepto está inspirado en los temporizadores-alarma de Android, y la API usa la interfaz de relojería POSIX.
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.
· Btrfs: defragmentación automática, scrubbing, mejoras de rendimiento
· Defragmentación automática: Los sistemas de archivos COW (copy-on-write, copiar-al-escribir) tienen muchas ventajas, pero también algunas desventajas, como por ejemplo la fragmentación. Cuando Btrfs escribe un archivo al disco por primera vez lo hace secuencialmente, pero el diseño COW implica que cualquier modificación posterior no debe reescribir los datos antiguos, sino escribirlos en un bloque libre del disco, lo cual causa fragmentación (las bases de datos RPM son un caso común de este problema). Además, están los problemas de fragmentación comunes a todos los sistemas de archivos. Btrfs ya ofrecía algunas alternativas para luchar contra este problema. En primer lugar, soporta defragmentación en vivo utilizando el comando "btrfs filesystem defragment". En segundo lugar, tiene una opción de montaje, -o nodatacow, que desactiva el COW para los datos. Ahora se añade una tercera opción, la opción de montaje -o autodefrag. Este mecanismo detecta pequeñas escrituras aleatorias en los archivos y los defragmenta automática y transparentemente, sin intervención del usuario. Aun no funciona bien con imágenes de virtualización o grandes bases de datos, pero funciona bien para los archivos pequeños como bases de datos rpm, sqlite o bdb.
· Scrubbing
"Scrubbing", que podría traducirse como "fregar", o "restregar", consiste en comprobar la integridad de todos los datos del sistema de archivos: Se van comprobando los checksums de todos los datos, y si hay alguno erróneo, o el disco está dañado, se restaura una copia en buen estado, de haberla.
· Mayor velocidad de creación/eliminación de archivos: Btrfs tiene bajo rendimiento en la creación/eliminación de archivos, la razón es que cada creación/eliminación necesita hacer modificaciones en el b+tree, como insertar o eliminar un item de inodo, de nombre de directorio, índice de directorio, etc. Ahora btrfs puede retrasar la inserción/eliminación de items en el b+tree, lo que permite acumular modificaciones y hacerlas todas de una vez. Los microbenchmarks de creación de archivos se han acelerado un ~15%, los de eliminación un 20%.
· No escribir al disco items de checksum de datos que no han cambiado: Mejora el rendimiento de fsync. Un benchmark sysbench haciendo "escritura aleatoria + fsync" ha aumentado de 112.75 peticiones/segundo a 1216 requests/seg.
· Asignador de espacio en configuraciones con múltiples discos: El asignador de "chunks" (el que busca espacio para usar en el disco) siempre asigna el espacio en las configuraciones multidisco en el mismo orden. Esto causa una distribución de los datos subóptima, especialmente usando RAID1/10 y un número impar de dispositivos. Ahora btrfs intenta buscar espacio en primer lugar en los discos con más espacio.
· sendmmsg(): acumulación de llamadas a sendmsg():
recvmsg() y sendmsg() son las llamadas al sistema que se utilizan para recibir/enviar datos a la red. En Linux 2.6.33 se añadió recvmmsg(), una llamada al sistema que permite recibir en una sola llamada al sistema los datos de varias llamadas recvmsg(), lo cual mejora el rendimiento y la latencia en muchos casos. Ahora, se ha añadido su equivalente sendmmsg(). Los microbenchmarks muestran una mejora de ancho de banda en el envío de tráfico UDP del 20% y un 30% en sockets raw.
· Soporte de Xem Dom0: Por fin, Linux tiene soporte del modo Dom0 de Xen, requisito para poder funcionar como host Xen sin parches.
· Cleancache: Cleancache es algo opcional que permite aumentar el rendimiento del caché de páginas del kernel. Podría describirse como algo análogo a memcached, pero para páginas de cache. Proporciona un almacenamiento no directamente direccionable por el kernel, que no garantiza que los datos que se escriban en él no desaparecerán. Puede ser usado por sistemas de virtualización para mejorar la gestión de memoria de las VMs, pero también puede usarse para implementar un caché comprimido.
· Filtrado de paquetes BPF mediante JIT: El filtrado de Berkeley Packet Filter, que es lo que utilizan herramientas como libpcap/tcpdump, normalmente se hace con un intérprete. En esta versión se ha añadido un JIT que genera código nativo para los filtros, y hace que el filtrado sea mucho más rápido. Aunque pueda parecer una exageración tener un JIT en el kernel, lo cierto es que se trata de un JIT muy, muy simple, y es algo que otros sistemas operativos, como FreeBSD, tienen desde hace años.
· Wake on WLAN: Wake-on-LAN es la capacidad de que un sistema dormido pueda ser "despertado" por un paquete de red especial. En esta versión se añade en la implementación 802.11 la misma capacidad, pero para tarjetas de red inalámbricas.
· Mensajes ICMP_ECHO sin privilegios: Esta versión permite enviar mensajes ICMP_ECHO (es decir, un ping) sin necesidad de privilegios de root, lo cual permite que la herramienta ping no requiera setuid.
· Llamada al sistema netns(): Linux soporta diferentes espacios de nombre para los diferentes recursos que gestiona; por ejemplo, las formas ligeras de virtualización, como los contenedores o systemd-nspaw, muestran a los procesos virtualizados un PID virtual en lugar del PID real. Lo mismo puede hacerse con la estructura de directorios del sistema de archivos, los recursos de red, IPC, etc. La única manera de configurar diferentes espacios de nombre es usar diferentes flags en la llamada al sistema clone(), pero ese método no permite hacer cierto tipo de cosas, como permitir que un proceso acceda al espacio de nombres de otro proceso. La llamada al sistema setns() resuelve ese problema.
· Temporizadores-alarma: Los temporizadores-alarma son temporizadores híbridos, similares a los temporizadores de alta resolución, sólo que cuando se suspende el sistema, se activa el RTC para que se dispare y despierte el sistema.Este concepto está inspirado en los temporizadores-alarma de Android, y la API usa la interfaz de relojería POSIX.
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.
15 de julio de 2011
Cómo instalar Fedora 15, u otra distro, sobre Btrfs como mandan los cánones
Hace ya meses que la cuenta de sectores relocalizados de mi disco duro (sectores dañados cuya referencia se modifica para que apunten a otros en buen estado) era demasiado preocupante, una especie de señal divina advirtiendo de que era hora de cambiar de disco, así que he aprovechado para conseguirle no un reemplazo, sino dos (con sus correspondientes ventiladores), y de ese modo dar a btrfs un hogar más apropiado.
Pero al comenzar una instalación nueva de Fedora 15, con ese inexplicable deseo de convertirla en espejo y honra de todos los administradores, me encontré con un problema que no había resuelto en la anterior instalación, y que ahora podía aprovechar resolver. Se trata de hacer, desde el principio, una instalación acondicionada para convivir con los subvolúmenes de btrfs.
En btrfs, los subvolumenes (que podrían describirse confusamente como pseudosistemas de archivos vacíos creados a partir del espacio disponible) son añadidos a la raíz del sistema de archivos como directorios. Una buena instalación sobre btrfs debería dejar ese directorio raíz exclusivamente para subvolúmenes, e instalar cosas dentro de estos. Por ejemplo, tendríamos un subvolumen "/raiz-fedora/" con la instalación de Fedora, otro "/raiz-debian/" con la de Debian, y un cursi "/casita/" para los datos personales. El problema está en que los instaladores de las distros no tienen nociones de subvolúmenes (Fedora los tendrá en la próxima versión), no permiten crearlos; y, lo que es más puntilloso, tampoco permiten montar unos que se hayan creado a mano fuera de la instalación, así que te instalan todo en la raíz principal. Se puede solucionar posteriormente a base copiar archivos y modificar el fstab, no digo que no, pero hay una alternativa, que cuento aquí porque no he logrado encontrarla en Google.
Resulta que btrfs permite configurar un subvolumen determinado como directorio raíz, es decir, podemos hacer que al montar el sistema de archivos, en lugar del directorio raíz contenedor de todos los subvolúmenes, monte /raiz-fedora o /raiz-debian. Así que, metidos en la tarea...
Con esto se crea un "pool" de almacenamiento consistente de esos dos discos, con la configuración de RAID0 (distribución) para datos y RAID1 (replicación) para metadatos (en un futuro se podrán tener diferentes políticas para cada subvolumen, pero de momento...)
Con esto se han creado los subvolúmenes requeridos.
Con esto se consigue que cada vez que se monte el sistema de archivos se monte directamente el subvolumen raiz-fedora, y no la verdadera raiz, que quedará oculta a primera vista (se puede volver a montar pasando a mount la opción -o subvolid=0). Ahora se puede instalar Fedora -con el DVD de instalación, no el Live, y pasando "btrfs" como opción del kernel-, y bastará indicar al instalador que se utilize /dev/disco1particion como raíz /: sin que el instalador se percate, estará instalando sus cosas en el subvolumen raiz-fedora.
Queda lo de poner al subvolumen casita como "/home". Una vez terminada la instalación, y antes de entrar por primera vez en la sesión, se puede entrar a una consola y modificar el /etc/fstab, añadiendo la línea correspondiente y, si apetece, adornar la de la raiz:
Tras esto, un reinicio, un mount -a o un montaje manual montará el subvolumen casita donde corresponde, aunque hay que acordarse de dar permisos adecuados al nuevo directorio /home (chmod o+rx /home). Ya puestos en la tarea, parecería apropiado crear el directorio del usuario que ya se había creado en los diálogos de inicio: mkdir /home/usuario; chown usuario:usuario /home/usuario - bonus para quien sea lo suficientemente diligente para, antes de montar el subvolumen en /home/, mover el directorio de usuario que la instalación había creado a, por ejemplo, /tmp, y devolverlo luego a su sitio natural.
Pero no se fíen, que siempre está SELinux para hacer la puñeta. Además de dar permisos a todos los usuarios en el nuevo montaje /home, es necesario darle el contexto SELinux adecuado, y también a /home/usuario, especialmente si quieren mover todos sus archivos personales de una instalación anterior. Así que queda un último comando: restorecon -R /home. Y, ahora si, todo completado.
Pero al comenzar una instalación nueva de Fedora 15, con ese inexplicable deseo de convertirla en espejo y honra de todos los administradores, me encontré con un problema que no había resuelto en la anterior instalación, y que ahora podía aprovechar resolver. Se trata de hacer, desde el principio, una instalación acondicionada para convivir con los subvolúmenes de btrfs.
En btrfs, los subvolumenes (que podrían describirse confusamente como pseudosistemas de archivos vacíos creados a partir del espacio disponible) son añadidos a la raíz del sistema de archivos como directorios. Una buena instalación sobre btrfs debería dejar ese directorio raíz exclusivamente para subvolúmenes, e instalar cosas dentro de estos. Por ejemplo, tendríamos un subvolumen "/raiz-fedora/" con la instalación de Fedora, otro "/raiz-debian/" con la de Debian, y un cursi "/casita/" para los datos personales. El problema está en que los instaladores de las distros no tienen nociones de subvolúmenes (Fedora los tendrá en la próxima versión), no permiten crearlos; y, lo que es más puntilloso, tampoco permiten montar unos que se hayan creado a mano fuera de la instalación, así que te instalan todo en la raíz principal. Se puede solucionar posteriormente a base copiar archivos y modificar el fstab, no digo que no, pero hay una alternativa, que cuento aquí porque no he logrado encontrarla en Google.
Resulta que btrfs permite configurar un subvolumen determinado como directorio raíz, es decir, podemos hacer que al montar el sistema de archivos, en lugar del directorio raíz contenedor de todos los subvolúmenes, monte /raiz-fedora o /raiz-debian. Así que, metidos en la tarea...
# mkfs.btrfs -d raid0 -m raid1 -L btrfspool /dev/disco1particion /dev/disco2particion Con esto se crea un "pool" de almacenamiento consistente de esos dos discos, con la configuración de RAID0 (distribución) para datos y RAID1 (replicación) para metadatos (en un futuro se podrán tener diferentes políticas para cada subvolumen, pero de momento...)
# mount /dev/sdb /mnt; cd /mnt # btrfs subvolume create raiz-fedora Create subvolume './raiz-fedora'# btrfs subvolume create casita Create subvolume './casita'
Con esto se han creado los subvolúmenes requeridos.
# btrfs subvolume list /mnt
ID 256 top level 5 path raiz-fedora
ID 257 top level 5 path casita# btrfs subvolume set-default 256 /mnt Con esto se consigue que cada vez que se monte el sistema de archivos se monte directamente el subvolumen raiz-fedora, y no la verdadera raiz, que quedará oculta a primera vista (se puede volver a montar pasando a mount la opción -o subvolid=0). Ahora se puede instalar Fedora -con el DVD de instalación, no el Live, y pasando "btrfs" como opción del kernel-, y bastará indicar al instalador que se utilize /dev/disco1particion como raíz /: sin que el instalador se percate, estará instalando sus cosas en el subvolumen raiz-fedora.
Queda lo de poner al subvolumen casita como "/home". Una vez terminada la instalación, y antes de entrar por primera vez en la sesión, se puede entrar a una consola y modificar el /etc/fstab, añadiendo la línea correspondiente y, si apetece, adornar la de la raiz:
UUID=numero-raro / btrfs defaults,subvol=raiz-fedora 1 1UUID=mismo-numero-raro /home btrfs defaults,subvol=casita 1 1 Tras esto, un reinicio, un mount -a o un montaje manual montará el subvolumen casita donde corresponde, aunque hay que acordarse de dar permisos adecuados al nuevo directorio /home (chmod o+rx /home). Ya puestos en la tarea, parecería apropiado crear el directorio del usuario que ya se había creado en los diálogos de inicio: mkdir /home/usuario; chown usuario:usuario /home/usuario - bonus para quien sea lo suficientemente diligente para, antes de montar el subvolumen en /home/, mover el directorio de usuario que la instalación había creado a, por ejemplo, /tmp, y devolverlo luego a su sitio natural.
Pero no se fíen, que siempre está SELinux para hacer la puñeta. Además de dar permisos a todos los usuarios en el nuevo montaje /home, es necesario darle el contexto SELinux adecuado, y también a /home/usuario, especialmente si quieren mover todos sus archivos personales de una instalación anterior. Así que queda un último comando: restorecon -R /home. Y, ahora si, todo completado.
14 de julio de 2011
10 de julio de 2011
Google++
Hay que reconocer que la estrategia de las invitaciones es un gran idea: se controla el número de usuarios durante el periodo de pruebas, y al mismo tiempo la gente hace ruido para entrar. De todos modos Google parece haber abierto en los últimos días el caudal de invitaciones, así que no tardarán en llegar a todo el mundo.
Pueden estar tranquilos, no voy a hablar sobre teoría de simetrías en las relaciones de redes sociales y en qué lado cae Google+, en parte porque no sé nada sobre el tema, y también porque otros ya lo han hecho. En general, los Círculos me parecen una buena idea. Se dice que esa manera de gestionar los contactos es más difícil de manejar que otras, pero esa afirmación sólo es cierta tomada como argumento técnico, desde el punto de vista de las relaciones sociales del mundo real los círculos son, en mi opinión, más intuitivos y comprensibles porque se corresponden con mayor fidelidad con la vida cotidiana.
Facebook desprecia ese punto de vista, y por eso nunca terminó de gustarme. Aunque allí se pueden gestionar los contactos en grupos, su filosofía es la de intentar apartar al usuario de ellos. Al fin y al cabo, Mark Zuckerberg cree que a la sociedad actual no le importa la privacidad, que las costumbres sociales han cambiado radicalmente (para coincidir asombrosamente con las reglas de privacidad de su web). Naturalmente, no deja de haber verdad en que hoy en día la gente quiere compartir muchas cosas con todo el mundo, pero la lista de excepciones es como para parar un tren.
El simple hecho de que las meteduras de pata en Facebook con padres, jefes o parejas se hayan convertido en fuente de humor en Internet debería ser tomado como una prueba obvia -un reporte de bug- de que hay problemas en la concepción de Facebook, de que deberían intentar evitarse esos casos para que sólo puedan ocurrir por meteduras de pata gigantescas, y no por no haberte parado a preveer la opinión de cada uno de tus cientos de contactos, pero eso a Zuckerger no parece importarle. En cambio, la idea de Google+ parece aspirar a que uno pueda tener en sus contactos a sus familiares cercanos, a compañeros de trabajo, a gente aficionada a pornografía judía y a gente del partido nazi local, y gestionarlos todos en un perfil común con la confianza de que uno no meterá la pata tan fácilmente. Google+ está pensado para la doble vida.
Google+ tiene, además, funciones como Hangout y Huddle, magníficas ideas para gestionar relaciones sociales y que encajan perfectamente con el concepto de círculos. La respuesta de Facebook a esto ha sido añadir un soporte de Skype que sólo permite videoconferencia entre dos, mientas que los Hangouts de Google+ permiten videoconferencia entre 10 personas, muy cómodo para pequeños grupos de trabajo en una empresa o reuniones familiares virtuales.
Pero dejando de un lado el tema de la gestión de contactos, que al fin y al cabo probablemente sufrirá modificaciones en el futuro, detrás de Google+ hay una finalidad que es tan ambiciosa como la de rivalizar con Facebook, la de convertirse en el punto de integración de todos los servicios de Google. Hace mucho tiempo que llevan intentándolo sin éxito y parece que esta vez será la buena, la información interna que se conoce apunta en esa dirección, casi todos los servicios de Google podrían añadir funcionalidad para compartir datos o notificar de acciones a otros usuarios, por ejemplo, las actualizaciones de este blog podrían ser notificadas automáticamente en Google+ a los círculos que yo prefiera, o, mejor aun, a cualquier persona que decida seguirme en un círculo, sin preocuparme yo de añadirlo a mis círculos, estilo twitter, también podrían permitir crear círculos en los que los usuarios incluidos sólo envíen notificaciones de los servicios que yo escoja, como una especie de lector primitivo de RSS, o no tan primitivo si lo mejoran con el tiempo, todo se andará.
(PD: El abuso de comas de la última frase se debe a que ayer terminé un libro de Saramago, quien lo conozca seguro que me comprende...)
Pueden estar tranquilos, no voy a hablar sobre teoría de simetrías en las relaciones de redes sociales y en qué lado cae Google+, en parte porque no sé nada sobre el tema, y también porque otros ya lo han hecho. En general, los Círculos me parecen una buena idea. Se dice que esa manera de gestionar los contactos es más difícil de manejar que otras, pero esa afirmación sólo es cierta tomada como argumento técnico, desde el punto de vista de las relaciones sociales del mundo real los círculos son, en mi opinión, más intuitivos y comprensibles porque se corresponden con mayor fidelidad con la vida cotidiana.
Facebook desprecia ese punto de vista, y por eso nunca terminó de gustarme. Aunque allí se pueden gestionar los contactos en grupos, su filosofía es la de intentar apartar al usuario de ellos. Al fin y al cabo, Mark Zuckerberg cree que a la sociedad actual no le importa la privacidad, que las costumbres sociales han cambiado radicalmente (para coincidir asombrosamente con las reglas de privacidad de su web). Naturalmente, no deja de haber verdad en que hoy en día la gente quiere compartir muchas cosas con todo el mundo, pero la lista de excepciones es como para parar un tren.
El simple hecho de que las meteduras de pata en Facebook con padres, jefes o parejas se hayan convertido en fuente de humor en Internet debería ser tomado como una prueba obvia -un reporte de bug- de que hay problemas en la concepción de Facebook, de que deberían intentar evitarse esos casos para que sólo puedan ocurrir por meteduras de pata gigantescas, y no por no haberte parado a preveer la opinión de cada uno de tus cientos de contactos, pero eso a Zuckerger no parece importarle. En cambio, la idea de Google+ parece aspirar a que uno pueda tener en sus contactos a sus familiares cercanos, a compañeros de trabajo, a gente aficionada a pornografía judía y a gente del partido nazi local, y gestionarlos todos en un perfil común con la confianza de que uno no meterá la pata tan fácilmente. Google+ está pensado para la doble vida.
Google+ tiene, además, funciones como Hangout y Huddle, magníficas ideas para gestionar relaciones sociales y que encajan perfectamente con el concepto de círculos. La respuesta de Facebook a esto ha sido añadir un soporte de Skype que sólo permite videoconferencia entre dos, mientas que los Hangouts de Google+ permiten videoconferencia entre 10 personas, muy cómodo para pequeños grupos de trabajo en una empresa o reuniones familiares virtuales.
Pero dejando de un lado el tema de la gestión de contactos, que al fin y al cabo probablemente sufrirá modificaciones en el futuro, detrás de Google+ hay una finalidad que es tan ambiciosa como la de rivalizar con Facebook, la de convertirse en el punto de integración de todos los servicios de Google. Hace mucho tiempo que llevan intentándolo sin éxito y parece que esta vez será la buena, la información interna que se conoce apunta en esa dirección, casi todos los servicios de Google podrían añadir funcionalidad para compartir datos o notificar de acciones a otros usuarios, por ejemplo, las actualizaciones de este blog podrían ser notificadas automáticamente en Google+ a los círculos que yo prefiera, o, mejor aun, a cualquier persona que decida seguirme en un círculo, sin preocuparme yo de añadirlo a mis círculos, estilo twitter, también podrían permitir crear círculos en los que los usuarios incluidos sólo envíen notificaciones de los servicios que yo escoja, como una especie de lector primitivo de RSS, o no tan primitivo si lo mejoran con el tiempo, todo se andará.
(PD: El abuso de comas de la última frase se debe a que ayer terminé un libro de Saramago, quien lo conozca seguro que me comprende...)
4 de julio de 2011
OS X 10.7
Hace ya unas semanas que Apple dio rienda suelta al bombo y platillo sobre OS X 10.7, y hay un par de cosas interesantes que merece la pena comentar.
La primera de ellas, el Autosave, autoguardar. La idea en si -guardar automáticamente los cambios de los documentos mientras se editan- no es novedosa. Se ha importado de iOS, pero en el escritorio tampoco lo es: Office tiene autoguardar, vim hace mmap() de un archivo temporal cuando edita algo, lo cual garantiza que se sincroniza al disco periódicamente, Firefox guarda el contenido de los formularios a medio escribir, hay muchos juegos que también lo usan, el propio editor web de Blogger lo usa...no, no es una una idea que no conozcamos. Los más críticos de Apple señalarán que esto es puro marketing, venta de humo.
Esta manera de ver las cosas desdeña, sin embargo, el punto de vista del "framework". Como tantas cosas en Apple, la novedad no está en lo que hace, sino en cómo lo hace. Puede que la idea no sea nueva, pero sí lo es proporcionar en el SO APIs de primer nivel que permitan a los programadores añadir autoguardar con facilidad sin tener que reimplementarlo en cada aplicación, también lo es el hecho de ir guardando varias versiones antiguas del documento y tener una interfaz de usuario unificada para ver los cambios entre ellas o para "bloquear" futuras ediciones a un documento. Y el tan criticado marketing, combinado con el hecho de que las aplicaciones de Apple son las primeras en utilizar (y de ese modo publicitar) las nuevas APIs, hace que quienes programan para Mac se interesen por incorporar estas cosas a sus programas, con el resultado final de que el usuario se encuentra con una nueva característica muy bien integrada en todos los rincones del SO.
Otro tanto se puede decir de "Resume", que consiste en restaurar el estado del escritorio tras un reinicio tal como estaba antes de producirse. Creo recordar que Windows 9x hacía algo de esto, y como usuario de KDE puedo certificar que tengo la sesión por defecto pre-configurada para que, en cada inicio de sesión, me restaure en su escritorio virtual correspondiente, el conjunto de aplicaciones básico que suelo utilizar. Y en Fedora al menos, la configuración por defecto es que en cada inicio de sesión se restaure la anterior. Sin embargo, individualmente cada aplicación no restaura su estado: kmail no abre la carpeta en la que estaba, kaffeine no recuerda el vídeo que estaba viendo, akregator no recuerda la fuente que estaba leyendo...no deja de ser una restauración imperfecta.
En OS X 10.7, se ha refinado este aspecto hasta el punto de que se ha eliminado, al igual que en iOS, la barrera entre aplicación cerrada y aplicación minimizada - de hecho, el Dock ya no indicará (por defecto) si una aplicación está minimizada. Cuando la aplicación es capaz de guardar en todo momento su estado (incluso la posición del cursor y el texto seleccionado), es posible que al minimizar un editor de texto, el SO en realidad le cierre. Si el usuario intenta "desminimizar" el editor, basta con iniciarlo de cero y cargar al estado anterior (tener APIs que ayuden facilita mucho la adopción de estas cosas), y no hace falta mencionar que es posible reiniciar el equipo y recuperarlo tal como se había dejado hasta el último detalle.
Quien sabe, en un futuro podrían arriesgarse a ser más extremos y cerrar incluso aplicaciones abiertas que estén visibles, que no hayan sido utilizadas en un buen rato y no estén haciendo nada por si mismas: se podría mantener una copia de la imagen de la ventana, cerrar el programa, y si el usuario la vuelve a tocar reiniciar la aplicación...esta manera de gestionar las aplicaciones abiertas puede ser confusa al principio, pero es bastante más natural que tener que acordarte de guardar un determinado documento antes de apagar el ordenador. Y cerrar los programas que no se usan para liberar RAM para los que si se usan es una buena idea.
No hay muchas más cosas interesantes en esta versión, con la excepción de que esta versión se distribuirá online, a través de la App Store, y de los snapshots locales (apostaría a que no tienen nada que ver con ZFS ni con snapshots de volúmenes tradicionales, y que algo deben tener que ver con el mismo mecanismo que las versiones de Autosave - pero este post ya es demasiado largo)
La primera de ellas, el Autosave, autoguardar. La idea en si -guardar automáticamente los cambios de los documentos mientras se editan- no es novedosa. Se ha importado de iOS, pero en el escritorio tampoco lo es: Office tiene autoguardar, vim hace mmap() de un archivo temporal cuando edita algo, lo cual garantiza que se sincroniza al disco periódicamente, Firefox guarda el contenido de los formularios a medio escribir, hay muchos juegos que también lo usan, el propio editor web de Blogger lo usa...no, no es una una idea que no conozcamos. Los más críticos de Apple señalarán que esto es puro marketing, venta de humo.
Esta manera de ver las cosas desdeña, sin embargo, el punto de vista del "framework". Como tantas cosas en Apple, la novedad no está en lo que hace, sino en cómo lo hace. Puede que la idea no sea nueva, pero sí lo es proporcionar en el SO APIs de primer nivel que permitan a los programadores añadir autoguardar con facilidad sin tener que reimplementarlo en cada aplicación, también lo es el hecho de ir guardando varias versiones antiguas del documento y tener una interfaz de usuario unificada para ver los cambios entre ellas o para "bloquear" futuras ediciones a un documento. Y el tan criticado marketing, combinado con el hecho de que las aplicaciones de Apple son las primeras en utilizar (y de ese modo publicitar) las nuevas APIs, hace que quienes programan para Mac se interesen por incorporar estas cosas a sus programas, con el resultado final de que el usuario se encuentra con una nueva característica muy bien integrada en todos los rincones del SO.
Otro tanto se puede decir de "Resume", que consiste en restaurar el estado del escritorio tras un reinicio tal como estaba antes de producirse. Creo recordar que Windows 9x hacía algo de esto, y como usuario de KDE puedo certificar que tengo la sesión por defecto pre-configurada para que, en cada inicio de sesión, me restaure en su escritorio virtual correspondiente, el conjunto de aplicaciones básico que suelo utilizar. Y en Fedora al menos, la configuración por defecto es que en cada inicio de sesión se restaure la anterior. Sin embargo, individualmente cada aplicación no restaura su estado: kmail no abre la carpeta en la que estaba, kaffeine no recuerda el vídeo que estaba viendo, akregator no recuerda la fuente que estaba leyendo...no deja de ser una restauración imperfecta.
En OS X 10.7, se ha refinado este aspecto hasta el punto de que se ha eliminado, al igual que en iOS, la barrera entre aplicación cerrada y aplicación minimizada - de hecho, el Dock ya no indicará (por defecto) si una aplicación está minimizada. Cuando la aplicación es capaz de guardar en todo momento su estado (incluso la posición del cursor y el texto seleccionado), es posible que al minimizar un editor de texto, el SO en realidad le cierre. Si el usuario intenta "desminimizar" el editor, basta con iniciarlo de cero y cargar al estado anterior (tener APIs que ayuden facilita mucho la adopción de estas cosas), y no hace falta mencionar que es posible reiniciar el equipo y recuperarlo tal como se había dejado hasta el último detalle.
Quien sabe, en un futuro podrían arriesgarse a ser más extremos y cerrar incluso aplicaciones abiertas que estén visibles, que no hayan sido utilizadas en un buen rato y no estén haciendo nada por si mismas: se podría mantener una copia de la imagen de la ventana, cerrar el programa, y si el usuario la vuelve a tocar reiniciar la aplicación...esta manera de gestionar las aplicaciones abiertas puede ser confusa al principio, pero es bastante más natural que tener que acordarte de guardar un determinado documento antes de apagar el ordenador. Y cerrar los programas que no se usan para liberar RAM para los que si se usan es una buena idea.
No hay muchas más cosas interesantes en esta versión, con la excepción de que esta versión se distribuirá online, a través de la App Store, y de los snapshots locales (apostaría a que no tienen nada que ver con ZFS ni con snapshots de volúmenes tradicionales, y que algo deben tener que ver con el mismo mecanismo que las versiones de Autosave - pero este post ya es demasiado largo)
26 de junio de 2011
GNOME no necesita gente que...
Un mantenedor de paquetes de varios terminales en Fedora ha contado en su blog una historia que resume muy bien la forma de pensar de los desarrolladores de GNOME. El sujeto en cuestión quería, simple y llanamente, que los usuarios de GNOME pudieran escoger en las preferencias, de entre todos los terminales que él empaqueta, el que los usuarios quieren que sea el terminal por defecto. Escueta respuesta por parte de un desarrollador de GNOME: "No estamos diseñando un escritorio para gente a la que le gusta escoger su terminal". Con un par.
La paradoja es que GNOME 3 ya tiene una interfaz para configurar las aplicaciones por defecto en el caso del navegador o el cliente de email (bajo el icono de "información del sistema", es decir, un lugar donde el usuario no esperaría encontrarlo), y hay sitio de sobra para añadir opción de escoger el terminal por defecto. Pero a pesar de ello los desarrolladores no quieren ver cosas tan técnicas ni de lejos. El post también enumera varias de las limitaciones que los desarrolladores de GNOME han decidido prohibir por-que-si (o porque OS X hace algo parecido):
. No permiten que haya una interfaz gráfica que permita cambiar de theme, los colores o los iconos.
· Si un usuario quiere utilizar en GDM una lengua diferente en el teclado o la interfaz no podrá hacerlo en el propio GDM. Tendrá que entrar en su sesión, configurarlo allí, salir de la sesión y volver a entrar.
· Si un usuario quiere apagar el ordenador no puede hacerlo directamente: tiene que salir de su sesión y usar la opción de apagar en GDM (se puede utilizar la tecla ALT para mostrar la opción, pero en los tablets no se puede hacer eso).
· Si un usuario quiere configurar las acciones a tomar en los diferentes eventos de gestión de energía (por ejemplo, desactivar la suspensión del sistema al cerrar la pantalla del portátil) habrá de hacerlo con gconf, no hay opción para ello en la interfaz.
Respecto a las varias limitaciones de GNOME Shell, existe un mecanismo de extensiones para cambiar los comportamientos por defecto del Shell. Eso quiere decir que para hacer algo tan simple como eliminar el icono de accesibilidad o mover el reloj de sitio (o utilizar para algo todo el enorme hueco vacío del panel superior en el caso de pantallas extremadamente grandes), hay que instalar una extensión. Lo más gracioso es que tendré que oir críticas a la usabilidad de KDE y loas a la de GNOME por parte de personas que, para deshabilitar un puñetero icono de accesibilidad del panel, tendrán que googlear la manera de hacerlo.
La paradoja es que GNOME 3 ya tiene una interfaz para configurar las aplicaciones por defecto en el caso del navegador o el cliente de email (bajo el icono de "información del sistema", es decir, un lugar donde el usuario no esperaría encontrarlo), y hay sitio de sobra para añadir opción de escoger el terminal por defecto. Pero a pesar de ello los desarrolladores no quieren ver cosas tan técnicas ni de lejos. El post también enumera varias de las limitaciones que los desarrolladores de GNOME han decidido prohibir por-que-si (o porque OS X hace algo parecido):
. No permiten que haya una interfaz gráfica que permita cambiar de theme, los colores o los iconos.
· Si un usuario quiere utilizar en GDM una lengua diferente en el teclado o la interfaz no podrá hacerlo en el propio GDM. Tendrá que entrar en su sesión, configurarlo allí, salir de la sesión y volver a entrar.
· Si un usuario quiere apagar el ordenador no puede hacerlo directamente: tiene que salir de su sesión y usar la opción de apagar en GDM (se puede utilizar la tecla ALT para mostrar la opción, pero en los tablets no se puede hacer eso).
· Si un usuario quiere configurar las acciones a tomar en los diferentes eventos de gestión de energía (por ejemplo, desactivar la suspensión del sistema al cerrar la pantalla del portátil) habrá de hacerlo con gconf, no hay opción para ello en la interfaz.
Respecto a las varias limitaciones de GNOME Shell, existe un mecanismo de extensiones para cambiar los comportamientos por defecto del Shell. Eso quiere decir que para hacer algo tan simple como eliminar el icono de accesibilidad o mover el reloj de sitio (o utilizar para algo todo el enorme hueco vacío del panel superior en el caso de pantallas extremadamente grandes), hay que instalar una extensión. Lo más gracioso es que tendré que oir críticas a la usabilidad de KDE y loas a la de GNOME por parte de personas que, para deshabilitar un puñetero icono de accesibilidad del panel, tendrán que googlear la manera de hacerlo.
21 de junio de 2011
Nokia N9, alegría y decepción
¿Era MeeGo la mejor plataforma móvil del mundo? Definitivamente no. Su desarrollo e incorporación a móviles había sido lento, lentísimo. Apenas tenían aplicaciones. Internamente, no supieron poner orden y tuvieron a la gente de Symbian y GTK perdiendo enormes cantidades de dinero y tiempo intentando competir QML: Si, Nokia se liaba en guerras internas de departamentos mientras Apple y Google se hartaban de comerles el desayuno en el sector de los smartphones.
Sin embargo, y a pesar de todos los fallos arrastrados, Nokia podía haberse tirado a la piscina, haberlo dado todo por MeeGo, y habrían tenido como punto de partida de su recuperación el Nokia N9, anunciado hoy. Con este 1.0 en la calle, podían dedicarse a apretar las tuercas, sacar actualizaciones frecuentes para refinarlo, ponerse a la altura de sus competidores e incluso mejorarlos. Todas, o casi todas las aplicaciones diseñadas para él serían válidas para millones de móviles Symbian existentes en el mercado. Podrían haberse centrado en la integración de QT con Android e iPhone para venderlo como el mejor toolkit multiplataforma para móviles, toolkit del que sus competidores se beneficiarían pero que los finlandeses controlarían en la práctica. Habrían gozado de gran apoyo por parte de los desarrolladores pro-software libre, que tienen su peso en todos los rincones de Internet. Sus competidores tendrían mucha ventaja, pero al menos Nokia estaría de vuelta en la carrera.
Pero nada de eso va a ocurrir. En lugar de eso seguirán con su apuesta por Windows Phone, la única gran plataforma móvil que no puede ejecutar aplicaciones nativas QT procedentes de Symbian, y sólo porque a Microsoft no le da la gana permitirlo. Tendrán que enfrentarse a esa burocracia que hace que el ritmo de desarrollo de IE o Windows sea tan exasperantemente lento y poco sorprendente. No controlarán la plataforma de desarrollo .NET/Silverlight, ni la tienda de aplicaciones, estarán a merced de Redmond. Y tendrán que esperar a final de este año para ver el primer móvil con Windows Phone, y eso teniendo suerte.
A pesar de todo, muchos enfermos del software libre no muy afines a la mentalidad de diseño autista de Android tenemos, por fin, un teléfono moderno que nos gusta. Larga vida al Nokia N9.
Sin embargo, y a pesar de todos los fallos arrastrados, Nokia podía haberse tirado a la piscina, haberlo dado todo por MeeGo, y habrían tenido como punto de partida de su recuperación el Nokia N9, anunciado hoy. Con este 1.0 en la calle, podían dedicarse a apretar las tuercas, sacar actualizaciones frecuentes para refinarlo, ponerse a la altura de sus competidores e incluso mejorarlos. Todas, o casi todas las aplicaciones diseñadas para él serían válidas para millones de móviles Symbian existentes en el mercado. Podrían haberse centrado en la integración de QT con Android e iPhone para venderlo como el mejor toolkit multiplataforma para móviles, toolkit del que sus competidores se beneficiarían pero que los finlandeses controlarían en la práctica. Habrían gozado de gran apoyo por parte de los desarrolladores pro-software libre, que tienen su peso en todos los rincones de Internet. Sus competidores tendrían mucha ventaja, pero al menos Nokia estaría de vuelta en la carrera.
Pero nada de eso va a ocurrir. En lugar de eso seguirán con su apuesta por Windows Phone, la única gran plataforma móvil que no puede ejecutar aplicaciones nativas QT procedentes de Symbian, y sólo porque a Microsoft no le da la gana permitirlo. Tendrán que enfrentarse a esa burocracia que hace que el ritmo de desarrollo de IE o Windows sea tan exasperantemente lento y poco sorprendente. No controlarán la plataforma de desarrollo .NET/Silverlight, ni la tienda de aplicaciones, estarán a merced de Redmond. Y tendrán que esperar a final de este año para ver el primer móvil con Windows Phone, y eso teniendo suerte.
A pesar de todo, muchos enfermos del software libre no muy afines a la mentalidad de diseño autista de Android tenemos, por fin, un teléfono moderno que nos gusta. Larga vida al Nokia N9.
14 de junio de 2011
Error, procesador demasiado inteligente
En este artículo de LWN se cuenta una curiosa historia de microoptimizaciones que no sirven para nada. Resulta que en equipos modernos la diferencia de tiempo de acceso entre memoria y registro de procesador es enorme, el tiempo necesario para acceder a una dirección de memoria RAM no cacheada previamente es de cientos de ciclos de CPU.
Para ayudar a los programadores a sortear esta desventaja, las CPUs modernas tienen instrucciones de "prelectura" (prefetch). Se trata de instrucciones que por si solas no hacen nada, pero advierten al procesador de que se va a leer una dirección concreta de memoria en un futuro muy cercano, información que el procesador aprovecha para decir al controlador de memoria que vaya leyendo esa dirección de memoria y colocándola en el caché L1. Así, cuando se acabe leyendo de verdad, no habrá que esperar cientos de ciclos sin hacer nada. En el kernel Linux, se utilizan las instrucciones de "prefetch" en muchos sitios, por ejemplo al ir leyendo elementos de una lista enlazada se hace un "prefetch" del próximo elemento. Sin embargo, mediciones recientes han determinado que el efecto práctico de esta técnica es el enlentecimiento del kernel - concretamente, un 0.5% más lento en el tiempo empleado en compilar un kernel.
¿Qué ha pasado? Los procesadores modernos tienen una porción de la CPU dedicada al análisis heurístico del código que se ejecuta, con el propósito de adivinar qué rutas de código se van a tomar, que partes de la memoria se van a leer, optimizar el código y hacer "prefetchs" por su cuenta (pueden estar seguros que también intentan detectar si el programa en ejecución es algún famoso benchmark de CPUs). Resulta que el analizador de código de los procesadores Intel es capaz de adivinar los "prefetchs" necesarios con más eficiencia que los programadores del kernel y GCC - hasta el punto de que esas microoptimizaciones manuales le molestan y disminuyen el rendimiento. Resumiendo, que en la próxima versión se ha eliminado todo tipo de prefetching de Linux, y es más rápido.
Este tipo de cosas, por cierto, son las que han puesto su granito de arena para que x86 triunfe y cosas como Itanium fracasen. Itanium está diseñado para que el software y el compilador hagan casi todo el trabajo de optimización, de hecho es el compilador el que debe decidir cosas como si una instrucción depende de otra y si, por tanto, se pueden procesador ambas simultáneamente o si deben ser serializadas la una detrás de la otra. De ese modo, el complejo optimizador de código se hace teóricamente innecesario y el diseño de la CPU se simplifica. Pero en la práctica resultó que los compiladores no son (y probablemente nunca sean) tan buenos y exprimir la potencia de un Itanium requiere unos esfuerzos de optimización impresionantes. Mientras tanto, el académicamente horroroso y recargado analizador de código de los x86 es capaz de optimizar en tiempo de ejecución cualquier basura que le echen encima.
Para ayudar a los programadores a sortear esta desventaja, las CPUs modernas tienen instrucciones de "prelectura" (prefetch). Se trata de instrucciones que por si solas no hacen nada, pero advierten al procesador de que se va a leer una dirección concreta de memoria en un futuro muy cercano, información que el procesador aprovecha para decir al controlador de memoria que vaya leyendo esa dirección de memoria y colocándola en el caché L1. Así, cuando se acabe leyendo de verdad, no habrá que esperar cientos de ciclos sin hacer nada. En el kernel Linux, se utilizan las instrucciones de "prefetch" en muchos sitios, por ejemplo al ir leyendo elementos de una lista enlazada se hace un "prefetch" del próximo elemento. Sin embargo, mediciones recientes han determinado que el efecto práctico de esta técnica es el enlentecimiento del kernel - concretamente, un 0.5% más lento en el tiempo empleado en compilar un kernel.
¿Qué ha pasado? Los procesadores modernos tienen una porción de la CPU dedicada al análisis heurístico del código que se ejecuta, con el propósito de adivinar qué rutas de código se van a tomar, que partes de la memoria se van a leer, optimizar el código y hacer "prefetchs" por su cuenta (pueden estar seguros que también intentan detectar si el programa en ejecución es algún famoso benchmark de CPUs). Resulta que el analizador de código de los procesadores Intel es capaz de adivinar los "prefetchs" necesarios con más eficiencia que los programadores del kernel y GCC - hasta el punto de que esas microoptimizaciones manuales le molestan y disminuyen el rendimiento. Resumiendo, que en la próxima versión se ha eliminado todo tipo de prefetching de Linux, y es más rápido.
Este tipo de cosas, por cierto, son las que han puesto su granito de arena para que x86 triunfe y cosas como Itanium fracasen. Itanium está diseñado para que el software y el compilador hagan casi todo el trabajo de optimización, de hecho es el compilador el que debe decidir cosas como si una instrucción depende de otra y si, por tanto, se pueden procesador ambas simultáneamente o si deben ser serializadas la una detrás de la otra. De ese modo, el complejo optimizador de código se hace teóricamente innecesario y el diseño de la CPU se simplifica. Pero en la práctica resultó que los compiladores no son (y probablemente nunca sean) tan buenos y exprimir la potencia de un Itanium requiere unos esfuerzos de optimización impresionantes. Mientras tanto, el académicamente horroroso y recargado analizador de código de los x86 es capaz de optimizar en tiempo de ejecución cualquier basura que le echen encima.
7 de junio de 2011
QT 5
Ya hace un tiempo que fue noticia este post en el blog de QT, que nos ilumina sobre las direcciones que podría tomar QT 5. Nadie sabe cuál va a ser el nivel de inversión de Nokia en QT a largo plazo (viendo el panorama que tienen las cosas, poco), pero al menos el equipo de programación es tan ambicioso como siempre, y si no fíjense en esto:
"While the QWidget based classes [los widgets tradicionales] are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term" "Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph". Y, de este PDF con más detalles: "The core platforms will be Linux on Wayland and X11, Mac and Windows"
Espero que los gnomeros comprendan que esto me parezca bastante más interesante que la aburrida GTK. Para entendernos, lo que QT 5 pretende hacer sería equivalente a que GTK pasara a usar Clutter como pilar de todas sus GUIs. En cambio, en GTK 3.0, que acaba de salir, el pilar usado es Cairo.
Más interesante que los desfases de Gnome es preguntarse qué pasará con KDE. Una nueva versión de QT rompería la compatibilidad binaria, así que es de suponer que se necesitaría un KDE 5. Sin embargo, el cambio tecnológico no sería tan grande como lo fue de KDE3 a KDE4, por lo que más allá de experimentar con nuevas interfaces, no habría grandes novedades.
Un detalla interesante es que ya hay una nueva versión de Plasma, una especie de Plasma 2, que se basará completamente en QML (y no, no se trata de que son unos chapuceros que estén "reescribiendo" Plasma de nuevo, como se ha oído por ahí). Por esa razón, no será necesario esperar a un KDE 5 para utilizar interfaces basadas en QML, pero es que además cabría preguntarse por la influencia que tendrá Plasma en KDE 5. ¿Se imaginan que KDE declara Plasma como el framework fundamental para construir UIs? Parece demasiado radical, pero ahí está Amarok, utilizándolo.
"While the QWidget based classes [los widgets tradicionales] are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term" "Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph". Y, de este PDF con más detalles: "The core platforms will be Linux on Wayland and X11, Mac and Windows"
Espero que los gnomeros comprendan que esto me parezca bastante más interesante que la aburrida GTK. Para entendernos, lo que QT 5 pretende hacer sería equivalente a que GTK pasara a usar Clutter como pilar de todas sus GUIs. En cambio, en GTK 3.0, que acaba de salir, el pilar usado es Cairo.
Más interesante que los desfases de Gnome es preguntarse qué pasará con KDE. Una nueva versión de QT rompería la compatibilidad binaria, así que es de suponer que se necesitaría un KDE 5. Sin embargo, el cambio tecnológico no sería tan grande como lo fue de KDE3 a KDE4, por lo que más allá de experimentar con nuevas interfaces, no habría grandes novedades.
Un detalla interesante es que ya hay una nueva versión de Plasma, una especie de Plasma 2, que se basará completamente en QML (y no, no se trata de que son unos chapuceros que estén "reescribiendo" Plasma de nuevo, como se ha oído por ahí). Por esa razón, no será necesario esperar a un KDE 5 para utilizar interfaces basadas en QML, pero es que además cabría preguntarse por la influencia que tendrá Plasma en KDE 5. ¿Se imaginan que KDE declara Plasma como el framework fundamental para construir UIs? Parece demasiado radical, pero ahí está Amarok, utilizándolo.
31 de mayo de 2011
El tenebroso mundo del firmware
Si les gustan las historias de terror que causan pesadillas por la noche y se llevan en un saco la poca inocencia que les pueda quedar, prueben a leer este post de Matthew Garrett. En el se cuenta cómo hay cinco maneras teóricas de provocar el reinicio de un PC, pero ninguna de ellas funciona correctamente por si sola en todos los equipos del mercado: sólo es posible conseguir un reinicio fiable imitando lo que Windows haga, porque Windows es lo único que los desarrolladores de las BIOS testean.
Y si les queda sangre en las venas, pueden probar con otros posts suyos anteriores, como el tenebroso caso de la implementación EFI de Apple, la especificación ACPI que todo el mundo pisotea, comportamientos absurdos con el bus PCI, o ordenadores nuevos que son incapaces de implementar bien características que los PCs tienen desde hace 25 años. Todos con el mismo síntoma: lo que Windows implemente se convierte en la regla. Esta es una de las razones por las que un día Linus dijo que las especificaciones no sirven para nada.
No sé ustedes, pero yo admiro profundamente a los programadores que tienen que lidiar con estas cosas. Son como los funcionarios de chaqueta gris y cargos relativamente importantes pero lejos de la cúpula, que se encargan de hacer el verdadero trabajo de gestión de los gobiernos. Nadie les conoce, pero son los verdaderos héroes.
Y si les queda sangre en las venas, pueden probar con otros posts suyos anteriores, como el tenebroso caso de la implementación EFI de Apple, la especificación ACPI que todo el mundo pisotea, comportamientos absurdos con el bus PCI, o ordenadores nuevos que son incapaces de implementar bien características que los PCs tienen desde hace 25 años. Todos con el mismo síntoma: lo que Windows implemente se convierte en la regla. Esta es una de las razones por las que un día Linus dijo que las especificaciones no sirven para nada.
No sé ustedes, pero yo admiro profundamente a los programadores que tienen que lidiar con estas cosas. Son como los funcionarios de chaqueta gris y cargos relativamente importantes pero lejos de la cúpula, que se encargan de hacer el verdadero trabajo de gestión de los gobiernos. Nadie les conoce, pero son los verdaderos héroes.
27 de mayo de 2011
Las novedades de Linux 2.6.39
Perdón por el imperdonable retraso en escribir este artículo, una semana después de lo debido. En mi defensa, señalaré que esta ha sido el periodo de desarrollo desde 2.6.14, hace más de 5 años.
Ya se ha anunciado la versión 2.6.39 del kernel Linux. Las novedades principales en esta versión son grandes mejoras de escalabilidad en Ext4, aumento de la ventana inicial de congestión de TCP, soporte de una nueva arquitectura de CPU llamada UniCore-32, una característica que permite la creación y gestión de grupos de recursos de red llamada IPset, pequeñas actualizaciones en Btrfs, una característica que permite almacenar la información de un cuelgue en el firmware para recuperarlo tras un reinicio, actualizaciones de perf, y muchos otros pequeños cambios y drivers nuevos. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.
· Escalabilidad SMP de Ext4: La lista de cambios de 2.6.37 mencionó unas mejoras enormes de rendimiento de Ext4 en sistemas con múltiples CPUs. Sin embargo, esa característica no estaba preparada del todo y fue desactivada antes de la versión final, algo que la lista de cambios no mencionó. En esta versión se han corregido los problemas y esta característica se ha activado por defecto, algo
Esta es la descripción de aquella lista: "En esta versión, Ext4 enviará los datos al subsistema de dispositivos de bloques mediante una nueva capa llamada "bio". Esta capa "bio" (que es un alias de "block I/O": Se trata de la parte del kernel que se encarga de enviar peticiones al I/O scheduler) fue una de las primeras características que se incluyeron en Linux 2.5.1, y fue un reemplazo de la capa que sustituía, llamada "buffer", que tenía muchos problemas de escalabilidad y rendimiento: Al usarla, Ext4 sólo podía hacer peticiones de 4KB cada vez; utilizando la capa bio Ext4 puede enviar peticiones de 512KB cada vez. En el benchmark FFSB ejecutado en un equipo con 48 procesadores AMD y con almacenamiento de array RAID de 24 discos SAS, utilizando 192 threads paralelos de ffsb, la mejora fue del 300%".
· Incrementar la ventana de congestión TCP a 10 paquetes: La ventana inicial del algoritmo anticongestión de TCP ha sido aumentada a 10 paquetes. Este es un cambio muy técnico, pero de una importancia considerable. Se trata de un cambio sugerido por Google, quien asegura que puede mejorar la latencia un 10% sin detrimento del rendimiento. Recomendado este artículo de LWN: Increasing the TCP initial congestion window.
· IPset: IPset (página web) permite crear grupos de recursos de red (direcciones IPv4/v6, puertos TCP/UDP, emparejamientos IP<->MAC, emparejamientos IP<->puerto) llamados "IP sets", que luego se utilizan para definir reglas de iptables. Estos sets son mucho más eficientes a la hora de clasificar paquetes que las reglas de iptables por si solas, aunque consumen más memoria. Existen diferentes algoritmos y diferentes estructuras para que el usuario escoja una solución óptima. Esta característica ha estado disponible durante mucho tiempo como un añadido en los parches xtables-addons.
· Actualizaciones de Btrfs: Btrfs permite aplicar diferentes configuraciones de compresión y copy-on-write a nivel de directorio. También se incluyen algunas mejoras de rendimiento, y tracepoints para el análisis en tiempo de ejecución.
· Pstore: almacenamiento de la ínformación de un crash: Pstore es una interfaz en forma de sistemas de archivo que permite almacenar y recuperar información de un cuelgue en lugares como el ERST -un lugar especificado por ACPI para almacenar esas cosas. De ese modo se puede recuperar un dmesg del equipo colgado, por ejemplo.
· Nueva arquitectura: UniCore32: UniCore-32 es una arquitectura de 32 bits que incluye una serie de diseños de chip RISC licenciados por PKUnity Ltd.
· Memoria 'trascendente': La memoria 'trascendente' (el nombre es un poco raro, aviso) es un nuevo tipo de memoria con un conjunto de características muy particular. De LWN: "la memoria trascendente puede concebirse como un disco RAM con unas características interesantes: nadie sabe cómo es de grande, las escrituras al disco podrían no ser exitosas, y los datos escritos al disco podrían desvanecerse antes de ser releídos". Aunque no lo parezca a primera vista, hay usos útiles para este tipo de memoria, como el caché de páginas, la memoria de intercambio, o virtualización. En esta versión esta memoria se utiliza para implementar un sistema de cacheado con compresión llamado zcache.
· BKL: Eso es todo, amigos: En 2.6.37 fue posible compilar, por primera vez, un kernel Linux sin soporte de BKL. En esta versión, el BKL se ha eliminado por completo de las fuentes del kernel, incluyendo las propias definiciones e implementaciones de lock_kernel() y unlock_kernel().
· Llamadas del sistema open-by-handle: Se han añadido dos nuevas llamadas al sistema, name_to_handle_at() y open_by_handle_at(). Estas llamadas al sistema devuelven un "handle" de archivo que puede ser útil para sistemas de archivo en espacio de usuario, software de copia de seguridad y otras herramientas de gestión de espacio de almacenamiento. Esos "handles" pueden utilizarse en la llamada al sistema open() junto con un nuevo flag: O_PATH.
· Actualizaciones de perf: Se permite filtrar eventos de cada cgroup en perf stat y perf record, utilizando la opción -G, una nueva UI basada en slang con anotación en vivo, comando perf top --tui, soporte para Intel SandyBridge, soporte de filtros en perf probe como por ejemplo perf probe -V schedule --externs --filter=cpu* y otras mejoras menores por el estilo.
Estas son las novedades principales. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.
Ya se ha anunciado la versión 2.6.39 del kernel Linux. Las novedades principales en esta versión son grandes mejoras de escalabilidad en Ext4, aumento de la ventana inicial de congestión de TCP, soporte de una nueva arquitectura de CPU llamada UniCore-32, una característica que permite la creación y gestión de grupos de recursos de red llamada IPset, pequeñas actualizaciones en Btrfs, una característica que permite almacenar la información de un cuelgue en el firmware para recuperarlo tras un reinicio, actualizaciones de perf, y muchos otros pequeños cambios y drivers nuevos. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.
· Escalabilidad SMP de Ext4: La lista de cambios de 2.6.37 mencionó unas mejoras enormes de rendimiento de Ext4 en sistemas con múltiples CPUs. Sin embargo, esa característica no estaba preparada del todo y fue desactivada antes de la versión final, algo que la lista de cambios no mencionó. En esta versión se han corregido los problemas y esta característica se ha activado por defecto, algo
Esta es la descripción de aquella lista: "En esta versión, Ext4 enviará los datos al subsistema de dispositivos de bloques mediante una nueva capa llamada "bio". Esta capa "bio" (que es un alias de "block I/O": Se trata de la parte del kernel que se encarga de enviar peticiones al I/O scheduler) fue una de las primeras características que se incluyeron en Linux 2.5.1, y fue un reemplazo de la capa que sustituía, llamada "buffer", que tenía muchos problemas de escalabilidad y rendimiento: Al usarla, Ext4 sólo podía hacer peticiones de 4KB cada vez; utilizando la capa bio Ext4 puede enviar peticiones de 512KB cada vez. En el benchmark FFSB ejecutado en un equipo con 48 procesadores AMD y con almacenamiento de array RAID de 24 discos SAS, utilizando 192 threads paralelos de ffsb, la mejora fue del 300%".
· Incrementar la ventana de congestión TCP a 10 paquetes: La ventana inicial del algoritmo anticongestión de TCP ha sido aumentada a 10 paquetes. Este es un cambio muy técnico, pero de una importancia considerable. Se trata de un cambio sugerido por Google, quien asegura que puede mejorar la latencia un 10% sin detrimento del rendimiento. Recomendado este artículo de LWN: Increasing the TCP initial congestion window.
· IPset: IPset (página web) permite crear grupos de recursos de red (direcciones IPv4/v6, puertos TCP/UDP, emparejamientos IP<->MAC, emparejamientos IP<->puerto) llamados "IP sets", que luego se utilizan para definir reglas de iptables. Estos sets son mucho más eficientes a la hora de clasificar paquetes que las reglas de iptables por si solas, aunque consumen más memoria. Existen diferentes algoritmos y diferentes estructuras para que el usuario escoja una solución óptima. Esta característica ha estado disponible durante mucho tiempo como un añadido en los parches xtables-addons.
· Actualizaciones de Btrfs: Btrfs permite aplicar diferentes configuraciones de compresión y copy-on-write a nivel de directorio. También se incluyen algunas mejoras de rendimiento, y tracepoints para el análisis en tiempo de ejecución.
· Pstore: almacenamiento de la ínformación de un crash: Pstore es una interfaz en forma de sistemas de archivo que permite almacenar y recuperar información de un cuelgue en lugares como el ERST -un lugar especificado por ACPI para almacenar esas cosas. De ese modo se puede recuperar un dmesg del equipo colgado, por ejemplo.
· Nueva arquitectura: UniCore32: UniCore-32 es una arquitectura de 32 bits que incluye una serie de diseños de chip RISC licenciados por PKUnity Ltd.
· Memoria 'trascendente': La memoria 'trascendente' (el nombre es un poco raro, aviso) es un nuevo tipo de memoria con un conjunto de características muy particular. De LWN: "la memoria trascendente puede concebirse como un disco RAM con unas características interesantes: nadie sabe cómo es de grande, las escrituras al disco podrían no ser exitosas, y los datos escritos al disco podrían desvanecerse antes de ser releídos". Aunque no lo parezca a primera vista, hay usos útiles para este tipo de memoria, como el caché de páginas, la memoria de intercambio, o virtualización. En esta versión esta memoria se utiliza para implementar un sistema de cacheado con compresión llamado zcache.
· BKL: Eso es todo, amigos: En 2.6.37 fue posible compilar, por primera vez, un kernel Linux sin soporte de BKL. En esta versión, el BKL se ha eliminado por completo de las fuentes del kernel, incluyendo las propias definiciones e implementaciones de lock_kernel() y unlock_kernel().
· Llamadas del sistema open-by-handle: Se han añadido dos nuevas llamadas al sistema, name_to_handle_at() y open_by_handle_at(). Estas llamadas al sistema devuelven un "handle" de archivo que puede ser útil para sistemas de archivo en espacio de usuario, software de copia de seguridad y otras herramientas de gestión de espacio de almacenamiento. Esos "handles" pueden utilizarse en la llamada al sistema open() junto con un nuevo flag: O_PATH.
· Actualizaciones de perf: Se permite filtrar eventos de cada cgroup en perf stat y perf record, utilizando la opción -G, una nueva UI basada en slang con anotación en vivo, comando perf top --tui, soporte para Intel SandyBridge, soporte de filtros en perf probe como por ejemplo perf probe -V schedule --externs --filter=cpu* y otras mejoras menores por el estilo.
Estas son las novedades principales. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.
Suscribirse a:
Entradas (Atom)