Manuale di Debian Live

A proposito

1. A proposito di questo manuale

1.1 Per gli impazienti
1.2 Glossario
1.3 Autori
1.4 Contribuire a questo documento
1.4.1 Applicare le modifiche
1.4.2 Traduzione

2. A proposito del progetto Debian Live

2.1 Motivazioni
2.1.1 Cosa c'è di sbagliato con gli attuali sistemi live
2.1.2 Perché creare il proprio sistema live?
2.2 Filosofia
2.2.1 Solamente pacchetti da Debian "main", inalterati.
2.2.2 Nessun pacchetto di configurazione per il sistema live
2.3 Contatti

Utente

3. Installazione

3.1 Requisiti
3.2 Installare live-build
3.2.1 Dal repository Debian
3.2.2 Da sorgenti
3.2.3 Da "istantanee"
3.3 live-boot e live-config
3.3.1 Dal repository Debian
3.3.2 Da sorgenti
3.3.3 Da "istantanee"

4. Nozioni di base

4.1 Che cos'è un sistema live?
4.2 Primi passi: creare un'immagine ISO ibrida
4.3 Utilizzare un'immagine ISO live ibrida
4.3.1 Masterizzare un'immagine ISO su un supporto fisico
4.3.2 Copiare un'immagine ISO ibrida su una penna USB
4.3.3 Avviare il supporto live
4.4 Utilizzare una macchina virtuale per le prove
4.4.1 Provare un'immagine ISO con QEMU
4.4.2 Provare un'immagine ISO con virtualbox-ose
4.5 Creare un'immagine HDD
4.6 Utilizzare un'immagine HDD
4.6.1 Provare un'immagine HDD con Qemu
4.6.2 Usare lo spazio rimanente su una penna USB
4.7 Creare un'immagine netboot
4.7.1 Server DHCP
4.7.2 Server TFTP
4.7.3 Server NFS
4.7.4 Come provare una netboot
4.7.5 Qemu
4.7.6 VMWare Player

5. Panoramica degli strumenti

5.1 live-build
5.1.1 Il comando lb config
5.1.2 Il comando lb build
5.1.3 Il comando lb clean
5.2 Il pacchetto live-boot
5.3 Il pacchetto live-config

6. Gestire una configurazione

6.1 Utilizzare auto per gestire i cambiamenti di configurazione
6.2 Esempi di script automatici

7. Panoramica sulla personalizzazione

7.1 Configurazione in fase di compilazione e di avvio
7.2 Fasi della creazione
7.3 Integrare la configurazione di lb con dei file
7.4 Personalizzazione dei compiti

8. Personalizzare l'installazione dei pacchetti

8.1 Sorgenti dei pacchetti
8.1.1 Distribuzione, le aree di archivio e le modalità
8.1.2 Mirror delle distribuzioni
8.1.3 Mirror delle distribuzioni usati in fase di compilazione
8.1.4 Mirror delle distribuzioni usate durante l'esecuzione
8.1.5 Repository addizionali
8.2 Scegliere i pacchetti da installare
8.2.1 Elenchi di pacchetti
8.2.2 Elenchi predefiniti di pacchetti
8.2.3 Elenchi locali dei pacchetti
8.2.4 Elenchi locali di pacchetti binari
8.2.5 Estendere un'elenco di pacchetti usando gli include
8.2.6 Usare condizioni all'interno degli elenchi di pacchetti
8.2.7 Task
8.2.8 Task per desktop e lingua
8.3 Installare pacchetti modificati o di terze parti
8.3.1 Utilizzare packages.chroot per installare pacchetti personalizzati
8.3.2 Utilizzare un repository APT per installare pacchetti personalizzati
8.3.3 Pacchetti personalizzati e APT
8.4 Configurare APT in fase di costruzione
8.4.1 Scegliere apt o aptitude
8.4.2 Utilizzare un proxy con APT
8.4.3 Modificare APT per risparmiare spazio
8.4.4 Passare opzioni ad apt o aptitude
8.4.5 APT pinning

9. Personalizzazione dei contenuti

