• Perché queste FAQ
• Cosa è LFS
• Cosa è BLFS
• Come posso contribuire a queste FAQ

• E se io sono nuovo a Linux o LFS
• Dove è il miglior posto per avere aiuto
• Quale lista devo usare per quale argomento
• Cosa è la netiquette
• Dove posso trovare il libro LFS tradotto in italiano
• Vorrei aiutare a tradurre i libri LFS e BLFS. Come posso fare

• I comandi "ln -s" nel libro sono sbagliati
• /bin/foo è una copia di /bin/bar
• Posso usare una versione più nuova di quella nel libro
• C'è una nuova versione del pacchetto Foo
• Il tasto Delete non funziona
• Il sistema si spegne quando fsck dà errore!
• Come trovo un pacchetto o comando
• Come aggiorno il mio sistema LFS/BLFS

Le FAQ tentano di rispondere alle domande prima che vengano poste. Questo risparmia il disturbo di chiederle, e, talvolta, il disturbo di incontrare un problema.

Riduce il traffico e migliora il raporto segnale/rumore, ma è solo un effetto collaterale.

Poiché le FAQ non sono il posto naturale in cui cercare informazioni, gli argomenti devono essere aggiunti ad esse solo se non possono essere aggiunte alla documentazione appropriata. Talvolta sarà necessario aggiungere un richiamo alle informazioni nella documentazione.

LFS significa Linux From Scratch, ed è un progetto che ambisce a insegnare il funzionamento interno di Linux attraverso la costruzione di un sistema Linux, scaricando, costruendo ed installando da sè i pacchetti.

Si dia anche un'occhiata all'introduzione a LFS scritta da Gerard Beekmans, il leader e iniziatore del progetto.

LFS è un sistema molto essenziale, in forte contrasto con le tradizionali distribuzioni. La ragione è questa: LFS non è pensato per creare il proprio sistema come si vuole. E' pensato per essere giusto sufficiente a permettere di costruire il proprio sistema come lo si vuole. Non è una fine, è un inizio. Quando si è finito con LFS, si è appena iniziato a costruire il proprio sistema.

Questo può essere un problema se non si conoscono i sistemi Unix e si vuole una tipica installazione desktop con X e un browser web ma non si ha idea di quali pacchetti servono. Per questa ragione esiste Beyond Linux From Scratch, o BLFS.

I suggerimenti sono più che benvenuti. Il maintainer delle FAQ può essere raggiunto o direttamente via email o sulla FAQ mailing list.

Suggerimenti utili comprendono l'aggiunta di domande che attualmente sono poste frequentemente (con risposte ben architettate) e la rimozione di domande obsolete.

Se si vuole contribuire regolarmente a queste FAQ ci si può iscrivere alla FAQ mailing list. Ogni suggerimento, aggiunta (e talvolta rimozione) delle FAQ è discussa lì. Anche patch sulle FAQ sono benvenute, sebbene normali contributi testuali sono ugualmente accettati.

Ogni cosa pensata per essere messa nelle FAQ senza sostanziali modifiche deve essere ben pensata, verificata, e ricercata; e scritta in uno stile coerente con il contenuto esistente.

Se si sono lette le pagine Prerequisiti e Audience si sa che l'audience di LFS sono gli utenti intermedi e avanzati di Linux. Chiunque abbia un'esperienza di qualche mese con Linux e specialmente la console dovrebbe essere in grado di assemblare con successo il proprio sistema LFS.

LFS sembra una buona guida per chi è nuovo a Linux, ma la realtà oggi è un po' diversa. L'esperienca con i canali di supporto mostra che LFS è difficile da afferrare e una esperienza frustrante per i newbie, perché manca loro la comprensione dei concetti di base.

In pratica, questo significa che i newbie dovrebbero farsi un po' di esperienza prima di iniziare con LFS. La Pagina dei prerequisiti elenca le minime conoscenze di Linux necessarie, ma vi preghiamo anche di leggere l'hint "Essential pre-reading for life with LFS".

Questi documenti e queste FAQ sono la guida di base di sopravvivenza a Linux. Leggendoli si passerà bene il tempo con LFS, e si potrebbero avere difficoltà con LFS e la comunità, ma più probabilmente se stessi, se non li si legge.

