Uno de los conceptos más importante que trajo el movimiento Open Source es que el software¹, más que un producto es un proceso. Las nuevas tendencias en gestión de proyectos retoman ese concepto. Sí, aun cuando hablen paradójicamente que lo importante es el producto. En el antiguo concepto de tipo catedral, un producto solo podía estar terminado tras meses, años o décadas. En este momento no voy a ahondar esa idea en particular. Pero quiero aportar el siguiente diagrama para tanto para el arranque como para la consecusión de proyectos. Puede ser una aplicación, una documentación, una implementación, creo que es bastante abarcativa la idea. Describiré bremvemente cada fase del diagrama:

Conclusión

Si bien hay un momento en que el proceso da y debe dar como resultado un producto, es bueno tener definidas algunas fases. Una nota especial a los que padecen perfeccionismo. Es importante notar que hay dos frentes aquí. El primero es que justamente aquellos que están detrás de los resultados rápidos y atajos son muchas veces los que más hablan sobre lo perfecto que tienen que estar las cosas. El segundo frente es interno. El que siempre encuentra un obstáculo para pasar de la fase del Valor Agregado. Si bien el primer frente es incontrolable y no depende de nosotros ya que no es nuestro problema, el segundo es el que nos tiene que interesar, acallar esa vocecita que nunca quiere que obtengamos el producto. Justamente esa fase se llama Valor Agregado porque es lo que convierte tu trabajo en un producto en algo distinto. Es esa pieza que falta para que el mecanismo funcione correctamente.

Este obra está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.

De acuerdo a los resultados, podría verse que autotools sigue siendo el “Build System” predominante. Otros paquetes todavía usan un makefile plano, tal vez merezcan un análisis aparte.

Limitaciones de estas estadísticas:

1. Se confía en que siempre que se usa CMakeList.txt se usa cmake.
2. Se confía en que siempre que existan los archivos  configure.ac o configure.in y Makefile.am o Makefile.in y se encuentra en el archivo spec el procedimiento ./configure && make se usan las autotools
3. Hubo 1 (un) archivos que no pudieron ser inspeccionados por dtrx porque tenía la extensión incorrecta

Actualización 2019

Sistema de construcción de paquetes (Parte 3)

El siguiente paso fue descomprimir de manera recursiva los paquetes, para luego poder inspeccionar en ellos. Lo hice con una herramienta poco conocida dtrx. Lo interesante de este script de python es que puede realizar extracciones recursivas y de acuerdo a la extensión del archivo utiliza el software de extracción necesario. Esperemos que pronto esté en los repositorios de Fedora (ver la solicitud en Red Hat Bugzilla).

Una vez descompridos todos los paquetes, se corrió el siguiente script

#! /bin/bash #Very simple script to get Build System Statistc dir=1
rm -f /tmp/ant /tmp/cmake /tmp/autotools /tmp/makefile /tmp/autoconf /tmp/autotools_procedure
for i in (find dir -maxdepth 1 -mindepth 1 -type d)
do
ls -R1 i | grep -q -P -m1 "^configure.(ac|in)"
if [[ ? -eq 0 ]];then
ls -R1 i | grep -P -q -m1 "^Makefile\.(am|in)"
if [[ ? -eq 0 ]];then
echo "{i##/}" >> /tmp/autotools 2>/dev/null
cant_autotools=(($cant_autotools+1))
else
echo "{i##/}" >> /tmp/autoconf 2>/dev/null
cant_autoconf=(($cant_autoconf+1))
fi
fi
#cmake
ls -R1 i | grep -q -m1 CMakeLists.txt
if [[ ? -eq 0 ]];then
cant_cmake=((cant_cmake+1))
echo "{i##/}" >> /tmp/cmake 2>/dev/null
fi
#Plain makefile
ls -R1 i | grep -q -P -m1 "^configure\.(ac|in)"
if [[ ? -ne 0 ]];then
ls -R1 i | grep -q -P -m1 "^(Makefile.(am|in)|CMakeLists.txt)"
if [[ ? -ne 0 ]];then
ls -R1 i | grep -q -P -m1 "^Makefile"
if [[ ? -eq 0 ]];then
cant_makefile=((cant_makefile+1))
echo "${i##/}" >> /tmp/makefile 2> /dev/null
fi
fi
fi
find i -name "*.spec" | xargs pcregrep -q -M "%build(.*\n)*(./|%)configure.*\n(.*\n)*make(.*\n)*%install"
if [[ ? -eq 0 ]];then
cant_autotools_build_section=(($cant_autotools_build_section+1))
echo "{i##*/}" >> /tmp/autotools_procedure
fi
done
echo "###Resultados###"
[ -f /tmp/autotools ] && echo -e "There are cant_autotools with autotools:\n\n(sort /tmp/autotools)\n\n"
[ -f /tmp/cmake ] && echo -e "cant_cmake with cmake:\n\n(sort /tmp/cmake)\n\n"
[ -f /tmp/makefile ] && echo -e "cant_makefile with makefile:\n\n(sort /tmp/makefile)\n\n"
[ -f /tmp/autoconf ] && echo -e "cant_autoconf with only autoconf:\n\n(sort /tmp/autoconf)\n\n"
[ -f /tmp/autotools_procedure ] && echo -e "cant_autotools_build_section with only autotools_build_section\n\n(sort /tmp/autotools_procedure)"

