View Full Version : Kerneler
Ciao!
Sono l'autore di Kerneler.
Compilare il Kernel su GNU/Linux spesso è difficile per i nuovi utenti che si affacciano per la prima volta su questo mondo.
Nasce quindi Kerneler! Un piccolo script che permette di semplificare notevolmente la compilazione del Kernel su distribuzioni debian-based
Kerneler è completamente testuale poiché ritengo abbastanza inutile la grafica per un programma che deve gestire la compilazione del Kernel. In realta' è presente una "grafica testuale" realizzata mediante l'uso di dialog che permette di avere dei menu interattivi che sono molto prossimi a quelli realizzati per X. Alcuni screenshot sono disponibili qui.
Il software è in fase di sviluppo ma attualmente è funzionante sulle seguenti distribuzioni:
* debian sarge (parzialmente, infatti monta una versione molto vecchia di make-kpkg)
* debian etch
* debian sid
* ubuntu dapper
* ubuntu edgy
Features:
* Downloader. Scarica automaticamente la versione scelta con il download manager scelto e ne controlla la dimensione
* Decompressione. Decomprime i file sorgenti e controlla che siano stati correttamente estratti.
* Patcher. Aggiorna i sorgenti all'ultima revisione automaticamente oppure aggiunge patch (con relativa funzione di rimozione) ck, mm e Beyond
* Configuratore. Copia il vecchio file .config in utilizzo e controlla che sia presente tutto il necessario perché make menuconfig possa venir lanciato
* Compilatore. Genera diversi tipi di pacchetti a partire dai sorgenti.
* Installatore. Installa i pacchetti .deb generati in questa, o in precedenti sessioni, della versione specificata
* Menu Hardware. Permette di avere una idea dell'hardware presente tramite un comodo menu
* Wizard. Processo che guida passo passo l'utente durante la compilazione del Kernel. Rispondendo a semplici domande sara' possibile ricompilare il Kernel.
Il link al sito ufficiale è http://www.kerneler.org
Per scaricarlo https://sourceforge.net/project/showfiles.php?group_id=176146&package_id=202500&release_id=472032
Vorrei sapere come lo trovate, se vi sembra una buona idea e cosa potrei migliorare!
Grazie a tutti!
ilsensine
18-12-2006, 09:07
* Configuratore. Copia il vecchio file .config in utilizzo
Non è la scelta ottimale; da un kernel all'altro possono spuntare o scomparire alcune voci, o - peggio - altre potrebbero cambiar nome.
Sarebbe interessante riuscire a rilevare l'hw presente e generare automaticamente un .config personalizzato, ma ovviamente non è banale :)
ilsensine
18-12-2006, 09:23
C'è un serio bug di sicurezza:
Utente esegue ln -s /dev/hda /tmp/kerneler.htm
Root esegue kerneler
Root piange perché hda è andato distrutto
Usa mktemp per creare il file temporaneo
ilsensine
18-12-2006, 09:35
Altro problema di sicurezza: dai una occhiata ai permessi della cartella contenente il kernel scompattato e dei file contenuti ;)
Sarebbe interessante riuscire a rilevare l'hw presente e generare automaticamente un .config personalizzato, ma ovviamente non è banale :)
In linea teorica non basterebbe verificare quali moduli siano caricati e abilitare quelli di conseguenza?
Innanzi tutto grazie mille!
1) Il problema della copia del file .config viene meno quando l'utente lancia make menuconfig o roba simile e salva il nuovo config... in questo modo le voci in piu' vengono aggiunte e quelle che vengono tolte vengono eliminate... Posso magari rendere obbligatorio che il file .config e quello nuovo generato devono essere diversi...
2) Effettivamente non ci avevo pensato pongo subito rimedio
3) Allora cambio tar jxvf con qualche cosa che mantenga i permessi originali effettivamente è meglio
Non so come ringraziarti sei stato di prezioso aiuto!
In linea teorica non basterebbe verificare quali moduli siano caricati e abilitare quelli di conseguenza?
Teoricamente se il pc è configurato ad hoc si potrebbe bastare (teoricamente perche' potrebbero cambiare moduli e far cambiare tutto)
Pero' se il pc non è configurato a dovere nemmeno la nuova configurazione lo sara'...
ilsensine
18-12-2006, 10:11
3) Allora cambio tar jxvf con qualche cosa che mantenga i permessi originali effettivamente è meglio
C'è stato un mezzo flame sulla lkml per il fatto che i pacchetti contengono i privilegi 777. Se scompatti da utente non te ne accorgi (la umask è applicata), ma se esegui tar da root no (in quanto tar in questo caso è pensato per ripristinare un backup, esattamente com'era).
La soluzione è tar -xjf --no-same-permissions -f <file>
ilsensine
18-12-2006, 10:41
Ti do una piccola dritta per mostrare in un dialog l'output dei programmi (ad es. wget). Prova questo:
#!/bin/bash
FIFO=/root/.fifo
# TODO: Controllare che $FIFO non esista,
# oppure che esista ed è effettivamente un fifo
mkfifo "$FIFO" 2>/dev/null
exec 3<>"$FIFO"
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.1.tar.bz2 -o "$FIFO" &
PID=$!
dialog --title "titolo" --backtitle "backtitolo" --progressbox 3 80 0<&3 &
DPID=$!
wait $PID
kill -TERM $DPID
E' molto rozzo, dovresti lavorarci un pò per migliorarlo. La cosa più fastidiosa è che utilizzando dialog in questa maniera distrugge le impostazioni del terminale (puoi effettuare un reset del terminale con "reset" all'uscita dello script).
Peccato che trap non cattura anche il SIGCHLD, avrebbe evitato di mettere dialog in background.
Fantastico! Grazie mille!
Vedo di aggiungere il tutto nella prossima release!
Come idea ti sembra buona puo' avere un futuro o è un fallimento in partenza?
ilsensine
18-12-2006, 11:16
Direi che può essere comodo, anche solo per il fatto che scarica & applica patch automaticamente.
Alcuni consigli:
- .config in base alla configurazione attuale. Non è necessario generarlo "completamente", parti dal defconfig per i386 e autoconfigura le parti più importanti (processore, supporto smp/up/highmem, driver necessari per montare il rootfs senza l'ausilio di un initrd ecc.). Il resto dei driver lasciali nella configurazione di default (probabilmente "m"), penserà udev a caricarli a sistema avviato.
- Più fiscalità sul controllo di fallimento dei programmi lanciati
- Possibilità di eseguirlo da utente normale (ovviamente non potrai fare alcune cose, e non potrai usare /usr/src come directory di compilazione ma una dir dell'utente)
- Dividilo in più script, 35k di script bash sono inmantenibili! Usa anche le "funzioni" bash.
- Indenta lo script (sezioni if, ecc.), così è poco leggibile
- Supporto multilingua (almeno l'inglese!) tramite gettext
La traduzione l'ho affidata ad un'amica a breve spero di riuscire a metterla su...
Sono sicuramente consigli d'oro...
L'unico problema sara' generare il .config anche sapendo processore ram e roba affina...
Ci lavorero' su
ilsensine
18-12-2006, 11:42
L'unico problema sara' generare il .config anche sapendo processore ram e roba affina...
Lascialo a bassa priorità, il riutilizzo di .config dovrebbe andar bene per la maggior parte dei casi. Fossi in te comincerei a dividere il progetto in più file e funzioni, in modo da renderlo più mantenibile.
Lascialo a bassa priorità, il riutilizzo di .config dovrebbe andar bene per la maggior parte dei casi. Fossi in te comincerei a dividere il progetto in più file e funzioni, in modo da renderlo più mantenibile.
io lo ho gia' diviso in vari file... poi quando lo rilascio li unisco tutti per aumentare la comodita' di chi lo usa... perche' credo che portarsi dietro un file unico sia meglio che portarsene 10... certo quando fai una modifica ti metti le mani nei capelli...
bel dilemma... magari faccio 2 pacchetti separati...
ilsensine
19-12-2006, 08:35
Ti do una piccola dritta per mostrare in un dialog l'output dei programmi
Ma quanto sono deficiente...
Questo non ha effetti collaterali:
#!/bin/bash
wait_child()
{
wait $1
RET=$?
return $RET
}
FIFO=/root/.fifo
# TODO: Controllare che $FIFO non esista,
# oppure che esista ed è effettivamente un fifo
mkfifo "$FIFO" 2>/dev/null
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.1.tar.bz2 -o "$FIFO" &
WPID=$!
dialog --title "titolo" --backtitle "backtitolo" --progressbox 3 80 0<$FIFO
# In caso di morte non prevista di dialog, dobbiamo comunque aspettare che wget termini.
wait_child $WPID
RETCODE=$?
if [ $RETCODE -ne 0 ]; then
# gestione errore in wget
fi
Ho provato anche con un reindirizzamento diretto di wget (tramite "|"), ma gli effetti non sono quelli desiderati.
grande gira benissimo!
non so come ringraziarti! :)
Scusate se mi intrometto,ma sarebbe possibile in futuro implementare i diversi tipi di configurazione del kernel?
Certo non è che abbia tutta questa importanza,però potrebbe catturare un maggior numero di utilizzatori e rendere piu user-friendly il tutto.
Scusate se mi intrometto,ma sarebbe possibile in futuro implementare i diversi tipi di configurazione del kernel?
Certo non è che abbia tutta questa importanza,però potrebbe catturare un maggior numero di utilizzatori e rendere piu user-friendly il tutto.
in che senso diversi tipi di configurazione?
Il patcher ora puo' aggiungere patch ck, mm e beyond oltre ad aggiornare all'ultima revisione....
conoscete qualche patch interessante che vale la pena di essere inserita?
ilsensine
21-12-2006, 08:31
Il patcher ora puo' aggiungere patch ck, mm e beyond oltre ad aggiornare all'ultima revisione....
conoscete qualche patch interessante che vale la pena di essere inserita?
Aggiungi il supporto per git:
http://linux.yyz.us/git-howto.html
e la possibilità di scaricare direttamente uno snapshot git del kernel (oppure lo snapshot di una determinata data, se possibile).
Sarebbe molto utile, anche se per un numero limitato di persone, poter applicare direttamente patch dai rami git dei diversi sviluppatori. Nota che il rischio che il patching automatico fallisca è più elevato, chi usa questa funzione deve sapere esattamente cosa sta facendo.
Alcuni update:
Da qualche giorno i server di kernel.org hanno una formattazione html diversa e questo ha incasinato un po' lo script ... questa sera ho rilasciato la versione 0.15a che risolve questi problemi...
Ho inoltre tenuto presente ogni vostro commento e ho quasi ultimato la 0.16 che oltre a correggere i bug segnalati da ilsensine avra' un primo rudimentale supporto per kernel git.. molto basilare download update configurazione e compilazione pero' lo avra'...
notizia del rilascio: http://www.kerneler.org/content/view/43/1/
link su sourceforge: https://sourceforge.net/project/showfiles.php?group_id=176146
Ciao a tutti!
Rilasciata la versione 0.16!
Grazie ai vostri consigli ho fatto molte modifiche!
Le piu' importanti sono:
- Possibilita' di aggiornare da qualsiasi versione all'ultima uscita in maniera automaitica!
- Possibilita' di applicare patch anche a kernel 2.6.19.2 (kerneler portera' prima di applicare la patch il kernel alla versione giusta)
- Modulare (in futuro sara' possibile installare facilmente plugin e attualmente permette di trovare errori molto piu' facilmente)
- Funziona da utente semplice e non piu' solo da root (le operazioni di installazione vengono fatte con sudo (se installato) oppure su.
E molte altre modifiche!
Fatemi sapere cosa ne pensate!
E ora un paio di link
Per scaricare:
https://sourceforge.net/project/showfiles.php?group_id=176146&package_id=202500&release_id=483600
Notizie del rilascio:
http://www.kerneler.org/content/view/51/1/
ilsensine
06-02-2007, 11:28
L'ho provato e va abbastanza bene; un paio di cose minori:
- locale saga. Tutti i caratteri non ascii mi si vedono corrotti, probabilmente perché uso un locale diverso dal tuo quando hai fatto gli script. Forse la cosa migliore sarebbe usare solo caratteri ascii (ad es. "e'" invece di "è"), a meno che non sai come gestire correttamente la cosa dagli script...
- Durante l'installazione di fakeroot ho messo la pwd di root come richiesto, ma per sbaglio l'ho...sbagliata :stordita: Il programma è andato avati, sarebbe meglio intercettare l'errore
Ok molte grazie un'altra volta!
Per il fatto delle lettere me ne ero accorto ma ogni tanto qualche lettera mi scappa :doh:
Per il fatto delle password metto un controllo di uscita... bella idea non ci avevo pensato...
Rilasciata la versione 0.17!
Ecco le nuove features!
* Aggiunto timer per le funzioni di compilazione.
* Aggiunto logger da controllare in caso di compilazioni fallite.
* ATI driver installer.
* Offline mode per usare kerneler anche senza essere connessi a internet.
* Patcher RT
* Aggiunto menu di configurazione (dove modificare: cartella sorgenti, sudo/su, controllo firme e offline mode)
* Aggiunta possibilita' di personalizzare il nome del kernel con "append to version" e "revision"
Ho inoltre corretto i bug segnalati da ilsensine e altri segnalati da voi utenti!
Link per scaricare (https://sourceforge.net/project/showfiles.php?group_id=176146&package_id=202500&release_id=497783)
Segnalo che l'utente mic1 di questo forum fa ora parte dello sviluppo e ha contribuito attivamente scrivendo ATI e correggendo alcuni bugs!
Se poteste farmi avere i vostri feedback ve ne sarei grato!
Ciao!
jimmazzo
31-03-2007, 23:24
Ciao Neon, davvero una gran bella idea, stò giusto ricompilando il kernel in ubuntu; ho usato la patch kolivas sul 2.6.20 (ma è la prima volta che uso delle patch per il kernel :D), se dovessi aver problemi con questa compilazione provo il tuo programma, ma probabilmente lo proverò anche senza aver problemi, per curiosità.
Ot: Ho chiesto a DarkBasic (che gentilmente m'ha fatto conoscere la patch ck) se è possibile applicare più patch allo stesso kernel, ma purtroppo lui non ha mai provato; vorrei installare la ck e quella realtime-preemption di Ingo Molnar ( http://guide.debianizzati.org/index.php/Low-latency_2.6_kernel_per_applicazioni_audio_realtime ) per poter usare il server jack in realtime; secondo voi è possibile?
Scusate l'ot, ma visto che sono niubbo in materia magari voi mi sapete dare qualche dritta. Ciao e grazie :)
Ciao!
Kerneler non permette l'applicazione di diverse patch contemporaneamente per adesso... dalla prossima versione ci sara' la possibilita' di farlo perche' sto ultimando una funzione che controlli la corretta aggiunta delle patch...
ho provato ad accoppiare ck e rt e a quanto pare la fase di patching va a gonfie vele...
bisognerebbe provarlo "on the road" per vedere come gira...
Attualmente kerneler aggiunge automaticamente sia ck che rt (rt con 2.6.20 fa un po' di casino perche' il loro repository è mantenuto da cani...) separatamente ma non insieme...
Appena ho tempo faccio una compilazione e vedo cosa ne esce fuori!
jimmazzo
01-04-2007, 17:50
Ciao!
Kerneler non permette l'applicazione di diverse patch contemporaneamente per adesso... dalla prossima versione ci sara' la possibilita' di farlo perche' sto ultimando una funzione che controlli la corretta aggiunta delle patch...
ho provato ad accoppiare ck e rt e a quanto pare la fase di patching va a gonfie vele...
bisognerebbe provarlo "on the road" per vedere come gira...
Ciao Neon; a quanto pare anche con la sola patch Ck riesco ad impostare il server Jack in realtime (ieri notte ho scritto il messaggio mentre il nuovo kernel compilava), e funziona anche molto bene.
Ho un unico problema con i driver nvidia; praticamente non avvia gdm e mi restituisce l'errore "EE: failed to load the nvidia kernel driver"; poi se provo a reinstalarli il processo restituisce un errore in compilazione.
Te probabilmente lavorando al programma sai quali possono essere le cause; bisogna forse patchare anche i driver nvidia (closed)?
Te lo chiedo perchè con le altre versioni del kernel, senza patch, funzionano bene; non vorrei che fosse dipeso dal nuovo sheduler.
Grazie e ciao.
ho provato anche io oggi e dalla prossima versione faro' in modo che sia possibile patchare sia rt che ck insieme!
domanda stupida non picchiarmi... hai dato un modprobe nvidia dopo averli installati?
perche' da quel che leggo la compilazione va a buon fine...
jimmazzo
01-04-2007, 20:22
ho provato anche io oggi e dalla prossima versione faro' in modo che sia possibile patchare sia rt che ck insieme!
domanda stupida non picchiarmi... hai dato un modprobe nvidia dopo averli installati?
perche' da quel che leggo la compilazione va a buon fine...
:D noo tranquillo non ti picchio, anzi, ti ringrazio della disponibilità.
Allora, la compilazione non va a buon fine, durante la schermata "building kernel module", presente nell'interfaccia pseudo-grafica dell'installazione dei driver esce questo errore "error: unable to build the nvidia kernel module"; poi volendo c'è anche il file di log molto dettagliato, in cui si vede che make viene interrotto con un "error 1" (se vuoi la posto ma è molto lungo il log).
Ho provato a dare un "modprobe nvidia" (da root e prima di provare a reinstallare i driver, driver che funzionano nel kernel non patchato) e esce questo errore "fatal: error running install command for nvidia".
Per compilare con successo i driver nvidia percaso c'è qualche opzione da abilitare\disabilitare nel kernel?
Ciao e grazie :)
direi di no... dovrebbe andare abbastanza tranquillamente...
è abbastanza tardi domani compilo un kernel con ck e rt e ti faccio sapere cosa fa con nvidia!
Uscito Kerneler 0.18!
E' stata rilasciata la versione 0.18...
Sono stati corretti alcuni bugs e riscritte parti di codice facendo tesoro delle cose apprese durante lo sviluppo...
Le nuove feature sono:
- Simulazione durante l'applicazione delle patch
- Possibilita' di importare sorgenti esterni
- Supporto per 'lshw' (per generare report sull'hardware)
- "Macchina del tempo" con la quale si puo' passare da una versione all'altra in maniera completamente automatica! Basta solo indicare la versione che si vuole e kerneler scaricando pochi kb di patch portera' i sorgenti presente su disco alla versione da voi scelta!
Fatemi sapere cosa ne pensate!
Una feature interessante secondo me potrebbe essere quella di applicare varie patch, non solo quelle, ad esempio la linux-phc per il supporto all'undervolting del centrino, che farebbe comodo a molti INMHO ;)
Sarei felicissimo di farlo...
Avrei bisogno del vostro aiuto pero' perche' non avendo un portatile non conosco ne il nome ne dove poterle reperire...
Se poteste fare una lista di patch con link e qualche riga di spiegazione ve ne sarei molto grato in modo da aggiungere gia' dalla prossima versione il supporto per queste!
Rilasciato Kerneler 0.19!
Le nuove feature sono:
- Interfaccia grafica (gtk+ con zenity).
- Potenziato notevolmente il patcher.
- Tradotto interamente in inglese
- Timer per decidere o ritardare l'orario della compilazione
- Corretti alcuni bug minori
- Nuovi menu di compilazione
- Rivoluzionati e aumentati i controlli
il sito è come sempre http://www.kerneler.org
Fatemi sapere cosa ne pensate!!!
Grazie!
Ciao!
Ho scaricato l'ultima versione e l'ho eseguita; è stato visualizzato il messaggio:
E' necessario installare:
- dialog
- module-assistant
- lshw
E mi è stato chiesto se volevo installarli ora. Io ho risposto 'no', pensando che così il programma si sarebbe interrotto, e invece ha iniziato a loopare senza fine :p
Quindi, secondo me, una prima correzione da fare riguarda questo caso, e magari nella domanda che chiede di installare i pacchetti vanno indicate le alternative, cioè qualcosa tipo (s/n) oppure (si/no) o (y/n) e via dicendo :)
EDIT: altra cosa. Compare il messaggio
Error with kerneler directory. . . Now it will be reconfigured!
ma non c'è nessun messaggio che dica qualcosa tipo "Premi ENTER per continuare" o semplicemente "Press ENTER"; uno potrebbe rimanere un po' spiazzato...
EDIT2: mi sembra di aver visto un articolo a proposito di Kerneler su Linux PRO o Linux Magazine, ma non ricordo il numero. qualcuno lo ricorda?
Grazie mille correggo subito!
Il tuo aiuto è stato preziosissimo!
EDIT:
Problemi corretti a breve verra' rilasciata una 0.19a
Le alternative le avevo messe il problema era che il ritorno dei valori perche' invece di ritornare con return dovevo ritornare con exit visto che era nel main!
EDIT2: L'hanno pubblicato su Linux Magazine un po' di tempo fa... E' stata una bella sorpresa :)
Rilasciata la versione 0.19 con i bug corretti da Gica78R e altre sviste minori!
Grazie!
Potete scaricarla da sourceforge dovrebbero gia' essere sincronizzati i vari server
Ciao! Ho visto che mi hai citato sul tuo sito! Sono lusingato! :)
Volevo segnalare una cosa: fino ad ora ho sempre provato kerneler con l'interfaccia pseudo-grafica ed andava bene; poi ho provato ad usare l'interfaccia grafica e, non trovando installato zenity, il programma è andato in loop con l'output
/home/gianluca/kerneler_0.19a_alpha//scripts/chkernel.kern: line 20: zenity: command not found
E' effettivamente un bug, oppure ero io che dovevo assicurarmi di aver installato zentity prima di avviare kerneler con la GUI?
Comunque per fermare l'applicazione ho usato CTRL+Z, ma in questo modo nel file di configurazione di kerneler l'opzione zenity rimane impostata a 1, quindi l'utente è impossibilitato a riavviarlo in modalità non grafica, a meno che non vada a modificare manualmente il file di conf.
Altra piccola cosa: se avvio kerneler in modalità non grafica e, senza fare nulla, nel primo menu che mi si presenta (Menu scelta versione) provo ad uscire... non esce!
Ciao
EDIT: ho scritto una micro recensione (http://gicatech.wordpress.com/2007/10/03/kerneler-kernel-facile-o-quasi/) su kerneler... Se ci sono imprecisioni, segnalatele che le correggo subito!
Ciao! Ho visto che mi hai citato sul tuo sito! Sono lusingato! :)
E' stato un piacere per me levare quei bug! :)
Volevo segnalare una cosa: fino ad ora ho sempre provato kerneler con l'interfaccia pseudo-grafica ed andava bene; poi ho provato ad usare l'interfaccia grafica e, non trovando installato zenity, il programma è andato in loop con l'output
E' effettivamente un bug, oppure ero io che dovevo assicurarmi di aver installato zentity prima di avviare kerneler con la GUI?
Kerneler funziona (o almeno dovrebbe :D) principalmente in modalita' pseudo grafica... Se poi uno vuole la modalita' grafica deve installare zenity...
Effettivamente pero' hai pienamente ragione implementero' un menu di scelta che chieda in caso non sia instalato se si vuole installare sul momento!
Altra piccola cosa: se avvio kerneler in modalità non grafica e, senza fare nulla, nel primo menu che mi si presenta (Menu scelta versione) provo ad uscire... non esce!
Quello l'ho fatto appositamente :D
Ad ogni modo non sei il primo a dirmelo quindi dalla prossima versione faro' in modo che esca subito
Ciao
EDIT: ho scritto una micro recensione (http://gicatech.wordpress.com/2007/10/03/kerneler-kernel-facile-o-quasi/) su kerneler... Se ci sono imprecisioni, segnalatele che le correggo subito!
Grazie mille! E' un piacere leggere di qualcuno a cui è utile il lavoro che ho svolto!
Le uniche cose che davvero mi fanno piacere e che mi ripagano tutto il lavoro sono la gente che segnala bug e la gente che scrive qualche riga sul proprio blog/sito/rivista...
Hai fatto entrambe ;)
Ora è ora che mi vesta e che vada in uni stasera correggo queste ultime imprecisioni!
Ciao e buona giornata!
mi è capitata la stessa cosa di Gica che lo script andasse in loop ma con in piu alcune considerazioni che espongo:
1) vero che è andato in loop per la mancanza di zenith installato ma non doveva scaricarloanzichè andare in circolo ?????
2) la cosa piu strana è+ che questo capita rifacendo la procedura da capo :(
per il punto 2) mi spiego dettagliatamente.
Scaricata la versione 19alpha. Scompattata sul Desktop ed avviato. Risposto alle domande di creare una dir dove mettere il tutto; fatto in /home/carcass/. Arrivato al punto di scegliere la GUI ho sbagliato dicendo si ed è andato in loop.
Ma la cosa piu strana è che rifacendo l'intera procedura da capo con l'intenzione di arrivare al punto in cui NON usare la GUI il risultato è sempre questo, nonostante avessi cancellato tutto quello relativo alla procedura di uso dello script (cancellazione dir, etc.......) con un rifacimento integrale della procedura iniziando dallo scompattamento del tar.
Secuenze
http://aycu03.webshots.com/image/29362/2001835653035991673_th.jpg (http://allyoucanupload.webshots.com/v/2001835653035991673)
http://aycu34.webshots.com/image/31913/2001895530965907551_th.jpg (http://allyoucanupload.webshots.com/v/2001895530965907551)
http://aycu06.webshots.com/image/29485/2001838148572854275_th.jpg (http://allyoucanupload.webshots.com/v/2001838148572854275)
:confused:
Ma la cosa piu strana è che rifacendo l'intera procedura da capo con l'intenzione di arrivare al punto in cui NON usare la GUI il risultato è sempre questo, nonostante avessi cancellato tutto quello relativo alla procedura di uso dello script (cancellazione dir, etc.......) con un rifacimento integrale della procedura iniziando dallo scompattamento del tar.
Hai cancellato il file (o directory, non ricordo) .keneler? :)
Sennò puoi anche modificarlo, mettendo 0 in corrispondenza dell'opzione zenity.
Ciao
Hai cancellato il file (o directory, non ricordo) .keneler? :)
Sennò puoi anche modificarlo, mettendo 0 in corrispondenza dell'opzione zenity.
Ciao
mi era proprio sfuggito quel file di configurazione :rolleyes:
Grazie.
se vi sono altre cose comunico subito che è la prima volta che lo sto testando, scaricando la versione 2.6.23 ;)
ciao,
conosci KernelCheck? E un programma simile al tuo, puoi usarlo per prendere degli spunti (anche se c'è un bel po di differenza tra uno script in bash e un programma in python, pero molte delle operazioni da eseguire sono simili):
http://www.ossblog.it/post/3114/compilazione-del-kernel-automatizzata-con-kernelcheck
http://kcheck.sourceforge.net/
Si usa interamente tramite GUI (in GTK), è scritto in Python, per adesso funziona su debian e ubuntu ma verra esteso anche per le distro rpm-based, sembra avere molte caratteristiche avanzate, come ad esempio la posibilità di compilare nel kernel i driver proprietari nvidia, ati e ndiswrapper.
http://kcheck.sourceforge.net/images/Screenshot-Kernel%20Information.png
ciao,
conosci KernelCheck? E un programma simile al tuo, puoi usarlo per prendere degli spunti (anche se c'è un bel po di differenza tra uno script in bash e un programma in python, pero molte delle operazioni da eseguire sono simili):
http://www.ossblog.it/post/3114/compilazione-del-kernel-automatizzata-con-kernelcheck
http://kcheck.sourceforge.net/
Si usa interamente tramite GUI (in GTK), è scritto in Python, per adesso funziona su debian e ubuntu ma verra esteso anche per le distro rpm-based, sembra avere molte caratteristiche avanzate, come ad esempio la posibilità di compilare nel kernel i driver proprietari nvidia, ati e ndiswrapper.
http://kcheck.sourceforge.net/images/Screenshot-Kernel%20Information.png
io non capisco perche lui dovrebbe prendere spunto, da che cosa poi?? da una interfaccia carina ma che fa la stessa cosa???
vi fate abbagliare dalla grafica :( le cose migliori su linux si fanno da console che è very very powerfull
NCURSES RULEZZZZZZZZZZZZZZZZZ
PS: ovviamente io ho creato il .deb con sorgenti doc etc.... tutto dentro, domanda idiota: installato il deb aggiorna automaticamente il menu di grub, giusto??? :D
Ciao!
Si ho letto anche io oggi su ossblog...
Ci ho dato un'occhiata ma sinceramente credo che sia meglio rendere facile la compilazione del kernel attraverso un'interfaccia diversa...
L'ho provato pero' lascia troppo allo scuro l'utente riguardo a cio' che accade al suo computer...
Preferisco fare in modo che l'utente scelga la versione e la scarichi ma che la compili solo 2 giorni dopo piuttosto che debba fare tutto uno dietro l'altro...
L'idea buona che ho preso è quella di creare una funziona wizard in modo che faccia tutto da solo...
Dalla prossima versione ad ogni modo su kerneler sara' presente anche un autoconfiguratore che settera' automaticamente cpu e (credo) ram in modo da procedere con prime ottimizzazioni...
ad ogni modo è meglio che ci siano programmi che fanno le stesse cose di quello che sto sviluppando così c'è un miglior confronto di idee e lo sviluppo non si arresta mai!
ovviamente io ho creato il .deb con sorgenti doc etc.... tutto dentro, domanda idiota: installato il deb aggiorna automaticamente il menu di grub, giusto???
si o no? :)
si o no? :)
si si aggiorna grub e naturalmente non tocca i vecchi kernel! così in caso ci fossero problemi col nuovo si puo' sempre scegliere di far partire una vecchia versione!
mindwings
13-10-2007, 12:26
mi è capitata la stessa cosa di Gica che lo script andasse in loop ma con in piu alcune considerazioni che espongo:
1) vero che è andato in loop per la mancanza di zenith installato ma non doveva scaricarloanzichè andare in circolo ?????
2) la cosa piu strana è+ che questo capita rifacendo la procedura da capo :(
per il punto 2) mi spiego dettagliatamente.
Scaricata la versione 19alpha. Scompattata sul Desktop ed avviato. Risposto alle domande di creare una dir dove mettere il tutto; fatto in /home/carcass/. Arrivato al punto di scegliere la GUI ho sbagliato dicendo si ed è andato in loop.
Ma la cosa piu strana è che rifacendo l'intera procedura da capo con l'intenzione di arrivare al punto in cui NON usare la GUI il risultato è sempre questo, nonostante avessi cancellato tutto quello relativo alla procedura di uso dello script (cancellazione dir, etc.......) con un rifacimento integrale della procedura iniziando dallo scompattamento del tar.
Secuenze
http://aycu03.webshots.com/image/29362/2001835653035991673_th.jpg (http://allyoucanupload.webshots.com/v/2001835653035991673)
http://aycu34.webshots.com/image/31913/2001895530965907551_th.jpg (http://allyoucanupload.webshots.com/v/2001895530965907551)
http://aycu06.webshots.com/image/29485/2001838148572854275_th.jpg (http://allyoucanupload.webshots.com/v/2001838148572854275)
:confused:
ti garba evangeline lilly ? :D
ti garba evangeline lilly ? :D
:oink:
io non capisco perche lui dovrebbe prendere spunto, da che cosa poi?? da una interfaccia carina ma che fa la stessa cosa???
vi fate abbagliare dalla grafica :( le cose migliori su linux si fanno da console che è very very powerfull
Mi hai frainteso, l'unica cosa che non ho guardato era proprio la grafica, ma piuttosto il codice! E comuqnue non è mica per criticare, anzi trovo che abbia fatto un buon lavoro.
Quello che mi chiedevo è perche hai scelto un linguaggio di scripting come Bash piuttosto di un vero linguaggio di programmazione, che sarebbe stato molto piu comodo e veloce da scrivere.
Ad esempio (per quello l'avevo citato), KernelCheck sono 500 righe pulite e ordinate in Python, che occupano 18KB, contro i 65KB di Kerneler. Senza contare tutto quello che potrebbe aggiungere su KernelCheck ma che su Kerneler non puoi per colpa di Bash.
Penso che farebbe comodo poter scrivere del codice come questo, tanto per fare un esempio alla svelta:
Moduli = dict()
Moduli["nVidia"] = "/lib/2.6.23/nvidia.ko"
Moduli["ATI"] = "/lib/2.6.23/ati.ko"
Moduli["ndiswrapper"] = "/lib/2.6.23/ndis.ko"
for nome, path in Moduli.items():
print "Il modulo ", nome, " si trova in ", path
Il modulo nVidia si trova in /lib/2.6.23/nvidia.ko
Il modulo ATI si trova in /lib/2.6.23/ati.ko
Il modulo ndiswrapper si trova in /lib/2.6.23/ndis.ko
Senza contare l'OOP, pieno supporto a ereditarietà e polimorfismo, librerie per gestire ad alto livello grafica, IO, stream, thread, rete, etc... e una sintassi tanto semplice quanto un linguaggio di scripting. Imho è l'ideale...:cool:
Se avessi tempo (e voglia soprattutto:D) per mettermi lo farei cosi: un backend generico che esporta degli hooks per scrivere dei plugins specifici per le varie distro, in modo da estenderlo facilmente, e una api per interfacciarlo con vari frontend a piacere, sia grafici che testuali.
Traduzioni con gettext, compilazione con automake e autoconf, un po di RPM e DEB per le varie distro... cosi verrebbe fuori un lavoro professionale!
Magari poi lo inseriscono anche nei repository ufficiali delle varie distro...
Comunque è solo un'opinione, giusto per sentire come l'avrebbe fatto un'altro e fare un confronto...:)
Mi hai frainteso, l'unica cosa che non ho guardato era proprio la grafica, ma piuttosto il codice! E comuqnue non è mica per criticare, anzi trovo che abbia fatto un buon lavoro.
Quello che mi chiedevo è perche hai scelto un linguaggio di scripting come Bash piuttosto di un vero linguaggio di programmazione, che sarebbe stato molto piu comodo e veloce da scrivere.
Ad esempio (per quello l'avevo citato), KernelCheck sono 500 righe pulite e ordinate in Python, che occupano 18KB, contro i 65KB di Kerneler. Senza contare tutto quello che potrebbe aggiungere su KernelCheck ma che su Kerneler non puoi per colpa di Bash.
Penso che farebbe comodo poter scrivere del codice come questo, tanto per fare un esempio alla svelta:
Moduli = dict()
Moduli["nVidia"] = "/lib/2.6.23/nvidia.ko"
Moduli["ATI"] = "/lib/2.6.23/ati.ko"
Moduli["ndiswrapper"] = "/lib/2.6.23/ndis.ko"
for nome, path in Moduli.items():
print "Il modulo ", nome, " si trova in ", path
Il modulo nVidia si trova in /lib/2.6.23/nvidia.ko
Il modulo ATI si trova in /lib/2.6.23/ati.ko
Il modulo ndiswrapper si trova in /lib/2.6.23/ndis.ko
Senza contare l'OOP, pieno supporto a ereditarietà e polimorfismo, librerie per gestire ad alto livello grafica, IO, stream, thread, rete, etc... e una sintassi tanto semplice quanto un linguaggio di scripting. Imho è l'ideale...:cool:
Se avessi tempo (e voglia soprattutto:D) per mettermi lo farei cosi: un backend generico che esporta degli hooks per scrivere dei plugins specifici per le varie distro, in modo da estenderlo facilmente, e una api per interfacciarlo con vari frontend a piacere, sia grafici che testuali.
Traduzioni con gettext, compilazione con automake e autoconf, un po di RPM e DEB per le varie distro... cosi verrebbe fuori un lavoro professionale!
Magari poi lo inseriscono anche nei repository ufficiali delle varie distro...
Comunque è solo un'opinione, giusto per sentire come l'avrebbe fatto un'altro e fare un confronto...:)
no no :)
nel mondo opensource sono le opinioni con criteri che fanno proghedire, è che io sono orientato a bash che mi piace molto.
cioè la compilazione è molto scorrevole, le opzioni non mancano e dunque va piu che bene.Ovvio che migliorare e fare le cose sempre meglio è anche esso un bene. :mano:
Ah, ok...
Ma hai scritto anche tu Kerneler? Pensavo lo stesse facendo Neon87!:D
Comunque, il punto è questo: quanto pensi di poter sviluppare Kerneler in Bash?
Finche Kerneler è uno script che scarica i sorgenti, ci applica delle patch e li compila, Bash è piu che sufficiente, ma se intendi sviluppare delle features avanzate imho devi passare a uno strumento piu potente.
Dipende da quello che vuole fare, pero ho letto che sta lavorando per far ottimizzare il kernel in automatico.
Farlo con Bash è a dir poco arduo, considerando che Bash ti mette a disposizione solo un minimo di programmazione procedurale, modifica del file system, avvio di processi e qualche strumento per elaborare grezzamente stringhe ed espressioni regolari.
Se non conosci Python ci mettti una settimana a impararlo bene, in pochi giorn riscrivi Kerneler e dopo ti trovi con una piattaforma molto piu evoluta su cui lavorare, con tutti i vantaggi che ne comporta se vuoi continuarne lo sviluppo.
Per l'architettura che ha Kerneler adesso, è quasi al massimo del suo sviluppo. A continuare oltre cosi rischi veramente che venga fuori un pastrocchio, inmantenibile da chiunque tranne che l'autore (che se poi sta due mesi senza guardarlo non ci riesce piu neanche lui:asd:).
Se vuoi fare un programma serio e pensare in grande, allora è il momento dare una riveduta alla struttura del progetto, altrimenti puo andare bene anche cosi come adesso, pero certe cose te le scordi.
Tutto imho ovviamente...
Purtroppo... o per fortuna hai pienamente ragione...
Infatti è un mesetto che studio python e ho gia' iniziato a fare un "port" in python anche se procedo abbastanza lentamente...
C'è da dire che è un altro mondo... ci sono delle funzioni built-in che mi fanno godere :D
Ho iniziato a scriverlo in bash perche' quando avevo iniziato non pensavo di andare così avanti... poi ho cambiato idea e ho deciso di portarlo molto avanti quindi sto rivedendo tutta la struttura...
Credo che rilascero' la 0.20 con una base di autoconfiguratore che ormai ho scritto quasi completamente...
Continuero' a mantenerla avanzando solo con le lettere (es 0.20a 0.20b) per correggere evventuali bug ma fermero' lo sviluppo finche' non riesco a "tradurre" tutto in python...
Per fortuna! Mi pareva strano che volessi ottimizzare il kernel a suon di cat, sed, grep ed echo! :D
Quando il nuovo port sarà a buon punto puoi metterlo su svn, cosi vediamo come butta...
Pensi di usare la stessa struttura attuale e convertire riga per riga da Bash a Python oppure hai in mente una riscrittura completa?
Ti do qualche spunto su cosa ci implementerei, poi vedi tu...
Il punto debole del codice di Kerneler è che non c'è sufficiente astrazione (vabbè, è uno script), ad esempio non va bene che l'interfaccia venga gestita all'interno dello stesso codice che esegue il lavoro sporco.
Se si verifica un errore, l'engine non deve stampare niente (al massimo un log), ma deve solo sollevare un'eccezione, a informare l'utente ci penserà il frontend che gestisce l'interfaccia, da un'altra parte.
Inoltre, le operazioni che eseguono effettivamente il lavoro non dovrebbero essere hard coded nel programma principale, ma piuttosto caricate esternamente tramite dei plugins, per migliorare l'estendibilità.
Puoi fornire degli hooks ("agganci") all'esterno, tipo preinstall(), install(), postinstall(), che se definiti sovrascrivono o completano il comportamento di default.
Cosi per portare Kerneler su un'altra distro basta creare un plugin vuoto e ridefinire le funzioni necessarie per modificarne il comportamento, da quello di default a quello spcifico per quella distro.
Il fatto che in Python le funzioni sono sempre virtuali ti viene in forte aiuto, ad esempio si puo creare un dizionario con i passi da eseguire da una parte e la funzione che svolge quel lavoro dall'altra, e adattarlo a run time.
Ad esempio se su Fedora dopo aver installato il kernel devo eseguire un comando particolare per finire l'installazione, creo un plugin kerneler_fedora che implementa la funzione postinstall() e dentro ci scrivo il nuovo comando da aggiungere.
Poi nel file /etc/kerneler.conf metto una riga tipo
default=fedora_plugin
ed ecco che ho portato kerneler su Fedora.
Piu hooks fornisci, piu facile sarà il lavoro per chi vuole portarlo su altre distro, e quindi estenderlo sul maggior numero di distribuzioni.
Ci sono molti altri metodi, l'idea è quella di slegare l'architettura di Kerneler dall'implementazione su una particolare distro.
Una funzione interessante sarebbe quella di fare il codice hash del kernel appena compilato e chiedere all'utente di salvarlo su un dischetto, cosi da controllare in seguito se ci sono rootkit, e la possibilità di abilitare macro aree ad alto livello, come ad esempio:
- Abilita/Disabilita SElinux
- Elimina supporto periferiche inutili (Parallela, Seriale, File System esotici)
- Supporto Rete di Base
- Supporto rete Avanzato
- etc...
ok, buon lavoro! ;)
La conversione riga per riga è praticamente impossibile e sarebbe stupida secondo me perche' ho maturato un po' di esperienza nello scriverlo in bash e credo che potrei riscriverlo meglio...
Naturalmente tenendo a vista gia' tutto quello che ho scritto con relativi controlli degli exit level, cicli per le patch e via dicendo che verranno solo convertiti...
Il problema che sto cercando di superare è cercare un toolkit gui per realizzare un'interfaccia ... allo stesso tempo pero' vorrei mantenere tutto il progetto anche testuale perche' è molto utile potrebbe servire via ssh o semplicemente su pc dove non vi è un ambiente grafico..
Pensavo di usare pygtk pero' non ho mai usato glade e devo imparare da 0...
consigli?
Grazie!
pyGTK non lo conosco, io uso wxPython (http://www.wxpython.org/), che è un bind per le wxWidget.
Ci sono molti GUI builder come wxGlade (anche DialogBlocks credo) o altri che permettono di disegnare la GUI e poi ti generano il relativo codice in python, ti permettono di associare un bottone a una funzione, etc... molto comodi e veloci per generare il codice che poi ottimizzi a mano, oppure lo usi come bozza o per vedere come si fanno le cose.
Un buon IDE è PyDev, http://pydev.sourceforge.net/screenshots.html, un plugin per eclipse per sviluppare in Python. Devo ancora provarlo pero, non quanto sia valido.
edit: l'ho appena installato, è molto buono: autocompletamento, refractoring, test unit, debugger...
cavolo veramente utile questo plugin mi sento un po' come su visualstudio solo che poi la roba che scrivo funziona anche :D
ho letto qualcosa sulle pygtk e mi garbano molto... con glade-3 sembra relativamente semplice disegnare le gui e poi integrarle a python...
ora finisco alcuni lavori sulla versione in bash e poi mi dedico completamente alla "traduzione"
darkbasic
14-10-2007, 17:10
pyqt + kdevelop designer? ;)
non mi garbano molto ultimamente le qt...
pero' le prendero' in considerazione...
Su questa pagina c'è l'elenco dei toolkit grafici disponibili per python, volendo c'è parecchia scelta oltre a gtk e qt (anche se sono le piu indicate):
GUI Programming in Python (http://wiki.python.org/moin/GuiProgramming?highlight=%28gui%29%7C%28programming%29)
Ad esempio le FullTick, sono delle librerie grafiche di base leggerissime fatte apposta per essere compilate staticamente nel programma, in modo da non portarsi dietro troppe dipendenze.
(almeno in c++ si compilano staticamente, in python non so che modalità usano, ci sara un modulo da copiare nella cartella del tuo eseguibile)
Grazie è proprio da quel sito che ho conosciuto pygtk...
Ho usato un po' eclipse e devo dire che me gusta veramente tanto...
La parte piu' pallosa è gestire tutti i comandi che devo dare via shell... ho visto che alcuni programmi lavorano tipo:
script bash di base => carica lo script python con la gui => lo script python carica un nuovo (o lo stesso) script passandogli delle istruzioni in modo da eseguire una dietro l'altra le istruzioni...
Mi sa che pero' scrivero' tutto in python e usero' os.system e altre funzioni simili per gestire i comandi da shell cercando di creare funzioni ad hoc e il piu' astratto possibile...
Infatti non ha molto senso scrivere un programma in python che fa eseguire i comandi alla bash, sarebbe una sorta wrapper, tanto valeva farlo in bash.
Per molte delle operazioni che si eseguono normalmente da shell c'è una funzione nel modulo os gia pronta, ad esempio invece di os.system("cp .config .config_old") è meglio chiamare os.rename(".config", ".config_old"), e cosi per tutte le altre.
Anche per il resto è meglio non appogiarsi alla shell. Per leggere i dati della CPU, non è molto elegante fare:
cpu_model = os.system("cat /proc/cpuinfo | grep \"model name\" | sed bla bla bla")
processor = os.system("cat /proc/cpuinfo | grep \"processor\" | sed bla bla bla")
flags = os.system("cat /proc/cpuinfo | grep \"flags\" | sed bla bla bla")
Piuttosto scrivi una funzione che legge il file /proc/cpuinfo e carica i dati su un dizionario:
proc_cpuinfo = file("/proc/cpuinfo", "r").readlines()
cpuinfo=dict()
for i in proc_cpuinfo:
if i.find(":") != -1:
cpuinfo[ i[0:i.find(":")].strip() ] = i[i.find(":")+1:].strip()
cosi dopo puoi fare:
# Stampa modello cpu
print cpuinfo["model name"]
# SMP?
if cpuinfo['processor']>"0":
print "Abilita smp"
else:
print "Disabilita smp"
# PAE?
if cpuinfo['flags'].count("pae")==1:
print "Supporta PAE"
else:
print "Non supporta PAE"
Spettacolo...
Questo linguaggio mi piace sempre di piu'!
Quello era solo un esempio, poi non ti conviene lavorare direttamente sul dizionario, piuttosto lo metti un una classe come questa:
import sys,os
class CPUinfo:
def __init__(self):
self.__cpuinfo = dict()
def getCPUinfo(self):
proc_cpuinfo = file("/proc/cpuinfo", "r").readlines()
for line in proc_cpuinfo:
if line.find(":") != -1:
self.__cpuinfo[ line[0:line.find(":")].strip() ] = line[line.find(":")+1:].strip()
def ModelName(self):
return self.__cpuinfo["model name"]
def Vendor(self):
return self.__cpuinfo["vendor_id"]
def NumCPU(self):
return int(self.__cpuinfo["processor"]) + 1
def Frequency(self):
return float( self.__cpuinfo["cpu MHz"] )
def Extension(self):
return [ e for e in self.__cpuinfo["flags"].split(" ") ]
cosi dopo è molto piu semplice da usare:
myCPU = CPUinfo()
myCPU.getCPUinfo()
print "Hai un", myCPU.ModelName(), "da", myCPU.Frequency()
if myCPU.NumCPU() > 1:
print "Multi core"
else:
print "Single core"
if "vt" in myCPU.Extension():
print "Virtualizzazione OK"
else:
print "Niente virtualizzazione"
print "Estensioni supportate:"
for estensione in myCPU.Extension():
print estensione
Un codice cosi lo scrivi in due minuti, a fare la stessa cosa in bash ci perdi un quarto d'ora e viene una schifezza da leggere.
Ti fai un po di classi cosi e ci carichi dentro tutto quello che ti serve da /proc (file system usati, periferiche, memoria, etc), dopo è uno scherzo decidere come ottimizzare il kernel.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.