Raspberry Pi® a fondo para desarrolladores. Derek Molloy

Чтение книги онлайн.

СКАЧАТЬ terminar el proceso, use el comando kill:

      pi@erpi ~ $ kill 30965

      [1]+ Terminated ./helloRPiSleep

      Podemos confirmar la terminación del proceso usando ps de nuevo. Si el proceso no termina de inmediato, usaremos el argumento -9 para asegurarnos de que lo haga. Por ejemplo: kill -9 30965. Un comando diferente, pkill, termina un proceso a partir de su nombre. Así, en este caso:

      pi@erpi ~ $ pkill helloRPiSleep

      Otro comando que merece la pena mencionar es watch. Este ejecuta un comando a intervalos regulares y muestra el resultado en terminal a pantalla completa. Por ejemplo, para ver el log de mensajes del núcleo, escribimos:

      pi@erpi ~ $ watch dmesg

      Podemos concretar la duración del intervalo entre ejecuciones mediante -n seguido del número de segundos. Una buena manera de comprender el funcionamiento de watch consiste en ejecutarlo del siguiente modo:

      pi@erpi ~ $ watch -n 1 ps a

      Every 1.0s: ps a Sat Jun 20 20:22:39 2015

      PID TTY STAT TIME COMMAND

      912 pts/0 Ss 0:06 -bash

      31184 pts/0 S+ 0:01 watch -n 1 ps a

      31257 pts/0 S+ 0:00 watch -n 1 ps a

      31258 pts/0 S+ 0:00 sh -c ps a

      31259 pts/0 R+ 0:00 ps a

      Veremos que el PID de ps, sh y watch cambia cada (1) segundo, lo que deja claro que watch está realmente ejecutando el comando (ps) al pasarlo a un nuevo intérprete de comandos mediante sh -c. La razón por la que watch aparece dos veces en la lista es que se reproduce a sí mismo temporalmente en el momento exacto en el que ejecuta ps a.

Otros temas de Linux

      En este punto del libro, el lector ha podido revisar los principales comandos para trabajar con Linux en el RPi. Sin embargo, el tema de la gestión de sistemas Linux da mucho más de sí. Por ejemplo: ¿cómo configurar un adaptador WiFi? ¿Cómo usar cron para planificar (schedule) trabajos con el RPi? Estos temas se analizarán en los capítulos restantes del libro. Sin ir más lejos: la programación de trabajos con cron se trata en el capítulo 12, en el contexto de los dispositivos IoT.

Cómo utilizar Git para el control de versiones

      De manera sencilla podemos decir que Git es un sistema que nos permite registrar cualquier cambio que se introduzca en el contenido de un proyecto de software a medida que avanza su desarrollo. Git, diseñado también por Linus Torvalds, se emplea hoy en la línea principal de desarrollo del núcleo de Linux. Git es un sistema increíblemente útil, que debemos entender bien por dos motivos principales: podemos utilizar Git en el desarrollo de nuestro propio software y además nos permite aprender a trabajar con distribuciones de código fuente del núcleo de Linux.

      Git es un sistema distribuido de control de versiones, o DVCS (Distributed Version Contol System) que facilita el control del código fuente de un proyecto. Un sistema de control de versiones, VCS, registra y gestiona cualquier cambio introducido en documentos de cualquier tipo. Normalmente, los documentos que cambiemos se destacarán con números de revisión y marcas de tiempo. Se pueden comparar revisiones y hasta regresar a versiones antiguas de los documentos. Hay dos tipos de sistemas VCS:

      ❏Centralizados (CVCS): estos sistemas, como Apache Subversion (SVN), funcionan con la premisa de que existe una copia "maestra" única del proyecto. El flujo de trabajo es simple y directo: bajamos los cambios desde un servidor central, introducimos los nuestros propios y los volvemos a subir como definitivos a la copia maestra (esta subida definitiva de los cambios se denomina "commit", término típico también de las bases de datos; en español su uso como sustantivo ("hacer commit") es abrumadoramente mayoritario en el entorno informático, y es el que usaremos aquí).

      ❏Distribuidos (DVCS): usando estos sistemas, por ejemplo Git y Selenic Mercurial, no bajamos cambios, sino que clonamos el repositorio completo, incluido todo el histórico de cambios. El clonado del repositorio produce una copia tan exacta como una copia maestra, que hasta puede llegar a actuar como tal si fuera preciso. Por fortuna, los estándares actuales hacen que los documentos de texto plano y los archivos de código fuente no ocupen mucho espacio en disco. Una precisión importante: el modelo DVCS no excluye el uso de un repositorio maestro central para todos los usuarios. Véase, por ejemplo, git.kernel.org.

      La ventaja principal de un DVCS frente a un CVCS es la posibilidad de hacer

      commit rápidamente y probar las modificaciones localmente, en nuestro propio sistema, sin tener que subirlas antes a ninguna copia maestra. Esto permite la flexibilidad de poder subir los cambios solo cuando alcancen un nivel apropiado de calidad. La única desventaja significativa es el espacio en disco que exige el almacenamiento de todo el proyecto con su histórico de cambios, que va creciendo con el paso del tiempo.

      Git es un DVCS centrado en el control y gestión de código fuente. Nos permite crear desarrollos paralelos que no afecten al original. Podemos regresar a una versión anterior de alguno de los archivos de código fuente, o bien a una de todo el proyecto. El proyecto, con sus archivos asociados e histórico de cambios, se denomina "repositorio" (repository). Esta capacidad resulta particularmente útil en proyectos de programación a gran escala, en los que es posible optar por una dirección para el desarrollo que, finalmente, acabe por resultar infructuosa. También es importante la facilidad para el desarrollo en paralelo cuando se tiene a varias personas trabajando en el mismo proyecto.

      Git está escrito en C y, aunque se creó para cubrir la necesidad de control de versiones en el desarrollo del núcleo de Linux, se utiliza ampliamente en otros proyectos de código abierto como Eclipse o Android.

      La manera más fácil de entender el manejo de Git es usarlo. Por tanto, hemos estructurado la sección siguiente en forma de guía paso a paso. Si todavía no lo tiene, Git se instala con facilidad mediante el comando sudo apt install git, así que no debería tener problemas para seguir los pasos directamente en el terminal. Este libro emplea GitHub como repositorio remoto de los ejemplos de código fuente. Salvo realizar commit de código fuente en el servidor, el lector podrá hacer todo lo expuesto en esta guía sin crear una cuenta en GitHub. No obstante, GitHub permite crear cuentas de repositorio públicas de forma gratuita, pero si queremos un repositorio privado, por ejemplo para desarrollos que deban salvaguardar derechos de propiedad intelectual, tendremos que pagar una cuota.

      NOTA Si el lector planea embarcarse en el desarrollo de un proyecto grande y prefiere que no esté públicamente disponible en www.github.com ni pagar cuota de suscripción alguna, es posible hospedar repositorios privados de pequeña escala en sitios como bitbucket.org y gitlab.com. Con un poco más de trabajo, hasta es posible configurar GitLab en nuestro propio servidor, ya que existe una versión de código abierto de la plataforma.

Una introducción práctica

      Para esta guía, hemos creado un repositorio llamado "test" en GitHub. En principio solo contiene un archivo, README.md, con una descripción breve del proyecto "test".

      Como podemos ver en la figura 3-4, casi todas las operaciones son locales. Git realiza una suma de verificación en cada archivo antes de almacenarlo. Suma que garantiza que Git detecte cualquier modificación realizada СКАЧАТЬ