Actividad sobre Feenberg

Pregunta 1

¿qué relaciones puedes establecer en esta conceptualización de la general tecnología con los desarrollos específicos de software, libre o privativo, con los diseños de las interfaces de usuario (físicas o lógicas) o incluso la cuestión de la utilidad real del acceso al código fuente para aquellos usuarios no programadores?

Feenberg de alguna manera dice que el rango de intereses es proporcional al disfrute de los seres humanos y el beneficio de la naturaleza. El acceso al codigo fuente es una condición indispensable pero no suficiente para que un ser humano puede disfrutar de la tecnología y a su vez que produzca resultados benéficos para la naturaleza.

Pregunta 2

¿cual podría ser un ejemplo del ámbito del software de códigos técnicos que se corresponden con "modos de vida culturalmente asegurados" y ejercicios de poder hegemónicos?

Allí donde tales códigos están reforzados por la percepción que los individuos tienen acerca de su propio interés y de la ley, su significado político generalmente pasa desapercibido. Esto es lo que significa decir que un cierto modo de vida está culturalmente asegurado y que el poder correspondiente es hegemónico. Así como la filosofía política cuestiona las formaciones culturales que se han arraigado a sí mismas en la ley, la filosofía de la tecnología cuestiona las formaciones que se han arraigado a sí mismas en códigos técnicos.

Un código técnico es la realización de un interés bajo la forma de una solución técnicamente coherente a un problema.

Ejemplo de modo de vida completamente asegurado y que el poder es hegemónico

Creo que dos ejemplos del mantenimiento del status-quo son los teléfonos celulares. Si bien por una lado muchos poseen algunos componente libres, el hecho de depender de la compañía telefónica, y la privación del uso como administradores del mismo hacen que el usuario nunca sea dueño realmente de dicho dispositivo.

Otro caso mucho más sutil es la "invisibilidad" de Google. El famoso verbo googlear como sinónimo de buscar en Internet. Ignorando las políticas y propósitos de la empresa.

Estas prácticas tecnocorporativas con el apoyo de algunos gobierno producen un sentido común muy difícil de desafiar:

Technical codes define a framework of technical decision-making within which certain choices appear rational.

SPT v9n1 - The Technical Codes of Online Education | Virginia Tech Scholarly Communication University Libraries

Pregunta 3

En la misma página, Feenberg afirma: "Esta descripción ayuda a entender la naturaleza de las controversias éticas que involucran a la tecnología en el mundo real. A menudo, éstas encienden la **supuesta oposición entre los estándares corrientes de eficiencia técnica y los valores.**" ¿en qué discusiones típicas por el uso/no uso de software libre podría aplicarse esta afirmación? Analicen un caso que conozcan.

Un caso que se me ocurre es el de voto electrónico. Detrás de un supuesto mensaje de eficiencia, no otra cosa que crear más fuentes de errores, más aun cuando se usa software no libre. El valor de la privacidad y del código fuente no está para nada reñido con la eficiencia que un escrutinio podría tener realizado con software libre debidamente auditado, o aun mejor con el tradicional voto en papel.

Tutorial: Autenticación en SSH con clave pública

Este es un tutorial para que empecemos a usar claves públicas para autenticarnos. El único requisito es que hayamos ingresado a un servidor o host remoto con ssh. En nuestro ejemplo ese host tiene la ip 10.0.3.11.

i
1

El uso de autenticación por clave pública, tal como vimos en el post anterior tiene la ventaja de no tener que ingresar usuario y contraseña. Esto puede ser útil en casos en que necesitemos realizar alguna tarea en un host remoto de manera no interactiva. Por ejemplo podríamos crear una tarea programada que ejecute todos los días un script de backup. Veremos paso a paso como conseguirlo. Lo primero que tendremos que hacer es generar un par de claves. Para ellos ejecutaremos el siguiente comando: ssh-keygen

Como se ve en la imagen de abajo se nos preguntará la ruta de la clave privada, aceptamos la predeterminada presionando la tecla Enter.

