4

1. Acerca de este manual

5

El objetivo principal de este manual es servir como único punto de acceso a toda la documentación referente al Live Systems Project y en particular al sofware que el proyecto crea para Debian 9.0 "stretch". Se puede encontrar siempre una versión actualizada en ‹http://debian-live.alioth.debian.org/›

6

live-manual está principalmente enfocado a ayudar en la creación de un sistema en vivo y no está dirigido al usuario final de estos sistemas. Un usuario final puede encontrar información útil en las siguentes secciones: Conceptos básicos que cubre la descarga de imágenes prefabricadas y la preparación de imágenes para arrancar un sistema desde un medio de almacenamiento o desde una red local, ya sea utilizando el constructor web o ejecutando live-build directamente en el sistema. Personalización del comportamiento en tiempo de ejecución que describe algunas de las opciones que pueden especificarse en el indicador de arranque, como pueden ser la selección de la distribución del teclado, las variantes locales o la persistencia.

7

Algunos de los comandos mencionados en el texto deben ser ejecutados con privilegios de superusuario, que pueden ser obtenidos accediendo a la cuenta de root mediante la orden su o mediante la orden sudo. Para distinguir las ordenes que deben ser ejecutadas como usuario no privilegiado de las que si requieren privilegios de superusuario se ha prefijado con $ las primeras y con # las segundas. Estos símbolos no son parte de la orden.

8

1.1 Para el impaciente.

9

Aunque se cree que todo lo descrito en este manual es importante para la mayoría de los usuarios, es cierto que hay mucho material a interiorizar y que los usuarios desean experimentar con las herramientas de forma rápida y satisfactoria antes de entrar en detalles. Por lo tanto, se sugiere leer siguiendo el siguiente orden.

10

Primero, leer el capítulo Acerca de este manual, desde el principio y terminando en la sección Términos. Después, saltar hasta los tres tutoriales que están al principio de la sección Ejemplos pensados para aprender a configurar y construir imágenes de forma básica. Se deberá leer primero Uso de los ejemplos, seguido de Tutorial 1: Una imagen predeterminada y Tutorial 2: Una utilidad de navegador web, para finalizar con Tutorial 3: Una imagen personalizada. Al final de estos tutoriales, el lector tendrá una visión de lo que se puede hacer con los sistemas en vivo.

11

Se anima a profundizar en el estudio del manual con la lectura detenida del siguiente capítulo: Conceptos básicos, y de una manera más somera el capítulo La creación de una imagen netboot, para acabar con la lectura de Descripción general de la personalización y los capítulos que le siguen. Se espera que, en este punto, el lector esté lo suficientemente motivado con lo que se puede hacer con los sistemas en vivo para leer el resto del manual, de principio a fin.

12

1.2 Términos

13

• Sistema en vivo: Se entiende por sistema en vivo aquel sistema operativo que se puede arrancar sin instalación previa en el disco duro. Un sistema en vivo no altera ningún sistema operativo previamente instalado ni ningún fichero existente en el disco duro de la máquina a menos que se le instruya para hacerlo. Los sistemas en vivo son arrancados típicamente desde medios extraíbles como CDs, DVDs o llaves USB. Algunos pueden también arrancar desde la red local (utilizando imágenes tipo netboot, ver Creación de una imagen de arranque en red), o incluso desde internet utilizando el parámetro de arranque fetch=URL, ver Arrancar desde internet).

14

• Medio en vivo: A diferencia de sistema en vivo, el medio en vivo se refiere al CD, DVD o memoria USB donde se copia el fichero binario producido por live-build y utilizado para arrancar el sistema en vivo. Más ampliamente, el término también se refiere a cualquier lugar en el que reside el fichero binario a los efectos de iniciar el sistema en vivo, tales como la ubicación de los ficheros de arranque de red.

15

• Live Systems Project: Es un proyecto que mantiene, entre otros, los paquetes live-boot, live-build, live-config, live-tools y live-manual.

16

