DarkForge Forum
Forum principali => Software => Linux, Open Source e compilazione => Topic started by: MsZ on Tue 19 February 2008, 12:54
-
E' viva.
E' VIIIIVAAAAAA!!!
Gli script funzionano. Con un bit di tweaking all'inizio li ho adattati e adesso mi avviano tutto quello che mi serve. Funziona pure il cambio di runlevel, che in LFS non è un vero cambio di runlevel. SI resta nel 3 ma i servizi "ruotano" tra loro. Però se avessi voluto andare in runlevel amministrativo (1) non potevo.
Adesso si. :biggrin:
Avevo pensato di ispirarmi anche un poco alla Gentoo, ma appena ho visto la struttura degli script mi sono messo le mani nei capelli. Mai visto tanto casino. Ci sono script addirittura in /sbin. Al confronto gli script della Slack sono ordinatissimi.
Ho scelto un'architettura SystemV. All'inizio avevo optato per una BSD -stile Slackware-, ma ho preso solo l'indispensabile. Mi ero reso conto che per quello che volevo fare io una BSD non era adatta. Ma neanche una SysV pura. Per esempio, tutti gli script di avvio in LFS (SysV) sono chiamati dal runlevel "sysinit". Sono molti, non uno solo. Io ho raggruppato tutti gli script in uno solo. In Slack (BSD) esiste rc.S che alla fine chiama rc.M, multiuser generico in runlevel 2,3,4 e 5.
I runlevel sono bellissimi. Si può killare dei servizi che non vuoi avere in un runlevel diverso dal tuo default. O avviarne altri, per avere una configurazione software più completa. Si può anche creare una configurazione di runlevel apposita per far avviare un'applicazione grafica oltre a X.
Come la 4. O la 5. Dato che i runlevel sono altamente configurabili -sono solo convenzioni- la Slack mette X11 nel 4. In verità sarebbe nel 5, ma noi siamo fighi -plurale maestatis :2funny: - e mettiamo X11 nel 4 e X11+aMule(esempio) nel 5. Ah, che bello.
Pure il 2 è configurabile. Di "assoluto" ci sono solo 1, 3 e 5. Oltre a 0 (halt), S (o s, single user senza demoni o network) e 6 (reboot).
Ma è solo una questione di preferenze. Dipende dagli script che vengono avviati in /etc/inittab.
Le funzioni sono dentro il file $BASECONF/config/library, la configurazione di sistema in $BASECONF/config/config, ma credo che cambierò nome. Tutti gli script si vanno a vedere i due file per funzioni di base, colori e impostazioni come console e interfacce LAN.
Beh... non è SysV pura. E' una specie di "ibrido", ho tentato di prendere le caratteristiche che giudicavo migliori -stabilità e modularità- evitando il peggio -dispersione di variabili tra i diversi script-. La dispersione è una bruttissima cosa: se devi andare a cercare un bug ti devi tracciare la variabile su tutti gli script in cui compare, e non è bello. Ho cercato di rendere questa cosa più semplice possibile.
Ho dovuto un po' "imparare Linux daccapo" ma ho avuto soddisfazioni tremende. I problemi più grossi sono nei confronti logici tramite bash: falli una riga e uno script non parte.
Sono un po' come Frankenstein che ha appena acceso il cervello del mostro. Mancano tante cose, ma le basi ci sono.
Ed ecco le ragioni principali per cui ho aperto il topic:
1-il nome. Che nome dovrei darle? Io pensavo ad una cosa tipo "LittleStep" (-un grande passo per me, un piccolo passo per la comunità-), ma sono disponibile a qualsiasi tipo di suggerimento.
2-Che applicazioni vi servono, quali usate molto spesso? Terminale, X o di rete. Grafiche e non.
3-Il Window Manager? Io metterò sicuramente AfterStep (da qui il nome che avevo pensato), e molto probabilmente Xfce. All'insegna della leggerezza, quindi KDE è escluso, anche se mi stanno comodi alcuni tool grafici per la configurazione. Ma cercherò di arrangiarmi. :)
Una cosa: non ditemi GNOME perchè lo odio. Qualsiasi altro DE va bene. :)
4-Il packet manager? Se lo metto sarà un semplice script che lavora su file compressi .tar.bz2. Genera un file di testo che contiene tutti i percorsi ai dati installati, così installare e disinstallare un pacchetto è facile come bere un bicchier d'acqua. Generarlo un po' meno, ma ci sto pensando. Più altre funzioni che mi verranno sicuramente in mente durante lo sviluppo.
5-L'interfaccia d'installazione?
Questa è una brutta bestia. La voglio in stile Slackware, ma me la devo studiare ben bene.
6-Creazione di un possibile LiveCD (e relativo disco di installazione)?
Idem. Pensavo ad un filesystem come SquashFS, ma non riesco a patchare il kernel. Ci deve essere qualcosa che mi sfugge. Sennò opto per una ISO nell'ISO ed un montaggio in loopback. Ma questa è l'ultima cosa, e spero di avere un po' più di esperienza -e conoscenze- quando ci arriverò.
Ed ecco il pezzo forte...
Dato che ci metterò un po' di tempo (non aspettatevi niente tra le mani almeno fino a quest'estate) avevo la mezza idea di chiedere a taz se volesse farmi l'onore di affidarmi il suo porting di SharkX da mettere come default nell'installazione. Alla faccia di aMule e compagnia.
-
:ipno: :ipno: :ipno: :ipno: :ipno: :ipno: :ipno: :ipno:
Che cosaaaa?? Quest'uomo è sovrumano. :whustling: :ph34r:
1) Mi piace LittleStep!
2) In che senso? Non ho capito bene...vorresti una lista?
3) Buon AfterStep, magari anche fluxbox adattato e personalizzato.
4) Ok per lo script...a me piace molto pacman...
5) Stile slack va bene, semplice e leggera ma non troppo ostica.
6) Potrebbe essere una buona idea.
Complimentoni MsZ, e BUON LAVORO! :type:
:smile:
-
ODDIO, IO TI AMOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!
Afterstep!!!! ca@@o, ma sei il mio mito!!!
per lo script di installazione, io avrei sempre desiderato qualcosa che permette di scaricare i sorgenti cvs/svn/bzr/git e simili e li compila...
per le applicazioni, sicuramente metterei firefox e thunderbird, e OOo (evitiamo di illuderci, abiword e altri non sono a livello). NON mettere mono con le sue librerie mostruosamente pesanti, cerca di eliminare font strani per ora, in modo da alleggerirla, e mi piacerebbe XFE (http://roland65.free.fr/xfe/) come filemanager...
Io darei un'occhiata all'installer della Vector, l'ho trovato meraviglioso, veloce e facile (anche senza VASM va bene)
[Edit by MsZ - Ehm ehm... ::)]
-
sei il migliore, complimenti
-
@PJF
In che senso? Non ho capito bene...vorresti una lista?
Più o meno. Quello che usi (usate) più spesso, da terminale o da X.
Buon AfterStep, magari anche fluxbox adattato e personalizzato.
Fluxbox è semplicissimo... a dir la verità pensavo di tenerlo fuori perchè è troppo leggero, ma può essere una buona idea se l'unica cosa che un utente vuole da X... è proprio X (come me) :biggrin:
a me piace molto pacman...
Pacman è scritto in Python. Se faccio il packet manager dovrà essere uno script bash.
@franz
io avrei sempre desiderato qualcosa che permette di scaricare i sorgenti cvs/svn/bzr/git e simili e li compila...
Portage può essere installato su qualsiasi distribuzione. I problemi di base sono:
1-sorgenti nuovissimi possono non essere stabili;
2-serve un archivio enorme di righe che descrivano dove trovare che cosa;
3-più protocolli vogliono dire più programmi ed una più difficile gestione degli stessi. Se un programma non è disponibile potrebbe non essere possibile compilare del tutto un software.
Casomai mi posso concentrare su SVN o CVS, ma comunque serve un archivio di siti e di funzioni.
OOo
... è pesantissimo!!!!! Sarà anche l'unica alternativa open source completa a Office, ma è pesantissimo.
NON mettere mono con le sue librerie mostruosamente pesanti
Lungi da me.
mi piacerebbe XFE come filemanager.
Qualsiasi cosa utile e leggera è ben accetta. :smile:
Firefox è già di default, non vi preoccupate. Non uso mai Thunderbird per la posta, ma ci darò uno sguardo.
-
eh, lo so che è pesantissimo OOo, ma riesci a trovare migliore abiword? io no. anche se ultimamente OOo mi sta combinando casini con xfce4, dato che l'interfaccia nuova non si vede per niente...
emesene di default, sebbene spesso sia buggato all'inverosimile, amsn sta restando indietro. e anche xchat, io lo adoro. come player audio è difficile, exaile ha ancora il bug del mixer, listen (il mio favorito) è molto lento nell'aggiornarsi, amarok è mostruosamente pesante e lento, rhtyhmbox sembrerebbe un'ottima scelta, ma non mi ci sono mai trovato bene... naturalmente per qualcosa di classico, audacious è ottimo. e anche mplayer va alla grande.
Per quanto riguarda l'editor, io mi trovo con nano e con medit (che è un clone di gedit), che sono due ottime risorse, una text e l'altra grafica.
Ci vorrebbe anche qualcosa tipo ipblock, un ipfilter grafico (moblock-gui è ancora in alpha, e si muove a rilento) anche se ipblock non lo puoi inserire senza inserire java preinstallato.
Di terminali metterei uno tipo xterm e uno tipo emulatore di terminale, o come cavolo si chiama, hai presente xfce4-terminale, gnome-terminal, konsole... comodi perchè completi, anche se lenti. Io metterei aterm + xfce4terminal (sempre se non richiede librerie di xfce4).
come programma per la masterizzazione io uso brasero, ma poi dipende se ti stai muovendo per creare un ambiente gtk o qt (spero gtk)...
-
MPlayer di default. VLC come seconda scelta. Xine non lo voglio neanche sentir nominare. E' un vero schifo. ::)
Nano è ottimo. Metterò anche vi (editor base: senza non fai un tubo, neanche gli script) e molto probabilmente emacs. Devo imparare ad usarlo. Se Stallman l'ha fatto qualcosa di buono deve avere :P
xterm e rxvt sono assoluti, devono esserci. I terminali emulati sono pesanti perchè usano framebuffer. Il framebuffer, per definizione, è sempre lento perchè usa un'emulazione software. Quelli normali sono smeplici terminali virtuali grafici. Quelli emulati emulano tutte le funzioni di un terminale reale e in più hanno altre funzioni come copia-incolla.
Come programma per la masterizzazione il migliore frontend grafico (secondo me) è Xcdroast. Il fatto è che ho perso un po' di vista il progetto, devo andarlo a vedere. K3B è molto completo, ma lento. (Usa librerie QT.)
Il frontend ha molte cose dietro, non solo un programma per il burning.
OOo è molto "grassa" come suite... temo che stiano un po' sforando. Devo andare a cercare altre cose che possano sostituirlo, oppure vedere come si può fare a compilarlo in modo più generico. Vedrò questo prima.
-
XcdRoast lo avevo provato, ma era buggato, ed è fermo ad agosto del 2007...
Di OOo, puoi mettere magari solo il word processor, il foglio elettronico, database e presentazione...
-
Sei un grande.. davvero.
Un solo suggerimento per l'installazione, io la farei molto simile a quella della slack, secondo me è molto intuitiva permette un sacco di personalizzazioni e non ha quelle inutili interfacce grafiche.
credo che la creazione di un live cd sia una buona cosa, cmq lascerei separati installazione e live (evitare un ibrido alla ubuntu tanto per interderci :biggrin:).
Condivido pienamente la tua idea di non usare gnome... non lo sopporto neanche io, punterei si afterstep e xfce, non mi piace tanto fluxbox però...
-
Di OOo, puoi mettere magari solo il word processor, il foglio elettronico, database e presentazione...
Era quella l'idea, stringerlo all'osso.
Mi va lento su un Athlon 64 3700+ 2200MHz, fate un po' voi... :think:
lascerei separati installazione e live
Accolta, in effetti è meglio, mi semplifica le cose. :biggrin:
Un solo suggerimento per l'installazione, io la farei molto simile a quella della slack
Già so. :laugh:
---EDIT---
Ho sistemato lo script dei runlevel. Era un pacco e non funzionava bene, ora dovrebbe compiere la sua missione come l'ho progettato: cambiare runlevel quando il sistema è up, e passare al runlevel di default quando il sistema è in sysinit. Il problema è fare i confronti tra script, ma penso di aver capito come si fa.
Adesso mi devo concentrare un pochettino su Xorg, così tra breve potrò cominciare a pensare di installare AfterStep e Xfce. E poi arriveranno tutte le applicazioni grafiche di base. Ovviamente mi dovrò appuntare tutto con cura, sennò addio.
Compilare Xorg sarà uno spasso. Ci metterò mesi solo per capire come fare. :2funny: :folle: :lgh: :haha: :ipno: :pianto: :wallbash: :pcwhack: :type:
Mwhohahahahahuuuhuhuuu. Sento che sto già diventando pazzo. :gogo8xe:
-
GCC lo hai già compilato, io credo sia un'ammazzata ancora di più compilare quello...
-
No, GCC al confronto è molto semplice. E' una delle prime cose che deve essere compilata in una distribuzione. La prima è Binutils.
-
X sta venendo su che è una bellezza. Già che ci sono ho intenzione di vedere se riesco a implementare Xgl, con Xegl e Xglx. Il problema più grande è riuscire a compilare Mesa con supporto 3d, ma ce l'ho fatta... 7 ore di sforzi ieri. Adesso ho Mesa3d con tutte le librerie GL abilitate. Notare che devo ancora vedere quante dipendenze ha xorg-xserver.
Solo Mesa ha qualcosa come una ventina di dipendenze, che devono essere installate rigorosamente in ordine. Mesa dipende da un pacchetto (libXxf86vm) che dipende dalle librerie di X11. Ieri mi sono divertito come un cane.
Sta prendendo forma. Ho pensato di dare un'occhiata a Enlightenment (E): sebbene sia in versione pre-alpha vorrei provare a vedermelo un po' meglio.
DE fissi sono Xfce, Fluxbox e Afterstep. Applicazioni grafiche aspetteranno, prima voglio consolidare l'ambiente X e installare tool testuali.
Penso che cambierò nome. Un acronimo, non so se ricorsivo o meno. (Probabilmente si, ma non voglio sembrare un "copione". :sdentato: )
Notare che devo ancora vedere quante dipendenze ha xorg-xserver.
Due pagine!!! :2funny: :folle: :lgh:
-
Io intanto mi sto informando riguardo la possibile traduzione di Afterstep, sarebbe carino che la distro fosse una delle prime a dare la possibilità di installare AS anche in italiano...
-
sarebbe carino che la distro fosse una delle prime a dare la possibilità di installare AS anche in italiano...
sante parole
-
X funziona. E anche bene. Ho avuto un po' di noie all'inizio per configurazioni sbagliate, e soprattutto ho capito una cosa importante: XOrg e Xgl vanno compilati separatamente.
Xgl utilizza gli header nuovi di XOrg, ma alcuni frammenti di codice sono rimasti al 2006, o adirittura al 2005, con funzioni dal numero di argomenti insufficiente o eccessivo. Morale: devo fare un po' di tweaking del codice per tentare di compilare Xgl. Istruzioni sulla compilazione in rete sono rimaste agli stessi anni, e dicono quasi tutte cose che già so.
E se anche ci riesco, non è detto che funzioni. Però XOrg è venuto una bomba. Sul portatile va alla grande.
Ora devo capire come usare PAM per l'autenticazione di xdm (anche quello mi ha dato noie. Ho disabilitato PAM nella configurazione ed è partito liscio come l'olio), e personalizzare il login.
Prossima mossa, dopo aver studiato un pochetto X, è installare il primo DE. Ho comunque in progetto di studiare E, e Entrance mi ha favorevolmente colpito, insieme a Enlightenment stesso. E' diverso dai soliti KDE o GNOME.
Appena installo il primo DE ci do dentro con le applicazioni grafiche. Però devo ancora compensare alcune mancanze in terminale, e devo studiare l'intercambiabilità dei desktop environment. Per questo devo conoscere più che bene xdm.
-
xdm non mi è mai funzionato, non so come mai. Comunque non mettere xgl come sessione predefinita. Cioè, pensavo che xgl servisse solo come sessione per gli effetti grafici, se è così, compiz funziona per le ATI anche senza (d'altro canto xgl è molto buggato, a me collassava sempre, oltre ad essere terribilmente pesante)
-
Xgl è solo per studio. Se riesco a tirarlo su lo metto su, ma solo come testing. Xorg sarà il predefinito, comunque. :P
In ogni caso dovrò studiarmi pure compiz. Beryl l'aveo provato a suo tempo, ma non mi è rimasto molto simpatico. In quanto a collassare, a me non succedeva, seppure fosse molto lento (solo in fase di snapshot del desktop per effetti di rivoluzione ed altre menate, ma fose perchè nella Gentoo avevo tralasciato qualcosa), ma avevo visto chiare le potenzialità di Xgl.
xdm è bellino, basta configurarlo a dovere.
Appunto: sul portatile ho una schedina ATI Rage Mobility. Con il modulo caricato Xorg va straveloce. :sbav:
-
Qualche bugfix negli script di avvio, e ora Xorg vede bene tutta la tastiera. Segno che mi devo ancora studiare bene X.
-
nell'installazione, una cosa che ho notato essere meravigliosa nel VASM di Vector Linux è la possibilità di configurare il mouse, in modo che funzionino rotellina e tasti laterali, oltre che i normali tasti dx e sx
-
Basta far caricare i moduli giusti.
-
Afterstep up and running. Non è un DE semplice da imparare. Pure io mi devo fare una cultura.
(A dire la verità era up and running già due giorni fa, ma solo ora ho fatto il post.)
Anche se da solo non è che sia un granchè. Andrebbero installate altre cosette. In basso a destra ha una cosa molto simile alla Sidebar di Vista, solo che è molto meno avida di risorse.
A quanto ho capito non è possibile chiudere nè il Wharf nè il Pager se non killandoli, ma è una cosa alla quale ci si abitua presto, e poi hanno la loro utilità, specialmente su macchine veloci.
A proposito: Afterstep avviato subito dopo il boot del sistema porta ad un utilizzo di memoria totale di appena 99MB su 512. Era esattamente quello che volevo. :tup:
(Fluxbox consuma ancora meno, ma non ho ancora capito come ficcare un'immagine in background. Fluxbox è un'opera d'arte.)
-
QUI (http://wiki.ubuntu-it.org/AmbienteGrafico/FluxboxHowTo) puoi trovare un po' di informazioni, tra cui come impostare l'immagine di sfondo (è relativa a Ubuntu, ma va bene per tutto) se ho ben capito quali sono le tue necessità...
Afterstep io lo adoro, apparentemente può sembrare anche un po' troppo "vintage", ma io lo avevo aggiustato in un modo perfetto. Basta rendere le app in alto più piccole, e quella diventa tipo una barra mac, il winlist lo sposti in basso (o lo cacci, io mi accontentavo delle iconcine in basso a sx). Nel wharf, la sidebar insomma, ci sta benissimo licq, che si adatta alla perfezione (va aggiunto modificando l'apposito file wharf). Il pager lo avevo ridotto a quattro desktop, tutti quei desk sono esagerati per me... Comunque, il wharf è una potenza per tutte quelle app che sono dockabili...
-
Sto compilando E, sta venendo su bene.
E' che non pensavo ci fosse tanto casotto, dovrò perdere un po' di tempo per fare ordine. Devo fare decine di liste e mettere a posto i sorgenti.
-
sono ansioso di installare la tua distro, non appena torno in italia questa estate me la voglio provare
-
Userò entrance come login manager di default. Devo solo capire come mettere tutti i DE nella lista. :whustling:
-
in Ubuntu basta aggiungere i file in /usr/share/xsessions
Crei file tipo Afterstep.desktop, e poi dentro ci metti
[Desktop Entry]
Encoding=UTF-8
Name=Afterstep
Comment=
Exec=/opt/e17/bin/as
Icon=
Type=Application
O qualcosa di simile. Nelle guide di ubuntu dice che è per GDM, ma io l'ho usato anche per entrance e kdm...
-
Si, ho già fatto. Mo' ho un problema di timing di sessione. Dopo qualche secondo (15 più o meno) entrance esce e torna alla schermata di login, anche se non faccio nulla.
Quasi sicuramente ho settato male qualcosa.
-
Riorganizzazione in casa, sto facendo un gran casino per passare da un sistema all'altro. Non ho dimenticato nè il C nè la distro, però ho anche ricominciato a lavorare. Vado a giornata (mo' sono a casa per pasqua) e andrò un poco più a rilento. Appena riesco a far rilegare i libri riparto di buona lena (almeno spero). :biggrin:
Buon lavoro e buona pasqua a tutti. :smile:
-
Sto generando uno script che, avendo sorgenti, patch e partizioni formattate, mi crea automaticamente la toolchain base per lavorare sulla distro. E' una bella cosa, posso far partire lo script e dopo qualche ora tornare su e trovare la toolchain già pronta mentre faccio altro.
Mi sa che automatizzerò un sacco di cose, e dovrò per forza di cose pensare ad un semplice script che mi faccia da packet manager (seppur rudimentale, deve funzionare).
-
oppure creare un sistema tipo i makepkg di Arch o gli ebuild di gentoo, semplici file che compilano tutto il programma...
-
Adesso mi metto a generare due toolchain generiche a 32 bit e a 64 bit. Spero di riuscirle a fare più compatibili possibile.
Entro un mesetto dovrei avere due liveCD funzionanti, per 64 e 32 bit.
-
Fammi il regalo di (sperata) promozione agli esami di stato!!!
-
Hip Hip Hurra, appena torno a casa in italia, la prima cosa che faccio è darlo in pasto al mio PC fisso.
In bocca al lupo per l'esame franz :timido:
-
non vedo l'ora di provarla! :tup:
-
Attendo mooolto fiducioso!
-
Non fatevi strane idee, quando li upperò l'unica cosa che vi chiederò è di dirmi se vi funzionano. :whustling:
Meglio provare la base su più tipologie di PC possibili prima di cominciare a costruire il resto sopra.
Intanto sto avendo problemi con glibc, e questo può rallentare.
-
Non fatevi strane idee, quando li upperò l'unica cosa che vi chiederò è di dirmi se vi funzionano. :whustling:
Meglio provare la base su più tipologie di PC possibili prima di cominciare a costruire il resto sopra.
Intanto sto avendo problemi con glibc, e questo può rallentare.
Ma userai un sistema di pacchettizzazione? questo non mi è ancora chiaro, o darai tutto in mano a make install?
-
io ho una sola richiesta, che la sharkx linux sia integrata con l'installazione :folle:
-
Ma userai un sistema di pacchettizzazione? questo non mi è ancora chiaro, o darai tutto in mano a make install?
All'inizio avevo un'idea di packet manager tramite script molto "rozzo" ma funzionale, che installi un pacchetto da sorgenti. E' fattibile e anche abbastanza semplice, vedrò come si può fare.
io ho una sola richiesta, che la sharkx linux sia integrata con l'installazione
Appena arriva e funziona bene 100% che la butto su al posto di aMule :tup:
-
Sistemo gli script, li rendo stabili e poi passo all'aggiornamento del software. Quella sarà la base.
-
A quando un'alpha? sto fremendo :smile:
-
Appena riesco a capire come si fa un livecd. :sdentato:
-
Vabbè, dai. Per dirla tutta ho problemi con autogen. Anzi, ho problemi con l'aggiornamento del software.
GCC 4.3.0 e glibc 2.7 sembra che non stiano bene insieme. glibc entra in un loop infinito in fase di compilazione delle routine di controllo errori (errno.h) con gcc 4.3.0. Ho provato a compilare gcc 4.2.3 ma vuole autogen per il test, che è vitale. Allora vada di autogen. Compilo autogen, tutto a posto. Senonchè in fase di test GCC esce perchè autogen non riconosce la sintassi di un file di definizioni. "Sarà un problema di parser, quindi di librerie" mi dico.
OK, vado a cercare le librerie che mancano. libregex le installa glibc (2.5.1 funzionante) quindi non ho problemi. Manca libxml2. Lo installo e devo ricompilare autogen. D'accordo, nulla da dire.
Errori in complazione. Non ho ben capito l'origine dell'errore, ma del resto non sono neanche sicuro che compilando autogen il test di gcc riesca.
Morale, al posto delle 2.7 provo le 2.6, chissà che non vada bene. Sennò devo rivedere metà struttura, oppure lascio glibc e gcc così come stanno, ma un po' mi da fastidio.
Ma autogen comunque mi serve, quindi l'errore di compilazione lo dovrò traccare prima o poi.
Proverò a compilare glibc 2.5.1 con gcc 4.3.0. Se funziona vado per gradi.
Comunque ho pensato ad un nome. YaGLiB. Yet another Gnu/Linux Box.
Dapprima un po' mi dispiaceva perchè "cacchio, ha una forte assonanza con l'inglese "ugly". Poi mi sono detto "beh, ci sta a pennello, mica è bellissima, e comunque non lo sarà mai. E poi mi piacciono i giochi di parole".
La versione è una 0.01 (ho cominciato dalla 0.00) ed è ancora in test. Funziona ma non come voglio io. Forse è solo questione di pulizia.
Per il momento la faccio generica 32 bit, poi studierò una versione a 64 bit con lo stesso toolchain. Adesso che ho capito come si fa non mi ferma più nessuno. :angelnot:
Il kernel è una bomba, 163 moduli perfetti (di cui si e no me ne servono una ventina, ma è generica) script quasi a posto (mi manca solo da definire il trasferimento di funzione a /etc/init.d per altri software, lo devo fare da tempo ma non l'ho ancora fatto) e comunque già così ci si può costruire sopra un sistema GNU completo con X e tutto il resto, basta saperlo fare. Sul portatile ho una distribuzione ibrida basata su LFS 6.3 (solo toolchain) con un po' di cose. E' già un po' di tempo che ce l'ho.
Ha ha ha. La cosa più bella è che mi compila il supporto squashfs nel kernel. Mo' faccio ISO compresse di sola lettura, e lo metto di serie, è utilissimo.
squashfs è un filesystem compresso di sola lettura, indovinate un po', ideale per un liveCD.
:sdentato:
-
Un idolo. :oki:
-
Oh beh, ho ancora tantissime cose da imparare.
-
Oh beh, ho ancora tantissime cose da imparare.
Sarà,io ho appena passato 3 ore pestandomi con il template copiato da Wiki che dava dei problemi... :folle: :folle:
-
Grande!!!! ho l'acquolina in bocca :smile:
-
Niente da fare, devo tenere GCC 4.1.2 e Glibc 2.5.1. Qualsiasi altra versione mi dà problemi di stabilità nell'ambiente di compilazione (oltre al fatto che glibc >= 2.6 non mi si compila con nessun gcc), ed è una cosa che voglio assolutamente evitare.
Ho buttato su un po' di roba. Volevo aggiungere Midnight Commander -so che c'è gente che lo apprezza- ma ho bisogno delle Glib, e ho sempre avuto problemi con quelle.
Comunque la rete è stabile e si connette. Niente X ma c'è un buon browser testuale (elinks) e volendo posso installare amuled e amulecmd, però scordatevi la grafica, almeno finchè non risolverò il problema di glib, che alla fin fine è un problema di gestione di pacchetti.
In pratica è completa: ci sono GCC, Python e Perl; dhcpcd, ip, elinks e volendo posso mettere iptables per configurare netfilter. Ho installato tre editor: jed, nano e vi. Il kernel è un 2.6.24 stabile con supporto squashfs (la 2.6.25.4 non lo compilava) e ho messo anche Samba per la condivisione di file in rete. Quasi compelto, manca poca roba -a parte mc, poi ne parlo- e poi posso studiare un metodo per buttare tutto su livecd.
Revisione versione: 2.6.24-YaGLiB-0.02
Pacchetti, tra i più importanti, installati ad oggi:
-binutils 2.18
-GCC 4.1.2
-Glibc 2.5.1
-Kernel 2.6.24 patchato con squashfs
-sed 4.1.5
-e2fsprogs 1.40.2 (ma lo devo aggiornare bene con supporto devel-ext4)
-coreutils 6.12
-m4 1.4.10 (aggiornerò alla 1.4.11)
-ncurses 5.6
-perl 5.8.8
-python 2.5.2
-autoconf 2.61
-automake 1.10
-bash 3.2 (mi dà problemi... bah, risolverò in qualche modo)
-less 418 (quello si che dà problemi, non so perchè)
-bzip2 1.0.4 (devo aggiornarlo se trovo una versione più recente)
-diffutils 2.8.1 (idem)
-flex 2.5.33
-grub 0.97 (quello è e quello resta)
-groff 1.18.1.4 (lo reinstallerò o prenderò una versione più recente perchè ho problemi con la formattazione di pagine di manuale)
-gzip 1.3.12 (come diffutils)
-patch 2.5.4 (idem)
-openssl 0.9.8g
-elinks 0.11.4rc0
-dhcpcd 3.2.3
-which 2.19
-wget 1.11.4 (come patch)
-nano 2.0.7
-samba 3.2.0 (da configurare)
-jed 0.99.18
-pkg-config 0.23
più altre librerie.
A proposito delle glib. E' una libreria delicata che deve essere trattata con i guanti perchè da essa dipende una sana fetta di applicazioni grafiche e non (pasti pensare che le GTK si reggono sulle glib, e le GTK sono uno dei cuori pulsanti di X). Ho problemi nell'installazione.
Teoricamente potrei installarla direttamente nella gerarchia, ma poi aggiornarla o disinstallarla è un casino anche con la presenza di pkg-config, che tende sempre a nascondere i file di descrizione dei pacchetti nei posti più reconditi del sistema. Quindi devo trovare una soluzione semplice, veloce e che funzioni bene, e quindi mi sa proprio che quel packet manager vedrà la luce, magari non subito. Ma prima devo pensare bene a come identificare ogni singolo file per ogni pacchetto.
-
Credo che sfruttando un packet manager sarebbe possibile creare un sistema base e poi aggiornarlo e completarlo mano a mano...
-
Uhm, forse la definizione "packet manager" non è la più corretta. Potrebbe calzare meglio "packet tracker".
Fondamentalmente l'idea che ho in mente io è lasciare più libertà possibile all'utente, che può configurare e installare un pacchetto come vuole. L'unico compito del packet tracker è tenere in memoria quali file sono stati installati e dove, così l'utente può andarsi a vedere in qualsiasi momento la lista e agire di conseguenza. Si salvano anche le installazioni multiple. E alla fine del ciclo di vita del pacchetto, anche se la directory dei sorgenti è stata rimossa o ripulita, l'utente può sempre cancellare tutti i file che vuole solo dando in pasto un comando al packet tracker.
E' quello che ho in mente di fare con glib. Con una gestione simile tenere a bada pacchetti ribelli come quello è una passeggiata.
Poi c'è una questione di divisione dei file installati in "classi": configurazione, eseguibili, librerie, eccetera. Così se voglio aggiornare solo le librerie so dove sono, se voglio tenere la configurazione a portata di mano so che cosa devo fare.
L'unico problema che ancora non mi è chiaro è come tenere un database dei file.
-
Oh dai, che se va tutto bene entro pochi giorni dovrei avere un liveCD funzionante.
-
Oh dai, che se va tutto bene entro pochi giorni dovrei avere un liveCD funzionante.
Che dire? :tup: :tup: :tup: :tup: :tup: :tup: :tup: :tup: :tup: :tup:
Se ci riesco mi prenderò l'onore di provarlo... :timido:
-
Ho ho ho, ho fatto una prova con un initrd e ho incasinato la slamd... mo' non mi parte più. Tanto meglio, sono forzato a portare avanti il progetto con X. :P
Devo dare un'occhiata a klibc e fare delle prove con qualche initrd e filesystem squash.
-
Ho sfiorato il disastro giochicchiando con le klibc. Ho installato per sbaglio gli header in /usr/include (path assoluta) invece che in usr/include (path relativa)...
:mellow: :haha:
Morale: non mi si compilava più nulla.
Ho dovuto tirare fuori la toolchain e ricompilare, nell'ordine, binutils, glibc e gcc con opzioni particolari per rimediare al guaio che ho combinato. Ma alla fine dovrei avere risolto in modo rapido e indolore.
Da questo incidente ho imparato due cose utili:
1. Usare sempre chroot per manipolare librerie di sistema, e
2. usare DESTDIR con un opportuno --prefix per installarle dove voglio io.
Combini questi due dettagli e hai controllo assoluto sull'installazione di qualsiasi cosa.
Nota.
Appena sarà pronto il liveCD lo capirete subito perchè la versione in calce al primo post sarà la 0.10. :sdentato:
-
0.05
Installati alsa-lib, alsa-utils, pciutils e mpg123 per sentire gli mp3. Così almeno fino al rilascio del livecd potrò ascoltarmi Elio. :sdentato:
Devo vedere delle cosette nel kernel, si sta comportando in un modo che non mi piace. /proc/bus/usb è vuota e non dovrebbe esserlo. Purtroppo finchè il sistema non è stabile non posso rilasciare un bel niente. Forse è una conseguenza dello scherzetto di ieri, lo dovrò ricompilare come va fatto, questione di poco.
Catastrofi universali non ce ne sono state, almeno per oggi :biggrin:
Intanto metto a posto il kernel e gli script di avvio, poi vedrò di concentrarmi sulla live... spero :music:
Se ci riesco mi prenderò l'onore di provarlo...
Appena è pronto parlo con Raid e vedo di upparlo da qualche parte, a disposizione della board. Più gente vede se funziona su macchine differenti meglio è per me.
Non c'è X, ma è perfettamente funzionante (a parte pochi dettagli come il kernel e gli script di avvio... chiamali dettagli...). Ha connessione LAN automatica all'avvio; browser testuale (elinks); Midnight Commander, che so che a qualcuno piace e comunque può servire; download manager (wget); Samba per reti Windows <-> UNIX; sshd per farci connettere putty; supporto squashfs e ntfs-3g. C'è pure ext4dev, per il momento. mdadm per il supporto RAID software (e uno script che non funziona come dovrebbe, ma dovrei stare poco a sistemarlo :biggrin: ) e presto spero di installare lm_sensors e di creare uno script per la gestione della frequenza della CPU. Avendo il supporto di frequenza scalabile nel kernel è affare di poco.
-
Appena è pronto parlo con Raid e vedo di upparlo da qualche parte, a disposizione della board. Più gente vede se funziona su macchine differenti meglio è per me.
ottimo, complimenti. Intanto io inizio a pensare ad una soluzione tra i nostri server.
a Sourceforge ci hai pensato?
-
Sinceramente no :think:
-
By uploading code to SourceForge.net, you grant SourceForge a perpetual proprietary license.
non so cosa voglia dire, ma non mi convince...
-
Sennò metto su un serverino ftp a casa. Si può fare, lo gestisco io e l'unica cosa che devo pagare è il provider.
Sbaglio?
L'unico problema è che forse lo dovrei tenere acceso 24/7.
-
sì, questo è il prpblema. Ci sono tuxfamily, berlioz, GForge, launchpad (ma forse sono per le "ubuntate"). Sennò, io prenderei una bell'hosting gratuito e metterei la distro da scaricare su torrent (anche se non so quanto possa essere conveniente)
-
non so, tenere il pc accesso 24h si bevwe un bel po di corrente, mi faccio un giro di mail e chiedo i vari hosting, con magari la possibilità di mettere loro banner nella pagina di download. un idea l'avrei
-
Quasi quasi. Però intanto è meglio fare le cose "in famiglia" per non prendere cantonate leggendarie.
Ringrazio tutti per il supporto, comunque. :smile:
-
bhè certo, inizialmente tutto in famiglia, parlavo a lungo termine, per i primi passi ci attrezziamo tra noi :wink:
-
Bene, ecco la situazione.
La LiveCD sta per nascere, sebbene ci siano ancora dei bug a livello di console (non vengono riconosciute le vocali accentate, ignoro la causa :deluso: ), però è stabile e stracollaudata. Mancano solo gli script del live (li ho già abbozzati) e il kernel compilato ad hoc + initramfs. Ci sto mettendo più tempo del previsto, per molti motivi.
La cosa nuova è che ho appena acquistato (oggi) un Asus eeePc 7014G con Xandros preinstallata. E la Xandros, così com'è, mi fa veramente schifo. (Opinione personale. :sdentato: ) NON l'eeePc, è carinissimo. :wub:
Da smanettone quale sono mi dà fastidio il fatto che non ci sia un collegamento diretto con la console virtuale da X (long live alt+f2), e che abbiano scelto KDE al posto di DE più leggeri e (quasi) altrettanto intuitivi (Xfce in primis con un po' di hack). Tra le (molte) altre cose. Inoltre ho visto codice proprietario e forse so come liberarmene.
Il sistema, così come si compra, sembra più che altro un minuscolo portatile mascherato da palmare, e la cosa che più mi dà fastidio di tutte è che chi non è abbastanza smaliziato con GNU/Linux può facilmente scambiarlo per quest'ultimo. Perchè è GNU. Solo che i tool più importanti sono sepolti sotto un ambiente grafico quasi impenetrabile.
Va beh. Il punto è che ho una mezza idea di portare la mia distro su eeePc. Prima però dovrò conoscere a fondo la macchina, vedere quello che può e non può fare (un po' di cose le ho già viste e mi stanno assai simpatiche). Bisogna strippare un disastro di cose perchè lissù non ci stanno tutte. Inoltre bisogna usare cautela con l'SSD da 4G, perchè eccessive riscritture possono accorciarne la vita. Forse è per questo che usano unionFS.
Comunque. Prima cerco di finire il live testuale, e poi vedo di avvicinarmi a questo (ve l'immaginate la SharkLinux su eeePc che scarica in bomba via wireless direttamente sulla schedina SD da 8GB? Che beeeeeeello :viaggio: )
Anzi, mi sa che potrei concentrarmi su questo... :think:
Prima però devo fare almeno un live, per vedere come funziona, se non altro.
(Il nome della distro su eeePc deve essere un altro, non mi piacerebbe un nome così "ugly" come YaGLiB su un cosetto così carino :happy: )
-
La versione attuale è la 0.07 (faccio un salto alla 0.10 direttamente se mi funziona il live) e spero di aver finito i controlli di init per initramfs.
Ho praticamente dovuto ristudiarmi daccapo il sistema di boot di un sistema GNU/Linux a partire dal kernel (anzi: a partire da GrUB) il che, combinato con il lavoro e le altre cose, mi ha portato via un sacco di tempo e la prima beta è slittata paurosamente.
Adesso scrivo un po' di cose solo per fare lo sborone ( :sdentato: ) e per ripassare insieme a voi la teoria del boot di GNU/Linux. Tralascerò gli eventuali messaggi d'errore.
In sostanza abbiamo:
(saltando la parte del BIOS)
--GrUB (MBR) (stage 1)--
In MBR ci sono scritti degli offset che fanno riferimento a delle posizioni del disco rigido di sistema, che GrUB deve andarsi a leggere.
Nei primi 30k del disco immediatamente successivi all'MBR sta lo stage 1.5 di GrUB, che carica lo stage 2. Ed ecco che salta all'occhio l'interfaccia di GrUB. Quella non sta nell'MBR: sta sul disco di sistema.
Le opzioni di GrUB sono modificabili, oppure è possibile accedere alla shell di GrUB con un primitivo command line editing.
Una volta selezionato il sistema operativo GrUB confronta la selezione operata e va a vedersi la tabella degli offset delle partizioni per sapere dove andare a pescare il kernel da caricare. Dopodichè GrUB carica il kernel selezionato in memoria e successivamente passa il controllo ad esso.
--linux--
Quando Linux è caricato "si accorge" di essere caricato (perchè è GrUB che gli dice 'Ehi, sei tu che comandi adesso') e si sposta in un'altra area di memoria (non ricordo quale ma ricordo che è per un motivo preciso... che non ricordo qual è :sdentato: ). Poi comincia il lavoro del kernel.
Inizializza l'hardware, il processore, i bus, le porte (USB, COM, IEEE vari, PS/2 eccetera) e le periferiche (scheda video, scheda audio, monitor, controllori vari sulla scheda madre, e tutto quello che è supportato da Linux internamente. I moduli sono una cosa a parte ed è a questo che serve initramfs.
Ad un certo punto, quando ha finito di inizializzare il sistema, il kernel si chiede 'Dov'è init? Dov'è il processo 1, padre di tutti i processi?'
Nota: init può non essere un eseguibile, ma piuttosto uno script bash avviabile (quindi con flag +x per amministratore).
Ed ecco che cominciano le magagne. Ecco dove finisce il lavoro del kernel e comincia quello dell'amministratore del sistema.
--initramfs--
Nei sistemi con initramfs, al kernel è sempre accoppiato un file compresso (solitamente) che viene caricato in memoria: il kernel alloca dello spazio in memoria come tmpfs e ci carica l'archivio compresso initramfs. Il bello è che all'interno il kernel deve trovare tutto quello che gli serve per trovare la vera partizione di root, ovvero:
1-i moduli che, caricati, diano l'accesso in lettura a periferiche supportate dai moduli stessi;
2-eventuali moduli che danno l'accesso in lettura a determinati filesystem;
3-ulteriori moduli per attivare periferiche non direttamente supportate dal kernel;
4-un file eseguibile (script o binario) che generi processi, o che faccia qualcosa che porta avanti il processo di boot. Solitamente questo ruolo spetta ad init.
Poi l'eseguibile di boot deve:
0-creare i mountpoint per il montaggio dei filesystem (e qui c'è un altro discorso di udev, periferiche, ricerche e quant'altro)
1-montare il (o i) filesystem root reali;
2-liberare spazio in memoria (eventualmente, ma normalmente viene fatto);
3-spostare l'ambiente operativo dall'initramfs alla root reale;
4-cambiare i riferimenti (se necessario) delle librerie e/o dell'ambiente dalla initramfs alla vera root;
5-passare il controllo alla vera root;
6-passare il controllo al vero init, quello che sta nella vera root, con gli argomenti dell'init in initramfs, se ce n'erano.
A quel punto initramfs ha terminato il suo compito. Ma in mezzo c'è tutta una serie di verifiche e confronti. E per un liveCD è ancora peggio, perchè se hai un lettore ottico esterno devi fargli caricare moduli per la lettura di periferiche USB (come sd la stragrande maggioranza delle volte, ma anche sg o sr nel caso di masterizzatori). Poi devi dire al kernel di andare a cercare l'immagine del filesystem da caricare, e se non c'è, o se il blocco device non esiste, o se il blocco device non è un filesystem iso9660, o se il blocco device è un iso9660 ma non ha il filesystem compresso bisogna dire "aspetta, aspetta, come non detto", smontare il blocco (se è montato) e fargli rimontare il prossimo.
Un lavoro 'grosso' di riconoscimento, che è ingigantito dal fatto di voler far riconoscere al sistema un liveCD piuttosto che un'installazione su disco rigido.
Allora ho pensato ad una cosa furba. Ho messo tutti i moduli script all'interno di uno solo (init) e ho previsto la presenza di un flag kernel chiamato "live". Se è a 0 non è una live e procede il boot da disco. Se il flag è 1 è una live e deve fare tutta la serie di verifiche a cui ho accennato prima. Prendono due strade diverse.
Alla fine, qualsiasi sia stato il caso preso in considerazione, c'è una root montata ed un initramfs che viene messo da parte. C'è una rilocazione delle librerie e lo spostamento dell'ambiente operativo.
Per quanto riguarda il liveCD ho previsto due casi.
Caso 1: il computer ha più di 512 MB di memoria RAM.
"Semplicemente" vengono creati dei mountpoint tmpfs in RAM dove viene ricopiata l'immagine del filesystem in squashfs e, tramite unionfs, si viene a creare un ambiente di sola lettura che fa riferimento alla squash (bin, sbin, usr, lib, eccetera) e un ambiente in lettura e scrittura che riporta tutte le altre cartelle (tra cui home, var, tmp e altre).
Caso 2: il computer ha meno di 512 MB di memoria RAM.
In questo caso è appena un po' più semplice. Non viene creato mountpoint per la gestione della squash e il filesystem in sola lettura viene montato direttamente da CDROM. Il procedimento di creazione della root è analogo. Il risultato finale è esattamente equivalente, solo che non c'è il vantaggio della velocità della RAM nella lettura dei file di sistema.
Beh, ora non mi resta che provarla... e incrociare le dita.