A chiunque possa essere interessato. Se ne trovo copie piu' recenti le
mandero'.
E' stato stupido farsi condizionare da una esperienza negativa. Ho bisogno
di almeno un altro paio di esperienze negative per arrendermi ;^))
pompini
c1cc10
PS: questo e' il documento tecnico e le riflessioni sui metodi di
creazione di
minidistribuzioni dedicate.
----- Start of File buildSDK.sh ------
#!/bin/bash
cat << PROVA
DOCUMENTAZIONE BUILDSDK // WHITE PAPERS
This software is free software; you can redistribute it and/or
modify it under the terms of the GNU Public License as published
by the Free Software Foundation; either version 2 of the License,
or (at your option) any later version.
This software is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Please refer to the GNU Public License for more details.
You should have received a copy of the GNU Public License along with
this source code; if not, write to:
Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA
Going further with the boot process and using this CD-ROM, you
accept the terms defined here and in the GNU Public License.
BuildSDK is copyleft (C) 2003-2004 by c1cc10 aka Francesco Rana
the included code is copyright by the respective authors, please
refer to the distributed documentation for details.
TODO:
- please translate it in a understandable italian and in
a reasonable english!
- we miss also some confirmation of the theory exposed here
(lectures by some fucking guru or stuff, if needed...dunno)
By: original emails from bomboclat and others, posted to
hackers@???.
a lot of discussions with LO and ppl in reload (thx 2 bakunin).
Collected and revisited:
* by c1cc10 on the Mon Jun 7 17:45:12 GMT 2004
* revised by c1cc10 on the Sun Aug 1 01:40:39 CEST 2004
* revised by c1cc10 on the Sat Aug 21 04:07:51 CEST 2004
INTRO
-------------
- Chi: questo documento dovrebbe essere letto da chi e' interessato
alla progettazione e creazioni di sistemi operativi unix like e in
particolare riconoscibili nell'etichetta GNU/linux. Inoltre mi aspetto
che questo documento possa interessare chi vuole ragionare
di informatica nel prossimo futuro.
- Cosa: questo documento e' in primis una analisi della
attuale situazione delle distribuzioni GNU/linux e poi una
proposta di intervento pratico per il loro sviluppo. Il legame tra
le due parti sta nelle valutazioni tecniche necessarie alla progettazione
e alla costruzione di una distribuzione linux.
- Come: Partiremo da una breve introduzione sullo status quo e sulle
previsioni di sviluppo dei sistemi operativi GNU/linux.
Poi ci analizzeremo alcune componenti di un sistema
operativo GNU/linux e la loro incidenza nello sviluppo
di una distribuzione GNU/linux.
Infine valuteremo nella prassi la possibilita' di creare un meccanismo per
generare distribuzioni linux, sia live che installate/installabili.
1. Lo status quo
------------------------
1.1 Il percorso di autodifesa di GNU/linux ripropone problemi di
approccio al pc
Come sempre la situazione attuale e' figlia di un percorso evolutivo.
Se guardiamo alla storia del progetto GNU/linux e soprattutto
alle sue recenti evoluzioni, possiamo dire che GNU/linux ha dovuto
lottare per la propria sopravvivenza. Il progetto ha raggiunto la sua
piena consapevolezza a meta' degli anni 90, durante il periodo di
massimo fulgore dei
sistemi operativi proprietari e in particolare di Microsoft windows
(versione 3.11
prima e 95 poi). I risultati di credibilita' raccolti negli ultimi 12 anni
sono stati una vittoria di tappa, per cosi' dire, e sono
inconfutabili, ma non sono stati senza conseguenze. Le loro tracce
sono presenti nelle principali distribuzioni sul mercato e nelle risposte
che hanno dato alle esigenze in cui si sono riconosciute.
Al momento la situazione e' composta da un piccolo numero di distribuzioni
ben note e affermate, che per amore di sintesi chiameremo "distribuzioni
maggiori".
Esse sono la Debian, suse, mandrake, red hat, slackware. Caso a parte e'
l'ultima arrivata gentoo, le cui caratteristiche rispondono a una
problematica nuova, che
coinvolge in parte gli stessi argomenti di cui vogliamo discutere in
questo documento, ma
che vedremo meglio in seguito.
La caratteristica che accomuna queste distribuzioni sta nel loro intento
di soddisfazione
generale. Esse, cioe', si propongono un target generalista denominato
come "desktop" che accoglie le istanze di un uso domestico coniugato con
un ambito
produttivo da ufficio. Dal punto di vista tecnico la selezione di
programmi e funzionalita'
prevede il riconoscimento automatico dell'hardware, server di grafica
autoconfigurato,
un bouquet di applicativi a'-la'-office, alcuni giochi e programmi di
telecomunicazione
(chat irc, browser e gestione della e-mail, trasferimento dati in FTP, etc).
Le differenze che le contraddistinguono consistono nel grado di
confidenza con il sistema
GNU/linux dell'utenza prefissata e non nell'obiettivo di produzione che
detta utenza si pone.
Le personalizzazioni legate alle esigenze di produzione ed utilizzo sono
ovviamente previste,
ma vengono procrastinate all'acquisizione di competenze specifiche che
passano per il proprio
sistema di configurazione e aggiornamento. Questa filosofia e il
necessario scambio di
informazioni tra utenti di livelli diversi crea la comunita'.
1.2 Il 'cursus honorum' dell'utenza linux
Questo metodo d'uso di una distribuzione GNU/linux, ha il difetto di non
porre
l'attenzione sulla consapevolezza del mezzo digitale come strumento di
produzione di
cultura e di formazione. Infatti il ciclo di vita di un _utente tipo_
dovrebbe
essere:
*) INIZIO: presa di coscienza di un nuovo sistema operativo e delle
sue caratteristiche tecniche (interfaccia, interoperabilita'
con l'interfaccia).
*) PRIMA FASE INTERMEDIA: valutazione generale dello strumento applicato
al proprio ambito di produzione. Questa fase di solito comprende la
ricerca di applicazioni 'end user' e la loro installazione, con
eventuali
paragoni con applicazioni simili utilizzate o viste in precedenza.
Ovviamente
lo studio del meccanismo di gestione specifico (pacchettizzazione)
e' necessario a questa ricerca
e puo' andare di pari passo con essa, limitandola o rafforzandola a
seconda dei
casi.
*) PRIMA FASE AVANZATA: utilizzo di un sottoinsieme di applicazioni che
siano sopravvissute alle sperimentazioni/valutazioni della fase
precedente.
Configurazioni user space di livello crescente, prima introduzione al
sistema di feedback tra utente e produttore di software.
*) FASE AVANZATA: in base alla disponibilita' dell'utente
all'apprendimento e alle sue
capacita' questa fase puo' portare o a produrre del proprio
software, o a
specializzarsi in configurazioni avanzate di sistema (ricompilazione
di kernel e/o drivers e/o applicazioni end user) che comportino una
responsivita' migliore del sistema alle necessita' che si sono
individuate nel corso del proprio training. A volte in questa fase
l'interesse si fa generico e l'utente crea un percorso formativo
svincolato
da effettive necessita' produttive.
Questo tipo di percorso esclude una realta' di fatto: l'abitudine
all'utilizzo
del mezzo informatico ha creato immaginario e aspettative. Per questo
motivo molto
spesso chi utilizza il mezzo digitale ha gia' una attivita' che si
aspetta di integrare
e migliorare, oppure ha un immaginario rispetto ad una attivita' futura
che intende
praticare direttamente con l'informatica. Per queste persone un
approccio come quello
appena elencato non porta vantaggi e in piu' impedisce all'intera
comunita' di sostegno
dell'open source di avere una qualunque consapevolezza delle forze che
si muovono al suo
interno. Questo approccio, figlio della lotta per la sopravvivenza
del progetto GNU/linux, ha lasciato scoperto quella che e' oggi una
fondamentale
necessita' di chi lavora con un computer: il riconoscersi in alcuni
strumenti
di lavoro che, a prescindere da interfacce e nomi, abbiano delle
_funzionalita'_
rispondenti alle necessita' dell'utente. A questo proposito si puo' pensare
sia a necessita' d'uso sgorganti da approccio fisico (un non vedente
comprende
lo strumento informatico in maniera differente da un vedente) che da un
approccio
di scopo. Per esempio un avvocato e un dj possono usare lo stesso modello di
computer per scopi completamente differenti.
Questo problema e' figlio dei nostri tempi e non ha avuto modo di
proporsi su larga
scala precedentemente. Infatti e' qui e ora che ci sono progetti GNU o
genericamente
open source sufficientemente longevi da essere considerati affidabili e
avere un
buon numero di funzionalita' pari e superiori a prodotti affermatisi in
ambito commerciale.
Il problema puo' essere risolto soltanto con la loro introduzione nelle
distribuzioni
maggiori? Non credo. Soprattutto perche' la risposta e' piu' complessa
di una operazione
per insiemi e fare una distribuzione non e' soltanto accostare uno o
piu' gruppi
di applicativi, per quanto coerenti tra di loro e noti e necessari.
1.3 E quindi cosa fare? (pars construens)
La risposta sta nella creazione di sistemi operativi GNU/linux dedicati.
Per "sistemi
operativi dedicati" intendo dei sistemi che siano specializzati nel
fornire funzionalita'
specifiche e non un generico supporto al funzionamento di un computer.
Essi possono
quindi riguarda sia progetti di fornitura di servizio che di usufrutto
(server e client).
La loro impostazione fa' si' che in essi siano presenti un sottoinsieme
di programmi end
user gia' configurati per un utilizzo ottimale della tipologia di utente
target, ma anche
una interfaccia 'ad hoc' e un raggruppamento di menu' studiato
coerentemente. Una vera e
propria organizzazione logica, supportata dalle necessarie
ottimizzazioni tecniche.
Si potrebbe pensare che questa proposta si giochi tutta sul campo dei
programmi
end user, ma (come si accennava al termine del precedente paragrafo) il
problema
e' (anche tecnicamente) piu' complesso e coinvolge componenti che
cambiano radicalmente
la natura di una distribuzione. Parliamo quindi di kernel o del sistema
grafico, nonche'
dello stack di rete. Per questo motivo le distribuzioni "generiche"
mostrano il loro limite
quando si smette di avere un approccio superficiale e si diventa
interessati a una branca
specifica dell'orizzonte digitale.
Vero e' che i metodi di personalizzazione di linux sono tali da superare
questi limiti
con ricompilazioni ad hoc, ma in questo modo il tentativo di
abbattimento del gap
digitale che le distribuzioni maggiori portano avanti fallisce
inesorabilmente decadendo
in miriadi di sottoprogetti da scovare e implementare e che soprattutto
rischiano di
essere esperienze uniche senza chance di riproducibilita' e di aggregazione
comunitaria.
Per questo motivo la gentoo e' diventata necessaria: essa risponde
esattamente alla
necessita' di creazione di un sistema estremamente personalizzabile.
Certo uno dei
suoi punti di forza sta nella ottimizzazione degli eseguibili e nel
relativo (presunto?)
aumento di performance, ma la sua effettiva forza sta nel meccanismo di
generazione
ed installazione che permette una estrema specializzazione della scelta.
E' possibile
definire l'albero delle dipendenze durante l'installazione dei programmi
singoli come
dell'intera distribuzione, per dirne una, e quindi definire variabili
quali lo spazio disco
utilizzato e la complessita' del sistema operativo a partire dai suoi
componenti base
(librerie di interfaccia con le syscall e shell). Purtroppo anche la
gentoo soffre del limite di non offrire una vera scelta, ma di dare la
possibilita'
di scegliere "soltanto" a chi e' capace di gestirla, soprattutto dal
punto di vista
sistemistico/tecnico.
<modify...>
Ma con il suo esempio chiudiamo questa parte, perche' essa e' la
dimostrazione di una
evoluzione nella richiesta degli utilizzatori di sistemi GNU/linux.
</modify...>
(? aggiungere ulteriori specifiche sui sistemi dedicati, esempi etc ?)
Prima di passare a un approccio pratico al problema della costruzione di
un sistema
operativo dedicato home made, dobbiamo necessariamente passare per la
conoscenza degli
elementi che lo costituiscono. Sara' questo l'argomento della prossima
parte.
2. Come e' fatto un sistema operativo GNU/linux?
---------------------------------------------------
Iniziamo con il dire che, per quelle che sono le mie competenze, queste
informazioni sono applicabili in generale ai sistemi operativi *nix e
*bsd. Tuttavia, conscio dei miei limiti, propongo questa analisi solo
per i sistemi GNU/linux e lascio ad altri le necessarie integrazioni.
Tre sono le componenti base di un sistema GNU/linux:
1) kernel e relativi moduli (se non compilato staticamente);
2) binari e relative estensioni/dipendenze (librerie);
3) file di configurazione;
I dati non sono parte del sistema, percio' non vengono inclusi in questo
elenco.
Queste componenti funzionano solo se impilate nel giusto ordine. La base,
la pietra angolare del sistema operativo e' il kernel. Su di esso poggiano
in vari strati i binari. Il loro funzionamento viene modificato dai file
di configurazione. Per quanto riguarda la progettazione, il meccanismo del
sistema operativo e' cosi' composto:
2.1. Il Kernel
Il kernel (ovvero la componente 'linux' di GNU/linux) e' l'interfaccia con
l'hardware. Questo componente si pone al livello piu' basso del sistema.
Il funzionamento dei restanti componenti dipende fortemente dalle sue
corrette
configurazioni. Le ottimizzazioni che si possono portare al sistema spesso
passano per il kernel, dal momento che esso determina non solo il corretto
funzionamento dell'hardware ospite, ma anche le ottimizzazioni praticabili.
Un paio di esempi:
* un kernel preemptive per velocizzare le operazioni real time
* un kernel con le patch per lo stack di rete per migliorare la capacita'
di streaming
* un kernel con i driver per le schede video con le accelerazioni 3D
2.2 I binari
Se il kernel ne e' il cuore, i file binari sono la nervatura di un
sistema GNU/linux
e sono la parte 'GNU'. Essi rappresentano le funzionalita' che, a vario
livello, il
sistema espone. Di solito per "binari" si intendono i programmi (detti
anche applicativi)
che compongono una distribuzione, ma nel nostro caso includiamo in
questa definizione
anche le cosidette "librerie". Esse sono delle funzionalita' aggiuntive
su cui buona
parte dei programmi fanno affidamento per il loro funzionamento. Di
solito le librerie
sono "dinamiche", ovvero vengono caricate al volo per essere utilizzate,
in modo da
non avere molti file grossi che contengono molte parti in comune, bensi'
altrettanti file piccoli che contengono solo le funzionalita'
specifiche. Quelle
comuni vengono caricate dalle librerie e sono condivise dai programmi
che ne fanno
uso. Questo meccanismo crea un sistema ad albero che viene di solito
chiamato "dipendenza".
Si dice quindi che un applicativo 'dipende' da una o piu' librerie.
Anche le librerie stesse
possono avere delle dipendenze da altre librerie.
<cancellare?> Altra caratteristica che distingue i binari dal resto del
sistema e' il fatto che essi
usano un'area di memoria non protetta, nota anche come "user space", che
si contrappone
all'area protetta chiamata "kernel space" </cancellare?>. I binari si
stratificano in un sistema in
base allo scopo che devono raggiungere. Molti di essi non sono
conosciuti dall'utente
finale, eppure sono fondamentali. D'altro canto altri programmi sono il
front off del
sistema e ne determinano l'usabilita', percio' diventano emblematici del
sistema stesso.
Le librerie sono la componente binaria meno conosciuta dall'utente
finale, eppure le loro
ottimizzazioni possono fare la differenza e caratterizzare notevolmente
un sistema GNU/linux.
2.3 I file di configurazione
Nonostante siano gli applicativi a fare il lavoro, essi non sono
progettati per
compiti cosi' specifici da stare dietro alle necessita' di ciascun
utente. Viste
le innumerevoli possibilita' di personalizzazione del comportamento di
un programma
sono stati introdotti i file di configurazione. In un ambiente *nix e
quindi anche
in GNU/linux, i file di configurazione sono di due tipi:
1) generali, inseriti nella directory /etc;
2) per utente, inseriti nella home directory dell'utente stesso
(/home/nomeutente)
I file di configurazione sono quasi sempre dei file di testo che
contengono delle
variabili a cui si assegna un valore. Ad esempio: dove sono i file
grafici che
contengono le icone dei pulsanti? La posizione della cartella standard
sta nel file di
configurazione generale, mentre le eventuali personalizzazioni
dell'utente vengono
registrate nel suo file di configurazione personale.
E' fondamentale notare che i file di configurazione personali
sovrascrivono le
impostazioni di quelli generali.
2.4 Mettiamo i pezzi assieme ****** RIVEDI DA QUI IN AVANTI!! *******
Come funziona quindi la progettazione e la realizzazione di una
distribuzione
(maggiore o specializzata che sia)?
I passi specifici sono:
-- Creazione del sistema base
- Creazione di un "nido", ovvero di un sistema di cartelle ospiti.
- Inserimento di applicativi e librerie nel sistema di cartelle.
- Aggiunta dei relativi file di configurazione
-- Creazione del kernel
- Compilazione del kernel
- Installazione dei moduli del kernel
-- Creazione del sistema aggiuntivo
- Inserimento degli applicativi e delle rispettive librerie partendo
dalla
cartella "usr" in avanti.
La parte piu' importante e' quella progettuale. In questa fase si
decidono le
funzionalita' della distribuzione, il suo sistema di manutenzione
(pacchettizzazione),
l'interfaccia grafica e il bouquet di programmi offerti. Si passa quindi
a creare una
cartella di lavoro in cui "installeremo" la distribuzione. Quello che
andiamo a fare e'
creare un altro albero "/" dentro la cartella, per cui si possono
elencare subito le
cartelle necessarie. Per le eventuali altre fate riferimento allo
standard HFS <e' giusto?>
Non possono quindi mancare 'etc', 'dev', 'proc', 'tmp', 'var', 'lib',
'bin', 'sbin'.
'usr', 'home' e 'root' sono un discorso a parte: 'home' e 'root' sono le
cartelle che
contengono i dati e le configurazioni degli utenti, quindi dipende dalla
progettazione
del sistema se esse sono indispensabili o meno. 'usr', invece, contiene
le aggiunte al
sistema base. In questa sezione non possiamo fare altro se non ragionare
per massimi sistemi
e genericamente, ma nell'ultima parte vedremo un esempio pratico di
applicazione.
Una volta preparato il "nido" del sistema, lo popoliamo partendo dagli
eseguibili. A
questo punto ci si prospettano due possibilita':
* copiare gli eseguibili;
* compilare gli eseguibili;
2.4.1 Copiare gli eseguibili
Questo metodo e' il piu' facile oltre che il piu' immediato. Il trucco
consiste nell'avere una
distribuzione "madre" da cui poter copiare i binari. Di solito il metodo
consiste nello
scegliere un applicativo e verificare le sue dipendenze con il comando ldd:
sdkbuilder:# ldd /path/del/comando
Ad esempio, su una debian unstable il comando 'ls' ha queste dipendenze:
sdkbuilder:# ldd /bin/ls
librt.so.1 => /lib/tls/librt.so.1 (0x40020000)
libacl.so.1 => /lib/libacl.so.1 (0x40026000)
libc.so.6 => /lib/tls/libc.so.6 (0x4002e000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40169000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libattr.so.1 => /lib/libattr.so.1 (0x40178000)
Cosa significa? Che se voglio che il comando 'ls' funzioni nella mia
distribuzione, devo essere
sicuro che siano presenti anche i file /lib/tls/librt.so.1,
/lib/libacl.so.1 etc. Con il tempo si
impara che alcune librerie sono indispensabili a tutto il sistema
GNU/linux. Esse sono ld-linux.so.2
e libc.so.6. Vista la loro natura condivisa spesso le librerie inserite
per un programma valgono
anche per altri, sicche' non e' necessario copiarle ancora. D'altro
canto e' possibile che alcune
librerie a loro volta dipendano da altre librerie. Ancora una volta il
comando ldd ci aiuta. Es:
sdkbuilder:# ldd /lib/libattr.so.1
libc.so.6 => /lib/tls/libc.so.6 (0x4000d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
In questo caso specifico la libreria dipende soltanto dalle librerie
base, ma non sono rari i casi
in cui l'albero delle dipendenze si allarga. Per ovviare
all'inconveniente di seguire tutte le
dipendenze, si puo' facilmente creare uno script che si limiti a fare un
ldd ricorsivo, controllando
anche se le librerie sono state gia' copiate per non ripetere
l'operazione (N.B. non e' un problema se
si ricopiano le stesse librerie, ma e' un inutile spreco di tempo).
<aggiungere qui lo script di esempio>
Quali sono i limiti di questo metodo? Innanzitutto ci si portano dietro
le scelte della distribuzione
madre e quindi la personalizzazione e' penalizzata. Un esempio fra
tutti: vim nella debian e' compilato
per avere il supporto gpm che permette di copiare e incollare usando il
mouse. Non e' detto che nella
distribuzione che produciamo questa funzionalita' (che richiede le
librerie libgpm e il programma gpm)
sia voluta o necessaria, ma se copiamo il file eseguibile vim dalla
debian non possiamo evitare di
copiare anche le librerie gpm.
In caso contrario 'vim' non funzionera'. E' da notare che il supporto
gpm funziona se e' in esecuzione
il relativo programma, ma questo a vim non interessa: se gpm non e'
attivo, semplicemente il mouse non
funzionera'. Tuttavia vim non andra' in esecuzione se gli mancano le
libgpm.
Altra conseguenza della copiatura di file e' quindi che il controllo
sullo spazio disco utilizzabile non e'
del tutto possibile, visto che ci possono essere file indesiderati e
comunque inutili che non e' possibile
escludere.
2.4.2 Compilare gli eseguibili
Questa modalita' consiste nel compilare tutti i programmi ex novo.
Compilare un programma significa
ottenere i 'sorgenti', ovvero il codice con cui sono stati scritti i
programmi e le librerie,
e poi renderli eseguibili passando per un processo di codifica che ha il
nome di compilazione.
La compilazione permette spesso una personalizzazione molto alta sia
delle funzionalita' di un programma
che della sua ottimizzazione. Per ottimizzazione si intende la
finalizzazione di un eseguibile
per un tipo di processore o per un uso della memoria personalizzato
(anche se in questo ultimo caso
le personalizzazioni sono variabili e non sempre possibili).
La compilazione di un programma quindi porta inevitabilmente una
capacita' di intervento
sul processo di creazione degli eseguibili _molto alta_, ma comporta
alcune difficolta'. Innanzitutto
e' necessario comprendere cosa sia la compilazione, competenza spesso
appannaggio dei programmatori ma
non dei sistemisti o dei progettisti di sistemi operativi. Inoltre il
processo comporta un onere alto
in fase di creazione, sia in termini di tempo che di spazio su disco.
Infatti per compilare un programma
e' necessario scaricarne il codice sorgente che spesso e' un archivio
compresso, scompattarlo, effettuare
la compilazione che lascia quasi sempre un botto di file temporanei in
giro. I file eseguibili generati
occupano uno spazio su hard disk molto inferiore (massimo il 10%)
rispetto allo spazio usato dai file
di compilazione.
Riassumendo: la compilazione porta un livello di personalizzazione
estremo per le dipendenze e
l'ottimizzazione, ma richiede molto tempo e molto spazio su disco,
nonche' una competenza da programmatori.
Per questi motivi (ma spesso piu' per l'ultimo che altro) la creazione
di una distribuzione mediante
compilazione non e' percorribile. Cosa succederebbe se si riuscisse a
ridurre considerevolmente il 'gap'
tecnico e tenere buoni solo i vantaggi di questo meccanismo? La gentoo e
il sistema di creazione dei sistemi
basati sulle libc5 hanno affrontato questo problema ed hanno offerto
delle soluzioni praticabili.
2.4.3 Compilare il kernel e installare i moduli
2.4.4 Inserire i file di configurazione
2.4.5 Creare un sistema avviabile usando init
========= DA QUI IN AVANTI CI SONO GLI APPUNTI SULLA TERZA PARTE ===========
A questo punto voglio creare un SDK (Software Developement Kit) e una
distribuzione mia.
Come faccio?
La proposta pratica che si presenta qui consiste nel lanciare uno script
che crea
un chroot gentoo per poi installare nella sottocartella home/the_root
(bacio a liw!)
un sistemino base, chiamando uno sottoprogramma. Aggiungiamo una bozza
di script
per creare, a processo terminato, sia un file initrd che usrfs. Questo
perche' la
proposta e' relativa a distribuzioni live, ma da questo meccanismo si
puo' tirare fuori
anche un sistema installabile ed autonomo.
Obiettivo: avere la soluzione finale per compilarsi l'initrd.gz e
Xfree86 dentro uno squashedfs, in modo da avere "la gomma base", poi ognuno
ci mette il gusto suo. che significa, trovare una maniera di gestirci la
possibilita' di creazione del sistema base per tutti, partendo dai
sorgenti e compilandosi almeno fino ad Xfree86 tutto il necessario in
modo che con lo script si possa fare il cd etc etc. Questo ci permetterebbe
di avere il pezzo che ci manca: la gestione dei sorgenti (e relative
dipendenze) e la possibilita' di rendere accessibile a chiunque il
"sorgente aperto" della distribuzione, come da GPL.
Versione base significa:
- initrd.gz
- usrfs con Xfree86
in modo che poi uno si fa il kernel e mette i tool che gli sono stati
richiesti, conservando tutto cio' che e' il lavoro fatto fin'ora in
/etc per quanto riguarda il riconoscimento dell'hw e degli rc di avvio.
perche' nello script ci sara' la ricetta per la
base comune. poi io mi auguro che ognuno abbia voglia di fare un proprio
cd customizzato per sottosezioni, ma in modo che tutti ci possiamo
scaricare
dagli ebuild i sorgenti che ci servono. Se sfruttiamo gentoo, possiamo
usare
la cartella /var/db/pkg per sapere cosa e' stato installato da ciascuno
degli sviluppatori.
cosi' scambiandoci un elenco potremmo fare:
emerge -De world
di un world che e' il sw di dynebolic base + eventualmente una delle
customizzazioni ed avere l'ultima versione del sw subito e concentrarci
sulle conf ed ottimizzazioni. potremmo finalmente mettere
con un qpkg -I > ELENCOPACCHETTI l'elenco completo di cio' che abbiamo
usato, indicare dove sono i sorgenti, decidere che li mettiamo in una
dir del sito, insomma renderci trasparenti rispetto come facciamo le
cose.
voglio poter ufficializzare un nostro baselayout con la possibilita' di
avere un
live cd con X funzionante per ciascuno di noi solo lanciando un paio di
script, sfruttando gentoo&portage , cosi' le differenze che ognuno di
noi portera' al
progetto saranno facilmente individuabili (dei diff dei portage, per
dirla grezza grezza) e ripetibili da ciascuno. cosi' non si dovra' piu'
cercare dove sono i sorgenti, ognuno si scarica la sua copia dai
relativi autori di quei programmi, sapendo bene che li mettera' in un
layout che dara' dynebolic e non gentoo.
provo a esemplificare:
l'idea e' quella di creare/fornire a tutti gli interessati il "sorgente"
della distribuzione.
Come si fornisce il sorgente di una distribuzione?
possiamo dire che una distro linux e' composta di 3 elementi fondanti:
kernel
binari
configurazioni
noi possiamo dare il .config del kernel e le configurazioni, ma ci manca
un meccanismo per distribuire
(e rendere accessibili/modificabili/aggiungibili) i binari, che sono
eseguibili e librerie.
Per trovare soluzione a questo problema abbiamo studiato come funzica la
gentoo, emerge, emerde e le
libc5 e abbiamo visto che il meccanismo per noi migliore consiste nel
fornire 2 elementi:
1) script che permettano di scaricare e compilare secondo i nostri flag
e con le nostre patch i binari
2) script che partendo da 1) consentano di "comporre" la distro.
quindi quello che stiamo cercando di fare e' creare questi script.
L'idea e' che ci si possa installare un SDK che compila la dynebolic e
poi con un paio di comandi impacchettarla
in una iso.
Il tutto lasciando a disposizione di chi usa il sistema sia i sorgenti
dei singoli pacchetti installati che i
nostri configure che la nostra selezione di pacchetti.
Abbiamo scelto di partire da una gentoo perche' e' la distro che al
momento implementa il metodo piu' funzionale,
ha piu' server in giro ed e' ben aggiornata.
Vogliamo percio' scrivere una suite di script che ci permettano di usare
lo stage 1 per creare un SDK
chrootato e da li' poter compilare ed installare in una sotto cartella
the_root il sistema d:b.
Altri script creano il nostro /etc, l'initrd.gz e lo usrfs e inseriscono
il tutto in una directory. Infine, dopo aver
aggiunto il kernel e aver configurato il loader, uno script finale crea
la iso.
Usare la gentoo (e finisco) permette un buon livello di accesso a chi
vuole proporre e/o seguire dei programmi/funzionalita'.
Infatti basta sistemare la lista dei pacchetti per creare la distro che
vogliamo, partendo dai sorgenti che ci sono
sui siti dei rispettivi programmatori e usando emerge come meccanismo di
installazione.
Infine cosi' facendo ci basta scambiarci dei file di testo per ottenere
la distro ricompilandola dove vogliamo e
quindi rendendo il lavoro distribuibile tra di noi.
STAGE1 di gentoo, da qui creiamo l'ambiente di compilazione:
|
|---bin
|---boot
|---cdrom
|---dev
|---etc
|---floppy | QUI SI CREA DYNEBOLIC (ROOT=/home/the_root emerge
programma)
|---home -------------the_root
| |
| |---bin
| |---boot
| |---cdrom
| |---dev
| |---etc
| |---floppy
| |---home
| |---lib
| |---lost+found
| |---mnt
| |---proc
| |---root
| |---sbin
| |---sys
| |---tmp
| |---usr -> questa dir e' vuota quando crei l'initrd.gz
| `---var
|---lib
|---lost+found
|---mnt
|---proc
|---root
|---sbin
|---sys
|---tmp
|---usr
`---var
con gli script che stiamo scrivendo questo SDK lo si genera a
runtime scaricando le ultime versioni dei pezzi che lo compongono.
cio' su cui dobbiamo essere compatibili sono i CFLAGS che settiamo nel
file make.conf di STAGE1, che sono i flag di compilazione di d:b.
noi riteniamo che fino alla compilazione di cio' che compone l'initrd.gz
siano sufficenti questi parametri:
-O2 -pipe -fomit-frame-pointers -mcpu=586
in quanto flag come sse, mmx, mfpmath=sse sono per noi interessanti solo
sugli applicativi che hanno a che fare con il multimedia e basta,
percio' possiamo decidere quali usare di questi a partire dalla
compilazione di Xfree86.
per riassumere cosa ci serve nell'initrd:
- baselayout-dynebolic (questo pacchetto lo dobbiamo fare noi, qpkg -l
baselayout di gentoo ti da un'idea molto chiara del tipo di
pacchetto
che discutiamo)
- linux-headers (questo nello script che crea initrd viene
spostato prima della creazione, perche' serve
per compilare ma non serve nell'initrd del
CD-LIVE
- glibc questo pacchetto si puo' sfoltire (ho anche
l'elenco delle lib "inutili" in /lib
- ncurses
- bash
- coreutils si puo' spuntare qualche eseguibile. non porta
libs, bastano le glibc.
- net-tools ifconfig etcetc
- iputils ping traceroute
con questi (sfoltendo pure un po') hai gia' un initrd 100% dynebolic
compatibile.
POI
premesso che le OTTIMIZZAZIONI di questo processo saranno il succo di
tutto quanto, posso anche dirti con certezza che tutto cio' che
compileremo da qui in poi per avere Xfree86 funzionante e pure un po'
incazzato NULLA ANDRA' FUORI DA /usr, quindi il primo livello del FSH
RIMARRA' DA QUI IN POI INVIOLATO, tenuto conto che in d:b ci sono le dir
scrivibili che vengono montate su tmpfs, quindi SIAMO GIA' A POSTO.
basta fare il nostro baselayout-dynebolic.ebuild che consideri le nostre
scelte progettuali per lo scheletro del sistema (autodetect ed init).
facciamo un esempio pratico e banale:
sdkbuilder:# ROOT=/home/the_root USE='mmx sse 3dfx 3dnow' emerge ati-drivers
[ebuild N ] sys-apps/module-init-tools-3.0 347 kB
[ebuild N ] sys-kernel/gentoo-sources-2.4.25-r2 -build 31,488 kB
[ebuild N ] media-libs/libpng-1.2.5-r4 369 kB
[ebuild N ] x11-base/opengl-update-1.5 [empty/missing/bad digest]
[ebuild N ] media-libs/freetype-2.1.5-r1 -bindist -cjk +zlib 830
kB
[ebuild N ] x11-misc/ttmkfdir-3.0.9-r1 19 kB
[ebuild N ] media-libs/fontconfig-2.2.1 599 kB
[ebuild N ] app-arch/unzip-5.50-r2 1,043 kB
[ebuild N ] app-arch/cabextract-0.6 90 kB
[ebuild N ] x11-base/xfree-4.3.0-r5 +3dfx +3dnow -bindist -cjk
-debug -doc -ipv6 +mmx +nls +pam -sdk +sse -static +truetype +xml2
71,131 kB
[ebuild N ] media-libs/glide-v3-3.10-r3 -voodoo3 3,566 kB
[ebuild N ] app-arch/rpm2targz-9.0-r2 2 kB
[ebuild N ] media-libs/libpng-1.2.5-r4 to /home/the_root/ 369 kB
[ebuild N ] x11-base/opengl-update-1.5 to /home/the_root/
[empty/missing/bad digest]
[ebuild N ] media-libs/freetype-2.1.5-r1 to /home/the_root/
-bindist -cjk +zlib 830 kB
[ebuild N ] x11-misc/ttmkfdir-3.0.9-r1 to /home/the_root/ 19 kB
[ebuild N ] media-libs/fontconfig-2.2.1 to /home/the_root/ 599 kB
[ebuild N ] app-arch/unzip-5.50-r2 to /home/the_root/ 1,043 kB
[ebuild N ] app-arch/cabextract-0.6 to /home/the_root/ 90 kB
[ebuild N ] x11-base/xfree-4.3.0-r5 to /home/the_root/ +3dfx +3dnow
-bindist -cjk -debug -doc -ipv6 +mmx +nls +pam -sdk +sse -static
+truetype +xml2 71,131 kB
[ebuild N ] media-video/ati-drivers-3.2.8-r1 to /home/the_root/
-gnome -kde +qt 4,262 kB
[ebuild N ] media-libs/glide-v3-3.10-r3 to /home/the_root/ -voodoo3
3,566 kB
TUTTO QUESTO VA IN /USR. ABBIAMO VINTO.
ripeto, cosi' si fa in fretta, la differenza la facciamo NOI in tutto
questo. COME?
patchando e rilasciando degli ebuild-dynebolic.patch compatibili con
gentoo in modo che introducendo le info nel portage noi ci scarichiamo i
sorgenti di XY, gli applichiamo la patch (in automatico con emerge)
fatta da chiunque di noi si senta di produrne, e compiliamo nell'SDK
che hai visto anche tu come e' fatto.
PROVA
------- End of File buildSDK,sh