• Sistema huésped: Es el conjunto de herramientas y equipo utilizado para crear el sistema en vivo.

17

• Sistema objetivo: Es el conjunto de herramientas y equipo donde se ejecutará el sistema en vivo.

18

• live-boot: Es una colección de scripts que serán responsables de arrancar el sistema en vivo.

19

• live-build: Una colección de scripts utilizados para construir sistemas en vivo personalizados.

20

• live-config: Es una colección de scripts utilizados para configurar un sistema en vivo durante el proceso de arranque.

21

• live-tools: Una colección de scripts adicionales que se utilizan para realizar tareas útiles en un sistema en vivo en ejecución.

22

• live-manual: Este documento forma parte de un paquete llamado live-manual.

23

• Instalador de Debian (Debian Installer o d-i): Es el mecanismo oficial de instalación para la distribución Debian.

24

• Parámetros de arranque: Parámetros que son entregados al gestor de arranque (bootloader) para modificar el comportamiento del kernel o del conjunto de scripts live-config. Son llamados también Parámetros de kernel u Opciones de arranque.

25

• chroot: El programa chroot, chroot(8), permite ejecutar diferentes instancias de un entorno GNU/Linux en un solo sistema de manera simultánea sin necesidad de reiniciar el sistema.

26

• Imagen binaria: Es un fichero que contiene el sistema en vivo. Su nombre puede ser, por ejemplo, live-image-i386.hybrid.iso o live-image-i386.img dependiendo de su formato.

27

• Distribución objetivo: Es la versión de la distribución Debian en la cual estará basado el sistema en vivo que puede diferir de la versión de la distribución en el sistema huésped.

28

• stable/testing/unstable: La distribución stable, actualmente llamada stretch, contiene la última distribución Debian publicada oficialmente. La distribución testing, temporalmente llamada buster, está en la rampa de salida para ser la próxima distribución stable. La principal ventaja de utilizar esta distribución es que tiene versiones de programas más recientes si se compara con la versión stable. La distribución unstable, permanentemente llamada sid, es dónde se realiza el desarrollo de Debian. Generalmente esta distribución es usada por los desarrolladores y aquellos que les gusta vivir al filo de lo imposible. A lo largo del manual, se usan sus nombres en clave, como por ejemplo buster o sid, ya que es lo que las mismas herramientas reconocen.

29

1.3 Autores

30

Lista de autores (en orden alfabético):

31

• Ben Armstrong

32

• Brendan Sleight

33

• Carlos Zuferri

34

• Chris Lamb

35

• Daniel Baumann

36

• Franklin Piat

37

• Jonas Stein

38

• Kai Hendry

39

• Marco Amadori

40

• Mathieu Geli

41

• Matthias Kirschner

42

• Richard Nelson

43

• Trent W. Buck

44

1.4 Cómo contribuir a este documento

45

Este manual se ha creado como un proyecto comunitario y cualquier propuesta para su mejora u otras contribuciones son siempre bienvenidas. Ver la sección Contribuir al proyecto para obtener información detallada sobre cómo obtener la clave pública y hacer buenos commits.

46

1.4.1 Aplicar cambios

47

Para realizar cambios en el manual en Inglés se debe editar los ficheros adecuados en manual/en/ pero antes de enviar una contribución se debería realizar una visualización del trabajo realizado. Para ello asegurarse de tener instalados los paquetes necesarios para la construcción de live-manual ejecutando la siguiente orden:

48

# apt-get install make po4a ruby ruby-nokogiri sisu-complete

49

Se puede realizar la construcción del manual posicionándose en el directorio de nivel superior, o sea, en el directorio clonado mediante Git y ejecutando la siguiente orden:

50

$ make build

51