9.1 Include
9.1.1 Live/chroot include locali
9.1.2 Include locali binari
9.1.3 Include binari
9.2 Hook
9.2.1 Live/chroot hook locali
9.2.2 Hook in fase di avvio
9.2.3 Hook binari locali
9.3 Preconfigurare le domande di Debconf

10. Personalizzare i comportamenti durante l'esecuzione

10.1 Personalizzare l'utente live
10.2 Personalizzare la localizzazione e la lingua
10.3 Persistenza
10.3.1 Strati di persistenza completa
10.3.2 Strati personalizzati
10.3.3 Istantanee
10.3.4 Sottotesto persistente
10.3.5 Rimasterizzazione parziale

11. Personalizzare l'immagine binaria

11.1 Bootloader
11.2 Metadati ISO

12. Personalizzare l'Installatore Debian

12.1 Tipologie dell'Installatore Debian
12.2 Personalizzare il Debian Installer con la preconfigurazione
12.3 Personalizzare il contenuto dell'Installatore Debian

Progetto

13. Segnalare bug

13.1 Problemi noti
13.2 Ricostruire da zero
13.3 Usare pacchetti aggiornati
13.4 Raccogliere informazioni
13.5 Se possibile isolare il caso non andato a buon fine
13.6 Segnalare il bug del pacchetto giusto
13.6.1 Durante la compilazione mentre esegue il bootstrap
13.6.2 Durante la compilazione mentre installa i pacchetti
13.6.3 In fase di avvio
13.6.4 In fase di esecuzione
13.7 Fare la ricerca
13.8 Dove segnalare i bug

14. Lo stile nello scrivere codice

14.1 Compatibilità
14.2 Rientri
14.3 Ritorno a capo
14.4 Variabili
14.5 Varie

15. Procedure

15.1 Aggiornamenti degli udeb
15.2 Rilasci importanti
15.3 Rilasci minori
15.3.1 Last Point Release of a Debian Release
15.3.2 Modello per l'annuncio di un rilascio minore.

Esempi

16. Esempi

16.1 Usare gli esempi
16.2 Tutorial 1: un'immagine standard
16.3 Tutorial 2: servizio browser web
16.4 Tutorial 3: un'immagine personalizzata
16.4.1 Prima revisione
16.4.2 Seconda revisione
16.5 Un client Kiosk VNC
16.6 Un'immagine base per una chiavetta USB da 128M
16.7 Un desktop KDE localizzato e l'installer

Appendix

17. Style guide

17.1 Guidelines for authors
17.1.1 Linguistic features
17.1.2 Procedures
17.2 Guidelines for translators
17.2.1 Translation hints

Manuale di Debian Live

Appendix

17. Style guide

17.1 Guidelines for authors

This section deals with some general considerations to be taken into account when writing technical documentation for live-manual. They are divided into linguistic features and recommended procedures.

Note: Authors should first read Contributing to this document

