slacky.eu

http://www.gadgetblog.it/post/6276/eeep ... -5-secondi

Chi ne sa di più sa dire se questa impresa è ancora in alfa-beta o è realta?
E se è portabile su slackware?
Grazie

l'articolo originale (tra l'altro linkato dal link che hai postato) spiega come funziona il tutto: http://lwn.net/Articles/299483/
è portabile su slackware? no. almeno: non immediatamente, a parte la necessità di introdurre il supporto per readahead (che magari esiste già, io non ho controllato) la differenza principale tra la Fedora e la Moblin impiegate per l'hack e la Slackware è che quest'ultima utilizza molto più pesantemente gli script di shell come programmi di init (rc.M e rc.S in primis) e questi sono inerentemente più lenti (la shell spawna un sottoprocesso ogni volta che lo script va a chiamare qualsiasi cosa che non è builtin).
Questo non significa che non si possa accellerare la slack, solo che il limite dei 5 secondi è arduo da raggiungere per come stanno adesso le cose, magari i 7 opppure gli 8 no

venerdi_12 ha scritto:http://www.gadgetblog.it/post/6276/eeep ... -5-secondi

Chi ne sa di più sa dire se questa impresa è ancora in alfa-beta o è realta?
E se è portabile su slackware?
Grazie

Senti io ho fatto qualche ricerca.
Forse non potrà aiutarti molto, ma magari questo piccolo trucco su gentoo può essere usato pure su slackware...
prova un pochetto e fammi sapere...

ti do il link

http://www.newdigest.com/tecnologia/dim ... di-gentoo/
o direttamente il wiki
http://gentoo-wiki.com/TIP_Speed_up_your_boot_time

Comunque credo che la chiave di volta sia l'avvio contemporaneo (parallelo) dei processi in altri articoli.
Dai un occhiata anche qui
http://www.linux.com/articles/53613

Ho visto che ulteriore miglioramento si può avere se si ritarda l'avvio invece di alcuni processi più pesanti a favore di processi più leggeri, oltre che l'ovvio sfrondamento di processi inutili



e per una visione più completa guarda questo spot
http://www.youtube.com/watch?v=y40Z1mvGOt8

E fare un articolo da aggiungere nel wiki specifico per Slackware?
Io purtroppo in questo periodo non posso (e forse non sarei in grado) però potrebbe essere utile...

Visto che si parla di wiki, vi invito a controllare il materiale di quei link che vi ho passato, magari chi è più in gamba di me saprà dirmi se quei trucchetti possono essere portati pure su slackware.

Ciao a tutti,

approfitto della apertura di questo topic per dirvi un problema che ho riscontrato, e che riscontro ogni volta che avvio il notebook.
Dopo che mi compare lilo, e mi avvio il kernel, il notebook rimane una decina di secondi senza dare segni di vita.
Dopo questo lasso di tempo, si avvia normalmente il sistema operativo.
Questi problemi me li da, vado a memoria, da quando utilizzo la serie del kernel 2.6.x ... Con la Slackware 11, ad esempio non avevo di quesi problemi sino a quando non avevo impostato il kernel 2.6.17

Vorrei sapere solo se è possibile risolvere il mio problema.

Grazie

kernel89 ha scritto:Ciao a tutti,

approfitto della apertura di questo topic per dirvi un problema che ho riscontrato, e che riscontro ogni volta che avvio il notebook.
Dopo che mi compare lilo, e mi avvio il kernel, il notebook rimane una decina di secondi senza dare segni di vita.
Dopo questo lasso di tempo, si avvia normalmente il sistema operativo.
Questi problemi me li da, vado a memoria, da quando utilizzo la serie del kernel 2.6.x ... Con la Slackware 11, ad esempio non avevo di quesi problemi sino a quando non avevo impostato il kernel 2.6.17

Vorrei sapere solo se è possibile risolvere il mio problema.

Grazie

Hai delle schede di rete configurate tramite DHCP in rc.inet1.conf?
Se sì, leggi questo post

no no, non ho delle schede da configurare.
Forse non mi sono spiegato bene:
il notebook sembra spento non durante o dopo che carica tutti i demoni ecc, ma subito dopo che lilo carica il kernel.