y además se nos pedirá una passphrase. La passphrase es una frase que sea fácil de recordar para uno mismo, pero a la vez difícil de adivinar para otros. El propósito es cifrar la clave privada. Si te estás preguntando ¿para qué hacer todo esto si de todas maneras tendré que ingresa una passphrase para autenticarme. La respuesta es que tenemos técnicas como veremos un poco más abajo, para evitar la necesidad del ingreso de la frase una y otra vez. Ingresamos la frase una vez después de la otra:

Esto generará dos archivos en el directorio ~/.ssh: id_rsa y id_rsa.pub que son la clave privada y la clave pública respectivamente. Como sus nombres lo indican la clave privada no debe compartirse, en cambio la clave pública es la que nosirve para identificarnos como usuarios frente a otros hosts y se puede compartir.

En este momento tenemos que copiar la clave pública al host que funciona como servidor ssh. La manera más fácil y ráṕida de hacerlo es con el comando siguiente:

ssh-copy-id

Ingresamos la contraseña de root y luego presionamos la tecla Enter. Lo que hace este comando es agregar la clave pública del archivo id_rsa.pub al archivo /root/.ssh/authorized_keys del servidor ssh.

Ahora lo que hacemos es reemplazar la shell actual con el agente de ssh y re-ejecutando la shell bash. El agente de ssh será el encargado de guardar las claves privadas en memoria para que no tengamos que ingresar más de una vez la passphrase:

ssh-agent

Luego ejecutamos el comando ssh-add:

ssh-add

Se nos pedirá la frase, la ingresamos y le damos Enter.

ssh sin contraseña

A través de este tutorial mencionamos varios conceptos que podés ampliar recurriendo a los siguientes enlaces:


  1. Photo by Jametlene Reskp on Unsplash 

Guía Breve sobre ssh con clave pública

La autenticación por clave pública nos permite loguearnos a un host sin necesidad de ingresar usuario y contraseña.

Llaves

unsplash-logo CMDR Shane

Descripción del método

Nociones fundamentales

  • El esquema se basa en criptografía de clave pública.
  • Usamos claves separadas para cifrar y descifrar.
  • Es imposible obtener la clave para descifrar a partir de la clave para cifrar
  • Solamente el cliente sabe la clave privada.

Funcionamiento

  • Desde el lado del cliente ssh creamos un par de claves (una pública y otra privada).

    • Cada clave se guarda en archivo separado.
    • Tenemos la opción en este momento de cifrar su clave privada mediante una frase de paso. La clave privada queda inutilizable si olvidamos esa contraseña.
    • Desde el lado cliente copiamos la clave pública agregándola al archivo ~/.ssh/authorized_keys en su directorio de la máquina remota.
    • Luego de esto, el usuario puede loguearse sin proporcionar la contraseña.
    • Cuando nos logueamos, el programa ssh le dice al servidor que par de claves le gustaría usar para autenticar. El cliente verifica que tiene acceso a la clave privada y el servidor verifica que la clave correspondiente está autorizada para aceptar la cuenta.
    • El servidor puede informarle al cliente los errores que impidan que la autenticación por clave pública se pueda usar exitósamente luego de que la autenticación se complete usando un método diferente.
    • De manera predeterminada si falla el método por clave pública se usará otro método, como por ejemplo el de usuario y password.

Nota:La manera más conveniente de usar una clave pública es con un agente de autenticación que se encargue de guardar en memora las claves privadas descifradas y de esta manera evitar tener que ingresar una y otra vez la frase de paso correspondiente.

Archivos involucrados del cliente

Archivo Descripción
/usr/bin/ssh cliente ssh
/usr/bin/ssh-keygen Generador de par de claves (una pública y otra privada). Con la opción -t se puede especificar el algoritmo
~/.ssh/known_hosts claves públicas de los hosts a los que ya accedimos alguna vez
~/.ssh/id_rsa (nombre predeterminado con algoritmo RSA)
~/.ssh/id_ecdsa nombre predeterminado con algoritmo ECDSA
~/.ssh/id_ed2551 nombre predeterminado con algoritmo ED25519