17.1.1 Linguistic features

  • Use plain English
  • Keep in mind that a high percentage of your readers are not native speakers. So as a general rule try to use short, meaningful sentences, followed by a full stop.

    This does not mean that you have to use a simplistic, naive style. It is a suggestion to try to avoid, as much as possible, complex subordinate sentences that make the text difficult to understand for non-native speakers.

  • Variety of English
  • The most widely spread varieties of English are British and American so it is very likely that most authors will use either one or the other. In a collaborative environment, the ideal variety would be "International English" but it is very difficult, not to say impossible, to decide on which variety among all the existing ones, is the best to use.

    We expect that different varieties may mix without creating misunderstandings but in general terms you should try to be coherent and before deciding on using British, American or any other English flavour at your discretion, please take a look at how other people write and try to imitate them.

  • Be balanced
  • Do not be biased. Avoid including references to ideologies completely unrelated to live-manual. Technical writing should be as neutral as possible. It is in the very nature of scientific writing.

  • Be politically correct
  • Try to avoid sexist language as much as possible. If you need to make references to the third person singular preferably use "they" rather than "he" or "she" or awkward inventions such as "s/he", "s(he)" and the like.

  • Be concise
  • Go straight to the point and do not wander around aimlessly. Give as much information as necessary but do not give more information than necessary, this is to say, do not explain unnecessary details. Your readers are intelligent. Presume some previous knowledge on their part.

  • Minimize translation work
  • Keep in mind that whatever you write will have to be translated into several other languages. This implies that a number of people will have to do an extra work if you add useless or redundant information.

  • Be coherent
  • As suggested before, it is almost impossible to standardize a collaborative document into a perfectly unified whole. However, every effort on your side to write in a coherent way with the rest of the authors will be appreciated.

  • Be cohesive
  • Use as many text-forming devices as necessary to make your text cohesive and unambiguous. (Text-forming devices are linguistic markers such as connectors).

  • Be descriptive
  • It is preferable to describe the point in one or several paragraphs than merely using a number of sentences in a typical "changelog" style. Describe it! Your readers will appreciate it.

  • Dictionary
  • Look up the meaning of words in a dictionary or encyclopedia if you do not know how to express certain concepts in English. But keep in mind that a dictionary can either be your best friend or can turn into your worst enemy if you do not know how to use it correctly.

    English has the largest vocabulary that exists (With over one million words). Many of these words are borrowings from other languages. When looking up the meaning of words in a bilingual dictionary the tendency of a non-native speaker is to choose the one that sounds more similar in their mother tongue. This often turns into an excessively formal discourse which does not sound quite natural in English.

    As a general rule, if a concept can be expressed using different synonyms, it is a good advice to choose the first word proposed by the dictionary. If in doubt, choosing words of Germanic origin (Usually monosyllabic words) is often the right thing to do. Be warned that these two techniques might produce a rather informal discourse but at least your choice of words will be of wide use and generally accepted.

    Using a dictionary of collocations is recommended. They are extremely helpful when it comes to know which words usually occur together.

    Again it is a good practice to learn from the work of others. Using a search engine to check how other authors use certain expressions may help a lot.

  • False friends, idioms and other idiomatic expressions
  • Watch out for false friends. No matter how proficient you are in a foreign language you cannot help falling from time to time in the trap of the so called "false friends", words that look similar in two languages but whose meanings or uses might be completely different.

    Try to avoid idioms as much as possible. "Idioms" are expressions that may convey a completely different meaning from what their individual words seem to mean. Sometimes, idioms are difficult to understand even for native speakers!

  • Avoid slang, abbreviations, contractions...
  • Even though you are encouraged to use plain, everyday English, technical writing belongs to the formal register of the language.

    Try to avoid slang, unusual abbreviations that are difficult to understand and above all contractions that try to imitate the spoken language. Not to mention typical irc and family friendly expressions.

    17.1.2 Procedures

  • Test before write
  • It is important that authors test their examples before adding them to live-manual to ensure that everything works as described. Testing on a clean chroot or VM can be a good starting point. Besides, it would be ideal if the tests were then carried out on different machines with different hardware to spot possible problems that may arise.

  • Examples
  • When providing an example try to be as specific as you can. An example is, after all, just an example.

    It is often better to use a line that only applies to an specific case than using abstractions that may confuse your readers. In this case you can provide a brief explanation of the effects of the proposed example.

    There may be some exceptions when the example suggests using some potentially dangerous commands that, if misused, may cause data loss or other similar undesirable effects. In this case you should provide a thorough explanation of the possible side effects.

  • External links
  • Links to external sites should only be used when the information on those sites is crucial when it comes to understanding a special point. Even so, try to use links to external sites as sparsely as possible. Internet links are likely to change from time to time resulting in broken links and leaving your arguments in an incomplete state.

    Besides, people who read the manual offline will not have the chance to follow those links.

  • Avoid branding and things that violate the license under which the manual is published
  • Try to avoid branding as much as possible. Keep in mind that other downstream projects might make use of the documentation you write. So you are complicating things for them if you add certain specific material.

    live-manual is licensed under the GNU GPL. This has a number of implications that apply to the distribution of the material (of any kind, including copyrighted graphics or logos) that is published with it.

  • Write a first draft, revise, edit, improve, redo if necessary
  • - Brainstorm!. You need to organize your ideas first in a logical sequence of events.

    - Once you have somehow organized those ideas in your mind write a first draft.

    - Revise grammar, syntax and spelling.

    - Improve your statements and redo any part if necessary.

  • Chapters
  • Use the conventional numbering system for chapters and subtitles. e.g. 1, 1.1, 1.1.1, 1.1.2 ... 1.2, 1.2.1, 1.2.2 ... 2, 2.1 ... and so on. See markup below.

    If you have to enumerate a series of steps or stages in your description, you can also use ordinal numbers: First, second, third ... or First, Then, After that, Finally ... Alternatively you can use bulleted items.

  • Markup
  • And last but not least, live-manual uses SiSU to process the text files and produce a multiple format output. It is recommended to take a look at SiSU's manual to get familiar with its markup, or else type:

    $ sisu --help markup

    Here are some markup examples that may prove useful:

    - For emphasis/bold text:

    *{foo}* or !{foo}!

    produces: foo or foo. Use it to emphasize certain key words.

    - For italics:

    /{foo}/

    produces: foo. Use them e.g. for the names of debian packages.

    - For monospace:

    #{foo}#

    produces: foo. Use it e.g. for the names of commands. And also to highlight some key words or things like paths.

    - For code blocks:

    code{

      $ foo
      # bar

    }code

    produces:

    $ foo
    # bar

    Use code{ to open and }code to close the tags. It is important to remember to leave a space at the beginning of each line of code.

    17.2 Guidelines for translators

    This section deals with some general considerations to be taken into account when translating the contents of live-manual.

    As a general recommendation, translators should have read and understood the translation rules that apply to their specific languages. Usually, translation groups and mailing lists provide information on how to produce translated work that complies with Debian quality standards.

    Note: Translators should also read Contributing to this document. In particular the section Translation

    17.2.1 Translation hints

  • Comments
  • The role of the translator is to convey as faithfully as possible the meaning of words, sentences, paragraphs and texts as written by the original authors into their target language.

    So they should refrain from adding personal comments or extra bits of information of their own. If they want to add a comment for other translators working on the same documents, they can leave it in the space reserved for that. That is, the header of the strings in the po files preceded by a number sign #. Most graphical translation programs can automatically handle those types of comments.

  • TN, Translator's Note
  • It is perfectly acceptable however, to include a word or an expression in brackets in the translated text if, and only if, that makes the meaning of a difficult word or expression clearer to the reader. Inside the brackets the translator should make evident that the addition was theirs using the abbreviation "TN" or "Translator's Note".

  • Impersonal sentences
  • Documents written in English make an extensive use of the impersonal form "you". In some other languages that do not share this characteristic, this might give the false impression that the original texts are directly addressing the reader when they are actually not doing so. Translators must be aware of that fact and reflect it in their language as accurately as possible.

  • False friends
  • The trap of "false friends" explained before especially applies to translators. Double check the meaning of suspicious false friends if in doubt.

  • Markup
  • Translators working initially with pot files and later on with po files will find many markup features in the strings. They can translate the text anyway, as long as it is translatable, but it is extremely important that they use exactly the same markup as the original English version.

  • Code blocks
  • Some translators decide to include the code blocks in the translated files because it is easier for them to identify what has already been translated and what has not by looking at the percentages if they use a graphical translation program.

    Include the code blocks if you want to score a 100% complete translation.

    On the other hand some translators prefer to leave the code blocks "untranslated" (i.e. not including them). This makes the translation easier to maintain once finished because it does not require translators intervention if the code changes.

    Leave the code blocks empty (they will be automatically added then) if you want to make your translation easier to maintain.

  • Newlines
  • The translated texts need to have the exact same newlines as the original texts. Be careful to press the "Enter" key or type \n if they appear in the original files. These newlines often appear, for instance, in the code blocks.

    Make no mistake, this does not mean that the translated text needs to have the same length as the English version. That is nearly impossible.

  • Untranslatable strings
  • Translators should never translate:

    - The code names of releases

    - The names of programs

    - The commands given as examples

    - Metadata (often between colons :metadata:)

    - Links

    - Paths