Quando l'aiuto di queste FAQ non basta, ci sono molti posti in cui andare.

Se si ha un problema con qualcosa nel libro, non è male tornare a leggerlo. E' sorprendente quanto sia facile trascurare le piccole cose.

Se ancora non si ottiene nulla la lettura di pagine man e agine info permetterà di avere utili informazioni su alcuni argomenti, se non proprio ciò che si sta cercando, e garantisce se ne sappia abbastanza da non trovarsi a disagio se si deve chiedere a qualcuno.

The Linux Documentation Project ha gli HOW-TO e una grande quantità di altra documentazione. Qui si può trovare qualcosa.

La ricerca nel sito include le mailing list. Molte questioni sono state discusse lì almeno una volta.

Per avere supporto IRC è spesso meglio. E' più veloce, e non intasa le mailing list. Maggiori informazioni sui canali IRC si trovano sul sito.

Ci sono due canali IRC di interesse. #LFS, che è un canale comune, e #lfs-support, che è per domande di supporto. Se si pone una domanda di supporto, è più facile avere aiuto competente ed amichevole in #lfs-support.

Come ultima risorsa ci sono le mailing list. La gente si irriterà verso di voi se si usa quella sbagliata o si fa cross post. Informazioni sulle Mailing sono sul sito web e dicono quale lista utilizzare.

Ricordarsi di fornire abbastanza informazioni quando si posta sulle mailing list. Nel capitolo 1 di LFS si può trovare un buon metodo per postare. Inoltre, qualcuno ha scritto un hint che dettaglia la procedura per riportare gli errori.

La risposta completa è sulla pagina delle mailinglist, ma qui c'è un sommario:

• Inviare domande di supporto per i rilasci stabili dei libri a lfs-support. Per qualunque cosa non appartenga a LFS, usare blfs-support. Gli utenti che usano il ramo di test o il ramo unstable lo fanno a loro rischio; non abbiamo una lista di supporto per loro. Rapporti di errore sono tuttavia accettati volentieri; potete usare bugzilla o la rispettiva branch mailing list (lfs-dev per la testing, lfs-hackers per la unstable).
• Se non si hanno problemi nel seguire il libro LFS, non inviare email a lfs-support.
• A meno che non si suggerisca un miglioramento al libro LFS, non inviare email a lfs-dev.
• In blfs-dev si accettano solo suggerimenti sul libro BLFS.
• Le cose sono un po' diverse con il suporto blfs. Qualunque cosa che non si adatti ad una delle liste precedenti va qui, tranne il prezzo della birra e le flamewar GNU contro BSD.
• Flamewar su prezzo della birra, GNU contro BSD, e Microsoft contro Linux sono ristrette a lfs-chat. Attualmente devono andare lì anche discussioni sull'hardware.

In particolare se si cita XFree86, KDE, o GNOME si può essere certi che il proprio post non appartiene a lfs-dev o lfs-support.

Qui ci sono alcuni consigli pratici di etichetta. Essi includono solo quegli argomenti che verrebbero citati se trascurati. Coloro che frequentano da un po' le mailing list troveranno ovvii i primi. Ci sono punti meno ovvii verso la fine.

Le ragioni di questi punti sono omesse per brevità, ma assicuriamo che queste linee guida sono più che semplici preferenze personali.

Nonostante il testo faccia riferimento esclusivamente “alle liste”, non intende ignorare i news group che fanno da mirror alle mailing list.

Chiarito questo, ci sono alcuni argomenti sui comportamenti seguiti da materie più “meccaniche”:

Vi preghiamo di ricordare che è maleducato postare domande che hanno già una risposta in documentazione comunemente disponibile come i libri LFS e BLFS, questa FAQ, gli Hint di LFS, le pagine man appropriate, gli archivi della lista, e ricerche Google. Se si può dimostrare che ci si è sforzati di trovare la risposta, e non si è offesi da un riferimento alla documentazione, nessuna persona ragionevole obbietterà alla vostra domanda.

Molte delle fastidiose flamewar iniziano quando un newbie posta una domanda ovvia, viene quindi criticato (anche in modo gentile), e viene pubblicamente offeso. Siete pregati di evitare questa situazione. Limitarsi a indirizzare al punto esatto nella documentazione è sufficiente. Se si ritiene di dover criticare, si è pregati di farlo attraverso l'email privata, non sulle liste. Lo stesso si applica a qualunque cosa possa diventare animata.

