View Full Version : sreadahead e boot in 5 secondi
Si sente molto parlare dei famosi 5 secondi per il boot completo di un netbook, ma a quanto sembra nessuno qui riesce a ottenere risultati così spinti.
Attualmente mi sono "piantato" sui 14 secondi incluso X, ma non ho ancora utilizzato l'opzione sreadahead per il caricamento asincrono dei file di boot.
In questo momento sto compilando il nuovo kernel 2.6.29-rc5.
L'ho patchato senza problemi con il file previsto per sreadahead-1.0, ho compilato l'eseguibile sreadahead e ora ho un po' di dubbi sul da farsi.
Pensavo di eseguire /sbin/sreadahead all'invio del sistema, ma non mi è chiaro perché dovrebbe essere più veloce, e dove andrà a scrivere il file package con l'elenco dei file da precaricare, né c'è scritto come fare per crearlo.
Qualcuno ha voglia di approcciare questo problema e trovare una soluzione cooperando?
Grazie
Sul forum di archlinux abbiamo provato a fare qualcosa in questo senso ma per ottenere tempi di quei livelli servono:
1) Hard disk SSD
2) Rivoluzionare gli script di avvio per parallelizzarli il più possibile
3) Sbudellare Xorg :D
Detto questo visto che impiego un 18 secondi ad avviare la distro con parecchi servizi non mi lamento e aspetto che i risultati della ricerca degli ingegneri intel vengano portati upstream. Purtroppo l'installazione che uso è quella su cui studio e lavoro quindi non posso permettere di perdere tempo in eventuali reinstallazioni da smanettamento forsennato ;-)
Attualmente sono riuscito ad ottenere 13 secondi di boot compreso l'ambiente grafico, ma vorrei scendere di almeno altri 5 secondi, quando ho tempo da dedicare alla cosa.
In questo momento, infatti, non ho ancora ottimizzato X, che di default impiega 7 secondi per avviarsi.
Per la cronaca, allego il bootchart del mio avvio.
Il mio PC è quello su cui lavoro, ed essendo portatile preferisco spegnerlo appena non mi serve.
Avere un boot time di 13 secondi è già qualcosa (contro gli oltre 30 che ci volevano prima che iniziassi a smanettarci un po').
Parallelizzando i servizi in rc5.d (quelli caricati al boot quando si entra in modalità grafica) ho recuperato altri 2 secondi, passando così a 11 secondi per il boot completo in modalità grafica.
http://www.radiorock.org/flx/altro/bootchart%2009-02-18_10:10.png
PS: Cerco sempre persone che hanno voglia di collaborare alla realizzazione di script di boot ottimizzati.
eclissi83
18-02-2009, 09:34
a parte la cosa interessante dello smanettamento per puro scopo di divertimento/conoscenza, non e' piu' comodo far funzionare correttamente lo stand-by/sospensione? personalmente uso un iBook G4 (per motivi di lavoro con Mac OS X) e non lo spengo quasi mai, lo trovo molto piu' comodo cosi'...
ciao
uso distro standard ceh arrivano al DE in 45 secondi ...
onestamente arrivarci in 30 secondi in meno potrebbe esser carino, ma in fin dei conti semi-useless specie se per arrivarci bisogna perderci mezze iornate di configurazione.
bhà...
:rolleyes:
a parte la cosa interessante dello smanettamento per puro scopo di divertimento/conoscenza, non e' piu' comodo far funzionare correttamente lo stand-by/sospensione? personalmente uso un iBook G4 (per motivi di lavoro con Mac OS X) e non lo spengo quasi mai, lo trovo molto piu' comodo cosi'...
ciao
Chiaramente, lo scopo è quello di imparare a gestire manualmente la configurazione dei processi più delicati di un sistema Linux.
Che poi dia risultati pratici è sicuramente tutto di guadagnato! ;)
La sospensione utilizza comunque la batteria, quindi è inutile se il portatile non può essere ricaricato fino al giorno dopo. Per questo è stata scartata di base.
L'ibernazione sarebbe una strada alternativa, ma riservare 2Gb di spazio per l'ibernazione su un netbook con disco da 8Gb che scrive a 6Mb/s è controproducente.
uso distro standard ceh arrivano al DE in 45 secondi ...
onestamente arrivarci in 30 secondi in meno potrebbe esser carino, ma in fin dei conti semi-useless specie se per arrivarci bisogna perderci mezze iornate di configurazione.
bhà...
:rolleyes:
Lo scopo di questo progetto è quello di definire un metodo di ottimizzazione dei sistemi Linux.
Già solo questo vuol dire che si vuole fare a meno delle distribuzioni. Esse hanno infatti la necessità di essere più generiche possibili, e quindi nascono per scopi diametralmente opposti a quello di cui stiamo parlando qui.
Se non ti serve un sistema ottimizzato è logico che scegli una distro già bella e pronta! :)
Chiaramente, lo scopo è quello di imparare a gestire manualmente la configurazione dei processi più delicati di un sistema Linux.
Che poi dia risultati pratici è sicuramente tutto di guadagnato! ;)
La sospensione utilizza comunque la batteria, quindi è inutile se il portatile non può essere ricaricato fino al giorno dopo. Per questo è stata scartata di base.
L'ibernazione sarebbe una strada alternativa, ma riservare 2Gb di spazio per l'ibernazione su un netbook con disco da 8Gb che scrive a 6Mb/s è controproducente.
Veramente un portatile con una buona batteria dura dei giorni in sospensione, e anzi per pause di lavoro relativamente brevi (sicuro attorno alla mezz'ora) si consuma meno batteria a sospenderlo che a spegnerlo e riaccenderlo.
ma che distribuzione usi?
comunque ho notato dei processi che iniziano per k.
secondo me devi passare a qualcosa di più leggero. non dico una openbox ma un lxde o un xfce
ma che distribuzione usi?
comunque ho notato dei processi che iniziano per k.
secondo me devi passare a qualcosa di più leggero. non dico una openbox ma un lxde o un xfce
Nessuna distribuzione, ho compilato ogni singolo programma da zero.
I processi che vedi con la K sono relativi al kernel e sono parte del sistema operativo.
Nello specifico "kthreadd" è il demone dei thread del kernel, mente "klogd" è il demone del log del kernel.
Come desktop environment c'è XFCE, e Slim è l'interfaccia per il login grafico.
puoi eliminare slim facendo partire direttamente xorg, questo dovrebbe farti recuperare qualche decimo :D
Nessuna distribuzione, ho compilato ogni singolo programma da zero.
bhe, complimenti!
pensi che i tuoi risultati possono essere riprodotti su arch?
ha un solo script di init e dovrebbe essere facilmente configurabile.
eclissi83
18-02-2009, 21:54
Chiaramente, lo scopo è quello di imparare a gestire manualmente la configurazione dei processi più delicati di un sistema Linux.
Che poi dia risultati pratici è sicuramente tutto di guadagnato! ;)
ok..
La sospensione utilizza comunque la batteria, quindi è inutile se il portatile non può essere ricaricato fino al giorno dopo. Per questo è stata scartata di base.
sinceramente, mi capita di avere il portatile in standby anche per 2 giorni (quando la batteria era "buona" arrivavo a 4 giorni di standby) per poi doverlo ricaricare necessariamente... pero' boh dipende dalla batteria e dalla gestione della stessa..
L'ibernazione sarebbe una strada alternativa, ma riservare 2Gb di spazio per l'ibernazione su un netbook con disco da 8Gb che scrive a 6Mb/s è controproducente.
non avevo pensato a questo aspetto della cosa...
bhe, complimenti!
pensi che i tuoi risultati possono essere riprodotti su arch?
ha un solo script di init e dovrebbe essere facilmente configurabile.
Sì, sicuramente arch è la distribuzione che meglio si può adattare a questo lavoro.
Psycotic
19-02-2009, 10:00
stai gia' utilizzando sysvinit-ng?
un'altra cosa che potrebbe velocizzare, ma nn so di qanto.. forse qalche millisecondo potrebbe essere cambiare la shell, perche' la bash e' un po' esosa.
Psycotic
19-02-2009, 10:26
Per quanto riguarda sreadahead ho trovato questo per la lista dei file
find / -type f \( -fstype ext3 -o -fstype rootfs \) > lista.packed.new
/sbin/sreadahead-pack lista.packed.new
Ma io dico... Questo genera un file con dentro tutta la root, anzi dipende come fai le partizioni direi "tutti i file dell'hd" e questo non ha senso!!!! almeno che sreadahead-pack capisca qale siano i file inutili x lui..
Ma cmq e' vero.. c'e' un po' di confusione su quest'argomento.. io nel file lo popolerei con tutto quello che trovi dentro gli script di init e ovviamente le librerie..
Bah.. facci sapere se serve a qualcosa!!
Il nuovo sreadahead non ha bisogno di creare la lista (il file pack) a mano perché se non presente lo genera in modo automatico, e lo usa dall'avvio successivo in poi.
In questo modo, grazie a una minima modifica in un file del kernel (inclusa nel nuovo sreadahead), cataloga solo i file effettivamente necessari al boot.
Quel comando è per la vecchia versione, infatti specifica ext3 visto che a differenza di quello attuale non funzionava su ext2.
PS: non sto utilizzando sysvinit-ng perché l'esercizio è mirato all'ottimizzazione degli script di boot e questa comprende già la parallelizzazione dei processi di boot.
In ogni caso mi sono fermato a 11 secondi di boot in ambiente grafico. Devo dire che rispetto ai 35-40 necessari prima dell'intervento è già un ottimo guadagno! :)
nel forum di gentoo si consigliava di usare sh (o busybox :D ) al posto di bash, se usi initscripts. Hai il "problema" di non poter usare i bashismi negli initscripts :D
Altra cosa... sempre su gentoo si sta sviluppando openRC, che (se non ho capito male) al posto degli script usa roba compilata in C (con config files esterni ovviamente). La differenza si sente rispetto ai classici scripts, ma è ancora abbastanza testing.
Buon lavoro!
nel forum di gentoo si consigliava di usare sh (o busybox :D ) al posto di bash, se usi initscripts. Hai il "problema" di non poter usare i bashismi negli initscripts :D
Altra cosa... sempre su gentoo si sta sviluppando openRC, che (se non ho capito male) al posto degli script usa roba compilata in C (con config files esterni ovviamente). La differenza si sente rispetto ai classici scripts, ma è ancora abbastanza testing.
Buon lavoro!
Grazie per le segnalazioni, molto interessanti.
Busybox è un'idea, ma vorrei avere un sistema tradizionale che però si avvi in tempi molto rapidi.
Usare SH al posto di BASH potrebbe dare risultati, magari proverò a vedere. Mi preoccupa solo l'uso massiccio di funzioni tipicamente BASH all'interno degli script di init (ad esempio codici come ${var##.conf} che a replicare su SH si finisce per peggiorare la situazione).
L'init in C invece mi sembra un'ottima idea. A questo punto ero arrivato a pensare che l'ideale fosse avere una sola coppia di script S00 e K00 per ogni runlevel, che caricassero tutti i processi tradizionali in maniera più parallela possibile.
Si sa che il C è più veloce della BASH, quindi potrebbe essere un'ulteriore passo in avanti per questo tipo di approccio a file singolo.
Oggi provo qualcosa e vi faccio sapere.
Grazie!
Psycotic
20-02-2009, 09:01
come shell intendevo la "dash" perche' lascia la shell pulita e profumata..
No scherzo la dash spesso la si trova anche nei cd di installazione delle distribuzioni, spesso anche nei router viene usata come shell.
Cmq ho comprato l'eeepc 901, ho installato eeebuntu e ci mette 33sec x avviarsi.... Mi sa che ho molto da fare adesso per raggiungere il tuo record.
Anzi come hai fatto per parallelizzare i servizi con sysvinit classico?
Hai per caso settato CONCURRENCY=shell su /etc/default/rcS ???
E per udev che ci mette una maternita per montare 4 moduli?
Per adesso le uniche modifiche che ho fatto sono state utilizzare la ram per il filesystem dello scarico archive di apt e x la cache di firefox.
La shell più bianca che c'è (la dash :D ) non l'avevo presa in considerazione.
Di fatto potrebbe essere un'idea, ma penso che realizzare un'applicazione di init in C sia più performante di qualsiasi shell sequenziale.
Più che parallelizzare i processi direi di averli resi asincroni.
Ho individuato una linea sequenziale per ogni ramo di applicazioni, e ho fatto partire ciascun ramo, che è sequenziale, parallelamente agli altri rami da cui non ha dipendenze.
Sul desktop il boot è sceso a meno di 6 secondi, mentre sul netbook è rimasto a 11, che è comunque più che soddisfacente visto che si intende 11 secondi dall'accensione alla possibilità di inserire utente e password già sotto X.
udev lo sto ancora usando, ma ho tolto qualsiasi richiesta di moduli, perché ho compilato ogni driver nativamente nel kernel (così si risparmia tempo all'avvio). Il prossimo passo sarà di memorizzare i device e saltare del tutto l'udev al boot, (tanto l'hardware non cambia ad ogni avvio) facendo in modo che udev sia caricato solo quando attacco una periferica esterna.
Psycotic
25-02-2009, 10:10
Effefttivamente non avevo letto bene che ricompilavi il kernel..
Daltronde nn mi sembra ci siano alternative, ho smembrato gli script x udev cio' guadagnato circa 5 secondi, ma sembra nn ci sia speranza l'unica e' ricompilare..
Piu' che altro non volevo compilare perche' volevo fare uno script che velocizzasse il boot, solo che se ricompili un kernel allora non sono daccordo col farlo in automatico..
La verita' e' che tutti ne parlano di velocizzare ma poi in effetti ognuno dice la sua...
Visto che sei cosi' volenteroso se hai un sito perche' nn avvii un progetto? sarebbe interessante secondo me...
Approposito non ho capito come hai parallelizzato gli script su rcS
Psycotic
25-02-2009, 10:17
approposito che i/o scheduler stai usando x i dischi ssd?
approposito che i/o scheduler stai usando x i dischi ssd?
Attualmente CFQ. Hai dei suggerimenti in merito?
-
Gli script rcS sono sequenziali, quindi vengono caricati uno dopo l'altro.
Per ottimizzare non basta farli caricare tutti insieme, perché alcuni dipendo dal caricamento precedente di altri.
Invece di parallelizzare tutti gli script, è stato più logico individuare le sequenze obbligate (ad esempio non puoi caricare l'udev prima di aver montato i dischi virtuali del kernel).
Infine, una volta individuato l'ordine e le dipendenze, ho fatto partire tutte le sequenze indipendenti tra loro in contemporanea.
PS: Che intendi con "avviare un progetto" ? Questo thread mi sembra già una specie di progetto al quale chiunque può contribuire, come stai facendo tu.
Che livello di conoscenza bisogna avere per com inciare con questo lavoro?
Approfondito ok.... Ma quanto approfondito?
Io di Linux ho una conoscenza non proprio profondissima... Ma vorrei imparare e passare al 80% di utilizzo esclusivo.. (Il rimanente 20 % così suddiviso: 19%MacOS(Mi ci trovo troooppo bene... XD) e 1% Win(Giochi rulez.. XD))
Mi sto anche studiando il C per ovvi motivi di università... (Già mi sento in colpa per non conoscerlo in partenza..)
Mi chiedevo quindi se posso sfruttare questo "processo di speed-up del boot" per conoscere meglio ed eviscerare Linux....
Che livello di conoscenza bisogna avere per com inciare con questo lavoro?
Approfondito ok.... Ma quanto approfondito?
Io di Linux ho una conoscenza non proprio profondissima... Ma vorrei imparare e passare al 80% di utilizzo esclusivo.. (Il rimanente 20 % così suddiviso: 19%MacOS(Mi ci trovo troooppo bene... XD) e 1% Win(Giochi rulez.. XD))
Mi sto anche studiando il C per ovvi motivi di università... (Già mi sento in colpa per non conoscerlo in partenza..)
Mi chiedevo quindi se posso sfruttare questo "processo di speed-up del boot" per conoscere meglio ed eviscerare Linux....
Sicuramente bisogna avere delle conoscenze di base sui sistemi Linux, nello specifico non si dovrebbero avere dubbi sul significato di questi termini: kernel, moduli, script, rc, runlevel, login, e X.
Poi è chiaro che contribuire al progetto vuol dire anche semplicemente provare ad utilizzare le idee degli altri, perché i riscontri di chi prova a fare quello che viene suggerito sono comunque molto importanti.
Io non sono affatto esperto in C, e per fortuna non è propriamente necessario saperlo programmare per migliorare il boot del sistema ;) Anche se può aiutare, come si stava pensando qualche post fa...
Quello che desidero ottenere da questo "progetto", se così vogliamo chiamarlo, è un sistema personalizzato e ottimizzato, in grado di fare tutto quello che mi occorre nel minor tempo possibile, senza sprecare risorse. (Non a caso sto lavorando su un piccolo netbook...)
Bene. Cosa può esserti utile per iniziare a fare delle prove?
Sicuramente bisogna avere delle conoscenze di base sui sistemi Linux, nello specifico non si dovrebbero avere dubbi sul significato di questi termini: kernel, moduli, script, rc, runlevel, login, e X.
Io non sono affatto esperto in C, e per fortuna non è propriamente necessario saperlo programmare per migliorare il boot del sistema ;) Anche se può aiutare, come si stava pensando qualche post fa...
Quello che desidero ottenere da questo "progetto", se così vogliamo chiamarlo, è un sistema personalizzato e ottimizzato, in grado di fare tutto quello che mi occorre nel minor tempo possibile, senza sprecare risorse. (Non a caso sto lavorando su un piccolo netbook...)
Bene. Cosa può esserti utile per iniziare a fare delle prove?
Per quanto riguarda kernel, moduli, script, runlevel, login, e X non penso proprio di avere problemi a comprendere il loro significato, mi sfugger però "rc"...
Io inizierei a lavorare sul mio MBp (e penso anche sul mio pc fisso), che distro mi consigli? Leggevo sopra che si parlava di ArchLinux, è una distro che mi è sempre interessata e che piu di una volta mi hanno consigliato, ma vuoi per un motivo vuoi per un altro non ho mai provato...
Psycotic
25-02-2009, 18:11
Quello che ho visto che consigliano di usare come i/o scheduler x ssd e' il noop, non perche' sia stato progettato x questo tipo di device ma perche' e' lo scheduler piu' semplice che c'e', e quindi meno pesante da gestire per la cpu.
Di default come sai si usa CFQ perche' bisogna scrivere i dati in modo intelligente x evitare che la testina faccia il ballo del qua qua.
Essendo che su SSD non ce rotazione di alcunche' si preferisce scrivere direttamente tipo una FIFO.
Vedrai mai la differenza? secondo me no.. Ma la teoria e' importante.
Per quanto riguarda il progetto che ti dicevo secondo me usare un forum non e' una buona soluzione, innanzitutto perche':
1) Se nessuno scrive poi ti devi andar a cercare dove cacchio e' finita la discussione.
2) se trovi la discussione devi leggere tutto per vedere se c'e' la parte che ti interessa.
3) vabbe basta critiche, semplicemente non lo trovo uno strumento adatto.
Quindi niente, non credo di partecipare.
Mhm.. be, per me l'ssd è ancora un pochino (XD) troppo costoso.. ^_^
Ho pensato che anche DSL potrebbe essere una base...
La domanda attuale dunque è: Da che distro parto per il "progetto"?
Ciao!
Mhm.. be, per me l'ssd è ancora un pochino (XD) troppo costoso.. ^_^
Ho pensato che anche DSL potrebbe essere una base...
La domanda attuale dunque è: Da che distro parto per il "progetto"?
Ciao!
Qualsiasi distribuzione si presta ad essere risistemata e ottimizzata, ma più è complessa o preorganizzata (tipo Ubuntu) e meno conviene modificarla.
Io, anche perché mi è valso da approfondimento sull'argomento, ho compilato la mia distribuzione partendo da zero, seguendo le istruzioni preliminari che ho trovato su http://www.linuxfromscratch.org/
Se vuoi partire da qualcosa di già pronto per questo progetto ti consiglio Gentoo e ArchLinux.
PS: Si parla di SSD perché il lavoro è su un Asus Eeepc che ha l'SSD di base.
Quello che ho visto che consigliano di usare come i/o scheduler x ssd e' il noop, non perche' sia stato progettato x questo tipo di device ma perche' e' lo scheduler piu' semplice che c'e', e quindi meno pesante da gestire per la cpu.
Di default come sai si usa CFQ perche' bisogna scrivere i dati in modo intelligente x evitare che la testina faccia il ballo del qua qua.
Essendo che su SSD non ce rotazione di alcunche' si preferisce scrivere direttamente tipo una FIFO.
Vedrai mai la differenza? secondo me no.. Ma la teoria e' importante.
Infatti credo che non vedrò differenze, però vedo una logica interessante nella scelta, quindi credo che comunque proverò questo noop.
Per quanto riguarda il progetto che ti dicevo secondo me usare un forum non e' una buona soluzione, innanzitutto perche':
1) Se nessuno scrive poi ti devi andar a cercare dove cacchio e' finita la discussione.
2) se trovi la discussione devi leggere tutto per vedere se c'e' la parte che ti interessa.
3) vabbe basta critiche, semplicemente non lo trovo uno strumento adatto.
Quindi niente, non credo di partecipare.
Mi spiace, ma realizzare un sito per questo progetto sarà una scelta sensata solo quando saremo almeno 2-3 persone fisse, perché col lavoro non ho il tempo materiale di dedicarmici completamente.
Mi spiace, ma realizzare un sito per questo progetto sarà una scelta sensata solo quando saremo almeno 2-3 persone fisse, perché col lavoro non ho il tempo materiale di dedicarmici completamente.
guarda, anche io sono interessato ma nelle ultime settimane non ho avuto un minuto libero. :muro:
é da un pó che voglio sporcarmi le mani per avere distro ottimizzata...
Qualsiasi distribuzione si presta ad essere risistemata e ottimizzata, ma più è complessa o preorganizzata (tipo Ubuntu) e meno conviene modificarla.
Io, anche perché mi è valso da approfondimento sull'argomento, ho compilato la mia distribuzione partendo da zero, seguendo le istruzioni preliminari che ho trovato su http://www.linuxfromscratch.org/
Se vuoi partire da qualcosa di già pronto per questo progetto ti consiglio Gentoo e ArchLinux.
PS: Si parla di SSD perché il lavoro è su un Asus Eeepc che ha l'SSD di base.
Giusto per capire, quanto ci hai messo a fare la tua distro? È accessibile o complicato?
In ongi caso non sarei mai partito da ubuntu et simila.. Capisco anche io che sia abastnaza complicato.... Beh vedo un po'... Ma rc che significa in fine?
Ah, ecco perche c'era di mezzo l'ssd.. :D
Se segui passo-passo il sito che ti ho linkato è veramente semplice. Il link alla pagina con le istruzioni dettagliate per l'ultima versione disponibile è questo: http://www.linuxfromscratch.org/lfs/view/development/
Vedrai che se leggi l'inglese è davvero facile.
Il tempo che ci vuole dipende... è lungo se compili su un computer lento. L'ideale è compilare su un'architettura equivalente ma più performante (io ho creato una macchina virtuale equivalente all'Eeepc su un core duo. Compilo lì e copio sul netbook).
L' rc (meglio detto rc.d) è il metodo System V per eseguire in automatico degli script quando si passa da un runlevel all'altro. Ci sono quindi diversi rc associati o ogni runlevel, che vengono eseguiti in base al valore al boot, al login, all'accesso della modalità grafica, al riavvio, ecc.
iridio191
28-02-2009, 01:25
E' da tempo che cerco di ottimizzare/velocizzare l'avvio del mio
sistema debian.
Ed adesso son capitato su questo topic
qualche domanda:
Che kernel hai utilizzato? configurazione? patch?
Per l'avvio hai usato gli rc script di lfs o li hai riscritti?
tutti quei tentativi sono solo su eeepc con ssd o li hai provati anche su pc/hard disck tradizionale?
Ma sopratutto cosa hai fatto ad udev?
Vorrei provar a riprodurre i tuoi risultati.
E' da tempo che cerco di ottimizzare/velocizzare l'avvio del mio
sistema debian.
Ed adesso son capitato su questo topic
qualche domanda:
Che kernel hai utilizzato? configurazione? patch?
Per l'avvio hai usato gli rc script di lfs o li hai riscritti?
tutti quei tentativi sono solo su eeepc con ssd o li hai provati anche su pc/hard disck tradizionale?
Ma sopratutto cosa hai fatto ad udev?
Vorrei provar a riprodurre i tuoi risultati.
Benvenuto!
Rispondo subito...
Il kernel (come si vede in firma) è il 2.6.29-rc5 (essendo rc non servono patch). Tutti i driver necessari all'Eeepc sono già inclusi, quindi è bastasto attivarli e farglieli compilare nel bzImage.
Gli script di avvio li ho riscritti ma partendo da quelli di LFS.
Ho due sistemi equivalenti a quello dell'Eeepc: un desktop e un virtualizzato (che uso per i test più critici e delicati).
Ad UDEV non ho ancora fatto niente.
Per avere questi risultati bisogna determinare un iter logico di configurazione. Credo che all'inizio della prossima settiamana butterò giù un elenco pratico dei passaggi fatti finora.
iridio191
28-02-2009, 13:19
Per avere questi risultati bisogna determinare un iter logico di configurazione. Credo che all'inizio della prossima settiamana butterò giù un elenco pratico dei passaggi fatti finora.
allora aspetterò con ansia!
Comunque ho diumneticato di scrivere che io non sono su eeepc bensì
su portatile core 2 duo 1.73 Ghz e disco sata tradizionale.
zephyr83
28-02-2009, 17:33
a me è sempre interessata questa cosa ma nello specifico come funziona? io ho un acer one con ssd cesso intel e linpus che si avvia in 18 secondi....ma è un barbatrucco secondo me perché il desktop compare entro 20 secondi ma poi ce ne vogliono altrettanti per essere effettivamente connessi a internet! a sto punto che senso ha caricare i vari servizi DOPO? in ogni caso bisogna aspettare!
con il tuo lavoro i vari servizi vengono caricati tutti prima? dopo i tuoi 10 secondi (mi sembra che sei riuscito a scendere ancora) sei già subito connesso alla rete o devi aspettare?
Inoltre anziché crearsi e compilarsi da zero una distro non conveniva usare gentoo che è già bella pronta e va "solo" ricompilat? :stordita: sulla tua distro usi anche pacchetti precompilati e un gestore di pacchetti?
a me è sempre interessata questa cosa ma nello specifico come funziona? io ho un acer one con ssd cesso intel e linpus che si avvia in 18 secondi....ma è un barbatrucco secondo me perché il desktop compare entro 20 secondi ma poi ce ne vogliono altrettanti per essere effettivamente connessi a internet! a sto punto che senso ha caricare i vari servizi DOPO? in ogni caso bisogna aspettare!
con il tuo lavoro i vari servizi vengono caricati tutti prima? dopo i tuoi 10 secondi (mi sembra che sei riuscito a scendere ancora) sei già subito connesso alla rete o devi aspettare?
La rete viene caricata durante l'avvio del gestore grafico. In genere nel tempo che faccio il login la connessione mi risulta già attiva.
Inoltre anziché crearsi e compilarsi da zero una distro non conveniva usare gentoo che è già bella pronta e va "solo" ricompilat? :stordita: sulla tua distro usi anche pacchetti precompilati e un gestore di pacchetti?
Compilarmi tutto da zero mi è servito per apprendere più a fondo la struttura di un sistema Linux: l'ho fatto per scelta a priori.
Attualmente non uso programmi precompilati tranne Firefox e OpenOffice, che vengono forniti pronti per x86 in maniera molto pulita e quindi accettabile.
Non usando pacchetti non uso nemmeno un gestore.
Attualmente non uso programmi precompilati tranne Firefox e OpenOffice,
firefox non so, ma leggevo che openoffice ricompilato con le ottimizzazioni per il processore/sistema/ecc sia più veloce (ad avviarsi sicuramente).
Ti ammiro per essere riuscito a costruire lfs, ma penso che con gentoo avresti fatto parecchio prima (compilazione "assistita", dipendenze già risolte - sia per i pacchetti che per i script di avvio :D, potresti disporre di openRC - gli "script in C", ecc ecc). Certo lo spazio su disco richiesto dalla distro è un problema abbastanza importante....
(Vedilo non come critica, ma come un tentativo blando di deviarti su qualcosa che possa tornare utile a tutti: )
Vista la tua competenza potresti contribuire a qualche progetto già esistente e avviato, piuttosto che fare una cosa a sè stante.... ;)
firefox non so, ma leggevo che openoffice ricompilato con le ottimizzazioni per il processore/sistema/ecc sia più veloce (ad avviarsi sicuramente).
Openoffice è sicuramente più rapido se preso da sorgenti, ma in quel caso il tempo richiesto per compilare su un hardware come quello di un Eeepc era veramente eccessivo (oltre 4 ore!).
Ti ammiro per essere riuscito a costruire lfs, ma penso che con gentoo avresti fatto parecchio prima (compilazione "assistita", dipendenze già risolte - sia per i pacchetti che per i script di avvio :D, potresti disporre di openRC - gli "script in C", ecc ecc). Certo lo spazio su disco richiesto dalla distro è un problema abbastanza importante....
(Vedilo non come critica, ma come un tentativo blando di deviarti su qualcosa che possa tornare utile a tutti: )
Come dicevo, costruire un sistema da zero era uno degli obiettivi del lavoro.
Se avessi voluto andare meno a fondo col sistema avrei certamente utilizzato Gentoo o ArchLinux.
Vista la tua competenza potresti contribuire a qualche progetto già esistente e avviato, piuttosto che fare una cosa a sè stante.... ;)
Volendo, sì. Di quale progetto parli, per esempio?
Psycotic
16-03-2009, 14:15
ultimamente ho avuto un'altro po' di tempo x dedicarmi al boot dello scarafaggio.
Sono arrivato facilmente ai 9secondi senza usare sreadhaead e senza eliminare del tutto udev.
Vabbe oramai sta discussione mi pare morta, cmq allego il bootchart.
ultimamente ho avuto un'altro po' di tempo x dedicarmi al boot dello scarafaggio.
Sono arrivato facilmente ai 9secondi senza usare sreadhaead e senza eliminare del tutto udev.
Vabbe oramai sta discussione mi pare morta, cmq allego il bootchart.
Ciao, il bootchart che hai allegato è praticamente illeggibile. Puoi pubblicarlo un po' più grande, o magari inserirlo su un host per immagini da cui scaricarlo a grandezza naturale?
Grazie.
PS: La discussione non è morta. Sto "rivoluzionando" il boot del mio sistema attraverso uno script rc completamente nuovo. Ieri ho terminato il programma, che è in PERL, e questa settimana conto di realizzare la funzione per tradurre un sistema attuale già esistente di tipo SysV nel sistema che ho realizzato.
Fatto ciò presento il progetto su SourceForge e riprendo la discussione su questo thread.
Psycotic
17-03-2009, 11:09
Ok effettivamente gimp ed io non siamo molto compatibili..
Stavolta si dovrebbe vedere meglio
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.