Hoy es noticia linuxera que Chris Mason, creador y principal programador de Btrfs, anuncia que se va de Oracle, la compañía en la que trabajaba. Y como el autor de este blog piensa que los programadores y sus circunstancias son muy importantes, hay que mencionarlo. Empecemos diciendo que para la comunidad linuxera es sin duda un gran alivio que un programador tan importante para Linux abandone una compañía que pretende que las APIs puedan ser copyrighteables. Para nuestra desgracia, no se tienen noticias de que Chris Mason haya prendido fuego a Oracle a su salida.
Como cuenta en el propio anuncio, no hay nada que temer por Btrfs, seguirá manteniéndolo y desarrollándolo como siempre. Sin embargo, algunos hemos notado desde hace un tiempo que Chris Mason no escribía tanto código como solía (el retraso del fsck es un ejemplo de esto), ni estaba tan presente en el día a día. Que estaba ocupado con otras cosas, vaya. Y aunque no era una alarma crítica para Btrfs, puesto que ya tiene programadores de sobra, era desde luego una situación poco deseable (el retraso de fsck es, de nuevo, una prueba de ello).
La nueva compañía en la que trabajará será Fusion IO. De este compañía se pueden decir varias cosas. La primera, que se dedica a desarrollar memoria flash para almacenamiento SSD. La segunda, que esta compañía ya tiene en su nómina a Jens Axboe, el principal programador y mantenedor de la capa de bloque de Linux (con el objetivo evidente de que Linux funcione muy bien con SSDs). Y la tercera, que es donde trabaja Steve Wozniak como "chief scientist".
Si, ese Wozniak.
Cabe decir, por tanto, que Chris Mason está en un buen lugar y que puede que incluso sea mejor para Btrfs y Linux en general.
7 de junio de 2012
5 de junio de 2012
Elementary OS
Elementary OS es una distribución a la que merece la pena hacer mención. Su particularidad se debe a que no es tan sólo una distribución, sino un proyecto-escritorio-distro-plataforma. Un cosa difícil de explicar, vaya.
Empezando por el principio, Elementary es y ha sido durante mucho tiempo un conjunto de iconos y un themes para Gnome con un estilo muy OS X, obra inicial de un tal Daniel Foré. Esto de hacer un theme clon de OS X parece (y es) poco novedoso, pero no lo era tanto la buena calidad que tenía y la fama que alcanzó. Sin embargo, las ambiciones de Daniel Faré y demás miembros del proyecto no se quedaron ahí, un theme no era suficiente. Así que iniciaron un proyecto de distro, "Elementary OS", cuya esencia es un repositorio PPA con una serie de paquetes a instalar sobre una Ubuntu tradicional. Los paquetes contienen un Gnome 2.x modificado a su gusto, un dock (docky), y una serie de aplicaciones alternativas a las oficiales de Gnome/Ubuntu.
Y eso es en lo que consiste la primera y de momento única versión de Elementary OS, la versión 0.1 "Jupiter", lanzada a finales de Marzo del año pasado, del cual muchos se burlan, y no sin cierta falta de razón, de ser un "clon de OS X". Sin embargo, lo interesante está en la próxima versión (0.2, "Luna"), que contiene el trabajo de más de un año, y sus ambiciones de futuro.
Un Gnome 2.x modificado y un docky tampoco son suficientes para ellos. Así que para la citada versión 0.2 "Luna", han reescrito de cero (están escribiendo en estos momentos) un entorno de escritorio al cual llaman Pantheon, que hasta tiene su propio gestor de inicio de sesión X. Además han escrito varias aplicaciones propias de cero, como un programa para escuchar música, un editor de texto, un terminal, gestor de archivos, panel de control del sistema, y aplicacioncillas de ese estilo, y cabe esperar que sigan desarrollando más. Usan, además, los programas del proyecto Yorba (Shotwell), y en ese caso no se han molestado en reescribirlos porque han hecho la elección de desarrollar todo el proyecto usando el lenguaje Vala. Como navegador, usan Midori, un navegador basado en webkit afín a XFCE.
Quizás piensen ustedes que un proyecto así, que pretende rehacer el mundo de cero no se puede esperar gran cosa, y tendrían razón, las aplicaciones apenas tienen características y de momento sólo sirven las necesidades más básicas. Sin embargo, hay cosas que en mi opinión hace a Elementary OS diferente. Una de ellas es el de cuidar el aspecto gráfico y la interfaz de usuario bastante bien. Además de copiar el estilo de OS X, también parecen haber copiado el estilo de desarrollo "top-down" de Apple, donde los diseñadores son dioses y dicen qué quieren, y los desarrolladores obedecen. A Daniel Foré, que aun lidera el proyecto, desde luego parece que lo de diseñar se le da bien (los iconos oficiales de Ubuntu son derivados de los de Elementary). Unas capturitas de ejemplo donde pienso que se nota las obsesiones con el detalle más que con la funcionalidad:
Si bien pueden ser acusados (hace falta recalcarlo) de imitar a OS X descaradamente, también es cierto es que probablemente sean los que mejor están haciéndolo. Mientras que unos se obsesionan con clonar Cocoa, usar Objective-C y construir frameworks potentes (Etoile/GNUStep) y otros tratan de imitar a OS X con themes, Elementary se a desarrollar su propio camino siguiendo el estilo OS X pero sin obsesionarse con ser clones exactos, centrándose en la apariencia sin obsesionarse con las tecnicidades (por Dios, usan Vala), y desarrollando sus propias aplicaciones en lugar de conformarse con ser un simple shell que ejecuta aplicaciones de otros.
El proyecto está hecho por gente que no tiene mucha experiencia (el tipo que comenzó el framework para aplicaciones Granite tiene 17 años), pero tiene algo que es más importante: una idea clara y mucho entusiasmo para hacerla realidad. Sin duda, es un proyecto que corre el riesgo de no llegar a ningún lado y acabar muriendo de inanición por abandono de algún programador importante. Los snapshots de 0.2 "Luna" muestran un escritorio inusable que tiene fallos y carencias por doquier, están aun muy lejos de sacar algo útil y estable, pero si lo logran no cabe duda que puede ganar muchos adeptos.
Empezando por el principio, Elementary es y ha sido durante mucho tiempo un conjunto de iconos y un themes para Gnome con un estilo muy OS X, obra inicial de un tal Daniel Foré. Esto de hacer un theme clon de OS X parece (y es) poco novedoso, pero no lo era tanto la buena calidad que tenía y la fama que alcanzó. Sin embargo, las ambiciones de Daniel Faré y demás miembros del proyecto no se quedaron ahí, un theme no era suficiente. Así que iniciaron un proyecto de distro, "Elementary OS", cuya esencia es un repositorio PPA con una serie de paquetes a instalar sobre una Ubuntu tradicional. Los paquetes contienen un Gnome 2.x modificado a su gusto, un dock (docky), y una serie de aplicaciones alternativas a las oficiales de Gnome/Ubuntu.
Y eso es en lo que consiste la primera y de momento única versión de Elementary OS, la versión 0.1 "Jupiter", lanzada a finales de Marzo del año pasado, del cual muchos se burlan, y no sin cierta falta de razón, de ser un "clon de OS X". Sin embargo, lo interesante está en la próxima versión (0.2, "Luna"), que contiene el trabajo de más de un año, y sus ambiciones de futuro.
Un Gnome 2.x modificado y un docky tampoco son suficientes para ellos. Así que para la citada versión 0.2 "Luna", han reescrito de cero (están escribiendo en estos momentos) un entorno de escritorio al cual llaman Pantheon, que hasta tiene su propio gestor de inicio de sesión X. Además han escrito varias aplicaciones propias de cero, como un programa para escuchar música, un editor de texto, un terminal, gestor de archivos, panel de control del sistema, y aplicacioncillas de ese estilo, y cabe esperar que sigan desarrollando más. Usan, además, los programas del proyecto Yorba (Shotwell), y en ese caso no se han molestado en reescribirlos porque han hecho la elección de desarrollar todo el proyecto usando el lenguaje Vala. Como navegador, usan Midori, un navegador basado en webkit afín a XFCE.
Quizás piensen ustedes que un proyecto así, que pretende rehacer el mundo de cero no se puede esperar gran cosa, y tendrían razón, las aplicaciones apenas tienen características y de momento sólo sirven las necesidades más básicas. Sin embargo, hay cosas que en mi opinión hace a Elementary OS diferente. Una de ellas es el de cuidar el aspecto gráfico y la interfaz de usuario bastante bien. Además de copiar el estilo de OS X, también parecen haber copiado el estilo de desarrollo "top-down" de Apple, donde los diseñadores son dioses y dicen qué quieren, y los desarrolladores obedecen. A Daniel Foré, que aun lidera el proyecto, desde luego parece que lo de diseñar se le da bien (los iconos oficiales de Ubuntu son derivados de los de Elementary). Unas capturitas de ejemplo donde pienso que se nota las obsesiones con el detalle más que con la funcionalidad:
Si bien pueden ser acusados (hace falta recalcarlo) de imitar a OS X descaradamente, también es cierto es que probablemente sean los que mejor están haciéndolo. Mientras que unos se obsesionan con clonar Cocoa, usar Objective-C y construir frameworks potentes (Etoile/GNUStep) y otros tratan de imitar a OS X con themes, Elementary se a desarrollar su propio camino siguiendo el estilo OS X pero sin obsesionarse con ser clones exactos, centrándose en la apariencia sin obsesionarse con las tecnicidades (por Dios, usan Vala), y desarrollando sus propias aplicaciones en lugar de conformarse con ser un simple shell que ejecuta aplicaciones de otros.
El proyecto está hecho por gente que no tiene mucha experiencia (el tipo que comenzó el framework para aplicaciones Granite tiene 17 años), pero tiene algo que es más importante: una idea clara y mucho entusiasmo para hacerla realidad. Sin duda, es un proyecto que corre el riesgo de no llegar a ningún lado y acabar muriendo de inanición por abandono de algún programador importante. Los snapshots de 0.2 "Luna" muestran un escritorio inusable que tiene fallos y carencias por doquier, están aun muy lejos de sacar algo útil y estable, pero si lo logran no cabe duda que puede ganar muchos adeptos.
28 de mayo de 2012
El sentido de Unix y de ls
En los últimos días han aparecido dos artículos afirmando que Unix no sigue la filosofía Unix, recurriendo como ejemplo al montón de opciones de ls.
La repercusión de esos artículos me ha sorprendido y confirmado. Que Unix no es perfecto ni sigue sus propios principios no debería ser a estas alturas sorpresa para nadie, Plan 9 es la confirmación práctica de ello. El mundo Unix padece del mito de la perfección y de la Pureza De Los Principios, y pocos están dispuestos a vivir con el hecho de que usamos derivados de Unix sólo por costumbre y compatibilidad, que instalamos en nuestras máquinas de última generación sistemas operativos con defectos bastante sonrojantes y que podríamos tener cosas mejores si pudiéramos partir de cero.
Pero quería referirme a la extraña tendencia a poner como ejemplo de usurpación de principios a ls y sus numerosas opciones. En realidad, se suele acusar de "bloat" no sólo a ls, sino de todas las utilidades Unix básicas de GNU. Se acusa a estas utilidades de faltar al principio de un programa que hace una sola función y la hace bien, y su resultado es una salida de texto que puede ser procesada con otros comandos mediante tuberías. ls sería en cambio un programa que hace muchas cosas y no siempre bien, y por tanto un comando "antiunix". A mi, esta acusación me parece errónea por varios motivos.
En primer lugar hay que dejar bien claro -aunque no tenga mucho que ver con ls- que si Unix tiene comandos simples para combinarlos mediante tuberías, es precisamente para eso: para combinar, para construir cosas. El propósito de un sistema Unix no es evitar la creación de programas grandes, complejos y con muchas opciones, sino precisamente facilitar su creación. Esos programas no son contrarios al espíritu Unix, son bienvenidos y no desentonan.
Pero sobre todo, el entorno de programación de Unix no es la solución a todo, de hecho a menudo es un entorno pobre (programar scripts complejos en bash es una proeza que debería tenerse en cuenta en el Purgatorio). En el Unix original, construir lineas de comando simples comunicadas con tuberías no sólo eran la manera recomendada de construir programas complejos, sino que era la única manera: Unix en sus inicios no soportaba aspectos tan elementales hoy en día como librerías compartidas. Parte de la funcionalidad de las Xlib de X11 se programó en el servidor porque las librerías compartidas no se había popularizado y los "demonios" eran la manera habitual de compartir código entre clientes.
En el caso de ls y sus numerosísimas opciones, está claro que hay algunas que podrían ser eliminadas y sustituidas por una combinación de shell que procese la salida de un ls más simple. Por ejemplo, la opción -i, que muestra el número de inodo, podría ser eliminada y sustituida por una combinación de comandos que extraigan cada nombre de archivo de la salida de ls, se lo pasen al comando stat, extraigan de stat el número de inodo, e impriman en la pantalla la salida equivalente de ls -i. Sin embargo, lo cierto es que semejante combinación es más compleja, y probablemente también menos eficiente (por los stat()s extra), que su equivalente en ls.c.
Por último, si a pesar de esto a la gente le parece que el ls actual es excesivamente complejo, la propia extensibilidad de Unix permite a uno programarse su ls ideal y utilizarlo en sus scripts (aunque nadie lo hará, porque no merece la pena). En realidad, parte de todo este dilema de ls es que el comando ls es un bloque constructor básico de comandos Unix y simultaneamente es utilizado como programa orientado al "usuario" (del shell): lo "ideal" para algunos sería, supongo, que estas dos funcionalidades estuvieran en dos comandos diferentes y que el último fuese implementado procesando la salida del primero. Lo cierto es que sería una pérdida de tiempo. Aunque Unix tenga sus más y sus menos, que ls tenga muchas opciones es, en mi opinión, el menor de sus problemas.
La repercusión de esos artículos me ha sorprendido y confirmado. Que Unix no es perfecto ni sigue sus propios principios no debería ser a estas alturas sorpresa para nadie, Plan 9 es la confirmación práctica de ello. El mundo Unix padece del mito de la perfección y de la Pureza De Los Principios, y pocos están dispuestos a vivir con el hecho de que usamos derivados de Unix sólo por costumbre y compatibilidad, que instalamos en nuestras máquinas de última generación sistemas operativos con defectos bastante sonrojantes y que podríamos tener cosas mejores si pudiéramos partir de cero.
Pero quería referirme a la extraña tendencia a poner como ejemplo de usurpación de principios a ls y sus numerosas opciones. En realidad, se suele acusar de "bloat" no sólo a ls, sino de todas las utilidades Unix básicas de GNU. Se acusa a estas utilidades de faltar al principio de un programa que hace una sola función y la hace bien, y su resultado es una salida de texto que puede ser procesada con otros comandos mediante tuberías. ls sería en cambio un programa que hace muchas cosas y no siempre bien, y por tanto un comando "antiunix". A mi, esta acusación me parece errónea por varios motivos.
En primer lugar hay que dejar bien claro -aunque no tenga mucho que ver con ls- que si Unix tiene comandos simples para combinarlos mediante tuberías, es precisamente para eso: para combinar, para construir cosas. El propósito de un sistema Unix no es evitar la creación de programas grandes, complejos y con muchas opciones, sino precisamente facilitar su creación. Esos programas no son contrarios al espíritu Unix, son bienvenidos y no desentonan.
Pero sobre todo, el entorno de programación de Unix no es la solución a todo, de hecho a menudo es un entorno pobre (programar scripts complejos en bash es una proeza que debería tenerse en cuenta en el Purgatorio). En el Unix original, construir lineas de comando simples comunicadas con tuberías no sólo eran la manera recomendada de construir programas complejos, sino que era la única manera: Unix en sus inicios no soportaba aspectos tan elementales hoy en día como librerías compartidas. Parte de la funcionalidad de las Xlib de X11 se programó en el servidor porque las librerías compartidas no se había popularizado y los "demonios" eran la manera habitual de compartir código entre clientes.
En el caso de ls y sus numerosísimas opciones, está claro que hay algunas que podrían ser eliminadas y sustituidas por una combinación de shell que procese la salida de un ls más simple. Por ejemplo, la opción -i, que muestra el número de inodo, podría ser eliminada y sustituida por una combinación de comandos que extraigan cada nombre de archivo de la salida de ls, se lo pasen al comando stat, extraigan de stat el número de inodo, e impriman en la pantalla la salida equivalente de ls -i. Sin embargo, lo cierto es que semejante combinación es más compleja, y probablemente también menos eficiente (por los stat()s extra), que su equivalente en ls.c.
Por último, si a pesar de esto a la gente le parece que el ls actual es excesivamente complejo, la propia extensibilidad de Unix permite a uno programarse su ls ideal y utilizarlo en sus scripts (aunque nadie lo hará, porque no merece la pena). En realidad, parte de todo este dilema de ls es que el comando ls es un bloque constructor básico de comandos Unix y simultaneamente es utilizado como programa orientado al "usuario" (del shell): lo "ideal" para algunos sería, supongo, que estas dos funcionalidades estuvieran en dos comandos diferentes y que el último fuese implementado procesando la salida del primero. Lo cierto es que sería una pérdida de tiempo. Aunque Unix tenga sus más y sus menos, que ls tenga muchas opciones es, en mi opinión, el menor de sus problemas.
Suscribirse a:
Entradas (Atom)