Archivos involucrados del servidor

Archivo Descripción
/usr/sbin/sshd servidor ssh
~/.ssh/authorized_keys Clave públicas de clientes autorizados

Formato de ~/.ssh/authorized_keys

El siguiente es un ejemplo de un archivo que contiene solamente dos claves pública:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCb96oGSIMquG5UGR6aFXtX6aHboMDS3Pkr8NOuLskabSnSzgUC8IGYvxn86W0xvcWGdVD+Qljl6h16ARFXGpCNWSxktl7TWMnbDn i5AZaJXETV1ZkB5ro5f33gEvaMcZel18X1FcE1RBEJG92ufOoIIastxYo+THU8TW0bwVG08/hHcPn+d9YYEwZ92b/sTQH3rtcvLrAtsSmI8flVc0M054Tmkhf15fXuVlPeYwqYhCWBT1JGg60Jn3ZrsQvD6di0KRBuw0icfeF1mdHnHSlrb7AhcNFs+kds1acWaE3cOINuKJmDHPmsyT6+wujnOx+3TCGVhGC8hm/8dizkALwks/1Zt5T1R8o/erOu8NFfzG3NvOB9dx9szbAHOxKiJ61FH6qOIUGj74xMNNGmCszz57g3JG8gfFe+zc7tlrvXgBIj1ZyY16JC6LkbYjUb5aXJQRLIPSe8XoAJU+UkxTjuXU7lCGnMPH0DjvvgLgpZYlWtL8zGqdu+ruMOE0S2N8= root@dublin.ireland.home

command="yum check-update" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCb96oGSIMquG5UGR6aFXtX6aHboMDS3Pkr8NOuLskabSnSzgUC8IGYvxn86W0xvcWGdVD+Qljl6h16ARFXGpCNWSxktl7TWMnbDnCi5AZaJXETV1ZkB5ro5f33gEvaMcZel18X1FcE1RBEJG92ufOoIIastxYo+THU8TW0bwVG08/hHcPn+d9YYEwZ92b/sTQH3rtcvLrAtsSmI8flVc0M054Tmkhf15fXuVlPeYwqYhCWBT1JGg60Jn3ZrsQvD6di0KRBuw0icfeF1mdHnHSlrb7AhcNFs+kds1acWaE3cOINuKJmDHPmsyT6+wujnOx+3TCGVhGC8hm/8dizkALwks/1Zt5T1R8o/erOu8NFfzG3NvOB9dx9szbAHOxKiJ61FH6qOIUGj74xMNNGmCszz57g3JG8gfFe+zc7tlrvXgBIj1ZyY16JC6LkbYjUb5aXJQRLIPSe8XoAJU+UkxTjuXU7lCGnMPH0DjvvgLgpZYlWtL8zGqdu+ruMOE0S2N8= root@belfast.ireland.home
  • ssh-rsa es el tipo de clave
  • AAAAB3NzaC1yc2EAAAADAQABAAAegQCb96oGSIMquG5UGR6aFXtX6aHboMDS3Pkr8NOuLskabSnSzgUC8IGYvxn86W0xvcWGdVD+Qljl6h16ARFXGpCNWSxktl7TWMnbDnCi5AZaJXETV1ZkB5ro5f33gEvaMcZel18X1FcE1RBEJG92ufOoIIastxYo+THU8TW0bwVG08/hHcPn+d9YYEwZ92b/sTQH3rtcvLrAtsSmI8flVc0M054Tmkhf15fXuVlPeYwqYhCWBT1JGg60Jn3ZrsQvD6di0KRBuw0icfeF1mdHnHSlrb7AhcNFs+kds1acWaE3cOINuKJmDHPmsyT6+wujnOx+3TCGVhGC8hm/8dizkALwks/1Zt5T1R8o/erOu8NFfzG3NvOB9dx9szbAHOxKiJ61FH6qOIUGj74xMNNGmCszz57g3JG8gfFe+zc7tlrvXgBIj1ZyY16JC6LkbYjUb5aXJQRLIPSe8XoAJU+UkxTjuXU7lCGnMPH0DjvvgLgpZYlWtL8zGqdu+ruMOE0S2N8= es la clave pública codificada en base64
  • root@dublin.ireland.home es un comentario opcional
  • command=yum check-update en la segunda línea restringe el acceso permitiendo la ejecución de un único comando.
  • El contenido de este archivo debería tener permisos 0600 y el directorio ~/.ssh 0700.

