Manual de Live Systems

Sobre aquest manual

1. Sobre aquest manual

1.1 Per als impacients
1.2 Termes
1.3 Autors
1.4 Contribuir a aquest document
1.4.1 Aplicar canvis
1.4.2 Traducció

2. Sobre el Live Systems Project

2.1 Motivació
2.1.1 Què passa amb els sistemes vius actuals
2.1.2 Per què crear el nostre pròpi sistema viu?
2.2 Filosofia
2.2.1 Només paquets Debian sense modificacions de la secció "main"
2.2.2 Paquets del sistema viu sense cap configuració
2.3 Contacte

Usuari

3. Instal·lació

3.1 Requisits
3.2 Instal·lació de live-build
3.2.1 Des del repositori de Debian
3.2.2 A partir del codi font
3.2.3 A partir d'instantànies
3.3 Instal.lació de live-boot i live-config
3.3.1 Des del repositori de Debian
3.3.2 A partir del codi font
3.3.3 A partir d'instantànies

4. Conceptes bàsics

4.1 Què és un sistema viu?
4.2 Descàrrega d'imatges prefabricades
4.3 Ús del servei de construcció d'imatges en viu web
4.3.1 Ús i advertències sobre el servei web
4.4 Primers passos: construcció d'una imatge ISO híbrida
4.5 Usar una imatge ISO híbrida en viu
4.5.1 Gravar una imatge ISO en un medi físic
4.5.2 Còpiar una imatge ISO híbrida en un dispositiu USB
4.5.3 Utilitzar l'espai lliure en una memòria USB
4.5.4 Arrencar el medi en viu
4.6 Utilitzar una màquina virtual per a fer proves
4.6.1 Provar una imatge ISO amb QEMU
4.6.2 Provar una imatge ISO amb VirtualBox
4.7 Construir i utilitzar una imatge HDD
4.8 Construir una imatge netboot
4.8.1 Servidor DHCP
4.8.2 Servidor TFTP
4.8.3 Servidor NFS
4.8.4 Com provar l'arrencada en xarxa
4.8.5 Qemu

5. Descripció general de les eines

5.1 El paquet live-build
5.1.1 The lb init command
5.1.2 L'ordre lb config
5.1.3 L'ordre lb build
5.1.4 L'ordre lb clean
5.2 El paquet live-boot
5.3 El paquet live-config

6. Gestió d'una configuració

6.1 Gestionar canvis en la configuració
6.1.1 Per què utilitzar scripts auto? Què fan?
6.1.2 Utilitzar scripts auto d'exemple
6.2 Clonar una configuració publicada via Git

7. Visió general de la personalització

7.1 Configuració durant la construcció vs. durant l'arrencada
7.2 Etapes de la construcció
7.3 Suplementar lb config amb fitxers
7.4 Tasques de personalització

8. Personalització de la instal·lació de paquets

8.1 Fonts dels paquets
8.1.1 Distribució, àrees d'arxiu i mode
8.1.2 Miralls de distribució
8.1.3 Miralls de distribució utilitzats en temps de construcció
8.1.4 Miralls de distribució utilitzats en temps d'execució
8.1.5 Repositoris addicionals
8.2 Selecció dels paquets a instal·lar
8.2.1 Llistes de paquets
8.2.2 Ús dels metapaquets
8.2.3 Llistes locals de paquets
8.2.4 Llistes locals de paquets per a l'etapa binary
8.2.5 Generar llistes de paquets
8.2.6 Ús de condicionals dins de les llistes de paquets
8.2.7 Eliminar paquets durant la instal·lació
8.2.8 Tasques d'escriptori i llenguatge
8.2.9 Tipus i versió del nucli
8.2.10 Nuclis personalitzats
8.3 Instal·lació de paquets modificats o de tercers
8.3.1 Fer servir packages.chroot per a instaŀar paquets personalitzats
8.3.2 Fer servir un repositori APT per a instal·lar paquets personalitzats
8.3.3 Paquets personalitzats i APT
8.4 Configurar APT en temps de construcció
8.4.1 Elegir apt o aptitude
8.4.2 L'ús d'un proxy amb APT
8.4.3 Afinar APT per a estalviar espai
8.4.4 Passar opcions per a apt o aptitude
8.4.5 APT pinning