Le liste hanno un seguito internazionale, così modi di dire di ogni tipo e idiomi sono facilmente fraintesi. (Ne è testimone la recente discussione sul “bootstrapping”.) Qualunque citazione di bestemmie, politica, guerra, o religione (anche nelle firme) potrebbe facilmente disturbare qualcuno da qualche parte nel mondo quindi vi preghiamo di avitare anche questi. Infine, è considerato educato postare in inglese, poiché molta gente nelle liste non conosce altre lingue.

Ora le materie più “meccaniche”.

• Non postare in HTML. Se si usa Yahoo, Hotmail, o Outlook e non si ha disattivato l'HTML, allora esso è attivo. Se si utilizza un altro mail client fare una verifica prima di postare. Se non si sa come disattivare l'HTML, guardare http://www.expita.com/nomime.html. Tutti i post contenenti tag HTML saranno mandati in /dev/null e non raggiungeranno mai la lista. Sfortunatamente il filtro HTML di Spamassassin è molto selettivo e bloccherà tutti i post con tag tipo HTML o XML. Si tenga presente questo quando si postano frammenti di XML a una lista. Un trucco comunemente usato è di rimpiazzare le parentesi angolari < > con parentesi quadre [].
• Confezionare testo a 72 colonne. Se non si vuole farlo a mano impostare il proprio mail client per farlo automaticamente all'invio.
• Replicare sotto il testo quotato. Outlook rende questo difficile. C'è un plugin per correggere Outlook, e uno per Outlook Express.
• Limitare le firme a quattro linee.
• Incorniciare il testo quotato, specialmente le firme. Ma non farlo in un modo che renda confusa la lettura della propria risposta senza consultare l'originale.
• Non si prema “rispondi” a meno che non si risponda a un post. Usare “nuovo”, o “componi”, o comunque lo chiami il proprio mail client, per fare una domanda o aprire un nuovo argomento. “Rispondi” coinvolge più della sola linea dell'oggetto e farà sì che il vostro post appaia nel luogo sbagliato, a meno che non si stia rispondendo.

Il seguente non è importante, ma è utile saperlo. Sulle liste LFS, la gente solitamente cancella il campo CC e invia mail alla lista solo con la risposta. Questa probabilmente non è una buona idea ma è una pratica comune dovuta a una situazione politica che difficilmente cambierà.

RFC 1855 “fornisce un insieme minimo di linee guida per la Network Etiquette (Netiquette) e funziona come un set minimo di linee guida per individui, sia utenti che amministratori.

Ovviamente in questo sito, o sul sito del PLUTO ildp

La traduzione in italiano di LFS è curata dal PLUTO. Esiste una mailing list di riferimento per tutti coloro che volessero aiutare nella traduzione dei libri e dei documenti correlati.

No, i comandi “ln -s” nel libro sono corretti. Un link simbolico non è altro che un file speciale contenente il nome file dato. Così questo nome file è relativo al link, non alla directory di lavoro quando il link viene creato. Provare e vedere. Altre informazioni in man ln.

Provare ”ls -i /bin/foo /bin/bar“. I numeri di inode Sono gli stessi? Se sì, non sono copie, sono link fisici.

Per maggiori informazioni e spiegazioni sulle differenze tra hard e soft link, si dia un'occhiata all'articolo Q & A sulla Linux Gazette presso http://www.telenovela-world.com/~spade/linux/lg/105/pitcher.html.

Se questa è la prima volta che si costruisce LFS, utilizzare una versione non nel libro o variare rispetto al libro in qualunque modo non è una buona idea. Il canale IRC ha sempre un detto, “FBBG”. Come bugz, il bot residente, è rapido a dire, significa, “Follow Book, Book Good”. Loro e la gente residente nelle liste hanno aiutato molti newbie infelici che avevano deviato rispetto al libro durante questa prima costruzione.

Una volta costruito il sistema “dal libro”, si ha una conoscenza di base stabile da cui sperimentare le cose che danno più gioia (o dolore, come è spesso il caso.)

