El artículo describe cómo funcionan las señales en Linux y cómo se manejan usando el API de POSIX. Se cubrirán las funciones en todos los sistemas modernos de Linux, cosa que también se puede aplicar a la mayoría de los sistemas POSIX (a menos que se indique lo contrario). Para seguir bien el artículo se recomienda tener un conocimiento básico acerca de señales.

En los primeros días de la informática, los programadores sólo podían soñar con la portabilidad. Todos los programas se escribieron directamente en código de máquina para cada arquitectura de computadora en la que debían ejecutarse. Los lenguajes ensambladores con nombres mnemotécnicos para cada instrucción de la CPU y otras ventajas facilitaron un poco la vida de los programadores, pero los programas seguían siendo específicos de la arquitectura. Los sistemas operativos aún no se habían inventado, por lo que un programa no […].

Los sistemas operativos y los sistemas de archivos se han desarrollado tradicionalmente de la mano ya que generalmente se imponen limitaciones mutuas. Hoy tenemos dos líderes importantes en la semántica del sistema de archivos: Windows y POSIX. Están muy cerca uno del otro según el conjunto completo de características, pero sucedieron cosas interesantes antes de que POSIX monopolizara la semántica de los sistemas de archivos.

bic es un proyecto que permite a los desarrolladores explorar y probar API usando un bucle de lectura, evaluación e impresión (REPL, Read, Eval and Print Loop en inglés) similar al que tiene Python o al propio BASH.

El API REST de LXD puede ser accedido directamente o bien a través de un socket Unix o bien a través de HTTPS. El protocolo es idéntico en ambos casos, la única diferencia es que en el caso del socket Unix se usa texto plano mientras que si se usa HTTPS se requiere autenticación. A continuación se muestran los pasos para el acceso al API y cómo se usa.

Cuando empezamos a trabajar en systemd, lo construimos alrededor de un bucle de eventos escrito a mano usando epoll en Linux. Pero cuanto más crecía nuestro proyecto, más nos dimos cuenta de las limitaciones del uso de epoll. Algunas de estas limitaciones son que usaba demasiados descriptores de fichero, que el gestionar el orden de los eventos era tedioso o que para cada programa que usaba systemd añadíamos el mismo código duplicándolo. Así que, a partir de ahí para solucionar estos problemas comenzamos a trabajar en sd-bus.

Todos los proyectos y librerías de Gtkmm han pasado a usar C++11 de forma predeterminada, no requiriendo ya la opción --std=C++11 en el compilador. Además, se pueden seguir usando las autotools en los proyectos junto con la macro AX_CXX_COMPILE_STDCXX_11() para requerir C++11. Los cambios a realizar en el código gracias a esta versión de C++ son, entre otros: usar auto para variables; bucles con rangos; usar nullptr en lugar de NULL; usar lambdas; etc.

Con la nueva versión 221 de systemd hemos declarando la API sd-bus de systemd como estable. sd-bus es nuestra biblioteca mínima de D-Bus que envuelve el clásico socket-D-Bus y kdbus. La biblioteca ha sido parte de systemd desde hace tiempo (aunque sólo para uso interno) ya que quería tener la libertad de poder hacer cambios en la API sin afectar al resto de usuarios de esta biblioteca. Sin embargo, ahora estamos seguros de que es un API estable por lo que estará disponible a partir de la versión 221 de systemd.