9. Personalització dels continguts

9.1 Includes
9.1.1 Live/chroot local includes
9.1.2 Binary local includes
9.2 Scripts ganxo (Hooks)
9.2.1 Live/chroot local hooks
9.2.2 Scripts ganxo durant l'arrencada
9.2.3 Binary local hooks
9.3 Preconfiguració de les preguntes de Debconf

10. Personalització dels comportaments en temps d'execució

10.1 Personalitzar l'usuari en viu
10.2 Personalització de l'entorn local i el llenguatge
10.3 Persistència
10.3.1 El fitxer persistence.conf
10.3.2 Utilitzar diversos medis persistents

11. Personalització de la imatge binària

11.1 Carregadors d'arrencada
11.2 metadades ISO

12. Personalització de l'instal·lador de debian

12.1 Tipus d'instal·lador de Debian
12.2 Personalització de l'instal·lador de Debian amb preconfiguració
12.3 Personalitzar el contingut de l'instal·lador de Debian

Projecte

13. Contribuir al projecte

13.1 Fer canvis

14. Informar dels errors

14.1 Problemes coneguts
14.2 Reconstruir des de zero
14.3 Fer servir paquets actualitzats
14.4 Recopilar informació
14.5 Aïllar el cas que falla, si és possible
14.6 Utilitzar el paquet correcte per a informar de l'error
14.6.1 A l'hora de construir mentre bootstrapping
14.6.2 A l'hora de construir, durant la instal·lació de paquets
14.6.3 En el moment d'arrencar
14.6.4 En temps d'execució
14.7 Fer la recerca
14.8 On informar dels errors

15. Estil de Codi

15.1 Compatibilitat
15.2 Indentació
15.3 Ajust de línia
15.4 Variables
15.5 Miscel·lània

16. Procediments

16.1 Publicacions majors
16.2 Publicacions puntuals
16.2.1 Ùltima publicació puntual d'una versió de Debian
16.2.2 Plantilla per a anunciar una publicació puntual

17. Repositoris Git

17.1 Gestió de múltiples repositoris

Exemples

18. Exemples

18.1 Ús dels exemples
18.2 Tutorial 1: Una imatge per defecte
18.3 Tutorial 2: Una utilitat de navegador web
18.4 Tutorial 3: Una imatge personalitzada
18.4.1 Primera revisió
18.4.2 Segona revisió
18.5 Un client per a un quiosc VNC
18.6 Una imatge bàsica per a un dispositiu USB de 128MB
18.7 Un escriptori GNOME localitzat i amb instal·lador

Apèndix

19. Guia d'estil

19.1 Instruccions per als autors
19.1.1 Característiques lingüístiques
19.1.2 Procediments
19.2 Directrius per als traductors
19.2.1 Consells de traducció

Metadata

Manual de Live Systems

Apèndix

19. Guia d'estil

19.1 Instruccions per als autors

Aquesta secció s'ocupa d'algunes consideracions generals a tenir en compte al escriure documentació tècnica per a live-manual. Es divideixen en aspectes lingüístics i procediments recomanats.

Nota: Els autors han de llegir primer Contribuir a aquest document

19.1.1 Característiques lingüístiques

Tenir en compte que un alt percentatge dels lectors no són parlants nadius d'anglès. Així que, com a regla general, intentar utilitzar frases curtes i significatives, seguides d'un punt i apart.

Això no vol dir que s'hagi d'utilitzar un estil simplista i ingenu. És un suggeriment per intentar evitar, en la mesura del possible, les oracions subordinades complexes que fan que el text sigui difícil d'entendre per als parlants no nadius d'anglès.