Fuentes y más recursos

Uso Institucional de Redes Sociales

Normas de uso y convivencia de Redes sociales y Web

Redes Sociales

unsplash-logo William Iven

Se permite el uso de Redes Sociales en la institución teniendo en cuenta estos aspectos:

  1. Existe un comité responsable de leer los términos y condiciones de cada servicio, informando sobre cada las novedades, y acerca de de beneficios, tanto para cada usuario como para la institución.
  2. La comunicación de este comité con la institución deberá ser permanente y estar abierta a las diferentes inquitudes de la comunidad.
  3. Existe además un comité técnico y pedagógico para asistir a los usuarios.
  4. Se entiende que cada persona tiene esferas privadas y públicas.
  5. Ninguna persona podrá ser obligada a compartir más allá de los estrictamente necesario para la comunidad. Por ejemplo, un alumno no podrá guardar bajo secreto los pormenores de un tratamiento médico.
  6. La compartición de imágenes y videos deberá ser consentida expresamente por los miembros de la comunidad involucradas.
  7. No se permitirá ninguna actividad que implique un trato deshumanizante.
  8. Si tenemos que decirle algo a otro miembro de la comunidad, tenemos que estar seguros de que podríamos hacerlo también personalmente.

¿Sabías qué?

Importante Saberlo

Photo by Markus Spiske

  • Vamos dejando rastros sobre lo que hacemos en la web, muchos sitios de internet están interconectados. Al hacer una operación sobre un sitio probablemente otros sitios de otras empresas y organizaciones registren esas actividades.
  • Nuestros datos son usados por terceros
  • Nuestros dispositivos hablan sobre nosotros, por ejemplo a qué hora encedemos un celular, qué enlaces hacemos clic, qué compramos, etc.
  • ¿Pueden crear un perfil sobre nuestros datos?
  • Sitios GMail y Twitter tienen un historial sobre tus accessos
  • Muchos servicios dicen ser gratuitos porque tus datos son el producto que tienen para ofrecer

Algunas recomendaciones

  • Apagar el GPS del dispositivo cuando no es estrictamente necesario.
  • Usar contraseñas fuertes. Una contraseña fuerte generalmente contiene al menos 8 caracteres, incluyendo letras (mayúsculas y minúsculas), números y otras caracteres.
  • Usar buscadores que no rastrean a los usuarios, por ejemplo DuckDuckGo.
  • Usar conexiones cifradas. La barra de direcciones debe indicarnos que la conexión es segura y que usa un certificado válido. De este modo los datos que vemos y/o ingresemos no podrán ser vistos por otras computadoras.
  • Usar navegadores libres. Esto implica que se puede acceder a la receta con la cual se hacen. Por ejemplo, Firefox es un navegador libre. Google Chrome es un navegador gratuito pero que no es libre.
  • Extensiones para navegadores. Hay varias extensiones que nos sirven para poder navegar con mayor privacidad, algunas de ellas son:

    • CanvasBlocker: Proporciona privacidad al navegador que estamos usando.
    • DuckDuckGo Privacy Essentials: Sirve para bloquear rastreadores y nos muestra el grado de privacidad que proporciona cada sitio visitado.
    • PrivacyBadger: Bloquea rastreadores.
    • Terms os Service; Didn't Read: Califica los términos y políticas de privacidad de los sitios con servicios, desde A (muy buenos) hasta E (muy malos)
    • TrackmeNot: Utiliza técnicas de ofuscación para evitar que construyan un perfil sobre nosotros.