Ya que construir el manual completo en todos los idiomas disponibles cuesta bastante rato, los autores seguramente estaran interesados en utilizar alguno de los siguientes atajos a la hora de revisar la documentación que hayan añadido al manual en inglés. Utilizando PROOF=1 se crea live-manual en formato html, pero sin los documentos html segmentados, y utilizando PROOF=2 se crea live-manual en formato pdf pero sólo en retrato A4 y carta. Por este motivo, utilizar cualquiera de las opciones PROOF= puede llegar a ahorrar una cantidad de tiempo considerable, por ejemplo.

52

$ make build PROOF=1

53

Cuando se revisa alguna de las traducciones, es posible construir sólo un idioma ejecutando, por ejemplo:

54

$ make build LANGUAGES=de

55

Es posible generar el documento por formato:

56

$ make build FORMATS=pdf

57

O combinar ambos, por ejemplo:

58

$ make build LANGUAGES=de FORMATS=html

59

Después de revisar el trabajo y asegurarse de que todo está bien, no ejecutar make commit a menos de que se actualicen las traducciones al mismo tiempo, y en ese caso, no mezclar los cambios al manual en inglés con las traducciones en el mismo commit, sino en commits separados. Ver la sección Traducción para más detalles.

60

1.4.2 Traducción

61

Nota: Para la traducción de las páginas de manual, ver Traducción de las páginas de manual

62

Para traducir live-manual, seguir estos pasos, dependiendo de si se está comenzando una traducción desde cero o si se continua trabajando en una traducción ya comenzada:

63

• Empezar una nueva traducción desde cero

64

• Traducir los ficheros about_manual.ssi.pot, about_project.ssi.pot y index.html.in.pot de manual/pot/ al idioma deseado con cualquier editor (como puede ser poedit) . Enviar los ficheros .po traducidos a la lista de correo para revisar su integridad. La comprobación de integridad de live-manual no sólo se asegura de que los ficheros .po estén 100% traducidos sino que también detecta posibles errores.

65

• Una vez comprobados, para activar una nueva lengua en el autobuild basta con añadir los ficheros traducidos inicialmente a manual/po/${LANGUAGE}/ y ejecutar make commit. Y entonces, editar manual/_sisu/home/index.html añadiendo el nombre de la lengua y su nombre en inglés entre paréntesis.

66

• Continuar con una traducción ya comenzada

67

• Si el nuevo idioma ya ha sido añadido, se puede continuar la traducción de los ficheros .po restantes en manual/po/${LANGUAGE}/ de manera aleatoria utilizando el editor preferido (como por ejemplo poedit) .

68

• No se debe olvidar la ejecución del comando make commit para actualizar los manuales traducidos a partir de los ficheros .po. Entonces se puede revisar los cambios ejecutando make build antes de git add ., git commit -m "Translating..." y git push. Recordar que como make build puede tardar una cantidad considerable de tiempo, se pueden revisar las diferentes lenguas de forma individual como se explica en Aplicar cambios

69

Después de ejecutar make commit se podrá observar bastante texto en la pantalla. Básicamente son mensajes informativos sobre el estado del proceso y también algunas pistas sobre lo que se puede hacer para mejorar live-manual. A menos que se vea un error fatal, generalmente se puede proceder y enviar la contribución.

70

live-manual incluye dos utilidades que pueden ser de gran ayuda para los traductores a la hora de encontrar mensajes sin traducir y mensajes difusos. La primera es "make translate". Esta activa un script que muestra en detalle cuántos mensajes sin traducir hay en cada fichero .po. La segunda, "make fixfuzzy", sólo actúa sobre los mensajes difusos pero ayuda a encontrarlos y corregirlos uno por uno.

71

Hay que tener en cuenta que aunque estas utilidades pueden ser de gran ayuda para traducir en la linea de comandos, se recomienda el uso de una herramienta especializada como por ejemplo poedit. Además, es una buena idea leer la documentación de debian sobre localizacion (l10n) y, especificamente para live-manual, las Directrices para los traductores.

72

Nota: Se puede utilizar make clean para limpiar el árbol git antes de enviar los cambios. Este paso no es obligatorio, gracias al fichero .gitignore, pero es una buena práctica para evitar enviar ficheros involuntariamente.