Les varietats d'anglès més esteses són el britànic i l'americà, així que és molt probable que la majoria dels autors acabin utilitzant l'una o l'altra. En un entorn de col·laboració, la varietat ideal seria "l'anglès internacional", però és molt difícil, per no dir impossible, decidir quina varietat d'entre totes les existents, és la millor.

Esperem que les diferents varietats es puguin barrejar sense crear malentesos, però en termes generals s'ha d'intentar ser coherent i abans de decidir sobre l'ús de l'anglès britànic, l'anglès americà o qualsevol altra varietat, fer una ullada a com escriuen altres persones i tractar d'imitar l'estil.

S'ha de ser imparcial. Evitar incloure referències a ideologies totalment alienes a live-manual. L'escriptura tècnica ha de ser el més neutral possible. Està en la naturalesa mateixa de l'escriptura científica.

Evitar el llenguatge sexista tant com sigui possible. Si es necessita fer referència a la tercera persona del singular utilitzar preferiblement "they" en lloc de "he" or "she" o invents estranys com per exemple "s/he" o "s(he)".

Anar directament al gra i no fent voltes. Donar tota la informació necessària, però no afegir més informació de la necessària, és a dir, no explicar detalls innecessaris. Els lectors són intel·ligents. Es presumeix algun coneixement previ per la seva part.

Tenir en compte que qualsevol cosa que s'escrigui haurà de ser traduida a diverses llengües. Això implica que un nombre de persones hauran de fer un treball extra si s'agrega informació innecessària o redundant.

Com s'ha suggerit abans, és gairebé impossible estandarditzar un document escrit en col·laboració en un tot perfectament unificat. No obstant això, s'aprecia tot esforç per escriure d'una manera coherent amb la resta dels autors.

Utilitzar connectors del discurs perquè el text sigui coherent i sense ambigüitats. (Normalment s'anomenen connectors).

És preferible descriure l'assumpte en un o diversos paràgrafs en lloc d'utilitzar una sèrie de oracions en un típic estil de "changelog". Cal descriure-ho! Els Lectors ho agrairan.

Buscar el significat de les paraules en un diccionari o una enciclopèdia si no es sap com expressar certs conceptes en anglès. Però cal tenir en compte que un diccionari pot ser el millor amic o pot convertir-se en el pitjor enemic si no es sap com utilitzar-lo correctament.

L'anglès té el vocabulari més gran que existeix (amb més d'un milió de paraules). Moltes d'aquestes paraules són préstecs d'altres llengües. Al buscar el significat de les paraules en un diccionari bilingüe la tendència d'un parlant no nadiu d'anglès és triar la que sona més semblant en la seva llengua materna. Sovint, això es converteix en un discurs excessivament formal que no sona ben natural en anglès.

Com a regla general, si un concepte es pot expressar utilitzant diferents sinònims, és un bon consell triar la primera paraula proposada pel diccionari. En cas de dubte, és sovint correcte elegir les paraules d'origen germànic (Normalment paraules monosíl·labes). Tenir en compte que aquestes dues tècniques poden produir un discurs més aviat informal, però almenys la elecció de paraules serà d'ampli ús i acceptació general.

L'ús d'un diccionari de frases fetes es recomanable. Són molt útils quan es tracta de saber quines paraules solen aparèixer juntes.

Com s'ha dit abans, és una bona pràctica aprendre del treball dels altres. L'ús d'un motor de recerca per comprovar com altres autors utilitzen certes expressions pot ajudar molt.

Compte amb els falsos amics. No importa com de competent un és en un idioma estranger, de tant en tant es pot caure en el parany dels anomenats "falsos amics", paraules que s'assemblen en dos idiomes però els significats o usos poden ser completament diferents.