unsplash-logo Glen Carrie

Enlaces de interés

El Open Source Bajo la Lupa

Hay un artículo1 escrito por Don Goodman-Wilson empleado de Github y miembro de Maintainerati. Ha sido sumamente inspirador por un lado y, ¿por qué no? pone en palabras cosas que uno viene elaborando hace rato.

unsplash-logo Tim Marshall

DGW lanza una ataque demoledor sobre la OSI (Iniciativa del Open Source) al afirmar que facilita la concentración en manos poderosos a expensas de la explotación de los desarrolladores y está muy lejos de propiciar la democratización que declama.

Se propone el autor del post reemplazar ideologías centradas en el código por gente-céntricas. En síntesis: si las elecciones que tomamos respetan a los seres humanos son correctas, de lo contrario no lo son. Y que la ideología del Open Source cosifica.

La crítica más contundente que hace sobre el código abierto es que explota trabajo no remunerado. Y ese modelo dice, es insostenible.

Cita algunos casos interesantes que contraponen esta supuesta neutralidad del software:

  • La licencia de JSON
  • La licencia de 996.ICU
  • La licencia hipocrática de Coraline Ada Emke

Algunos principios para iniciar algo nuevo

  • Los responsable de un proyecto de software merecen ser tratados como personas.
  • La tecnología existe para servir a las necesidades humanas.
  • Los valores del código abierto tienen que servir a la comunidad

El código fuente es un dogma al que no le interesan las personas.

Y se termina preguntando:

¿Cómo luce un modelo colaborativo centrado en las personas, de desarrollo de software abierto?

Quiero agregar como opinión personal que mi posición está muy alejada de "software libre" bueno, "open source" malo. No hay mucha distancia de lo que proponen los caprichos del stallmanismo. Según él, lo más importante es la libertad del software. El centro no son las personas. Pero bueno, eso da para otro post.

Cómo Hacer Túneles SSH

Una de las funcionalidades extraordinarias que posee openssh es la de encapsular el tráfico inseguro a puertos TCP. A continuación vemos algunos ejemplos útiles de cuándo y cómo utilizarlos.

Túneles

unsplash-logo Aaron Burden

Algunas suposiciones:

  • openssh-server.example.com: Es el host que posee el servicio ssh y el servicio sin cifrar
  • otrohost.example.com: Es un host que posee un servidor web sin TLS pero que carece de ssh.
  • 192.0.2.1/24: Es la dirección IP del cliente ssh.
  • filtrado.example.com: Es un host que tiene el puerto del servicio al que queremos acceder pero se encuentra filtrado para el exterior.
  • casa.example.com: Es un host remoto respecto a un servidor ssh accesible desde la red de filtrado.example.com. Este host está en un lugar en el cual podemos trabajar cómodamente 😊 por fuera de la infraestructura de filtrado.example.com.

Caso 1: Redireccionado remoto (Segurizar un servicio sin cifrar)

Queremos segurizar el acceso a un servidor web sin TLS.

ssh -N -f -v -L 10001:localhost:80 openssh-server.example.com

  • 80: Es el puerto que tiene el servicio sin cifrar
  • localhost: Es la dirección en el host servicio-remoto.example.com que escucha en el puerto 80.
  • 10001: Es el puerto local al cual tendremos que conectarnos para obtener el servicio web.
  • -N No ejecuta comandos en el lado remoto.
  • -g Permite a otros hosts conectarse a nuestro puerto 10001.
  • -f El proceso va al segundo plazo antes de la ejecución de comandos.
  • -v Imprime información detallada.
  • El url que habrá que poner en el navegador es http://localhost:80.

Caso 2: Redireccionado remoto laxo (Segurizar un servicio sin cifrar)

Queremos permitir que otros hosts de la red puedan acceder nuestro servicio encapsulado.