Se la nuova versione è vecchia di oltre un giorno, è facile che qualcuno abbia testato la release e l'abbia segnalato nelle mailing list. Vi preghiamo di cercare negli archivi prima di porre domande su come e se funziona.

Se si vorrebbe fare un rapporto sulla nuova release, seguire questi passi per evitare di fare un rapporto duplicato.

• Verificare la pagina freshmeat del progetto per vedere se è stato aggiornato. Se non lo è, segnalare lì la release.
• Se freshmeat è stato aggiornato, verificare LFS bugzilla (o BLFS bugzilla) per vedere se la release è stata postata lì.
• Se la release non è in bugzilla, segnlarlo al libro lfs (o al libro blfs per pacchetti in BLFS). Se si vuole, testarlo e segnalare anche qualunque problema o cambiamento nelle istruzioni di compilazione.

Siete pregati di leggere la pagina inputrc di BLFS.

I sistemi Unix normalmente eseguono sulogin se l'fsck normale all'avvio ha errori, così root può accedere e correggerli. Poiché sulogin accetterà qualunque password se /etc/passwd è corrotto, gli svilupatori di LFS hanno deciso che questo è un rischio sicurezza. Perciò gli script di avvio di LFS spengono la macchina in caso di errori fsck, e deve essere avviata con il parametro del kernel “init=/bin/bash” per avere una root shell. Se questo sia saggio o meno è oltre lo scopo delle FAQ, ma se per voi non va bene si può cambiare questo script di avvio prima che sia troppo tardi.

Fare riferimento alla pagina web di download dei pacchetti LFS.

Probabilmente questo lo si sa già, ma LFS non è una distribuzione nel senso tradizionale. Il suo scopo primario è: insegnare alla gente come funziona internamente un sistema Linux.

Mentre questo significa che si ha un grande controllo sul proprio sistema (“Your distro. Your rules.”), ha anche lo svantaggio che ci si deve preoccupare da sè di aggiornarlo.

Se si è costruito un sistema LFS e lo si è esteso per renderlo il proprio sistema primario, la cosa migliore da fare è di decidere una politica di aggiornamento. Si vuole mantenere l'ultima versione di ogni pacchetto? E' importante essere cauti, perché si rischia di scottarsi. Raccomandiamo di essere conservativi quando si aggiorna per mantenere un sistema sano. Una regola generale che funziona per molta gente è: aggiornare i pacchetti solo se hanno correzioni di sicurezza. Sottoscrivete lfs-security e LWN per tenersi informati sulle correzioni delle vulnerabilità. Un'altra regola è: non aggiornare la toolchain (gcc, glibc e binutils) a meno che non si stia per ricostruire l'intero sistema. Questi pacchetti formano il cuore del proprio sistema LFS, distruggerli significa distruggere l'abilità di compilare pacchetti o anche solo avviare binari.

Ricordare che l'aggiornamento dei pacchetti è a proprio rischio. LFS è molto attenta a presentare un mix stabile di pacchetti che siano compatibili in ogni modo a BLFS, così che si possa compilare OpenOffice.Org e Java (che sono dei veri dinosauri da compilare). Questo significa che il sistema LFS potrebbe diventare leggermente datato ma assicura compatibilità e stabilità. Si può confrontare questo con le release stable e testing di Debian, sebbene la LFS stable sia generalmente all'avanguardia in confronto ad altre distribuzioni.

In generale l'aggiornamento di singoli pacchetti è sicuro; essi si limitano a sovrascrivere i vecchi contenuti. I package manager si preoccupano di disinstallare le vecchie versioni, e conviene davvero avere installato qualche tipo di sistema di package management. Si dia un'occhiata agli hint; ce ne sono molti, spaziando da RPM a DEB a TGZ (Slackware) a Checkinstall.

Un ultimo commento: quali istruzioni si devono usare quando si aggiorna un pacchetto? In generale si possono usare le istruzioni standard LFS, sebbene non si debba presumere ciecamente che si applichino a tutti i pacchetti. Per tenersi informati su aggiornamenti e nuove istruzioni dei pacchetti iscriversi a lfs-dev, e, se si è veramente all'avanguardia, lfs-hackers. Si tenga presente che queste non sono liste di supporto, ma liste di sviluppo.