Intentar evitar els modismes tant com sigui possible. Els "modismes " són expressions que tenen un significat completament diferent del que les seves paraules per separat semblen voler dir. De vegades, els modismes poden ser difícils d'entendre fins i tot per als parlants nadius d'anglès!

Tot i que s'anima a utilitzar un anglès senzill i planer, l'escriptura tècnica pertany al registre formal de la llengua.

Intentar evitar l'argot, les abreviatures inusuals que són difícils d'entendre i per sobre de tot, les contraccions que tracten d'imitar el llenguatge parlat. Per no parlar d'expressions familiars o típiques de l'irc.

19.1.2 Procediments

És important que els autors provin els seus exemples abans d'afegir-los a live-manual per assegurar-se que tot funciona com es descriu. Fer les proves en un entorn chroot net o en una màquina virtual pot ser un bon punt de partida. A més, seria ideal si les proves fossin dutes a terme en diferents ordinadors amb un maquinari diferent per detectar els possibles problemes que puguin sorgir.

Quan es posa un exemple mirar de ser el més específic possible. Un exemple és, després de tot, només un exemple.

Sovint és millor utilitzar una línia que només s'aplica a un cas concret que l'ús d'abstraccions que poden confondre als lectors. En aquest cas es pot donar una breu explicació dels efectes de l'exemple proposat.

Hi pot haver algunes excepcions quan l'exemple suggereixi l'ús d'algunes ordres potencialment perilloses que, si s'utilitzen incorrectament, poden provocar la pèrdua de dades o altres efectes indesitjables similars. En aquest cas, s'haurà de proporcionar una explicació detallada sobre els possibles efectes secundaris.

Els enllaços a llocs externs només s'han d'utilitzar quan la informació en aquests llocs és crucial per a comprendre un punt especial. Tot i això, intentar utilitzar els enllaços a llocs externs el menys possible. Els enllaços d'internet poden canviar de tant en tant, donant lloc a enllaços trencats i deixant els arguments en un estat incomplet.

A més, la gent que llegeix el manual sense connexió no podrà seguir els enllaços.

Intentar evitar les marques tant com sigui possible. Tenir en compte que altres projectes derivats poden fer ús de la documentació que escrivim. Així que estem complicant les coses per a ells si s'afegix determinat material específic.