ssh -g -N -f -v -L 10001:localhost:80 openssh-server.example.com

  • -g Permite acceder a otros hosts de la red 192.0.2.0/24 acceder a el url http://192.0.2.1:10001/

Caso 3: Redireccionado remoto (Segurizar un servicio sin cifrar en otro host)

Queremos acceder de manera segura a un servicio sin TLS ni ssh.

ssh -N -f -v -L 10001:otrohost.example.com:80 openssh-server.example.com

  • Aquí la url será http://otrohost.example.com/10001

Caso 4: Acceder puertos filtrados

Queremos acceder a un puerto filtrado

ssh -v -N -f -R 9000:localhost:22 casa.example.com

  • 22 es el puerto al que queremos conectarnos desde casa.example.com al puerto 9000

Caso 5: Acceder a puertos filtrados y permitir acceso a otros hosts de la red

Queremos permitir que otros hosts de la red local de casa.example.com puedan acceder al servicio encapsulado

ssh -v -N -f -R 0.0.0.0:9000:localhost:22 casa.example.com

  • Luego para acceder al puerto ssh de filtrado.example.com podremos hacer por afuera de la red:
ssh -p 9000 casa.example.com
  • En este caso debe estar habilitado GatewayPorts en el archivo sshd_config

Borrar configuraciones de red

En Linux a veces nos podemos meter en un embrollo. Los sistemas para configurar y administrar la red son varios:

  • net-tools

  • iproute2

  • Archivos "legacy"

  • NetworkManager

  • systemd-networkd, etc

Cuando colisionan y necesitamos blanquear la configuraciones podemos hacer lo siguiente:

for i in $(ip -4 -o link |  cut -f2 -d ":"  | grep -v '^lo$')
        do
           ip addr flush dev  "$i"
           ip route flush dev  "$i"
           ip rule flush dev  "$i"
        done

Listo, a hacer la configuración en limpio ahora!

Obviamente no deberíamos hacer esto con una conexión remota a un equipo no virtualizado :)

Edición de Wikipedia o Wikiversidad

  1. Sí, puedo afirmar que la comunidad wikipedista es receptiva a nuevos usuarios y aportes. Mi primer aporte es de 2005 y en general la experiencia ha sido positiva.

  2. Si un docente decide poner a sus estudiantes a editar creo que en general tendrá un efecto positivo. Desde luego existe el riesgo de colisiones o que ciertos artículos puedan quedar de manera inconsistente. O tal vez con opiniones personales, cuestiones muy secundarias o carencia de referencias.

  3. Las dificultades anteriores podrían resolverse leyendo esta página:

  4. Ayuda:Contenidos - Wikipedia, la enciclopedia libre

Por supuesto es mucha documentación para leer, pero creo que los más importantes son:

El artículo que edite para esta actividad es :

Vim - Wikipedia, la enciclopedia libre

Cómo hacer un producto

Uno de los conceptos más importante que trajo el movimiento Open Source es que el software1, 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:

El proceso para hacer un producto

Fase Descripción
Base Tiene la terminología, conceptos, herramientas fundamentales para que tenga sentido el trabajo
Formato Tiene que tener una coherencia y una legibilidad o usabilidad básica para que pueda ser aprovechada por otros
Valor Agregado Aquí es cuando le agregamos al trabajo ese talento especial que todos tenemos que hace distinto el producto. Al terminar esta fase el producto se considera entregable. Sea para ser presentado ante un jefe o vendido a un cliente
Corrección de Errores Una vez que hemos obtenido feedback del resto del mundo, podemos corregir errores
Optimización En este punto volvemos a los pasos Base, Formato, y Valor Agregado. ¿Hasta cuándo? ¿Hasta que sea perfecto? Bueno, eso no existe. La idea es iterar todas las veces que el sentido y la alegría estén presentes

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.

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

Sistemas de construcción de paquetes (Parte 4)

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

Las dos cosas más notables son la reducción del uso de autotools y por otro lado la aparición de sistemas alternativos de construcción (casi un 70%).

Sistema de construcción de paquetes (Parte 3)