kernel89 ha scritto:no no, non ho delle schede da configurare.
Forse non mi sono spiegato bene:
il notebook sembra spento non durante o dopo che carica tutti i demoni ecc, ma subito dopo che lilo carica il kernel.

O prima di caricare il kernel?
A me a volte si blocca prima del caricamento del kernel. In pratico vedo LILO, scelgo il kernel, compare la scritta, ma si ferma, senza iniziare il caricamento.

Hai provato l'opzioni compact di lilo?

414N ha scritto:Hai provato l'opzioni compact di lilo?

Io sì, ma è la stessa cosa. Tanto si blocca prima ancora di vedere i puntini in sequenza.
Per questo dicevo che a me si blocca "prima" di caricare il kernel

Gli unici PC che vedo partire in 35s dalla pressione del pulsante di accensione sono i thinclient del LTSP peccato che leggano il boot dal dischetto e per far questo perdono 6 o 7s.

Ritornando al discorso del boot, credo che Pat abbia già provveduto ad aggiungere una '&' ai servizi che si possono mandare in background;
mi chiedo però se si potrebbe fare di più e per questo bisogna tirare fuori il know how della community. Intanto, come altri hanno già consigliato, si potrebbe cominciare ad eliminare i servizi inutili, ma in che modo? Certamente togliere i permessi di esecuzione ad alcuni script in /etc/rc.d/ è la soluzione più elegante, ma sicuramente non è la più veloce. Infatti, non dobbiamo sottovalutare il fatto che il bash scripting è un linguaggio interpretato che può essere decine se non centinaia
di volte più lento di un linguaggio interpretato. Con questo voglio dire che se apriamo /etc/rc.d/rc.M e prendiamo per esempio la sezione relativa a ldconfig:

# Update all the shared library links:
if [ -x /sbin/ldconfig ]; then
echo "Updating shared library links: /sbin/ldconfig &"
/sbin/ldconfig &
fi

anche se Pat ha provveduto a mandare il processo in background, considerata l'inutilità di questo controllo, molti consigliano di commentare solo
# /sbin/ldconfig &
invece se commentiamo tutta la sezione evitiamo all'interprete di eseguire delle istruzioni inutili che vanno ad assorbire cicli di CPU:

#if [ -x /sbin/ldconfig ]; then #
# echo "Updating shared library links: /sbin/ldconfig &"
# /sbin/ldconfig &
#fi
altrimenti la prima riga verrebbe eseguita lo stesso ed anche la seconda (lentissima anche per un linguaggio compilato).
A maggior ragione se il controllo viene fatto su uno script dove abbiamo tolto i permessi di esecuzione.
Questo sistema, se usato sistematicamente in tutti gli script che si occupano di far partire dei servizi, permette di risparmiare qualche secondo prezioso.
Per quanto riguarda il riconoscimento hardware, la cosa migliore sarebbe un kernel su misura, ma se diamo un #lsmod probabilmente ci saranno dei moduli
che si possono tranquillamente blacklistare.
Scusate se mi sono permesso di aprire questa parentesi, ma questo è un problema sul quale si potrebbe e si dovrebbe fare di più a prescindere dalla misura del kernel.
Saluti!

Allora.
Anche io commento tutta la sezione.

Però puoi commentare quel che non ti serve, ma anche quel che ti serve. Se sai che httpd dovrà andare in funzione ed è eseguibile, non metti il controllo
E poi perché non toglierlo direttamente?

Alla fine in un sistema desktop rc.M lo fai diventare qualcosa come
Poi fai uno script che lanci quando vuoi tu con
e la rete la lanci a mano quando ti serve e tutti i demoni che vuoi li lanci a mano, tanto in un sistema desktop non ti serviranno sempre
naturalmente se hai pcmcia, periferiche che hanno bisogno di scaluns, stampanti hp, etc... devi lanciare tali script o rimettere i comandi in rc.M
Ma se vuoi provare uno script come quello sopra il tempo si riduce e naturalmente c'è sempre da lavorare su rc.S

P.S.
per chi vuol provare si faccia un backup di rc.M e si prenda tutti i rischi. Io vi ho avvertito

Come sempre il tuo contributo è prezioso! Saluti!