Blog recenti
Da Wiki di NetBSD Italia.
Guardare i commit e' istruttivoProprio cosi'. Sono stato illuminato grazie a due banali commit effettuati su NetBSD Changes. In genere utilizzo i commit piu' importanti per allestire delle notizie tecniche sul wiki (vedi in basso). In effetti, anche solo questo e' sufficiente per incrementare lievemente le mie competenze relative ai sorgenti del sistema, a come vengono gestiti e quali file toccare in alcune occasioni; di certo non tutte visto che i campi applicativi e le possibili modifiche sono pressoche' infinite. Tuttavia, piu' passa il tempo e piu' ci si fa' un'idea piu' o meno chiara della situazione all'interno di src. Tra l'altro, quando ci sono piu' commit relativi alla stessa modifica, ci si rende chiaramente conto di cosa bisogna toccare quando si mettono le mani a quella categoria di sorgenti ed eventualmente come funziona quel supporto specifico. Mi piace definire questo sistema come kernel watching learning (KWL). Oggi ad esempio, motivo che mi ha spinto a bloggare, ho appreso due concetti banali se vogliamo, ma comunque indispensabili in alcuni casi. Innanzi tutto appare chiaro che se bisogna caricare un supporto dalla radice del kernel (la cosiddetta root) basta includere una chiamata a config_rootfound() direttamente in src/sys/kern/init_main.c, possibilmente all'interno di un #ifdef NOMESUPPORTO, come nel seguente codice (rimosso nel commit #1.396), facendo in modo che il kernel carichi tale supporto integrato come se fosse uno pseudo-device (non disattivabile dal file di configurazione del kernel in fase di compilazione): #if NGPIOSIM > 0
config_rootfound("gpiosim", NULL);
#endif
Inoltre, sembra conseguenziale il fatto che ogni chiamata a config_rootfound() puo' essere rimpiazzata da uno pseudo-device, allegerendo cosi' la radice del kernel; probabilmente e' per questo che dopo il commit #1.396, non c'e' piu' alcuna chiamata a tale funzione in init_main.c. Un altro dato meno importante ma altrettanto utile e' relativo al commit #1.317) che mostra chiaramente come aggiungere un nuovo supporto PCI al kernel: # Marvell Serial-ATA Host Controller attach mvsata at pci with mvsata_pci file dev/pci/mvsata_pci.c mvsata_pci Naturalmente il file mvsata_pci.c dev'essere presente altrimenti non solo non avrebbe senso il commit ma ci sarebbe anche un errore in fase di compilazione a causa del file mancante. Qualora si decidesse di includere un nuovo supporto ata(4), bastera' includere il file sorgente con un nome rilevante nella directory dev/ata/ ed aggiungere (almeno) le direttive attach e file all'interno del file dev/ata/files.ata. La logica vale per qualsiasi altro tipo di supporto. Grandioso! Chi avrebbe mai pensato che un kernel, per quanto complesso, avesse delle caratteristiche cosi' semplici? Ovviamente questo non basta ad essere kernel hackers ma avere una buona infarinatura, una visione generale, puo' semplificare la vita nella risoluzione dei problemi e magari, un giorno, nella scrittura del nostro primo supporto per il kernel. Happy commit! :-) Notizie tecnicheCommit relativi
|
Eccoci qua, ancora una volta. Va' benissimo anche senza audio e/o senza ACPI. Tutto sommato potro' benissimo fare a meno del supporto ACPI in favore di qualche Ogg Vorbis di BSDTalk di tanto in tanto. Ma questo maledettissimo rumore proprio non lo sopporto piu'! Mi privo letteralmente di stentare un briciolo di uptime(1) e di stare volentieri al PC per questo insopportabile e continuo, monotono, martellante ronzio della ventola che gira a velocita' folla per raffreddare i core della CPU che si aggirano entrambi intorno ai 60 gradi. Mi costringe a passare ore su un laptop con GNU/Linux! SNAFU. Tutto questo perche', per qualche bizzarro motivo, il supporto per l'Intel Enanched Speedstep Technology, che e' regolarmente supportato dalla mia CPU, non e' gestito da NetBSD. Non che il sistema non implementi tale tecnologia; semplicemente la mia versione non e' supportata (?). Stento a credere a quello che io stesso sto' dicendo... Giusto perche' nessuno e' stato ancora in grado di aiutarmi mi sono sentito in dovere, dopo qualche consiglio del buon vecchio amico leot, di rompere un po' i cosiddetti coglioni in giro per la comunita'. Il risultato dopo estenuanti videopoker ore di ricerche e discussioni su #NetBSD@Freenode e' stato questo post su netbsd-users. Che la comunita' me la mandi buona!
|
E' evidente che qualcuno nel BSD-paradise ce l'ha con me. Avevo risolto tutto, era tutto funzionante, l'orgasmo geek stava finalmente invadendo per l'ennesima volta il mio ego e il mio hardware. Era troppo bello per essere vero. Infatti, di punto in bianco, il signor azalia(4) ha pensato bene di venire a guastare la festa attaccando brighe col supporto acpi(4). L'effetto principale e' che l'audio semplicemente non funziona. O meglio, funziona la riproduzione di un qualsiasi file con un qualsiasi riproduttore si blocca in un ciclo infinito subito dopo l'avvio, ripetendo ininterrottamente il primo secondo del file. A questo punto, dopo il doveroso tentativo di avviare il sistema passando al comando boot del bootloader l'opzione -2 (disabilitando il supporto ACPI), mi ritrovo con l'audio che funziona e l'ACPI disabilitato. Inoltre, per una serie di bizzarri motivi, non posso disabilitare l'ACPI direttamente dal file di configurazione del kernel essendo costretto a impostare in /boot.cfg la flag -2 di default. Al di la' del fatto che non posso spegnere la macchina in maniera normale (cioe' come si farebbe con qualsiasi altro sistema operativo) c'e' l'anomalia del kernel, che piu' che un'anomalia sembrerebbe una collezione di sviste:
Insomma, una serie di considerazioni tecniche e in qualche modo etiche che per me sono inaccettabili. Per questo motivo, aihme', vi scrivo da un sistema FreeBSD (non pensavate davvero che avrei rimesso GNU/Linux!?) col quale non ho avuto assolutamente alcun problema eccetto per l'estrema scomodita' (pratica e mentale) causata dalla (il)logicita' del sistema. Una delle cose divertenti e' che ho dovuto caricare il modulo snd_hda per poter utilizzare l'audio ed e' stato necessario resettare lo stato del kernel relativo a kern.securelevel, il quale se impostato a 2 non consente la configurazione di X11 a causa dell'impossibilita' di caricare i moduli dei driver video. Apparte questo, non c'e' stato verso di disabilitare il cosiddetto boot selector (quello che su NetBSD compare qualora ci fosse il file /boot.cfg per intenderci) lasciando il normale prompt del loader. In compenso ho trovato un ottima infrastruttura per la gestione della tastiera in console; e' veramente potente questa impostazione. Qualsiasi spiegazione sarebbe inutile di fronte alla disarmante autoesplicazione del file per la keymap: # alt # scan cntrl alt alt cntrl lock # code base shift cntrl shift alt shift cntrl shift state # ------------------------------------------------------------------ 000 nop nop nop nop nop nop nop nop O 001 esc esc esc esc esc esc debug esc O 002 '1' '!' nop nop '1' '!' nop nop O [ ... ] Per invertire caps lock e backspace non ho dovuto fare altro che invertire i numeri (scan code) delle relative righe (ovvero 014 e 058) e utilizzare questo nuovo layout come predefinito. Non e' stato possibile utilizzare il layout dvorak normale e poi apportare solo questa modifica come si fa su NetBSD ad esempio, tramite la direttiva mapfile di wscons.conf(4). Tuttavia e' stato piuttosto comodo creare il layout dvoraky (la variante dvorakx gia' c'e') e utilizzarlo semplicemente come layout predefinito. Potrebbe essere istruttivo dare un'occhiata alla keymap del layout dvorak classico per farsi un'idea piu' ampia. Per concludere sottolineo solamente che mi piacerebbe capire perche' il backspace su ELinks non funziona. I misteri della fede... Ad ogni modo, complessivamente non mi lamento. Aspettero' anzioso che azalia e ACPI facciano pace per tornare nuovamente e definitivamente a NetBSD, stavolta sul PC primario.
|
Buon giorno!!!!Sono Philbsd (alias Pietro) sono un fortunato/sfortunato possessore di imac che l'altro giorno ha deciso di cambiare os, passando da una debian@linux a Netbsd.. Fortunato perché ha un bello schermo e un hardware abbastanza potente (calcolando che ha 7 anni di vita) Sfortunato perché non ha i driver della scheda video (eccetto i vecchi nv), e perchè molti pacchetti non si compilano sul powerpc (troppi problemi e pochi sviluppatori) ..
|
Meno di una settimana fa ho aggiunto su pkgsrc-wip frozen-bubble-2.2.0. Su pkgsrc c'è già games/frozen-bubble ma una versione datata, la 1.0.0. Tuttavia a differenza della versione 1.0.0 la 2.2.0 necessita di devel/SDL_Pango con una patch. Per semplificare la vita dell'utente e del potenziale tester ho anche aggiunto wip/SDL_Pango che altro non è che devel/SDL_Pango con l'apposito PATCHFILES (molto comoda e potente... più usi pkgsrc e più te ne innamori). Attualmente il pacchetto necessita ancora di qualche revisione, quindi: se avete qualche minuto libero, vi piace questo gioco e non avete installato devel/SDL_Pango vi prego di provarlo, magari tramite il canale #NetBSD-it ci possiamo metter d'accordo per qualche partita in rete (no, non significa cazzeggiare, è puro testing questo ;-)). Per ora c'è il freeze per pkgsrc-2008Q4... quindi spero che riusciremo ad aggiornare games/frozen-bubble importando wip/frozen-bubble per pkgsrc-2009Q1. Vi ringrazio in anticipo, buon divertimento e buon Natale!
|
Gli utenti NetBSD, soprattutto gli utenti che utilizzano NetBSD su dispositivi portatili, hanno spesso l'esigenza che, per ragioni di privacy, i loro dati rimangano loro. Da poco tempo ho avuto questa esigenza anche io, nella /home non ho nulla di personale, eccetto dei file di configurazione che hanno password in chiaro (vedere mail/msmtp, wip/fdm e probabilmente molti altri programmi). Chiunque abbia accesso alla macchina, basta che avvii in single-user mode (senza sapere nessuna password) e diventa padrone della macchina (e dei dati). Perciò ho deciso di fare una piccola /home (600MB circa) criptata, mentre i miei documenti (non personali) /home/leot/documents non criptati (8GB circa). Per criptare la /home su NetBSD abbiamo diverse alternative, o utilizziamo filesystem in user-space come filesystems/fuse-cryptofs o filesystems/fuse-encfs tramite refuse(3) (presente dalla 5.0) oppure il nativo cgd(4). Dato che cgd(4) è presete dalla 2.0, abilitato anche in GENERIC (e quindi parte integrante del sistema operativo) e ben documentato ho scelto quest'ultimo. La configurazione non è stata difficile grazie all'ottima documentazione ed alla semplicità di cgdconfig(8). Prima di tutto tramite disklabel(8) individuo la partizione da criptare (che verrà ovviamente sovrascritta, quindi prima di provare cgd(4) effettuate sempre un backup): # disklabel wd0 La partizione da criptare è la wd0h, siccome è vuota (prima di cgd(4) la partizione da 8GB era montata come /home, mentre quella da 600MB non era neache montata) inizio subito a preparare la partizione criptata, come tipo di filesystem impostiamo ccd in modo tale da distinguerla facilmente dalle altre non criptate:
# disklabel -i wd0
partition> h
Filesystem type [?] [4.2BSD]: ccd
Start offset ('x' to start after partition 'x') [30008.1c, 30248127s, 14769.6M]:
Partition size ('$' for all remaining) [1263.94c, 1274049s, 622.094M]:
partition> W
Label disk [n]? y
partition> Q
Il risultato sarà la seguente partizione: # disklabel wd0 | grep " h:" h: 1274049 30248127 ccd # (Cyl. 30008*- 31271) Ora tramite cgdconfig(8) creiamo il file di configurazione necessario (tramite il flag -g) e impostiamo la password che cripterà la nostra wd0h: # cgdconfig -g -V disklabel -o /etc/cgd/wd0h aes-cbc 256 # cgdconfig -V re-enter cgd0 /dev/wd0h Infine creiamo la partizione cgd0h tramite disklabel(8), questa partizione dovrà avere le stesse dimensioni di wd0h: # disklabel -e -I cgd0 # /dev/rcgd0d: type: cgd disk: cgd label: fictitious [...] # size offset fstype [fsize bsize cpg/sgs] d: 1274049 0 unused 0 0 # (Cyl. 0 - 622*) h: 1274049 0 4.2BSD 0 0 0 # (Cyl. 0 - 622*) Ecco fatto, ora gli ultimi ritocchi: fstab(5) e rc.conf(5). # ${EDITOR} /etc/fstab
[...]
/dev/cgd0h /home ffs rw,softdep 1 2
/dev/wd0g /home/leot/documents ffs rw,softdep,union 1 2
[...]
# ${EDITOR} /etc/rc.conf
[...]
cgd=YES
[...]
Perfetto! Al prossimo riavvio avremo la /home criptata mentre la /home/leot/documents non criptata. Quindi tutti i file presenti su /home/leot saranno criptati (eccetto quelli nella subdirectory documents/). Ora ad ogni riavvio ci verrà chiesta la password per montare automaticamente le partizioni cgd(4). Buon divertimento con cgd(4)!
|
Devo ammettere che la scheda azalia(4) presente nell'Eee PC ha molti mixer configurabili tramite mixerctl(1) e dato che questo pomeriggio volevo provare i microfoni dell'Eee PC, sia quello interno vicino alla webcam, che il supporto del microfono esterno ho deciso di condividere gli "appunti" tramite questo post. Prima di tutto per registare l'audio dal microfono possiamo utilizzare il classico audiorecord(1) semplicemente in questo modo: $ audiorecord hello_neeetbsd.wav Per concludere la registrazione basta interrompere il programma con C-c (Control + c). Per ascoltare ciò che abbiamo registrato: $ audioplay hello_neeetbsd.wav Se il volume del microfono fosse troppo basso si può impostare un volume più alto in questo modo: $ mixerctl -w record.volume=224,224 Ricordo che record.volume influenzerà il volume sia del microfono interno (da qui in poi imic) che quello di un eventuale microfono esterno (mic). Inoltre di default entrambi i microfoni sono abilitati (provate a verificarlo soffiando su imic), per disabilitarli: $ mixerctl -w mix.mix0b.imic.mute=on $ mixerctl -w mix.mix0b.mic.mute=on Riguardo al volume delle casse o eventuali cuffie è come al solito outputs.master. Da notare che questo valore viene modificato anche dalla combinazione di tasti Fn + F7 (disattiva/attiva l'audio), Fn + F8 (diminuisce il volume di 3), Fn + F9 (alza il volume di 3). Una volta che abbiamo trovato le nostre impostazioni preferite possiamo salvare il tutto e fare in modo che il sistema rc(8) avvii automaticamente le nostre impostazioni preferite: # mixerctl -a > /etc/mixerctl.conf # echo "mixerctl=YES" >> /etc/rc.conf Questo è tutto, buon ascolto con NetBSD!
|
Meno di una settimana fa ho ricevuto un Eee PC 900. Una volta scartato dalla scatola l'ho acceso ed ho provato il GNU/Linux preinstallato. Insoddisfatto del GNU/Linux (piuttosto restrittivo secondo me) ho installato NetBSD su questo netbook direttamente nel disco SSD, in modo da essere a mio agio ovunque (o quasi). :-) Il primo problema che è subito venuto alla luce è stato: come installerò NetBSD? (l'Eee PC non ha un lettore CD o DVD). Nell'ottima pagina relativa a NetBSD sui netbook ho letto che uno tra i possibili metodi era quello di fare il boot tramite scheda di rete. Questo metodo mi è sembrato a prima vista un po' troppo invasivo e quindi ho optato per altri metodi. Questo netbook ha infatti 3 porte USB 2.0 e uno lettore di card SD, e dando un occhiata veloce al BIOS ho subito visto che il boot da questi dispositivi era supportato. Ho quindi preso una chiavetta USB (dovrebbe bastare una da qualche decina di MB, perché tanto la scheda lii(4) è supportata anche dal kernel di installazione, nel mio caso era da 1GB) dove ho estratto l'immagine ISO di NetBSD 5.0_BETA seguendo questa utilissima guida. L'installazione è stata molto veloce ed al primo boot ho subito messo a posto rc.conf(5) e tramite pkg_add(1) ho installato i vari pacchetti di cui ho bisogno (generati tramite pkgtools/pkg_tarup ed il target package di pkgsrc sulla mia workstation principale con NetBSD 4.0.1), per quanto riguarda i driver per X.org modulare la scheda dell'Eee PC è una scheda che ha bisogno dei driver x11/xf86-video-intel. La scheda wireless sull'Eee PC è una ath(4), tuttavia per farla funzionare correttamente necessita di questa patch, per applicarla: $ cd /usr/src/ $ ftp http://ftp.netbsd.org/pub/NetBSD/misc/jmcneill/atheee.patch $ patch < atheee.patch L'Eee PC 900 ha anche la funzionalità di poter attaccare e staccare a caldo la scheda wireless semplicemente premendo il tasto Fn ed F2 (risulta particolarmente utile disabilitare la scheda wireless quando si utilizza la batteria ma non si ha bisogno della scheda wireless). NetBSD supporta questa funzionalità, ma per poterla sfruttare bisogna sfruttare un'altra patch scritta da jmcneill@ e proveniente da OpenBSD: $ cd /usr/src/sys/dev/pci/ $ ftp http://ftp.netbsd.org/pub/NetBSD/misc/jmcneill/ppb-hotplug.patch $ patch < ppb-hotplug.patch Una volta applicate queste due patch ho ricompilato il kernel, adattandolo all'hardware del netbook. Una volta cp(1)iato il kernel appena compilato su /netbsd, fatto il backup del kernel GENERIC su /onetbsd ed adattato boot.cfg(5) alle modifiche ho riavviato il sistema. Sia col kernel GENERIC che con il kernel più o meno ottimizzato all'Eee PC 900 il tempo di boot è equivalente (se non inferiore) a quello del GNU/Linux preinstallato (da boot(8) al login 12 secondi circa). Una volta provata la scheda ath(4), ho iniziato a provare il lettore di card SD. Per abilitarlo basta andare sul BIOS (premendo F2), Advanced, Onboard Devices Configuration, e controllare che sia abilitato Onboard CardReader (di default è abilitato), per uscire e salvare dal BIOS basta premere F10 e confermare, NetBSD rileverà la card SD come sd0, basta quindi utilizzare mount(8) (di solito) su /dev/sd0a o /dev/sd0e per montare le schede SD. La scheda audio è una scheda azalia(4), e per farla funzionare non necessitiamo di modificare nulla. Riguardo allo stato della batteria e la temperatura basta utilizzare envstat(8): $ envstat
Current CritMax CritMin CritCap Unit
[acpiacad0]
connected: OFF
[acpibat0]
present: ON
design cap: 5.200 Ah
last full cap: 0.100 Ah
technology: 1
design voltage: 8.400 V
warn cap: 0.020 Ah (20.00%)
low cap: 0.010 Ah (10.00%)
voltage: 7.598 V
charge rate: N/A
discharge rate: -0.001 A
charge: 0.070 Ah (70.00%)
charging: OFF
charge state: NORMAL
[acpitz0]
temperature: 52.000 degC
Per quanto riguarda l'uscita VGA invece potrebbe risultare utile x11(xrandr), per abilitare l'uscita VGA per clonare lo schermo: $ xrandr --output VGA --auto Per spegnere il monitor dell'Eee PC ed utilizzare solo quello collegato all'uscita: $ xrandr --output LVDS --off Insomma che dire, per qualsiasi utente NetBSD medio che vuole avere NetBSD sempre con se, un Eee PC, dato i prezzi non troppo alti, ed il supporto hardware di NetBSD potrebbe risultare una buona scelta, buon divertimento con NetBSD!
|
Non troppe settimane fa su #netbsd-it ho chiesto il client sia FTP che SFTP utilizzato e di cui si era soddisfatti per provarlo ed utilizzarlo. Allora Claudio mi consigliò di provare net/lftp. È piuttosto buono e mi sono trovato subito bene. Dopo un po' di tempo che lo utilizzo però scopro che net/lftp è un datato, in pkgsrc c'è infatti la versione 3.5.11. pkgsrc/doc/TODO mi conferma ciò e ieri inizio a lavorarci su per aggiornarlo alla versione 3.7.3 (l'ultima stabile). Mi sono imbattuto in un problema che non mi era mai capitato: le patch. Aggiornare il Makefile ed il distinfo è un bazzecola ma capire le patch ed il perché vengono utilizzate non è sempre semplice. Allora ho iniziato a capirle (grazie anche a joerg@ su #pkgsrc) e commentarle per poi finire l'aggiornamento con un PR: pkg/39809. Morale della storia: se le patch non sono chiare, commentatele! :-)
|
Poche settimane fa e l'altro ieri ho aggiunto wip/dmenu e wip/dwm. Oltre al fatto che i rispettivi x11/dmenu e wm/dwm sono abbastanza datati essi utilizzano delle patch che spingono inevitabilmente il MAINTAINER (o chi per lui) ad ogni nuovo aggiornamento a rigenerare tutte le patch. Per risolvere questo problema ed eliminare le patch il framework SUBST fa al caso nostro. Se avete 5 minuti liberi e siete utenti x11/dmenu e/o wm/dwm vi prego di dare un occhiata a wip/dmenu e/o wip/dwm e perché no migliorarli. Grazie.
|