live-manual es publica sota la llicència GNU GPL. Això té una sèrie d'implicacions que s'apliquen a la distribució dels materials (de qualsevol tipus, incloent-hi gràfics o logotips amb drets d'autor) que es publica amb ell.

- Pluja d'idees!. Es necessari organitzar les idees primer en una seqüència lògica d'esdeveniments.

- Quan d'alguna manera ja s'han organitzat aquestes idees en la ment, escriure un primer esborrany.

- Revisar la gramàtica, la sintaxi i l'ortografia. Tenir en compte que els noms propis de les versions, com ara jessie o sid, no s'han d'escriure en majúscula quan es refereixen als noms en clau.

- Millorar les frases i refer qualsevol part si és necessari.

Utilitzar el sistema de numeració convencional dels capítols i subtítols. Per exemple 1, 1.1, 1.1.1, 1.1.2 ... 1.2, 1.2.1, 1.2.2 ... 2, 2.1 ... i així successivament. Veure marcat a continuació.

Si s'ha d'enumerar una sèrie de passos o etapes en la descripció, també es poden utilitzar els nombres ordinals: primer, segon, tercer ... o en primer lloc, llavors, després, per fi ... Alternativament, es poden utilitzar punts.

I per últim però no menys important, live-manual utilitza SiSU per processar els fitxers de text i produir múltiples formats. Es recomana fer una ullada al manual de SiSU per a familiaritzar-se amb el seu marcat, o bé escriure:

$ sisu --help markup

Aquests són alguns exemples de marcat que poden ser útils:

- Per a l'èmfasi/negreta:

*{foo}* o !{foo}!

produeixen: foo o foo. S'usen per emfatitzar certes paraules clau.

- Per a la cursiva:

/{foo}/

produeix: foo. S'usa, per exemple, per als noms dels paquets Debian.

- Per a monospace:

#{foo}#

produeix: foo. S'usa per exemple, per als noms de les ordres. I també per ressaltar algunes paraules clau o coses com les rutes.

- Per a blocs de codi:

code{

  $ foo
  # bar

}code

produeix:

$ foo
# bar

S'utilitza code{ per a obrir i }code per a tancar els blocs. És important recordar deixar un espai al principi de cada línia de codi.

19.2 Directrius per als traductors

Aquesta secció s'ocupa d'algunes consideracions generals a tenir en compte a l'hora de traduir el contingut de live-manual.

Com a recomanació general, els traductors haurien d'haver llegit i entès les regles de traducció que s'apliquen als seus llenguatges específics. En general, els grups de traductors i les llistes de correu proporcionen informació sobre com produir traduccions que compleixin amb els estàndards de qualitat de Debian.

Nota: Els traductors també han de llegir Contribuir a aquest document. En particular, la secció Traducció

19.2.1 Consells de traducció

El paper del traductor és transmetre el més fidelment possible el significat de les paraules, oracions, paràgrafs i textos de com van ser escrits pels autors originals al seu idioma.

Per tant, aquests, s'han d'abstenir d'afegir comentaris personals o informacions addicionals pel seu compte. Si es vol afegir un comentari per als traductors que treballen en els mateixos documents, es poden deixar a l'espai reservat per a això. És a dir, la capçalera de les cadenes dels fitxers po precedits pel signe #. La majoria dels programes gràfics de traducció poden manejar aquest tipus de comentaris automàticament.

És perfectament acceptable però, incloure una paraula o una expressió entre parèntesi en el text traduït si, i només si, aixó fa que el significat d'una paraula o expressió difícil sigui més clara per al lector. Dins dels parèntesis, el traductor ha de posar de manifest que l'addició és seva utilitzant l'abreviatura "NT" o "Nota del traductor".

Els documents escrits en anglès fan un gran ús de la forma impersonal "you". En alguns altres idiomes que no comparteixen aquesta característica, això pot donar la falsa impressió que els textos originals s'adresen directament el lector quan en realitat n'ho fan. Els traductors han de ser conscients d'aquest fet i ho han de reflectir en el seu idioma amb la major precisió possible.

El perill dels "falsos amics" explicat anteriorment s'aplica especialment als traductors. Tornar a comprovar el significat dels falsos amics sospitosos en cas de dubte.

Els traductors que treballin inicialment amb els fitxers pot i posteriorment amb els fitxers po trobaràn moltes característiques de marcat en les cadenes. Es pot traduir el text, sempre que sigui traduïble, però és extremadament important que s'utilitzi exactament el mateix marcat que a la versió original en anglès.

Tot i que els blocs de codi són generalment intraduïbles, incloure'ls en la traducció és l'única manera de conseguir una traducció completa al 100%. I encara que això signifiqui més feina al principi, ja que pot requerir la intervenció dels traductors s'hi ha canvis en el codi, és la millor manera, a la llarga, per identificar el que s'ha traduït i el que no al comprovar la integritat dels fitxers .po.

Els texts traduïts han de tenir exactament els mateixos salts de línia que els texts originals. Aneu amb compte de pressionar la tecla "Enter" o escriure \n si apareix als fitxers originals. Aquests salts de línies apareixen sovint, per exemple, en els blocs de codi.

No confondre's, això no vol dir que el text traduït hagi de tenir la mateixa longitud que la versió en anglès. Aixó és gairebé impossible.

Els traductors no han de traduir mai:

- Els noms en clau de les versions (que han de ser escrits en minúscules)

- Els noms dels programes

- Les ordres que es posen com a exemples

- Les metadades (apareixen sovint entre dos punts :metadata:)

- Els enllaços

- Les rutes