Han pasado ya algunos meses desde que la valoración en bolsa de Apple pasó a la de Microsoft. Es algo que se interpretó como uno de esos vaivenes locos de la bolsa al que no se dio más que una importancia simbólica. Y así se lo tomo Steve Ballmer:
"I will make more profits and certainly there is no technology company
in the planet which is as profitable as we are". "Stock markets
will take care of the rest". Hablando en plata: nuestra empresa tiene muchos más beneficios que Apple, por lo que con el tiempo la bolsa se rendirá a la evidencia y volverá a valorarnos más que ellos.
Esto ocurrió hace casi un año, exactamente el tiempo que ha tardado la realidad en pisotearle el argumento a Ballmer. No sólo Microsoft sigue sin estar valorada por encima de Apple, es que este último trimestre Apple ha ganado más dinero que Microsoft: 5.990$ millones vs 5.230$. Y no estamos hablando de ingresos (en los que Apple les sobrepasó hace tiempo - el hardware suele tener menos margen de beneficio que el software), sino en beneficios contantes y sonantes, tras haber pagado las nóminas y los impuestos (los pocos que pagan gracias a los loopholes fiscales, claro).
¿Es demasiado atrevido que un humilde bloguero tenga la arrogancia de sugerir que es hora de asumir que Steve Ballmer es un mal CEO, y que va siendo hora de cambiarlo? Sigue pareciéndome increíble que de Redmon no se oigan más voces críticas cuando Ballmer hace cosas increíblemente estúpidas, como intentar imitar la red de tiendas físicas de Apple. Algo absurdo para una compañía que vende software, que tiene redes de empresas colaboradoras que se lo preinstalan en el 90 y pico % de los ordenadores del mundo, y que se supone que está planeando vender todo a través de Internet. Una pequeña cita del anterior enlace: "Most of the shops aren’t making money, partly
because most of the products are already available at other retailers,
such as Best Buy".
Y hablando de Internet, en realidad una de las razones por las que Microsoft tiene menos beneficios que Apple es, en gran medida, su fallida competencia con Google. En los resultados detallados del último trimestre, se puede observar como las pérdidas en la división de "Servicios Online" siguen aumentando, un agujero de 726$ millones - en un periodo de tres meses. Si no perdieran todo ese dinero, seguirían ganando más que Apple.
Claro que al menos todo ese dinero les ha ayudado a competir con Google en los servicios de Internet. ¿O quizás no?
29 de abril de 2011
24 de abril de 2011
GTK+ 3.0
De Gnome 3 y su nuevo Gnome Shell no hay mucho más que decir, ya está todo el pescado vendido. ¿Y que hay de GTK+? En realidad, lo más interesante son siempre los cambios en la maquinaria, los que no se ven, ya que son los pilares que hacen que una casa se sostenga o no.
GDK: En primer lugar, han rediseñado GDK -la parte de GTK+ que se encarga de interactuar con el sistema gráfico- por completo. GDK estaba modelado, por razones históricas, para encajar con el diseño de las APIs de X.org; lo cual, además de dificultar la portabilidad, era un poquito vetusto. Ahora está diseñado para encajar con el diseño de la librería gráfica Cairo (antes ya usaban Cairo en muchas partes, ahora la usan para todo), cediéndola ya de paso gran parte del tedio de la portabilidad. Siendo realistas, más que una gran mejora, esto es un adecentamiento para ponerse al nivel de otros toolkits bien diseñados (como QT). Pero no deja de ser interesante.
'Backends': Otra novedad en el campo de GDK es que se pueden compilar varios "backends" gráficos en el mismo binario y decidir cuál utilizar en tiempo de ejecución. Por ejemplo, se puede compilar GTK+ con soporte de Wayland y de X.org simultáneamente, y optar por uno u otro dependiendo del contenido de la variable GDK_BACKEND (o autodetectarlo), lo que permitirá que las distribuciones incluyan Wayland y X.org sin tener que preocuparse de que las aplicaciones funcionen o no. Esto es muy bonito, aunque QT lleva pudiendo hacer lo mismo (por ejemplo, "kword --graphicssystem opengl" abre un kword acelerado con OpenGL - desgraciadamente, el mal estado de las implementaciones OpenGL en Linux impide utilizarlo por defecto) desde 2008.
CSS: La siguiente novedad es la capacidad de diseñar themes con sintaxis CSS. Algo que, seguro que se sorprenden, QT ya tenía desde 2006.
Dconf: Han decidido reemplazar Gconf, ese sistema que se encarga de gestionar las configuraciones de ~/.gconf, con un nuevo invento: Dconf + Gsettings. Dconf sería el "backend" de almacenamiento en el disco de las configuraciones, y Gsettings la interfaz que utilizan las aplicaciones para acceder a él. Gsettings puede utilizar varios backends, pero es obvio que está optimizado para utilizar Dconf en Linux. La novedad principal de Dconf es que todas las configuraciones se guardan en un solo archivo binario (seguro que dará mucho que hablar cuando la gente se entere), y la ventaja es que el rendimiento es mucho mejor.
XInput2: Soporte para la extensión de X.org XInput2. XInput2 es una API alternativa que reemplaza el actual infierno de gestión de dispositivos de entrada de X.org por algo decente. En XInput 2.1 -que, desgraciadamente, no entró en la última versión de xorg-server, y tendrá que esperar a la de mediados de este año- se añade buen soporte para multitouch, y los toolkits (también QT) lo soportarán por defecto.
Height-for-width: Esta es una característica muy vaga de una parte de GTK+ llamada "gestión de geometría", y que en la práctica consiste en decidir dónde se colocan las cosas y qué ocurre al redimensionar la ventana. Este nombre tan rimbombante de "height-for-width" quiere decir que a partir de ahora cada widget informará al gestor de geometría de hasta qué punto es apropiado redimensionarle o no, para que pueda redimensionar las cosas como debe ser y no haga cosas como, por ejemplo, lo que ocurre en el caso 3 de esta imagen (algo que puede evitarse con hacks, pero que se soporta correctamente con esta nueva característica). QT lo soporta desde hace tiempo (mínimo 2001).
Gobject introspection: Se ha añadido soporte para introspección en Gobject, lo cual es útil principalmente para automatizar la creación de bindings de otros lenguajes. Una vez que un determinado binding de un lenguaje utilice esta introspección, no necesitará ser "actualizado" cada vez que una nueva versión de GTK+ añada nuevas APIs, como ocurre hoy, y permitirá mayor colaboración entre programas escritos en varios lenguajes. Una vez más, KDE...
Renderizado "offscreen": Esto es algo que se podría simplificar como "capacidad de dibujar en un buffer de memoria". Para entenderlo, hay que resumir en breve la evolución del renderizado de GUIs en Linux. En un principio teníamos las APIs de X.org, que eran del tipo "dibuja un círculo", "dibuja la letra a": el servidor gráfico se ocupaba de renderizar él mismo esas cosas tal y como se le pedía. Entonces vino Keith Packard del cielo y trajo consigo la extensión XRender, que implementa un modelo de composición de imágenes para permitir que las aplicaciones, y no el servidor, tomaran parte en el renderizado. Eso hizo que pasaramos a tener librerías como freetype, que renderizan, a peticion de las aplicaciones, las fuentes con antialiasing y lo que haga falta, y el toolkit va pidiendo al servidor, vía XRender, que dibuje las cosas aquí o allá. De ese modelo, que es el actual, pasamos al del futuro: Las aplicaciones pasan completamente de APIs como XRender, renderizan absolutamente todo por si mismas. Es el modelo de Wayland, la aplicación dibuja lo que quiera en un buffer de memoria que representa a la ventana de la aplicación -ubicado en la memoria de la GPU y generado mediante OpenGL, si quiere-, y cuando se termina de dibujar se notifica al servidor gráfico, que se limita a juntar las imágenes de todas las ventanas, dibujar la imagen final, y enviar el buffer a la salida de vídeo. GTK+ 3 soporta este modelo, y gracias a ello puede incorporar soporte de Wayland con mucha facilidad.
No hay mucho más que contar de las cosas nuevas que incluye GTK+ 3.0. Si que habría que comentar algo de las que no incluyen: animaciones complejas, del estilo de Core Animation o QT QML. ¿Por qué? Porque GTK+ se ha dado completamente por vencida en este aspecto, y lo deja todo en manos de Clutter, que es una librería aparte y sin más relación con GTK+ que el hecho de usar GLib/GObject. ¿Y cómo se integran ambas? Se utiliza el renderizado "offscreen" para que GTK+ dibuje sus cosas en un buffer de memoria, Clutter coge esos buffers y los manipula como se le antoja (que ambas librerías no están muy integradas se comprueba en que puede hacer lo mismo con widgets QT). Un servidor no encuentra mucho sentido a esta división, y se pregunta por qué no se integran Clutter y GTK+ como Dios manda, o por qué GTK+ no desarrolla su propio sistema. Pero de momento la simbiosis entre ambos proyectos parece funcionar bien.
GDK: En primer lugar, han rediseñado GDK -la parte de GTK+ que se encarga de interactuar con el sistema gráfico- por completo. GDK estaba modelado, por razones históricas, para encajar con el diseño de las APIs de X.org; lo cual, además de dificultar la portabilidad, era un poquito vetusto. Ahora está diseñado para encajar con el diseño de la librería gráfica Cairo (antes ya usaban Cairo en muchas partes, ahora la usan para todo), cediéndola ya de paso gran parte del tedio de la portabilidad. Siendo realistas, más que una gran mejora, esto es un adecentamiento para ponerse al nivel de otros toolkits bien diseñados (como QT). Pero no deja de ser interesante.
'Backends': Otra novedad en el campo de GDK es que se pueden compilar varios "backends" gráficos en el mismo binario y decidir cuál utilizar en tiempo de ejecución. Por ejemplo, se puede compilar GTK+ con soporte de Wayland y de X.org simultáneamente, y optar por uno u otro dependiendo del contenido de la variable GDK_BACKEND (o autodetectarlo), lo que permitirá que las distribuciones incluyan Wayland y X.org sin tener que preocuparse de que las aplicaciones funcionen o no. Esto es muy bonito, aunque QT lleva pudiendo hacer lo mismo (por ejemplo, "kword --graphicssystem opengl" abre un kword acelerado con OpenGL - desgraciadamente, el mal estado de las implementaciones OpenGL en Linux impide utilizarlo por defecto) desde 2008.
CSS: La siguiente novedad es la capacidad de diseñar themes con sintaxis CSS. Algo que, seguro que se sorprenden, QT ya tenía desde 2006.
Dconf: Han decidido reemplazar Gconf, ese sistema que se encarga de gestionar las configuraciones de ~/.gconf, con un nuevo invento: Dconf + Gsettings. Dconf sería el "backend" de almacenamiento en el disco de las configuraciones, y Gsettings la interfaz que utilizan las aplicaciones para acceder a él. Gsettings puede utilizar varios backends, pero es obvio que está optimizado para utilizar Dconf en Linux. La novedad principal de Dconf es que todas las configuraciones se guardan en un solo archivo binario (seguro que dará mucho que hablar cuando la gente se entere), y la ventaja es que el rendimiento es mucho mejor.
XInput2: Soporte para la extensión de X.org XInput2. XInput2 es una API alternativa que reemplaza el actual infierno de gestión de dispositivos de entrada de X.org por algo decente. En XInput 2.1 -que, desgraciadamente, no entró en la última versión de xorg-server, y tendrá que esperar a la de mediados de este año- se añade buen soporte para multitouch, y los toolkits (también QT) lo soportarán por defecto.
Height-for-width: Esta es una característica muy vaga de una parte de GTK+ llamada "gestión de geometría", y que en la práctica consiste en decidir dónde se colocan las cosas y qué ocurre al redimensionar la ventana. Este nombre tan rimbombante de "height-for-width" quiere decir que a partir de ahora cada widget informará al gestor de geometría de hasta qué punto es apropiado redimensionarle o no, para que pueda redimensionar las cosas como debe ser y no haga cosas como, por ejemplo, lo que ocurre en el caso 3 de esta imagen (algo que puede evitarse con hacks, pero que se soporta correctamente con esta nueva característica). QT lo soporta desde hace tiempo (mínimo 2001).
Gobject introspection: Se ha añadido soporte para introspección en Gobject, lo cual es útil principalmente para automatizar la creación de bindings de otros lenguajes. Una vez que un determinado binding de un lenguaje utilice esta introspección, no necesitará ser "actualizado" cada vez que una nueva versión de GTK+ añada nuevas APIs, como ocurre hoy, y permitirá mayor colaboración entre programas escritos en varios lenguajes. Una vez más, KDE...
Renderizado "offscreen": Esto es algo que se podría simplificar como "capacidad de dibujar en un buffer de memoria". Para entenderlo, hay que resumir en breve la evolución del renderizado de GUIs en Linux. En un principio teníamos las APIs de X.org, que eran del tipo "dibuja un círculo", "dibuja la letra a": el servidor gráfico se ocupaba de renderizar él mismo esas cosas tal y como se le pedía. Entonces vino Keith Packard del cielo y trajo consigo la extensión XRender, que implementa un modelo de composición de imágenes para permitir que las aplicaciones, y no el servidor, tomaran parte en el renderizado. Eso hizo que pasaramos a tener librerías como freetype, que renderizan, a peticion de las aplicaciones, las fuentes con antialiasing y lo que haga falta, y el toolkit va pidiendo al servidor, vía XRender, que dibuje las cosas aquí o allá. De ese modelo, que es el actual, pasamos al del futuro: Las aplicaciones pasan completamente de APIs como XRender, renderizan absolutamente todo por si mismas. Es el modelo de Wayland, la aplicación dibuja lo que quiera en un buffer de memoria que representa a la ventana de la aplicación -ubicado en la memoria de la GPU y generado mediante OpenGL, si quiere-, y cuando se termina de dibujar se notifica al servidor gráfico, que se limita a juntar las imágenes de todas las ventanas, dibujar la imagen final, y enviar el buffer a la salida de vídeo. GTK+ 3 soporta este modelo, y gracias a ello puede incorporar soporte de Wayland con mucha facilidad.
No hay mucho más que contar de las cosas nuevas que incluye GTK+ 3.0. Si que habría que comentar algo de las que no incluyen: animaciones complejas, del estilo de Core Animation o QT QML. ¿Por qué? Porque GTK+ se ha dado completamente por vencida en este aspecto, y lo deja todo en manos de Clutter, que es una librería aparte y sin más relación con GTK+ que el hecho de usar GLib/GObject. ¿Y cómo se integran ambas? Se utiliza el renderizado "offscreen" para que GTK+ dibuje sus cosas en un buffer de memoria, Clutter coge esos buffers y los manipula como se le antoja (que ambas librerías no están muy integradas se comprueba en que puede hacer lo mismo con widgets QT). Un servidor no encuentra mucho sentido a esta división, y se pregunta por qué no se integran Clutter y GTK+ como Dios manda, o por qué GTK+ no desarrolla su propio sistema. Pero de momento la simbiosis entre ambos proyectos parece funcionar bien.
16 de abril de 2011
Novedades en systemd, III
(Continuación de esta serie)
Tal vez muchos de ustedes ya crean que systemd es de por si bueno y suficientemente interesante. Pues aun no han visto nada. Hoy toca hablar de dos nuevas características de systemd, que son una prueba de hasta que punto las cosas pueden mejorar dramáticamente cuando si se replantean a lo grande y con talento.
La primera tiene que ver con los chroot's. Últimamente me he dado cuenta (escuchando el podcast de Pánico en el Núcleo, por ejemplo) de que las cosas demasiado técnicas pierden a la gente, así que me pregunto si todo el mundo que lee esto sabrá que es un chroot. Lo resumiré diciendo que si uno tiene una distro en, por ejemplo, /mnt/debian, basta ejecutar "chroot /mnt/debian" para conseguir un shell que tenga como raiz (/) ese directorio, como si estuviera dentro de esa distro. En realidad, chroot es una forma antigua y muy primitiva (aunque también versátil) de virtualización, y suele utilizarse para todo tipo de cosas; en el caso de sistemas de inicio para crear una sandbox en servicios para mejorar la seguridad (pero no mucho, hace tiempo que se sabe que chroot no es nada seguro).
El caso es que Linux soporta, desde versiones tempranas, una característica inventada por Plan 9, llamada "diferentes espacios de nombres del sistema de archivos", que consiste en que cada proceso del sistema puede tener, opcionalmente, una visión diferente de los directorios del sistema de archivos. Un proceso puede, por ejemplo, montar un sistema de archivos en /mnt, o eliminar un directorio, y que esa operación solo sea visible para él, mientras el resto de procesos del sistema no se entera de nada. Con esto se puede implementar una sandbox al estilo chroot pero con seguridad de verdad.
Systemd permite a los servicios explotar esta característica añadiendo a los archivos de configuración una línea como "InaccessibleDirectories=/directorio", que hace que /directorio simplemente no sea visible ni accesible por el proceso. También está "ReadOnlyDirectories=/etc", que hace que /etc sea visible, pero en modo de solo lectura. Y, por cierto, también permite crear chroots simples con "RootDirectory=/directorio/del/chroot".
Pero no se queda ahí, uno de los problemas tanto de los chroots como de la nueva solución propuesta es que los números de los PIDs se comparten entre todo el sistema, así que se ha creado un comando, systemd-nspawn, que a lo anterior añade las capacidades de virtualización de PIDs del kernel, es decir, que permite crear una especie de contenedores/jaulas/zonas muy simples. Con lo cual, uno puede arrancar una distro con un comando como "$ systemd-nspawn -d /directorio/de/distro/debian /sbin/init". O sea, un sustituto del comando chroot.
La segunda característica que se ha añadido a systemd es la medición del tiempo de inicio, tanto de todo el sistema como de cada servicio. Para empezar, en cada inicio se deja en los logs un mensaje que notifica que el inicio se ha completado, el tiempo total que se ha tardado, y qué porción de tiempo se ha empleado en arrancar el kernel y cual en los programas de inicio. Con el comando "$ systemd-analyze blame" se puede ver una lista de todos los servicios iniciados y el tiempo que tardan en iniciarse cada uno. Y, finalmente, se ha integrado una especie de bootchart simple que puede verse con el comando "$ systemd-analyze plot > foo.svg".
Repito, un ejemplo de lo mucho que pueden mejorar las cosas cuando alguien con talento se las replantea como Dios manda.
Tal vez muchos de ustedes ya crean que systemd es de por si bueno y suficientemente interesante. Pues aun no han visto nada. Hoy toca hablar de dos nuevas características de systemd, que son una prueba de hasta que punto las cosas pueden mejorar dramáticamente cuando si se replantean a lo grande y con talento.
La primera tiene que ver con los chroot's. Últimamente me he dado cuenta (escuchando el podcast de Pánico en el Núcleo, por ejemplo) de que las cosas demasiado técnicas pierden a la gente, así que me pregunto si todo el mundo que lee esto sabrá que es un chroot. Lo resumiré diciendo que si uno tiene una distro en, por ejemplo, /mnt/debian, basta ejecutar "chroot /mnt/debian" para conseguir un shell que tenga como raiz (/) ese directorio, como si estuviera dentro de esa distro. En realidad, chroot es una forma antigua y muy primitiva (aunque también versátil) de virtualización, y suele utilizarse para todo tipo de cosas; en el caso de sistemas de inicio para crear una sandbox en servicios para mejorar la seguridad (pero no mucho, hace tiempo que se sabe que chroot no es nada seguro).
El caso es que Linux soporta, desde versiones tempranas, una característica inventada por Plan 9, llamada "diferentes espacios de nombres del sistema de archivos", que consiste en que cada proceso del sistema puede tener, opcionalmente, una visión diferente de los directorios del sistema de archivos. Un proceso puede, por ejemplo, montar un sistema de archivos en /mnt, o eliminar un directorio, y que esa operación solo sea visible para él, mientras el resto de procesos del sistema no se entera de nada. Con esto se puede implementar una sandbox al estilo chroot pero con seguridad de verdad.
Systemd permite a los servicios explotar esta característica añadiendo a los archivos de configuración una línea como "InaccessibleDirectories=/directorio", que hace que /directorio simplemente no sea visible ni accesible por el proceso. También está "ReadOnlyDirectories=/etc", que hace que /etc sea visible, pero en modo de solo lectura. Y, por cierto, también permite crear chroots simples con "RootDirectory=/directorio/del/chroot".
Pero no se queda ahí, uno de los problemas tanto de los chroots como de la nueva solución propuesta es que los números de los PIDs se comparten entre todo el sistema, así que se ha creado un comando, systemd-nspawn, que a lo anterior añade las capacidades de virtualización de PIDs del kernel, es decir, que permite crear una especie de contenedores/jaulas/zonas muy simples. Con lo cual, uno puede arrancar una distro con un comando como "$ systemd-nspawn -d /directorio/de/distro/debian /sbin/init". O sea, un sustituto del comando chroot.
La segunda característica que se ha añadido a systemd es la medición del tiempo de inicio, tanto de todo el sistema como de cada servicio. Para empezar, en cada inicio se deja en los logs un mensaje que notifica que el inicio se ha completado, el tiempo total que se ha tardado, y qué porción de tiempo se ha empleado en arrancar el kernel y cual en los programas de inicio. Con el comando "$ systemd-analyze blame" se puede ver una lista de todos los servicios iniciados y el tiempo que tardan en iniciarse cada uno. Y, finalmente, se ha integrado una especie de bootchart simple que puede verse con el comando "$ systemd-analyze plot > foo.svg".
Repito, un ejemplo de lo mucho que pueden mejorar las cosas cuando alguien con talento se las replantea como Dios manda.
1 de abril de 2011
¿Qué hace ese directorio /run en mi sistema?
Parece ser que todo sistema Linux va a incorporar un directorio "run" a su directorio raiz, o sea, un /run. La primera reacción de muchos Linuxeros va a ser empezar a afilar los cuchillos, pero pueden estar tranquilos: En realidad es una buena idea, y nos librará de varios artilugios oscuros de los que hasta ahora no éramos demasiado conscientes (nota: este post viene a ser una asimilación de esta explicación de Lennart Poettering).
En el proceso de inicio temprano de un sistema Linux típico suelen ejecutarse varios programas -udev, mdadm, systemd, scripts varios- que necesitan almacenar datos de la misma categoría que los que hay en /var/run. Sin embargo se va a tardar un rato en montarlo, ya que podría estar ubicado incluso en un disco distinto a "/", recordemos que es "tradición" unixera considerar a /var un directorio de datos altamente "var-iables", con mucha actividad, idóneo para ubicarse en un disco rápido (por ejemplo un RAID, precisamente el tipo de cosas que necesita mdadm).
Pero estos programas de inicio necesitan guardar esos datos. ¿Dónde hacerlo, puesto que no se puede asumir que guardalos en /var/run es seguro? La cosa no está nada clara, y la convención no oficial ha sido usar como almacen a /dev, que se montado sobre tmpfs desde el principio. En mi sistema, dentro de /dev tengo los siguientes directorios de este tipo: .initramfs, .mdadm, .mount, .systemd, .udev.
Sin embargo, ese no es el sitio apropiado para guardar esos datos y supone una duplicación mal hecha de /var/run. En otras palabras, es un hack. Así que, en un ejemplo de unidad que raras veces suele verse en este mundo, se han unido todas las distros principales para decidir que en realidad /var/run no pertenece a /var: /var es para "datos persistentes que cambian mucho" y /var/run es para "datos volátiles que cambian mucho". Asi que se ha llegado a la decisión unánime de que es necesario un nuevo directorio raiz "/run", montado sobre tmpfs; /var/run por su parte se convertirá en un enlace a /run, y /var/lock (que ya de paso sufre los mismos problemas) lo será a /run/lock.
De ese modo, todas las aplicaciones, tanto las que se inician al principio del sistema como las menos tempraneras, utilizan el mismo directorio montado sobre tmpfs, ya no es necesario meter directorios ocultos en /dev, y /var/run y /var/lock pasarán a compartir el mismo tmpfs.
A la vista de los argumentos es indudable que es una decisión buena, pero no olvidemos que existen fuertes ultraconservadurismos en el mundo Unix/Linux que consideran la introducción de algo así como algo que enturbia las prístinas aguas del Verdadero Diseño Unixero y corroe la pureza de nuestros espíritus. A Lennart Poettering le tocará, una vez más, cargar con las culpas de querer mejorar las cosas.
En el proceso de inicio temprano de un sistema Linux típico suelen ejecutarse varios programas -udev, mdadm, systemd, scripts varios- que necesitan almacenar datos de la misma categoría que los que hay en /var/run. Sin embargo se va a tardar un rato en montarlo, ya que podría estar ubicado incluso en un disco distinto a "/", recordemos que es "tradición" unixera considerar a /var un directorio de datos altamente "var-iables", con mucha actividad, idóneo para ubicarse en un disco rápido (por ejemplo un RAID, precisamente el tipo de cosas que necesita mdadm).
Pero estos programas de inicio necesitan guardar esos datos. ¿Dónde hacerlo, puesto que no se puede asumir que guardalos en /var/run es seguro? La cosa no está nada clara, y la convención no oficial ha sido usar como almacen a /dev, que se montado sobre tmpfs desde el principio. En mi sistema, dentro de /dev tengo los siguientes directorios de este tipo: .initramfs, .mdadm, .mount, .systemd, .udev.
Sin embargo, ese no es el sitio apropiado para guardar esos datos y supone una duplicación mal hecha de /var/run. En otras palabras, es un hack. Así que, en un ejemplo de unidad que raras veces suele verse en este mundo, se han unido todas las distros principales para decidir que en realidad /var/run no pertenece a /var: /var es para "datos persistentes que cambian mucho" y /var/run es para "datos volátiles que cambian mucho". Asi que se ha llegado a la decisión unánime de que es necesario un nuevo directorio raiz "/run", montado sobre tmpfs; /var/run por su parte se convertirá en un enlace a /run, y /var/lock (que ya de paso sufre los mismos problemas) lo será a /run/lock.
De ese modo, todas las aplicaciones, tanto las que se inician al principio del sistema como las menos tempraneras, utilizan el mismo directorio montado sobre tmpfs, ya no es necesario meter directorios ocultos en /dev, y /var/run y /var/lock pasarán a compartir el mismo tmpfs.
A la vista de los argumentos es indudable que es una decisión buena, pero no olvidemos que existen fuertes ultraconservadurismos en el mundo Unix/Linux que consideran la introducción de algo así como algo que enturbia las prístinas aguas del Verdadero Diseño Unixero y corroe la pureza de nuestros espíritus. A Lennart Poettering le tocará, una vez más, cargar con las culpas de querer mejorar las cosas.
Suscribirse a:
Entradas (Atom)