En la siguiente parte veremos los resultados….

El archivo /proc/net/sockstat muestra una síntesis muy útil de cada tipo de socket:

# cat /proc/net/sockstat

sockets: used 435
TCP: inuse 29 orphan 0 tw 10 alloc 58 mem 2
UDP: inuse 101 mem 83
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

Interesante ¿no?

Algo bastante frecuente es crear archivos temporales a mano para probar cierto código. Estaba bastante acostumbrado a crear archivos del tipo /tmp/q[0-9]. Así, terminaba con muchos archivos con ese patrón. Hay varios problemas con eso, uno de ellos es que si ya tenemos abierto un archivo /tmp/q1 por ejemplo, podemos fácilmente olvidar eso y abrirlo en otra shell con vim. Y ya sabemos como nuestro querido editor se molesta (y con razón en esos casos). Un truco que se me había ocurrido era crear un alias de este tipo: alias viq='alias viq='vi /tmp/q$(date +'%s')'

El problema con ese approach es que no era reutilizable. Es decir al ejecutarlo de vuelta abría un archivo con otro nombre. Existe una opción que es tal vez mejor y es usar el comando mktemp.

Ejemplo:

mktemp 
/tmp/tmp.7WUOKYMTEQ

Es decir, crea el archivo /tmp/tmp.7WUOKYMTEQ

Si el archivo deseamos crearlo en otro lugar, sencilamente hacemos algo así:

mktemp -d /home/sergio/temp

También podemos editar el archivo directamente:

mktemp|xargs vim -

Nota: Los nombres de los paquetes están puestos como ejemplos

1. Mostrar los tipos de archivos que contiene un paquete

rpm -q --fileclass zram

2. Mostrar el orden y fecha en que fueron instalados los paquetes

rpm -qa --last --qf '%{name}\n'|tac

3. Mostrar los nombres (y solamente los nombres!) de todos los paquetes instalados

rpm -qa --qf '%{name}'|sort

4. Ver los cambios que tiene un paquete en su versión

rpm -q --changes neovim|less

5. Ver lo que hace un paquete al instalarse/desinstalarse

rpm -q --scripts mariadb-server

6. Restaurar los permisos predeterminados

rpm --restore mariadb

Este comando restaura los permisos, propietarios y capacidades de los archivos. No reestablece marcas de tiempo.

7. Extraer los archivos de un paquete

cd /tmp
dnf download mariadb-server # Aquí puede usarse también yumdownloader
mkdir mariadb-server
mv mariadb-server*rpm mariadb-server
cd mariadb-server
rpm2cpio mariadb-server  | cpio -imdv

8. Listar los paquetes duplicados

rpm -qa --dupes

9. Encontrar el archivo de licencia del paquete

rpm -qL firefox

10. Operar por red

Las operaciones con rpm se pueden realizar también con direcciones remotas, como se muestra en la imagen inferior:

Más información

rpm.org - Home

Hace algún tiempo les había presentado a buku, un gestor de línea de comandos de marcadores. Usar Firefox y buku rompe un poco el flujo de trabajo al tener que ir a una línea de comandos. Entonces aquí es cuando bukubrow, un complemento escrito por Sam A. Horvath-Hunt viene al rescate. Se trata de una extensión para Firefox que funciona como interfaz gráfica de buku:

Con esta extensión podemos buscar, agregar, editar, borrar marcadores, abrirlos en ventanas y/o pestañas. Todos eso se puede hacer o bien accediendo al botón en la barra de herramientas como haciendo clic derecho sobre la página deseada. Es importante tener en cuenta que es necesario bajar e instalar la bukubrow-host que sirve para conectar buku con la extensión. Esta aplicación usa un archivo json para conectarse con la extensión de Firefox:

{"name":"com.samhh.bukubrow","description":"Bukubrow host for the Firefox extension","path":"/usr/local/bin/bukubrow-linux-x64","type":"stdio","allowed_extensions":["bukubrow@samhh.com"]}

De esta manera podemos manipular la base de buku directamente desde Firefox :wink:

Más información: Native messaging - Mozilla | MDN

Esta es una tabla comparativa resumida de los 3 sistemas operativos principales en la actualidad. Si bien Wikipedia cuenta con una muy buena, decidí hacer una resumida con los datos que a mí entender son los más buscados e interesantes.

Fuente y más información: - macOS - Wikipedia

• Microsoft Windows - Wikipedia

• Linux - Wikipedia

• Comparison of operating systems - Wikipedia