Da tempo non andavo a leggere le ultime su disinformazione.it. Peccato, è una buona abitudine... non mi sono mai pentito di aver dato una letta a ciò che propone questo angolo di web.
Ultima chicca una "riflessione/indagine" su Beppe Grillo e il suo editore. Secondo me un articolo che vale la pena di leggere. Non mi dilungo oltre e vi lascio il link: http://www.disinformazione.it/beppe_grillo.htm. Eventuali considerazioni personali le riamando al futuro. Una cosa sola voglio ricordare; è bene sempre sentire il maggior numero di campane possibili e, tanto per continuare a metafore, ricordare che tutte le monete hanno due facce.
giovedì 27 dicembre 2007
Prima di Napster
Quando la "Pirateria" copia era analogica!
Saranno le feste di Natale che, un poco, mi fanno tornare bambino. Saranno i discorsi nostalgici, fatti nelle lunghe serate fredde e noiose, di gente che comincia a sentire le primavere che ha sul groppone. Saranno le discussioni sui DRM e le loro conseguenze. Saranno i ragazzini, del giorno d'oggi, sempre con gli auricolari dell' iPod, o affini, infilati nelle orecchie. Qualsiasi cosa sia, ultimamente sto pensando molto al "come eravamo". In particolare mi è tornato alla mente il periodo delle mie scuole medie e primi anni delle superiori.
Era l'inizio dell'"era digitale". I sitemi operativi di casa Microsoft (MS-DOS) erano ancora a 16 bit. Linux, agli "albori", era ancora una cosa per pochi "eletti".
Anche se i CD audio avevano ormai compiuto 10 anni, gli LP venivano ancora commercializzati nel formato MC (musicassetta). E proprio le "cassettine" erano il supporto prediletto da noi ragazzini. C'era tutto un giro di cassette fra amici e compagni di classe. Un amico ti prestava una cassetta, tu la infilavi nel tuo stereo, con la doppia piastra, insieme ad una "vergine", o una che non ti interessava più, e, finito l'ascolto, avevi la tua brava copia piratata. Esistevano anche degli Hi-Fi che davano la possibilità di fare copie ad alta velocità, il risultato spesso era scadente ma, durante la copia, c'era da pisciarsi addosso dalle risate.
Così, anche senza peer2peer, la musica veniva copiata e scambiata... di mano in mano, non garantendo nessuna qualità per la copia della copia della coppia...
Anche i CD, comunque, venivano copiati... su musicassette ovviamente! Quasi tutti avevamo in casa uno di quei mastodontici stereo che "leggevano" di tutto, dal Vinile all'ottico. Tuttavia questi colossi ingombranti riuscivano a "incidere" solo su cassetta.
Erano tempi d'oro anche per quelli che noi chiamavamo Walkman. In realtà nessuno, o quasi, aveva un Walkman originale... avevamo tutti dei mangianastri portatili a batterie, in pratica delle, più o meno valide, imitazioni. Sarebbe come se oggi chiamassimo "iPod" tutti i lettori mp3.
Non era come adesso. I mangianastri erano ingombranti e non li si aveva sempre dietro. Le cassette non contenevano tanta musica quindi, oltre al mangianastri, bisognava portarsi dietro anche 2 o 3 cassette. Le meccaniche dei mangianastri divoravano le batterie (di solito due stilo AA) e quindi un cambio era d'obbligo. Verso la fine delle batterie la cassetta cominciava a girare più lenta... ma ormai c'eravamo abituati e sopportavamo. Gli auricolari erano usati da pochi, solitamente servivano ad ascoltare in 2 contemporaneamente... un auricolare a testa, di solito si preferivano le cuffie, più ingombranti certamente ma sicuramente più comode. Oggi con un lettore mp3 grande come una supposta le cuffie farebbero troppo ingombro. Poi la cuffia appesa al collo andava di moda allora! Di Walkman in gita ne vedevi di tutte le razze e caste. Dal più economico e grezzo con solo l'avanzamento del nastro, per riavvolgere si girava la cassetta. Al più sofisticato: con 2 uscite per le cuffie, equalizzatore, radio, riavvolgimento, ecc... In ogni caso la qualità dei nastri era sempre dubbia, originali o non che fossero, si rovinavano con una facilità incredibile. Alle volte i fruscii coprivano la canzone, altre volte il volume si abbassava tanto che riuscivi ad avvertire il rumore delle meccaniche. Il volume si regolava con dei potenziometri, che si ossidano facilmente, e non era difficile sentire delle belle "scorreggione" coprire la tua musica. Alcuni mangianastri portatili avevano, come le autoradio, la capacità di farti avanzare di una "traccia" automaticamente. Ovviamente le cassette non erano nate per simili funzioni e, manco a dirlo, la procedura era lenta e, molto spesso, imprecisa.
I lettori CD portatili costavano ancora troppo... e poi, salvo la maggiore qualità del suono, non erano poi molto più pratici dei Walkman.
Certi mangianastri, vecchi o di bassa qualità, alla volte aggrovigliavano il nastro attorno alle meccaniche. L'autoradio di mio Padre era imbattibile in questo. Alle volte si doveva faticare parecchio per estrarre la cassetta e, soprattutto, il suo contenuto dall'apparecchio. Poi, se il nastro si era salvato, con una penna a sfera si faceva girare una matassa della cassetta sino a far rientrare tutto il nastro uscito. Ovviamente quella sezione di nastro, spiegazzata ben bene, non avrebbe mai più riavuto la stessa qualità.
Molti avevano ancora l'abitudine di tenere sempre un nastro vergine nello stereo per registrare le canzoni quando passavano alla radio. Ci si facevano delle vere e proprie compilation, come si sarebbe fatto poi con i CD e gli mp3 scaricati dalla rete. Ovviamente la qualità di queste "opere" era infima: rarissimamente la canzone attaccava dall'inizio, spesso rimaneva traccia di qualche vaccata sparata dal Dj di turno, ogni traccia iniziava e finiva con un bel scorreggione, non mancava mai un minimo di pubblicità, magari c'erano delle traccie stereo e altre mono. Insomma, erano altri tempi!
Sulle musicassette ci si registravano anche i dati per i Personal Computer. Chi non si ricorda i giochi in cassetta del C=64 e affini!?! Qualche volta il mio stereo a doppia piastra è anche riuscito a duplicare delle cassette per C=64.
Avevo scatole da scarpe interamente piene di musicassette. E ancora ne ho molte sperse per casa. Alcune hanno ancora il nastro adesivo attaccato sopra, lo si usava per "aggirare" la, totalmente meccanica, "protezione anti-scrittura". Le musicassette, infatti, hanno un sistema "anti registrazione accidentale", del tutto analogo a quello dei VCR, costituito da due, uno per lato, fori "tappati" da una linguetta di plastica staccabile, bisognava spezzarla se si voleva "attivare la protezione".
La musicassetta è stato un gran supporto. Economico e flessibile. Il primo supporto ad aver permesso a tutti di registrare. Oggi sembra un mezzo grezzo e inaffidabile. Però, a testimonianza della sua diffusione e bontà, ancora alcuni impianti Hi-Fi hanno almeno una piastra. La doppia piastra è quasi sparita, ormai quasi tutti hanno in casa un masterizzatore e, comunque, a nessuno verrebbe più in mente di registrare musica si MC.
Ho appreso proprio durante la stesura di questo post che Currys, una fra le maggiori catene Inglesi di distribuzione di materiale elettronico, ha deciso di non trattare più questo supporto.
Insomma, ormai obsoleta, la musicassetta sta definitivamente tramontando. Comunque per la sua validità và, secondo me, ricordata.
Questo post aveva originariamente proprio l'intento di ricordare questa tecnologia. Alla fine, invece, è divenuta una trascrizione disordinata, e me ne scuso, dei miei ricordi. Ricordi dei tempi delle Cassette suonate nei Wolkman o nei stereoloni portati sulla spalla. I tempi in cui le canzoni negli LP non erano la traccia 1, 2, 3, ecc... ma stavano semplicemente sul lato A o sul lato B, e per cercarsele dovevi girare la cassetta e lavorare di REW e FWD. Troppi ricordi per stare in un solo post! Magari un giorno faccio il "Lato B".
Saranno le feste di Natale che, un poco, mi fanno tornare bambino. Saranno i discorsi nostalgici, fatti nelle lunghe serate fredde e noiose, di gente che comincia a sentire le primavere che ha sul groppone. Saranno le discussioni sui DRM e le loro conseguenze. Saranno i ragazzini, del giorno d'oggi, sempre con gli auricolari dell' iPod, o affini, infilati nelle orecchie. Qualsiasi cosa sia, ultimamente sto pensando molto al "come eravamo". In particolare mi è tornato alla mente il periodo delle mie scuole medie e primi anni delle superiori.
Era l'inizio dell'"era digitale". I sitemi operativi di casa Microsoft (MS-DOS) erano ancora a 16 bit. Linux, agli "albori", era ancora una cosa per pochi "eletti".
Anche se i CD audio avevano ormai compiuto 10 anni, gli LP venivano ancora commercializzati nel formato MC (musicassetta). E proprio le "cassettine" erano il supporto prediletto da noi ragazzini. C'era tutto un giro di cassette fra amici e compagni di classe. Un amico ti prestava una cassetta, tu la infilavi nel tuo stereo, con la doppia piastra, insieme ad una "vergine", o una che non ti interessava più, e, finito l'ascolto, avevi la tua brava copia piratata. Esistevano anche degli Hi-Fi che davano la possibilità di fare copie ad alta velocità, il risultato spesso era scadente ma, durante la copia, c'era da pisciarsi addosso dalle risate.
Così, anche senza peer2peer, la musica veniva copiata e scambiata... di mano in mano, non garantendo nessuna qualità per la copia della copia della coppia...
Anche i CD, comunque, venivano copiati... su musicassette ovviamente! Quasi tutti avevamo in casa uno di quei mastodontici stereo che "leggevano" di tutto, dal Vinile all'ottico. Tuttavia questi colossi ingombranti riuscivano a "incidere" solo su cassetta.
Erano tempi d'oro anche per quelli che noi chiamavamo Walkman. In realtà nessuno, o quasi, aveva un Walkman originale... avevamo tutti dei mangianastri portatili a batterie, in pratica delle, più o meno valide, imitazioni. Sarebbe come se oggi chiamassimo "iPod" tutti i lettori mp3.
Non era come adesso. I mangianastri erano ingombranti e non li si aveva sempre dietro. Le cassette non contenevano tanta musica quindi, oltre al mangianastri, bisognava portarsi dietro anche 2 o 3 cassette. Le meccaniche dei mangianastri divoravano le batterie (di solito due stilo AA) e quindi un cambio era d'obbligo. Verso la fine delle batterie la cassetta cominciava a girare più lenta... ma ormai c'eravamo abituati e sopportavamo. Gli auricolari erano usati da pochi, solitamente servivano ad ascoltare in 2 contemporaneamente... un auricolare a testa, di solito si preferivano le cuffie, più ingombranti certamente ma sicuramente più comode. Oggi con un lettore mp3 grande come una supposta le cuffie farebbero troppo ingombro. Poi la cuffia appesa al collo andava di moda allora! Di Walkman in gita ne vedevi di tutte le razze e caste. Dal più economico e grezzo con solo l'avanzamento del nastro, per riavvolgere si girava la cassetta. Al più sofisticato: con 2 uscite per le cuffie, equalizzatore, radio, riavvolgimento, ecc... In ogni caso la qualità dei nastri era sempre dubbia, originali o non che fossero, si rovinavano con una facilità incredibile. Alle volte i fruscii coprivano la canzone, altre volte il volume si abbassava tanto che riuscivi ad avvertire il rumore delle meccaniche. Il volume si regolava con dei potenziometri, che si ossidano facilmente, e non era difficile sentire delle belle "scorreggione" coprire la tua musica. Alcuni mangianastri portatili avevano, come le autoradio, la capacità di farti avanzare di una "traccia" automaticamente. Ovviamente le cassette non erano nate per simili funzioni e, manco a dirlo, la procedura era lenta e, molto spesso, imprecisa.
I lettori CD portatili costavano ancora troppo... e poi, salvo la maggiore qualità del suono, non erano poi molto più pratici dei Walkman.
Certi mangianastri, vecchi o di bassa qualità, alla volte aggrovigliavano il nastro attorno alle meccaniche. L'autoradio di mio Padre era imbattibile in questo. Alle volte si doveva faticare parecchio per estrarre la cassetta e, soprattutto, il suo contenuto dall'apparecchio. Poi, se il nastro si era salvato, con una penna a sfera si faceva girare una matassa della cassetta sino a far rientrare tutto il nastro uscito. Ovviamente quella sezione di nastro, spiegazzata ben bene, non avrebbe mai più riavuto la stessa qualità.
Molti avevano ancora l'abitudine di tenere sempre un nastro vergine nello stereo per registrare le canzoni quando passavano alla radio. Ci si facevano delle vere e proprie compilation, come si sarebbe fatto poi con i CD e gli mp3 scaricati dalla rete. Ovviamente la qualità di queste "opere" era infima: rarissimamente la canzone attaccava dall'inizio, spesso rimaneva traccia di qualche vaccata sparata dal Dj di turno, ogni traccia iniziava e finiva con un bel scorreggione, non mancava mai un minimo di pubblicità, magari c'erano delle traccie stereo e altre mono. Insomma, erano altri tempi!
Sulle musicassette ci si registravano anche i dati per i Personal Computer. Chi non si ricorda i giochi in cassetta del C=64 e affini!?! Qualche volta il mio stereo a doppia piastra è anche riuscito a duplicare delle cassette per C=64.
Avevo scatole da scarpe interamente piene di musicassette. E ancora ne ho molte sperse per casa. Alcune hanno ancora il nastro adesivo attaccato sopra, lo si usava per "aggirare" la, totalmente meccanica, "protezione anti-scrittura". Le musicassette, infatti, hanno un sistema "anti registrazione accidentale", del tutto analogo a quello dei VCR, costituito da due, uno per lato, fori "tappati" da una linguetta di plastica staccabile, bisognava spezzarla se si voleva "attivare la protezione".
La musicassetta è stato un gran supporto. Economico e flessibile. Il primo supporto ad aver permesso a tutti di registrare. Oggi sembra un mezzo grezzo e inaffidabile. Però, a testimonianza della sua diffusione e bontà, ancora alcuni impianti Hi-Fi hanno almeno una piastra. La doppia piastra è quasi sparita, ormai quasi tutti hanno in casa un masterizzatore e, comunque, a nessuno verrebbe più in mente di registrare musica si MC.
Ho appreso proprio durante la stesura di questo post che Currys, una fra le maggiori catene Inglesi di distribuzione di materiale elettronico, ha deciso di non trattare più questo supporto.
Insomma, ormai obsoleta, la musicassetta sta definitivamente tramontando. Comunque per la sua validità và, secondo me, ricordata.
Questo post aveva originariamente proprio l'intento di ricordare questa tecnologia. Alla fine, invece, è divenuta una trascrizione disordinata, e me ne scuso, dei miei ricordi. Ricordi dei tempi delle Cassette suonate nei Wolkman o nei stereoloni portati sulla spalla. I tempi in cui le canzoni negli LP non erano la traccia 1, 2, 3, ecc... ma stavano semplicemente sul lato A o sul lato B, e per cercarsele dovevi girare la cassetta e lavorare di REW e FWD. Troppi ricordi per stare in un solo post! Magari un giorno faccio il "Lato B".
lunedì 24 dicembre 2007
giovedì 20 dicembre 2007
Il Vero Programmatore!
Lo so, è vecchia! La sua prima "relase" sembra risalire al 1982... ma a me piace comunque!
IL VERO PROGRAMMATORE
=====================
Tornando indietro ai vecchi e gloriosi giorni dell'informatica
primordiale era relativamente facile distinguere tra veri uomini e
ragazzini (nella letteratura classica la distinzione e' tra "veri
uomini" e "mangia-quiche").
Durante quei tempi i Veri Uomini erano gli unici che si intendevano di
computer, gli altri (i ragazzini o "mangiatori di quiche") erano quelli
che di computer non se ne intendevano.
I Veri Uomini dicevano cose come "DO 10 I=1,10" o "ABEND" (ovviamente
parlando in lettere maiuscole, mi sembra ovvio), mentre il resto della
gente diceva semplicemente che i computer erano cose troppo complicate
per loro. (sempre il lavoro [1] dice appunto che non esistono cose
troppo complicate per il vero uomo).
Ma, come in tutte le cose, i tempi cambiano, adesso viviamo in tempi in
cui anche le vecchiette hanno dei computer dentro i loro forni a
microonde, in cui qualunque Vero Uomo puo' essere battuto da un
ragazzino di 12 anni in qualunque videogioco, in cui chiunque puo'
comperare, usare e capire un computer.
Il Vero Programmatore rischia di intraprendere la via dell'estinzione,
sopraffatto da universitari che basano la loro vita su Mouse ed Icone.
E' percio' necessario stabilire una netta distinzione tra Il Vero
Programmatore ed un universitario giocatore di Pac-Man. Se questa
distinzione sara' chiara questi giovani inesperti potranno avere un
modello guida, un padre spirituale a cui ispirarsi. Inoltre sara'
possibile spiegare ai datori di lavoro perche' non e' ne' necessario
ne' giusto sostituire dei Veri Programmatori con dei giocatori di Pac
Man, anche se il risparmio sugli stipendi sarebbe considerevole.
LINGUAGGI
=========
Il sistema piu' rapido e sicuro per distinguere un Vero programmatore
dal resto del mondo e' considerare il linguaggio che usa: il Vero
Programmatore programmava in FORTRAN, mentre ora programma in C.
I mangiatori di Quiche programmano in Pascal. Da questo si deduce che
sicuramente Niklaus Wirth era un mangiatore di Quiche e NON un Vero
Programmatore.
Ad un Vero Programmatore non servono tutte le strutture ed i meccanismi
del pascal, un Vero Programmatore puo' essere felice con un perforatore
di schede o un terminale a 1200 baud, un C a standard K&R (ANSI... a
che serve, il K&R e' fin troppo chiaro), ed una birra.
A proposito, Kerningan e Ritchie sicuramente erano dei Veri Uomini.
probabilmente anche dei veri programmatori.
- Il Vero Programmatore processa liste in C
- Il Vero Programmatore processa numeri in C
- Il Vero Programmatore manipola stringhe in C
- Il Vero Programmatore elabora programmi di IA in C
- Il Vero Programmatore fa contabilita' in C
- Il Vero Programmatore crea simulatori di reti neuronali in C
- Il Vero Programmatore starnutisce in C
- Il Vero Programmatore fa TUTTO in C
Se per caso il C non fosse sufficiente il Vero Programmatore lavorera'
in assembler, se neppure questo fosse sufficiente allora il lavoro non
e' fattibile, ma la cosa e' impossibile, un Vero Programmatore in C ed
assembler puo' fare TUTTO, per definizione.
PROGRAMMAZIONE STRUTTURATA
==========================
Gli accademici negli ultimi anni hanno stabilito, dall'alto delle loro
cattedre, che un programma e' piu' facilmente leggibile se il
programmatore utilizza particolari tecniche, strutture e costrutti.
Ovviamente essi non sono d'accordo su quali questi costrutti e queste
tecniche precisamente siano, e percio' le loro teorie sono discordanti
ed erratiche. In questo modo solo alcuni mangia-Quiche si lasciano
convincere dai loro assiomi.
Un tipico lavoro del mondo reale (e non un lavoro teorico da
universita') e' di prendere un sorgente di 100.000 o 200.000 linee e
farlo andare il doppio piu' veloce. In questo caso qualunque Vero
Programmatore vi potra' dire che la programmazione strutturata non
serve a nulla, quello che in realta' serve e' del talento.
Alcune rapide considerazioni del Vero Programmatore sulla programmazione
strutturata:
- Il Vero Programmatore non ha paura di usare GOTO
- Il Vero Programmatore puo' scrivere un ciclo DO lungo 5 pagine senza
fare confusione.
- Il Vero Programmatore usa i costrutti CASE basati su calcoli
aritmetici, essi rendono un programma piu' divertente.
- Il Vero Programmatore scrive del codice automodificante, soprattutto
se questo puo' salvare 20 nanosecondi all'interno di un ciclo.
- Il Vero Programmatore utilizza l'area di memoria di un codice gia'
eseguito e che non servira' piu' come area di memoria per i dati, ottimizzando
in questo modo lo spazio a disposizione.
- Il Vero Programmatore non ha bisogno di commenti, il codice e' gia'
autoesplicante a sufficienza.
Dopo aver parlato di programmazione strutturata si e' anche parlato
molto di strutture di dati. Tipi di dati astratti, stringhe, liste e
chi piu' ne ha piu' ne metta.
Wirth (il mangiatore di Quiche menzionato poco sopra) ha scritto un
intero libro [2] tentando di dimostrare che si puo' scrivere un intero
programma basandosi solo sulle strutture di dati.
Come ogni Vero Programmatore sa invece l'unica struttura che serve
VERAMENTE e' l'array, dato che tutti gli altri tipi di dato altro non
sono che sottoinsieme limitati di questi. e dato che sono limitati egli
usa solo puntatori, soprattutto se questi rendono possibile bombare
irrimediabilmente il computer, se no dove starebbe il divertimento?
SISTEMI OPERATIVI
=================
Che SO usa un Vero Programmatore?
UNIX? NO!, Unix e' qualcosa di simile a quello che si aspetta un vero
Hacker, dato che qualunque Vero Programmatore non trova alcun
divertimento nel tentare di indovinare come cavolo il comando PRINT
viene chiamato questa settimana. La gente non fa lavori seri su Unix,
lo usano soprattutto per fare adventure, modificare Rogue e mandarsi il
tutto via UUCP.
MS-DOS? Gia' meglio, crittico quel tanto che basta, facile da
modificare, se ce ne fosse necessita', facile da bombare, con tante
cose sconosciute e strane.
Una cosa sicuramente possiamo dire:
- Il Vero Programmatore non usa il mouse e le icone, infatti il Vero
Programmatore non capisce perche' mai per compilare un programma uno debba
staccare le mani dalla tastiera e cliccare su un menu quando e' tanto
semplice battere:
CL pippo.c -k -iC:\gnu\c\all -q -w -e -r +t -y +cvb +f -g +g +p =l /f /a
/s
Comunque il Vero Programmatore ha una sola nostalgia: il sistema IBM OS/370.
Questo era infatti il SO che qualunque Vero Programmatore vorrebbe vedere
implementato su TUTTI i computer del mondo.
Un Vero Programmatore sa che se vede comparire l'errore IJK3051 basta andare
a vedere nel manuale del JCL per capire cosa e' successo.
Un Grande Programmatore poi sapra' i codici a memoria, mentre un Grandissimo
Programmatore potra' trovare l'errore osservando 6 mega di dump senza neppure
usare un calcolatore esadecimale...
L'OS/370 e' VERAMENTE un SO potente, infatti e' possibile distruggere
giorni e giorni di lavoro con la semplice pressione di un tasto. Questo
incoraggia l'attenzione sul lavoro e forma una mentalita' che servira'
in futuro, quando per distruggere giorni di lavoro saranno sufficienti
tre tasti...
TOOL DI PROGRAMMAZIONE
======================
Quali tool di programmazione necessita realmente un Vero Programmatore?
In effetti, come detto prima sono sufficienti un terminale a 1200 baud
o un lettore di schede perforate, ma anche una semplice tastiera
esadecimale sarebbe gia' piu' che sufficiente.
Ma purtroppo adesso i computer non hanno piu' tastiere esadecimali,
come pure non hanno piu' quei magnifici pannelli frontali pieni di
lucine e tastini che facevano tanto futuro.
I primi veri programmatori sapevano a memoria l'intero settore di boot
del- l'hard disk, e lo potevano riscrivere a memoria ogniqualvolta che
il loro programma lo rovinava.
La leggenda narra che Seymore Cray (creatore del Cray I) scrisse il SO
del primo CDC7600 usando il pannello frontale del computer la prima
volta che questo venne acceso. Senza bisogno di dirlo Seymore era un
Vero Programmatore.
Uno dei migliori Veri Programmatori che abbia mai conosciuto e' un
sistemista della Texas Instrument. Una volta rispose alla telefonata di
un cliente a cui si era bombato il sistema durante il salvataggio del
lavoro. Il Vero Programmatore rimise a posto tutto facendo scrivere le
istruzioni per terminare il lavoro di I/O sul pannello frontale (allora
c'erano ancora), riscrivendo i dati rovinati in esadecimale e facendosi
dire i risultati per telefono.
La morale della storia e' che se un tastierino ed una stampante possono
far comodo un Vero Programmatore puo' arrangiarsi anche con solo un
telefono.
Un altro tool fondamentale e' un buon text editor. Molti dicono che il
migliore sia quello della Xerox di Palo Alto, ma, come gia' detto, il
Vero Programmatore non parla al suo computer attraverso un mouse.
Altri preferiscono EMACS o VI, ma in effetti il concetto di WYSYWYG
(quello che vedi e' quello che ottieni) si applica ai computer
malissimo, cosi' come si applica alle donne.
Quello che un vero programmatore vuole e' in effetti qualcosa di piu'
complesso, che implementi la filosofia del "You asked for it, you got
it !!!" (YAFIYGI, avrai solo quello che chiedi).
Insomma, l'editor perfetto e' il TECO.
Alcuni hanno osservato che una linea di comandi per TECO assomiglia
molto di piu' al rumore sulle linee telefoniche che ad una linea di
comandi, ed in effetti uno dei giochi piu' divertenti da fare e' quello
di scrivere il proprio nome sulla linea di comando e vedere cosa
succede.
Inoltre ogni piccolo errore avra' come risultato quello di distruggere
il vostro programma, o, peggio, di introdurre subdoli errori che
saranno in seguito difficilmente rintracciabili.
Per questa ragione un Vero Programmatore e' molto riluttante a editare
un programma funzionante per dargli gli ultimi ritocchi. E sempre per
questa ragione un Vero Programmatore trova piu' semplice fare le
modifiche finali utilizzando un programma come lo Zap.
Alcuni Veri Programmatori utilizzano lo Zap stesso come editor, altri
scrivono il programma direttamente in codice eseguibile, ma e' forse
esagerato.
Procedendo su questa linea il risultato e' che tra il codice sorgente e
quello che in effetti c'e' scritto su disco c'e' una discrepanza sempre
maggiore, con il risultato che il lavoro e' sempre piu' sicuro, perche'
solo un Vero Programmatore potra' lavorarci sopra in modo proficuo,
nessun mangiatore di Quiche potra' fare manutenzione, minimizzando
cosi' i rischi di malfunzionamenti ulteriori del programma. Questa e'
SICUREZZA.
Altri tool importanti sono le documentazioni su cui il vero
programmatore basa gran parte del suo lavoro:
- Il Vero Programmatore non legge mai i manuali introduttivi, bastano ed
avanzano i Reference Manual.
- Il Vero Programmatore ha imparato il C sul K&R, qualunque altro testo e'
inutile e deviante.
- Il Vero Programmatore se possibile legge i manuali in lingua originale,
anche se questo a volte pone dei problemi di reperibilita'.
- Il Vero Programmatore non colleziona libri di raccolte di algoritmi.
Questo perche' e' piu' lento cercare l'algoritmo in 3000 pagine di manuale
che scriverlo di getto.
- Il Vero Programmatore non ha bisogno di manuali sull'assembler, sono
sufficienti i data sheet dei microprocessori.
- Il Vero Programmatore non scrive MAI i manuali dei programmi che fa, non ne
ha il tempo materiale.
Il Vero Programmatore generalmente ha da qualche parte la
documentazione completa del SO su cui lavora, pubblicata dalla casa che
ha fatto il SO, ma sa che SICURAMENTE nelle 3500 pagine che in media
compongono la documentazione non trovera' quello che cerca.
Se nelle vicinanze del terminale sono presenti piu' di 5 manuali ci
sono delle forti probabilita' che NON sia un Vero Programmatore.
Alcuni Tool NON usati da un Vero Programmatore:
- Preprocessori di linguaggio.
- Traduttori di linguaggio.
- Full Screen Debugger a livello sorgente.
Il Vero Programmatore e' in grado di capire quello che dice il Debug.
- Compilatori ottimizzanti.
L'ottimizzazione del programma scritto dal Vero Programmatore e' gia' il
massimo, e percio' altre modifiche non farebbero altro che peggiorare la
situazione.
IL LAVORO DEL VERO PROGRAMMATORE
================================
In generale il Vero Programmatore non fa lavori semplici come gestione
di indirizzari o programmi gestionali, ecco alcuni dei lavori piu'
adatti ai veri programmatori:
- Il Vero Programmatore scrive programmi per la simulazione di una guerra
termonucleare per l'esercito.
- Il Vero Programmatore lavora per lo spionaggio, per decrittare le
trasmissioni in cifra del nemico.
- E' in gran parte dovuto al lavoro dei Veri Programmatori che gli americani
sono arrivati sulla Luna.
- Il Vero Programmatore programma i sistemi guida di satelliti e missili.
- In ogni caso il Vero Programmatore lavora su progetti molto importanti o
molto ben pagati.
IL VERO PROGRAMMATORE MENTRE GIOCA
==================================
Il generale il Vero Programmatore gioca nello stesso modo in cui
lavora: con i computer.
In generale lo stesso lavoro e' un gioco, ed alla fine del mese il Vero
Programmatore e' sempre abbastanza stupito di ricevere un compenso per
quello che, a tutti gli effetti, e' per lui un divertimento, anche se
non lo dira' mai a voce alta.
Occasionalmente il Vero Programmatore uscira' dall'ufficio per prendere
una boccata d'aria e farsi una birra, ecco alcuni sistemi per
riconoscere un Vero Programmatore fuori dal suo posto di lavoro:
- Ad un party i Veri Programmatori sono quelli che stanno in angolo parlando
di Sistemi Operativi, mentre di fianco a loro passano ragazze che si fermano,
ascoltano per alcuni secondi e poi, dato che non capiscono una parola, se
ne vanno. A volte un vero Programmatore incontra una Vera Programmatrice.
Vi risparmio per decenza il racconto di come si svolgono i fatti.
- Ad una partita di football il Vero Programmatore e' quello che controlla gli
schemi delle squadre basandosi su quelli disegnati dal suo programma su di
un foglio 11x14.
- Sulla spiaggia il Vero Programmatore e' quello che disegna flow chart sulla
sabbia.
- Durante un black out un Vero Programmatore generalmente sviene in quanto
vengono a mancare i vitali afflussi di energia che gli permettono di vivere.
L'HABITAT DEL VERO PROGRAMMATORE
================================
Dal momento che un vero programmatore e', per l'azienda che lo usa,
generalmente molto costoso, vediamo come fare per farlo rendere al
meglio sul posto di lavoro.
Il Vero Programmatore vive davanti ad uno o piu' monitor, attorno,
sopra, dietro e sotto questi terminali si trovano generalmente le
seguenti cose:
- I listati di TUTTI i programmi a cui il Vero Programmatore ha mai lavorato,
accatastati, in ordine piu' o meno cronologico, su ogni superficie piatta
disponibile intorno.
- Sei o piu' tazze di caffe', quasi sempre fredde, ed alcune con alcuni
mozziconi di sigaretta galleggianti.
- Attaccato al muro c'e' un ritratto di Spock con in mano l'enterprise stampato
con una vecchia stampante a margherita.
- Sparsi per terra ci sono pacchetti vuoti di noccioline e vaccate simili.
In generale un Vero Programmatore puo' lavorare anche 30 o 40 ore di
fila, anzi, di solito lavora molto megli sotto sforzo. Fino a qualche
tempo fa si concedeva dei pisolini mentre il computer compilava il
programma, ma purtroppo il diffondersi di computer e periferiche veloci
ha reso questa pratica difficile.
In generale un Vero Programmatore se ha 5 settimane per terminare un
programma passa le prime 4 cincischiando con aspetti secondari, ma
interessanti, del progetto, mentre il grosso del lavoro viene fatto in
una settimana di lavoro ininterrotto. Questo provoca sempre grosse
preoccupazioni al principale che teme sempre che il lavoro non sia mai
pronto in tempo, ed offre al Vero Programmatore una buona scusa per non
scrivere la documentazione.
VARIE ED EVENTUALI
==================
- Il Vero Programmatore a volte puo' scordare il nome della moglie o della
ragazza, ma sa a memoria il codice ASCII.
- Il Vero Programmatore non si cura della tastiera, le sue dita si
adattano automaticamente a qualunque layout.
- Il Vero Programmatore sa che anche avendo 8 mega di RAM questa non
sara' mai abbastanza, e percio' tenta di fare programmi piccoli.
- Il Vero Programmatore tiene sempre i backup da quando ha dovuto
riscrivere 327000 linee di assembler 68020.
- Il Vero Programmatore scrive programmi di pubblico dominio, anche se
di solito sono programmi talmente specialistici che serviranno solo ad
altre tre persone al mondo oltre a lui.
ALTRI COROLLARI
===============
- Il Vero Programmatore si trovava a suo agio con il Fortran in quanto
consentiva la programmazione a spaghetti senza limitazioni.
- Va comunque detto che il Vero Programmatore e' in grado di scrivere
programmi a spaghetti in qualsiasi linguaggio. In questo senso, il C va
a pennello per la sua capacita' di scrivere programmi Write-only che
nessuno, a parte un altro Vero Programmatore, sara' mai in grado di
decodificare.
- Il Vero Programmatore non mette mai commenti perche' a suo parere il
codice e' autodocumentante. Questo vale anche per i dump esadecimali di
codice assembly.
- Nel tempo libero, il Vero Programmatore va abbastanza spesso in
discoteca, ma si limita ad osservare il gioco di luci. Ultimamente,
viene stranamente attratto dal terminale del controllore laser.
- Ai funerali di un collega, il Vero Programmatore commenta:
"Peccato.. la sua routine di sort O(logN) stava quasi per funzionare"
- Le Vere Programmatrici esistono in ragione di 1 per ogni 256 Vero
Programmatori, come tale la probabilita' di incontrarne una e' estremamente
bassa.
- Il Vero Programmatore ha scarsa considerazione degli utenti, ritenuti
ad un livello troppo basso. La probabilita' di trovare un utente
competente e' stimata inferiore a quella di trovare una Vera
Programmatrice.
- Il Vero Programmatore conta in base due.
ERRATA CORRIGE
==============
- QUALE hard disk? mangianastri e ferriti!
- QUALI nastri? cassetti di schede perforate! Solo i ricchi avevano i
nastri!
- QUALI tastiere e display esadecimali? File di interruttori e LED in
binario.
- l Vero Programmatore non usa commenti: se e` stato difficile da
scrivere, deve essere difficile da leggere. Ma se e` un VERO
PROGRAMMATORE lo legge ugualmente con facilita`.
- Il Vero Programmatore usa il C, e QUINDI usa anche Unix e i
Preprocessori. Unix, almeno nelle prime versioni, e' il vero sistema
operativo contemporaneo l'unico che consente ancora di azzerare un
intero file system con un comando di sette lettere blank compresi:
rm -r /
- OS/370 era seriamente migliore, ma non bastava battere un tasto per
perdere tutto, era sufficiente sbagliare la posizione di un blank.
=========
POSTILLE:
=========
- Il Vero Programmatore edita direttamente il file Postscript di un
documento, se deve modificarlo.
- il Vero Programmatore conosce sempre almeno 16 cifre di pi greco,
di cui conosce anche la rappresentazione IEEE in esadecimale, e
(se anche fisico) tutte le cifre di c (e' definito con 9 cifre), in modo
da non aver bisogno di noiosi include files.
- Il Vero Programmatore e la programmazione ad oggetti: se costretto a
simili pratiche, il Vero Programmatore PRIMA scrive il programma, e POI,
quando funziona, ne fa un'analisi ad oggetti. Per nessuna ragione
comunque modifichera' il codice gia' scritto per conformarlo
all'analisi. Comunqe inserira' nel programma un numero sufficente di
variabili globali usate da TUTTE le classi, in modo da renderne
impossibile la manutenzione da un mangiatore di Quiche (vedi praragrafo
sulla sicurezza dei programmi).
- Il Vero Programmatore chiama le variabili con nomi autoespicativi di
massimo 5 lettere (es. CVfrZ). Solo mangiatori di Quiche usano nomi
tipo "Massimo_Numero_Di_Dipendenti" per una variabile. Se un Vero
Programmatore usa un nome simile, probabilmente la variabile indica la
velocita' terminale di uno ione in una nube molecolare (il codice e'
stato riciclato efficentemente da un programma di contabilita').
- Il capitano Picard di Star Trek TNG e' un Vero Programmatore:
riprogramma Data usando un pezzo di ferro per cortocircuitarne il
circuito di input in binario. (Time's Arrow, part II, stardate
46001.3)
REFERENZE
=========
[1] Feirstein, B., "Real Men don't Eat Quiche", New York, Pocket Books,
1982.
[2] Wirth, N., "Algorithms + Data structures = Programs", Prentice Hall,
1976.
- L'idea originale:
[0] sdcarl!lin, "Real Programmers", UUCP-net, Thu Oct 21 16:55:16 1982
Input singolo Output multipli - tee
A dire il vero non so se questo sia un comando "nativo" di Unix o un Shell-Tool introdotto dalla GNU. In ogni caso io mi riferisco, in queste righe, alla versione GNU di tee. L'idea che sta alla base di tee è semplice, come la sua realizzazione, ma molto efficace: Copiare lo standard-input sullo standard-output e su altri files contemporaneamente. Come molti tool, e filtri, per shell tee ha un senso pratico se lo si usa con redirezione e pipe.
Possiamo quindi considerare tee come una "multipla" o qualcosa di simile... magari un giunto a T! Con un poco di pratica ci si capisce meglio:
Possiamo quindi considerare tee come una "multipla" o qualcosa di simile... magari un giunto a T! Con un poco di pratica ci si capisce meglio:
:~/esempi$ lsCome si vede dal primo ls la directory esempi è vuota. Avviamo tee, $tee pluto.txt, e, al suo termine, troviamo un file (pluto.txt appunto) contenete le righe che avevamo digitato. tee è in grado di copiare lo standard-input su più files, basta specificare una lista di nomi/path alla riga di comando:
:~/esempi$ tee pluto.txt
Io scrivo e tee ripete allo standard-output
Io scrivo e tee ripete allo standard-output
Esattamente come fà cat a prima vista
Esattamente come fà cat a prima vista
Premo ctrl+d (EOF) per terminare tee
Premo ctrl+d (EOF) per terminare tee
mesillo@stellascura:~/esempi$ ls
pluto.txt
:~/esempi$ cat pluto.txt
Io scrivo e tee ripete allo standard-output
Esattamente come fà cat a prima vista
Premo ctrl+d (EOF) per terminare tee
:~/esempi$
$ tee file1 file2 file3 ...
Ovviamente tutti i files avranno lo stesso contenuto.
Le due opzioni di maggior rilievo, almeno a parer mio, di tee sono:
Ovviamente tutti i files avranno lo stesso contenuto.- -a : output su file in modalità append, gli eventuali dati già presenti non vengono cancellati.
- -i : ignora i SIGINT (ctrl+c) che eventualmente dovesse ricevere. Utile nell'uso con certi programmi.
:~/esempi$ dmesg | tee dmesg_file.txt | headVedrete apparire subito le prime 10 righe, dei messaggi di avvio del Kernel, mentre nel file, dmesg_file.txt, saranno presenti tutte quante.
giovedì 13 dicembre 2007
VICE - Debian etch - Commodore
Questa faccenda dei 25 anni del Commodore 64 mi ha fatto venire voglia di lavorare ancora su questa fantastica macchina.
Ora come ora credo che la maniera migliore di "pistolare" con un Commodore sia emularlo.
Ho scelto VICE come emulatore. Questo software è in grado di emulare l'hardware dei più famosi Commodore pre-Amiga, tra cui l'amato C64.
Come al solito l'installazione su Debian è una storia di due comandi dati da root:
Il pacchetto Debian per Vice è privato delle ROMs che sono coperte da Copyright:
Visto che senza le ROMs l'emulatore non ci serve a molto, almeno che non vogliate scrivere un OS per Commodore 64 partendo da zero, dobbiamo procurarci queste benedette immagini.
Io ho optato per la strada più semplice: scaricare il pacchetto sorgenti completo di VICE. L'ultima versione di questo tarball è sempre scaricabile della home del progetto: http://www.viceteam.org/. Al momento attuale il link e questo: http://www.viceteam.org/online/vice-1.22.tar.gz. A dire il vero, comunque, le ROMs dovrebbero essere sempre le stesse qualunque sia la versione.
Di tutti i files contenuti nel pacchetto a noi servono solo quelli della directory data.
Ovviamente x64 non è l'unico emulatore fornito da VICE, ne esistono parecchi:
Ora come ora credo che la maniera migliore di "pistolare" con un Commodore sia emularlo.
Ho scelto VICE come emulatore. Questo software è in grado di emulare l'hardware dei più famosi Commodore pre-Amiga, tra cui l'amato C64.
Come al solito l'installazione su Debian è una storia di due comandi dati da root:
:~$ apt-get updateProviamo ora ad avviare l'emulatore C64, da utente normale, con:
:~$ apt-get install vice
:~$ x64Non funziona? Si lamenta che non trova la ROM adatta? Normale!
Il pacchetto Debian per Vice è privato delle ROMs che sono coperte da Copyright:
The ROM images for the 8-bit components required to make VICE are
copyrighted, and you install them at your own legal risk. Tulip
Computers, in the Netherlands, appears to hold the copyright to them,
and is being somewhat persnickety about who uses them. You will have
to get your ROMs somewhere other than this package.
Così recita un file della documentazione installata col pacchetto. Il file propone anche una soluzione:copyrighted, and you install them at your own legal risk. Tulip
Computers, in the Netherlands, appears to hold the copyright to them,
and is being somewhat persnickety about who uses them. You will have
to get your ROMs somewhere other than this package.
Previously, this was handled with the vice-getroms package, which was
a fragile downloader that attempted to download the individual ROM
images and put them in their correct places. At one point, the
upstream maintainers of VICE put together a tarball of the necessary
images, which can be found at:
ftp://ftp.funet.fi/pub/cbm/crossplatform/emulators/VICE/old/vice-1.5-roms.tar.gz
Download that file, and copy the contents of vice-roms-1.5/data/* into
the matching directories in /usr/lib/vice. You will probably need to
be root to do this.
Alternately, the original upstream tarballs also contain the ROM
images, though they are stripped out in the source tarball that Debian
distributes.
- Zed Pobre, Debian Maintainer, 2004.01.18
Io ho provato a fare un wget del file citato ma il link risulta "rotto".a fragile downloader that attempted to download the individual ROM
images and put them in their correct places. At one point, the
upstream maintainers of VICE put together a tarball of the necessary
images, which can be found at:
ftp://ftp.funet.fi/pub/cbm/crossplatform/emulators/VICE/old/vice-1.5-roms.tar.gz
Download that file, and copy the contents of vice-roms-1.5/data/* into
the matching directories in /usr/lib/vice. You will probably need to
be root to do this.
Alternately, the original upstream tarballs also contain the ROM
images, though they are stripped out in the source tarball that Debian
distributes.
- Zed Pobre, Debian Maintainer, 2004.01.18
Visto che senza le ROMs l'emulatore non ci serve a molto, almeno che non vogliate scrivere un OS per Commodore 64 partendo da zero, dobbiamo procurarci queste benedette immagini.
Io ho optato per la strada più semplice: scaricare il pacchetto sorgenti completo di VICE. L'ultima versione di questo tarball è sempre scaricabile della home del progetto: http://www.viceteam.org/. Al momento attuale il link e questo: http://www.viceteam.org/online/vice-1.22.tar.gz. A dire il vero, comunque, le ROMs dovrebbero essere sempre le stesse qualunque sia la versione.
Di tutti i files contenuti nel pacchetto a noi servono solo quelli della directory data.
- Scompattiamo il pacchetto, o anche solo la directory data, con il tool che più ci garba.
- Entriamo nella directory data.
- Rimuoviamo i file Makefile.am e Makefile.in
- Da root diamo un:
:~$ cp -R * /usr/lib/vice/
- Rimuoviamo i file derivati dalla scompattazione del pacchetto sorgenti
:~$ x64
Ovviamente x64 non è l'unico emulatore fornito da VICE, ne esistono parecchi:- Commodore 64
- Commodore 128
- CBM-II
- VIC-20
- PET
Note: Vi ricordo che le immagini delle ROMs sono coperte da Copyright. Installandole, ed usandole, ve ne assumete tutte le responsabilità ed eventuali conseguenze.
lunedì 10 dicembre 2007
25° C64
25 anni di C64!
Mi sento vecchio... questo gioiellino mi ha iniziato all'informatica.
Non mi dilungo oltre e vi lascio qualche links.
http://www.repubblica.it/2007/12/sezioni/scienza_e_tecnologia/commodore-25-anni/commodore-25-anni/commodore-25-anni.html
http://www.c64.com/
http://it.wikipedia.org/wiki/Commodore_64
Mi sento vecchio... questo gioiellino mi ha iniziato all'informatica.
Non mi dilungo oltre e vi lascio qualche links.
http://www.repubblica.it/2007/12/sezioni/scienza_e_tecnologia/commodore-25-anni/commodore-25-anni/commodore-25-anni.html
http://www.c64.com/
http://it.wikipedia.org/wiki/Commodore_64
Un'immagine dal passato
venerdì 7 dicembre 2007
Debian etch - fortune in italiano
Fortune è un bel giocattolino. Almeno io lo trovo divertente. Forse solo perché mi ci sono abituato con SlackWare.
A molti, comunque, piace vedere apparire, ogni volta, una pillola diversa quando si apre un terminale. Magari in Italiano.
Italianizzare fortune:
Su Debian bastano 2 comandi:
Impostare fortune all'avvio di bash:
Apriamo il file .bashrc, presente nella nostra home directory, con il nostro editor preferito ed aggiungiamo la riga: /usr/games/fortune. Magari preceduto da un commentino... che non fà mai male!
Da ora in poi, ogni volta che apriremo un terminale o faremo login, la shell ci darà il benvenuto con una massima in Italiano.
A molti, comunque, piace vedere apparire, ogni volta, una pillola diversa quando si apre un terminale. Magari in Italiano.
Italianizzare fortune:
Su Debian bastano 2 comandi:
:~$ apt-get updateOvviamente dati da root.
:~$ apt-get install fortunes-it
Impostare fortune all'avvio di bash:
Apriamo il file .bashrc, presente nella nostra home directory, con il nostro editor preferito ed aggiungiamo la riga: /usr/games/fortune. Magari preceduto da un commentino... che non fà mai male!
Da ora in poi, ogni volta che apriremo un terminale o faremo login, la shell ci darà il benvenuto con una massima in Italiano.
Se volete anche i contenuti "offensivi" nel database dei vostri fortunes potete installare il pacchetto fortunes-it-off
Home page di fortune-IT: http://www.fortune-it.net/main.html.
Redirezione e Pipelining
Una delle caratteristiche che ha portato al successo le prime versioni di Unix è sicuramente la capacità di redirigere i flussi e creare pipe. In particolare la redirezione dei tre flussi standard e l'uso delle pipe per accoppiare più comandi.
Va detto che le due cose dipendono una dall'altra. Una pipe è un meccanismo messo a disposizione dal sistema che permette di mettere in comunicazione due processi. Senza la capacità di redirigere i flussi però non si avrebbe la necessaria flessibilità per permettere di arrivare alla filosofia del "poco ma ben fatto".
Mi spiego meglio: una delle caratteristiche dei tool di Unix, a differenza di quelli di Multix, è assere realizzati per svolgere una sola semplice funzione nel miglior modo possibile.
Un esempio pratico è il comando cat, che a prima vista non fà nulla di utile; provate ad aprire una Shell e a dare il comando cat:
I flussi e la redirezione:
Partiamo dal concetto base, forse un poco spartano a dire il vero, per il quale: per Unix tutto è un file! Con tutto intendo anche tastiera e monitor/video. Questo può sembrare una masochistica complicazione ma, in realtà, ci facilita la vita in una maniera impressionate (sia a livello di realizzazione che utilizzo di un software)! Vediamo il perchè:
Abbiamo "imbrogliato" cat sostituendogli il flusso verso lo schermo con quello verso il file pippo.txt, che è stato appositamte creato. Tutto stà nel simbolo di redirezione dell'output >. Ora se aprissimo pippo.txt con il nostro editor di testo preferito vedremmo che contiene le righe da noi scritte. Ma, visto che vogliamo redirigere, possiamo anche usare cat per verificare. L'output di $cat < pippo.txt sarà:
Pipes:
Tubi è il nome che meglio si addice a queste particolari strutture messe a disposizione da Unix. Abbiamo visto come sia facile sostituire lo stdin di un processo con un file. Abbiamo visto come sia facile farlo anche con lo stdout.
Sarebbe bello, a questo punto, vedere se si può sostituire lo stdin di un processo con lo stdout di un'altro. Secondo voi?
Dobbiamo pensare la pipe esattamante come un tubo. Un tubo attraverso il quale non scorre acqua ma caratteri. Mettere in pipe due processi significa collegarli.
Uno sguardo veloce a grep:
In fine dei conti una pipe è un speciale file, temporaneo, che viene sostiuito allo stdout del primo programma, della linea di comando, e, contemporanemamte, allo stdin del secondo. Ci permette quindi di redirigere l'output di un processo nell'input di un'altro.
Anche le pipes possono essere multiple:
$prog1 | prog2 | prog3 | prog4
Un riassuntino grafico può aiutare a fissare le idee?
Redirezione stdout: $ prog > file
Redirezione stdin: $ prog < file
Pipe: $ prog1 | prog2
Va detto che le due cose dipendono una dall'altra. Una pipe è un meccanismo messo a disposizione dal sistema che permette di mettere in comunicazione due processi. Senza la capacità di redirigere i flussi però non si avrebbe la necessaria flessibilità per permettere di arrivare alla filosofia del "poco ma ben fatto".
Mi spiego meglio: una delle caratteristiche dei tool di Unix, a differenza di quelli di Multix, è assere realizzati per svolgere una sola semplice funzione nel miglior modo possibile.
Un esempio pratico è il comando cat, che a prima vista non fà nulla di utile; provate ad aprire una Shell e a dare il comando cat:
:~$ catA cosa serve un programma del genere? Se non esistesse modo di redirigere i flussi e creare pipe praticamente a nulla! Ma, con i dovuti supporti del sistema operativo, cat mi può servire a mille scopi.
questo ripete tutto quello che scrivo
questo ripete tutto quello che scrivo
quando batto invio lui ripete la riga pari-pari
quando batto invio lui ripete la riga pari-pari
a prima vista sembrerebbe una cosa assurda
a prima vista sembrerebbe una cosa assurda
ma chi usa Unix non potrebbe farne a meno
ma chi usa Unix non potrebbe farne a meno
per uscire da questa situazione premo ctrl+d
per uscire da questa situazione premo ctrl+d
:~$
I flussi e la redirezione:
Partiamo dal concetto base, forse un poco spartano a dire il vero, per il quale: per Unix tutto è un file! Con tutto intendo anche tastiera e monitor/video. Questo può sembrare una masochistica complicazione ma, in realtà, ci facilita la vita in una maniera impressionate (sia a livello di realizzazione che utilizzo di un software)! Vediamo il perchè:
- Ho un programma che legge i dati da tastiera e li scrive a video.
- La tastiera è un file.
- Il video è un file.
- Il mio programma può leggere da un file.
- Il mio programma può scrivere su un file.
- Un processo può aprire (avere accesso a, se preferite) file durante l'esecuzione del suo programma
- Un file aperto, da un processo, lo chiameremo flusso
- I file si possono aprire nelle due modalità (in realtà sono di più di due, ma per ora va benone così) lettura o scrittura.
- stdin: lo standard input, normalmente la tastiera (lettura)
- stdout: lo standard output, normalmente lo schermo (scrittura)
- stderr: lo standard error, normalmente lo schermo (scrittura)
:~/esempi$ lsLa directory esempi era vuota, lo si vede dall'output del primo ls. Dopo l'esecuzione di cat invece è comparso il file pippo.txt. Cosa è successo?
:~/esempi$ cat > pippo.txt
Ora scrivo ma cat non ripete
le mie righe a video...
Come mai?
Semplice, le stà scrivendo dentro al file pippo.txt
... provare per credere!
:~/esempi$ ls
pippo.txt
:~$
Abbiamo "imbrogliato" cat sostituendogli il flusso verso lo schermo con quello verso il file pippo.txt, che è stato appositamte creato. Tutto stà nel simbolo di redirezione dell'output >. Ora se aprissimo pippo.txt con il nostro editor di testo preferito vedremmo che contiene le righe da noi scritte. Ma, visto che vogliamo redirigere, possiamo anche usare cat per verificare. L'output di $cat < pippo.txt sarà:
Ora scrivo ma cat non ripeteQuindi, per redirigere l'input usiamo il simbolo <. La faccenda non è difficile da ricordare, basta considerare i simboli di redirezione come frecce:
le mie righe a video...
Come mai?
Semplice, le stà scrivendo dentro al file pippo.txt
... provare per credere!
- Redirezione input - freccia da file al programma: $nomeprog < file_input
- Redirezione output - freccia da programma al file: $nomeprog > file_output
- Redirezione input e output: $nomeprog > file_output < file_input
- Redirezione stdout in modalità append: $nomeprog >> file_output
Pipes:
Tubi è il nome che meglio si addice a queste particolari strutture messe a disposizione da Unix. Abbiamo visto come sia facile sostituire lo stdin di un processo con un file. Abbiamo visto come sia facile farlo anche con lo stdout.
Sarebbe bello, a questo punto, vedere se si può sostituire lo stdin di un processo con lo stdout di un'altro. Secondo voi?
Dobbiamo pensare la pipe esattamante come un tubo. Un tubo attraverso il quale non scorre acqua ma caratteri. Mettere in pipe due processi significa collegarli.
Uno sguardo veloce a grep:
:~/esempi$ grep pippoQuindi dare un comando come $grep pippo vuol dire cercare nello stdin tutte le righe che contengono la parola "pippo". E se volessimo controllare quali righe contengono la parola "video" nel file pippo.txt?
grep non è come cat
lui non ripete tutte le righe
ma solamente quelle che gli ho detto di cercare
in questo caso particolare solo quelle che
contengono la parola pippo
contengono la parola pippo
Mario và al mare
pippo và in montagna
pippo và in montagna
per uscire uso ctrl+d
:~/esempi$
:~/esempi$ cat pippo.txt | grep videoE così abbiamo scoperto come si possono mettere in comunicazione due processi tramite pipe: $nomeprog1 | nomeprog2. Il simbolo che usiamo per creare le pipe è |. Mi rendo conto che l'esempio è stupido, infondo possiamo ottenere lo stesso risultato con: $grep video < pippo.txt. Ma è un caso dovuto alla semplicità dell'esempio. Mettiamo invece di voler controllare se sul nostro sistema gira apache:
le mie righe a video...
:~/esempi$
:~/esempi$ ps ax | grep apacheComodo no? Senza pipe non avremo potuto dire a grep di cercare per noi nell'output di ps. Se volete avere un'idea di come la faccenda semplifichi estremamente la vita provate a dare un $ps ax e a cercare voi stessi quello che vi interessa.
2958 ? Ss 0:00 /usr/sbin/apache2 -k start
2996 ? S 0:00 /usr/sbin/apache2 -k start
2997 ? S 0:00 /usr/sbin/apache2 -k start
2998 ? S 0:00 /usr/sbin/apache2 -k start
2999 ? S 0:00 /usr/sbin/apache2 -k start
3000 ? S 0:00 /usr/sbin/apache2 -k start
3386 pts/0 R+ 0:00 grep apache
In fine dei conti una pipe è un speciale file, temporaneo, che viene sostiuito allo stdout del primo programma, della linea di comando, e, contemporanemamte, allo stdin del secondo. Ci permette quindi di redirigere l'output di un processo nell'input di un'altro.
Anche le pipes possono essere multiple:
$prog1 | prog2 | prog3 | prog4
Un riassuntino grafico può aiutare a fissare le idee?
Redirezione stdout: $ prog > file
Redirezione stdin: $ prog < file
Pipe: $ prog1 | prog2
Immagini realizzate con Dia: http://live.gnome.org/Dia
mercoledì 5 dicembre 2007
BlackMailer
La nuova generazione di virus ricattatori.
Questa sembra essere la nuova frontiera dei virus: Costringere gli utenti ad accettare l'infezione, del proprio sistema, punendo chi non vuole cedere.
Questa nuova schiera di malware sfrutterebbe la debolezza del primo, e forse fondamentale, servizio storicamente offerto dalla rete; la E-Mail. La stessa debolezza intrinseca, del protocollo SMTP, che rende, già oggi, tanto difficile proteggersi dallo Spam. Qui non è un discorso di bachi di un particolare software.
Questi ingeniosi software userebbero chi è già infetto per intasare la mail di chi ancora resiste. L'unica maniera che uno ha, a questo punto, di poter tornare ad usare liberamente la sua casella è lasciarsi infettare; in questo modo il "virus" segnalerà agli altri infetti la vostra resa e questi non vi seccheranno più. Adesso anche voi, nuovi infetti, intaserete le mailbox dei "sani". Vi faccio notare che con questa tecnica non v'è antivirus che regga, siete voi, infatti, ad accettare l'installazione del virus.
La mole di traffico prodotta da questi malware potrebbe, inoltre, creare problemi alla rete stessa.
Per ora questo software è stato creato solo in un laboratorio, dove si studiano le debolezze dei sistemi informatici, ma la realizzazione di un analogo, a scopo "pratico", non è troppo difficile.
Per saperne di più: http://sicurezza.html.it/articoli/leggi/2450/il-virus-perfetto/1/.
Questa sembra essere la nuova frontiera dei virus: Costringere gli utenti ad accettare l'infezione, del proprio sistema, punendo chi non vuole cedere.
Questa nuova schiera di malware sfrutterebbe la debolezza del primo, e forse fondamentale, servizio storicamente offerto dalla rete; la E-Mail. La stessa debolezza intrinseca, del protocollo SMTP, che rende, già oggi, tanto difficile proteggersi dallo Spam. Qui non è un discorso di bachi di un particolare software.
Questi ingeniosi software userebbero chi è già infetto per intasare la mail di chi ancora resiste. L'unica maniera che uno ha, a questo punto, di poter tornare ad usare liberamente la sua casella è lasciarsi infettare; in questo modo il "virus" segnalerà agli altri infetti la vostra resa e questi non vi seccheranno più. Adesso anche voi, nuovi infetti, intaserete le mailbox dei "sani". Vi faccio notare che con questa tecnica non v'è antivirus che regga, siete voi, infatti, ad accettare l'installazione del virus.
La mole di traffico prodotta da questi malware potrebbe, inoltre, creare problemi alla rete stessa.
Per ora questo software è stato creato solo in un laboratorio, dove si studiano le debolezze dei sistemi informatici, ma la realizzazione di un analogo, a scopo "pratico", non è troppo difficile.
Per saperne di più: http://sicurezza.html.it/articoli/leggi/2450/il-virus-perfetto/1/.
Mi sono reso conto che ho scritto questo post in maniera barbina... perdonatemi! Chiedo umilmente scusa!
sabato 1 dicembre 2007
Il culo delle Mucche...
Per la serie "la madre degli idioti è sempre gravida" e "la realtà supera qualsiasi immaginazione"; ecco come un Premio Nobel e un Primo Ministro si dedicano alle scorreggie del bestiame:
Il premio Nobel Barry J. Marshall ha progettato un catalizzatore anale da innestare nell' ano degli animali per abbattere le emissioni gassose, mentre il primo ministro australiano John Howard ha proposto l' innesto di condutture a tenuta stagna che dall' ano degli animali portino le emissioni direttamente ai rigassificatori più vicini.
Da Wikipedia, L'enciclopedia libera. alle 20:13, 1 Dicembre 2007 http://it.wikipedia.org/w/index.php?title=Flatulenza&oldid=12502724
Vabbè che parte dell'effetto serra a da attribuirsi anche alle flatulenze degli animali da allevamento... ma catalizzare il culo delle Vacche mi pare troppo! Povere Bestie! Con tutto quello che immettiamo in atmosfera con le fabbriche e tutto il resto preoccuparsi delle perne degli animali lo trovo ridicolo e inutile, scorreggiano come hanno sempre fatto e sempre faranno! Ed è giusto che sia così!
Per quello che riguarda la malsana proposta del Primo Ministro Australiano, io vorrei ricordargli che anche lui le molla... e, prima di procedere ad "intubare" tutto il bestiame di un continente, sarebbe giusto fare un esperimento/prova... visto che l'idea e sua potrebbe provare lui per primo il guinzaglio anale che la sua mente geniale ha partorito...
Meditiamo ragazzi... meditiamo...
Debian etch - XFCE4 - gnome-screensaver
Da un poco di tempo ho adottato Debian etch come SO principale. Di default questa distribuzione usa GNOME come Desktop-Manager. Niente da ridire su GNOME, per carità, ma preferisco sempre XFCE di cui mi sono innamorato lavorando su macchine datate. Sulla "Vecchia Signora" (SlackWare) XFCE era installato di default. Su Debian si installa in un lampo:
Mi sono accorto poi che XFCE così installato non avviava nessun gestore di screensavers. Perché, mi son detto, andare a installare roba nuova quando ne ho già uno pronto sull'hd? E ho deciso di usare quello di GNOME.
I file eseguibili che ci interessano sono 2:
Avviamo il gestore:
Per far partire gnome-screensaver all'avvio della sessione XFCE usiamo xfce4-autostart-editor:
Clicchiamo su Aggiungi e compiliamo i campi che ci vengono presentati: i primi due (Nome e Descrizione) sono puramente descrittivi, potete quindi inserire quello che vi pare, il terzo (Comando) invece è il comando da eseguire, inseriremo quindi: /usr/bin/gnome-screensaver .
Clicchiamo su OK e vedremo apparire una nuova voce sulla lista delle applicazioni all'avvio. A questo punto clicchiamo su Chiudi e dedichiamoci ad "altro".
Launcher per le "preferenze":
Adesso non ci resta che creare un nuovo launcher sul pannello per gnome-screensaver-preferences. Tasto destro del mouse sul pannello e scegliamo "Add new item". Doppio click su "Launcher". Completiamo i campi. Come al solito l'unica cosa fondamentale è che il campo Comando sia impostato ad /usr/bin/gnome-screensaver-preferences . Confermiamo tutto e siamo a cavallo!
:~$ apt-get updatePer il sistema base, se vogliamo proprio tutto, ed io lo consiglio, allora aggiungiamo un:
:~$ apt-get install xfce4
:~$ apt-get install xfce4-goodiesOvviamente essendo loggati come root.
Mi sono accorto poi che XFCE così installato non avviava nessun gestore di screensavers. Perché, mi son detto, andare a installare roba nuova quando ne ho già uno pronto sull'hd? E ho deciso di usare quello di GNOME.
I file eseguibili che ci interessano sono 2:
- /usr/bin/gnome-screensaver
- /usr/bin/gnome-screensaver-preferences
Avviamo il gestore:
Per far partire gnome-screensaver all'avvio della sessione XFCE usiamo xfce4-autostart-editor:
:~$ xfce4-autostart-editorCi apparirà una semplice interfaccia grafica.
Clicchiamo su Aggiungi e compiliamo i campi che ci vengono presentati: i primi due (Nome e Descrizione) sono puramente descrittivi, potete quindi inserire quello che vi pare, il terzo (Comando) invece è il comando da eseguire, inseriremo quindi: /usr/bin/gnome-screensaver .Clicchiamo su OK e vedremo apparire una nuova voce sulla lista delle applicazioni all'avvio. A questo punto clicchiamo su Chiudi e dedichiamoci ad "altro".
Launcher per le "preferenze":
Adesso non ci resta che creare un nuovo launcher sul pannello per gnome-screensaver-preferences. Tasto destro del mouse sul pannello e scegliamo "Add new item". Doppio click su "Launcher". Completiamo i campi. Come al solito l'unica cosa fondamentale è che il campo Comando sia impostato ad /usr/bin/gnome-screensaver-preferences . Confermiamo tutto e siamo a cavallo!
giovedì 29 novembre 2007
I Processi
Questo è un argomento che non riguarda solamente Unix, e derivati, ma l'informatica in generale. Ormai tutti, o quasi, i sistemi operativi sono multitasking, e quindi gestiscono i processi.
Cercherò di essere il più possibile chiaro per chiunque, a costo anche di commettere qualche imprecisione.
Programma:
Prima di addentrarci oltre ci viene utile, per poi capirci meglio, darci una "definizione" di cos'è un programma. Possiamo considerare un programma come: una sequenza, logicamente ordinata, di semplici operazioni, che un calcolatore è in grado di eseguire, che descrive un modo per ottenere un dato output partendo da un dato input.
Ad un informatico questa definizione balorda farebbe venire la pelle d'oca per la sua imprecisione. In realtà a noi non serve, per il momento, una definizione "assoluta" e rigorosa di programma. Ci basta arrivare ad un punto di partenza comune per poi continuare il nostro discorso. A questo punto ci viene in aiuto il famoso discorso della ricetta, che poi ci porteremo dietro per continuare a capirci. Consideriamo il programma come una ricetta di cucina. La ricetta/programma è un'entità statica, se ne stà lì, sul suo foglio che potremmo paragonare al file o alla scheda perforata, ad aspettare che qualcuno la esegua. A questo punto noi che seguiamo/eseguiamo la ricetta potremmo essere paragonati al sistema/calcolatore. Se la ricetta comprendesse delle uova, una frittata ad esempio, noi potremmo pensare queste uova come dei dati. Notiamo che le uova non stanno sul foglio, infatti la ricetta ci dice che ci servono dei dati del tipo uovo, i dati veri sono le uova che noi estraiamo dal frigo. Notiamo anche che noi, per fare la frittata, non mettiamo le uova (uova dato effettivo intento, quelle fisiche) nel foglio della ricetta e, come per magia, ne esce una frittata. Noi, che siamo il sistema, prendiamo le uova e seguiamo le istruzioni della ricetta. La ricetta è una serie di istruzioni, logicamente ordinate, che noi seguiamo per produrre, a partire dal nostro input uova, il nostro output frittata.
Il programma è come una ricetta di cucina.
Il Time Sharing:
Letteralmente la "condivisione del tempo". A livello umano sembra una cosa tanto ovvia da sembrare assurda e insensata.
Un calcolatore (o computer, come preferite) è composto da diverse parti:
Non perdiamoci e vediamo di focalizzare il problema dei tempi. Non tutte le parti del calcolatore sono veloci allo stesso modo: il primato spetta al processore, poi viene la memoria (solo RAM intendiamo) e infine tutte le periferiche. Anche se fra le varie periferiche ci possono essere notevoli differenze di velocità per il processore questo non conta. Qualsiasi periferica, anche la più veloce, è talmente lenta rispetto al cuore della macchina che non fà differenza.
Vediamo ora cosa fà un programma quando gira:
Ecco cosa si intende per Time Sharing: lo sfruttamento intelligente e massimizzato del tempo della CPU. Questo rendimento alto lo si ottiene facendo eseguire ad un processore un certo numero di programmi contemporaneamente. Ovviamente una singola CPU esegue il codice di un programma alla volta, ma cambia programma ogni volta che quello che stà eseguendo richiede un lento I/O. Più programmi condividono la stessa CPU.
Stiamo eseguendo la ricetta/programma "pastasciutta". Ad un certo punto ci troviamo ad eseguire l'operazione "fare bollire l'acqua". Se non adottassimo il Time Sharing staremmo li a girarci i pollici davanti alla pentola sul fuoco per buoni 20 minuti. Tempo sprecato visto che noi dopo dobbiamo eseguire la ricetta "frittata". Allora decidiamo di puntare il timer del forno e di dedicarci alle nostre uova. Tanto in 20 minuti ci portiamo bene avanti con la frittata. Poi, al suonare del timer, buttiamo la pasta e mescoliamo e ci tocca "aspettare" ancora, allora andremo avanti con la frittata. Oggi vanno tanto di moda i programmi televisivi dedicati alla cucina, osservate uno chef dei tanti che appaiono in TV e vedrete che realizza un Time Sharing molto spinto.
Processo:
Adesso però ci serve fare una distinzione fra programma e "programma in esecuzione". Se prima davamo in pasto alla CPU un programma alla volta questa distinzione non aveva senso. Adesso invece dobbiamo distinguere tra la sequenza di istruzioni presente sul disco (o su un supporto qualsiasi) e quell'entità, attiva e vitale, che gira sul sistema di cui il programma è una parte. Sia ben chiaro che la distinzione non è mera filosofia informatica, ci sono delle precise necessità tecniche che ci portano a farla:
Ed ecco che con il Time Sharing compare una nuova entità: il processo. Da ora in poi non parleremo più di "programma che gira" su un sistema, ma di processo che, girando sul sistema, esegue un programma. Ad ogni processo è associato un programma da eseguire. Il sistema gestisce i processi. Un processo è composto da molte altre cose oltre che dal programma. Per fare un esempio i dati. Vi sarà capitato sicuramente di eseguire due processi che usano lo stesso programma. Capita spesso con i browser web. Se vi trovate con una marea di finestre aperte dello stesso programma avete davanti agli occhi un esempio di molti processi, uno per finestra, che eseguono lo stesso programma. Infatti sul disco avete un solo file eseguibile del vostro browser preferito. Allora cosa cambia? Cambia l'indirizzo web che avete specificato (input) e la pagina che il browser vi mostra (output). A questo punto è legittimo, e giusto, pensare che i vari processi eseguano lo stesso programma trattando però un set di dati diversi. Ed è importante che il sistema operativo si ricordi quale processo a chiesto la tale pagina, sarebbe fastidioso digitare su una finestra e vedere che la pagina si apre su un'altra a caso. Eppure se ci si riferisse al programma non si avrebbe modo di distinguere le sue varie istanze in esecuzione. Ma questa è già un visione paradossalmente ottimistica. In realtà le cose sono ben più complesse. Ogni processo è ad un punto diverso dell'esecuzione del programma, anche se il programma è lo stesso. Bisogna anche che un processo si ricordi dove è arrivato ad eseguire il programma.
Ritorniamo in cucina:
Quando il timer del forno suona dobbiamo ricordarci che eravamo arrivati al punto "butare la pasta nell'acqua", ad esempio, e non a quello "aggiungere sale".
Se stiamo anche cucinando due frittate diverse, una con gli spinaci e una con piselli e tonno (che vada giù na roba del genere?), dobbiamo ricordarci quali sono gli ingredienti che associamo ad una esecuzione e quali all'altra della stessa ricetta, onde evitare di fare macelli all'istruzione comune: "aggiungere gli ingredienti a vostra scelta".
Scendere nei particolari di cosa fà, e come, un processo richiederebbe molto tempo e molte parole. Per arrivare fin nell'intimo di come si realizza il Time Sharing bisognerebbe partire da lontano ed affrontare un sacco di problemi. Basti sapere che ancora oggi si cercano vie nuove e sempre più efficaci. Non tutti i sistemi usano la stessa identica filosofia/metodologia. Non mi sembra il caso ora. Spero comunque che siamo riusciti a farci un'idea generale.
Cercherò di essere il più possibile chiaro per chiunque, a costo anche di commettere qualche imprecisione.
Programma:
Prima di addentrarci oltre ci viene utile, per poi capirci meglio, darci una "definizione" di cos'è un programma. Possiamo considerare un programma come: una sequenza, logicamente ordinata, di semplici operazioni, che un calcolatore è in grado di eseguire, che descrive un modo per ottenere un dato output partendo da un dato input.
Ad un informatico questa definizione balorda farebbe venire la pelle d'oca per la sua imprecisione. In realtà a noi non serve, per il momento, una definizione "assoluta" e rigorosa di programma. Ci basta arrivare ad un punto di partenza comune per poi continuare il nostro discorso. A questo punto ci viene in aiuto il famoso discorso della ricetta, che poi ci porteremo dietro per continuare a capirci. Consideriamo il programma come una ricetta di cucina. La ricetta/programma è un'entità statica, se ne stà lì, sul suo foglio che potremmo paragonare al file o alla scheda perforata, ad aspettare che qualcuno la esegua. A questo punto noi che seguiamo/eseguiamo la ricetta potremmo essere paragonati al sistema/calcolatore. Se la ricetta comprendesse delle uova, una frittata ad esempio, noi potremmo pensare queste uova come dei dati. Notiamo che le uova non stanno sul foglio, infatti la ricetta ci dice che ci servono dei dati del tipo uovo, i dati veri sono le uova che noi estraiamo dal frigo. Notiamo anche che noi, per fare la frittata, non mettiamo le uova (uova dato effettivo intento, quelle fisiche) nel foglio della ricetta e, come per magia, ne esce una frittata. Noi, che siamo il sistema, prendiamo le uova e seguiamo le istruzioni della ricetta. La ricetta è una serie di istruzioni, logicamente ordinate, che noi seguiamo per produrre, a partire dal nostro input uova, il nostro output frittata.
Il programma è come una ricetta di cucina.
Il Time Sharing:
Letteralmente la "condivisione del tempo". A livello umano sembra una cosa tanto ovvia da sembrare assurda e insensata.
Un calcolatore (o computer, come preferite) è composto da diverse parti:
- Processore (ALU)
- Memoria (RAM)
- Dispositivi esterni o periferiche
Non perdiamoci e vediamo di focalizzare il problema dei tempi. Non tutte le parti del calcolatore sono veloci allo stesso modo: il primato spetta al processore, poi viene la memoria (solo RAM intendiamo) e infine tutte le periferiche. Anche se fra le varie periferiche ci possono essere notevoli differenze di velocità per il processore questo non conta. Qualsiasi periferica, anche la più veloce, è talmente lenta rispetto al cuore della macchina che non fà differenza.
Vediamo ora cosa fà un programma quando gira:
- Fà dei calcoli sui dati che ha a disposizione
- Acquisisce dati (Input).
- Emette dei dati (Output).
- Scrive e legge dalla Memoria (RAM).
Ecco cosa si intende per Time Sharing: lo sfruttamento intelligente e massimizzato del tempo della CPU. Questo rendimento alto lo si ottiene facendo eseguire ad un processore un certo numero di programmi contemporaneamente. Ovviamente una singola CPU esegue il codice di un programma alla volta, ma cambia programma ogni volta che quello che stà eseguendo richiede un lento I/O. Più programmi condividono la stessa CPU.
e.g.: in questo momento 109 programmi si stanno dividendo il tempo della mia CPU. Stò fruttando le capacità del processore ad un 15% scarso. Non ho un supercomputer, anzi!Torniamo al nostro esempio della ricetta culinaria:
Stiamo eseguendo la ricetta/programma "pastasciutta". Ad un certo punto ci troviamo ad eseguire l'operazione "fare bollire l'acqua". Se non adottassimo il Time Sharing staremmo li a girarci i pollici davanti alla pentola sul fuoco per buoni 20 minuti. Tempo sprecato visto che noi dopo dobbiamo eseguire la ricetta "frittata". Allora decidiamo di puntare il timer del forno e di dedicarci alle nostre uova. Tanto in 20 minuti ci portiamo bene avanti con la frittata. Poi, al suonare del timer, buttiamo la pasta e mescoliamo e ci tocca "aspettare" ancora, allora andremo avanti con la frittata. Oggi vanno tanto di moda i programmi televisivi dedicati alla cucina, osservate uno chef dei tanti che appaiono in TV e vedrete che realizza un Time Sharing molto spinto.
Processo:
Adesso però ci serve fare una distinzione fra programma e "programma in esecuzione". Se prima davamo in pasto alla CPU un programma alla volta questa distinzione non aveva senso. Adesso invece dobbiamo distinguere tra la sequenza di istruzioni presente sul disco (o su un supporto qualsiasi) e quell'entità, attiva e vitale, che gira sul sistema di cui il programma è una parte. Sia ben chiaro che la distinzione non è mera filosofia informatica, ci sono delle precise necessità tecniche che ci portano a farla:
- Il "set" di dati che un "programma in esecuzione" si porta appresso.
- Il "punto" dell'esecuzione al quale siamo arrivati.
- Quale input e quale output ci ha costretti a cambiare programma.
Ed ecco che con il Time Sharing compare una nuova entità: il processo. Da ora in poi non parleremo più di "programma che gira" su un sistema, ma di processo che, girando sul sistema, esegue un programma. Ad ogni processo è associato un programma da eseguire. Il sistema gestisce i processi. Un processo è composto da molte altre cose oltre che dal programma. Per fare un esempio i dati. Vi sarà capitato sicuramente di eseguire due processi che usano lo stesso programma. Capita spesso con i browser web. Se vi trovate con una marea di finestre aperte dello stesso programma avete davanti agli occhi un esempio di molti processi, uno per finestra, che eseguono lo stesso programma. Infatti sul disco avete un solo file eseguibile del vostro browser preferito. Allora cosa cambia? Cambia l'indirizzo web che avete specificato (input) e la pagina che il browser vi mostra (output). A questo punto è legittimo, e giusto, pensare che i vari processi eseguano lo stesso programma trattando però un set di dati diversi. Ed è importante che il sistema operativo si ricordi quale processo a chiesto la tale pagina, sarebbe fastidioso digitare su una finestra e vedere che la pagina si apre su un'altra a caso. Eppure se ci si riferisse al programma non si avrebbe modo di distinguere le sue varie istanze in esecuzione. Ma questa è già un visione paradossalmente ottimistica. In realtà le cose sono ben più complesse. Ogni processo è ad un punto diverso dell'esecuzione del programma, anche se il programma è lo stesso. Bisogna anche che un processo si ricordi dove è arrivato ad eseguire il programma.
Ritorniamo in cucina:
Quando il timer del forno suona dobbiamo ricordarci che eravamo arrivati al punto "butare la pasta nell'acqua", ad esempio, e non a quello "aggiungere sale".
Se stiamo anche cucinando due frittate diverse, una con gli spinaci e una con piselli e tonno (che vada giù na roba del genere?), dobbiamo ricordarci quali sono gli ingredienti che associamo ad una esecuzione e quali all'altra della stessa ricetta, onde evitare di fare macelli all'istruzione comune: "aggiungere gli ingredienti a vostra scelta".
Scendere nei particolari di cosa fà, e come, un processo richiederebbe molto tempo e molte parole. Per arrivare fin nell'intimo di come si realizza il Time Sharing bisognerebbe partire da lontano ed affrontare un sacco di problemi. Basti sapere che ancora oggi si cercano vie nuove e sempre più efficaci. Non tutti i sistemi usano la stessa identica filosofia/metodologia. Non mi sembra il caso ora. Spero comunque che siamo riusciti a farci un'idea generale.
martedì 27 novembre 2007
Time to leave!
Sta volta voglio affrontare l'uso di un comando/programma di Unix che alcuni potrebbero considerare un poco anacronistico. Stò parlando di leave. Un programmino che gira in background e che ci aiuta a non perdere la cognizione del tempo. In sostanza leave è una sveglia/timer.
Si può settare leave per avvisarci ad una data ora o fra un tot di tempo.
Se dovessimo invocare leave senza argomenti sarebbe lui stesso a chiederci esplicitamente quando avvertirci.
Una volta settato leave lascierà l'utente libero di lavorare, alla shell ovviamente, fino a 5 minuti prima dell'ora X. A cinque minuti partirà il primo avviso. Ad 1 minuto il secondo. All'ora X e ogni minuto successivo leave disturberà l'user ricordandogli che deve andarsene. Solo dopo 10 minuti dallo scadere del timer leave si cheterà!
I mesaggi di leave:
Bisogna ricordarsi che leave è un programma/processo "normale" e quindi dipende dall padre. Insomma, se chiudete la shell da cui lo avete avviato chiudete anche lui, inoltre non usa files per memorizzare le impostazioni che quindi sono "labili".
Certe versioni/implementazioni usano accompagnare i messaggi anche con il suono della campanella di sistema (beep). A parole sembra una vaccata ma vi giuro che funziona... stressa da morire!
leave usa un modo abbastanza singolare per interpretare gli orari che gli passate, mi spiego meglio; se siamo di pomeriggio e diamo un comando del tipo:
Non tutti i sistemi, ormai, adottano leave nella installazione "standard".
Nel caso di Debian etch si può seguire la più canonica delle vie:
Si può settare leave per avvisarci ad una data ora o fra un tot di tempo.
:~&leave +15Per ricordarci di andarcene fra 15 minuti.
:~&leave 2115Per ricordarci che dobbiamo sortire alle 21:15.
Se dovessimo invocare leave senza argomenti sarebbe lui stesso a chiederci esplicitamente quando avvertirci.
:~$ leaveLa maniera per rispondere è la stessa con cui passare i parametri direttamente a linea di comando. La conferma dell'avvenuto avvio di leave sarà, in tutti i casi, sempre una cosa del tipo:
When do you have to leave?
Alarm set for Tue Nov 27 20:00. (pid 6124)Mi sembra che non ci sia nulla da spiegare!
Una volta settato leave lascierà l'utente libero di lavorare, alla shell ovviamente, fino a 5 minuti prima dell'ora X. A cinque minuti partirà il primo avviso. Ad 1 minuto il secondo. All'ora X e ogni minuto successivo leave disturberà l'user ricordandogli che deve andarsene. Solo dopo 10 minuti dallo scadere del timer leave si cheterà!
I mesaggi di leave:
You have to leave in 5 minutes.Dopo lo scadere certe versioni/implementazioni ripetono sempre "Time to leave!" altre invece si sbizzarriscono con messaggi più vari.
Just one more minute!
Time to leave!
[...]
That was the last time I'll tell you. Bye.
Bisogna ricordarsi che leave è un programma/processo "normale" e quindi dipende dall padre. Insomma, se chiudete la shell da cui lo avete avviato chiudete anche lui, inoltre non usa files per memorizzare le impostazioni che quindi sono "labili".
Certe versioni/implementazioni usano accompagnare i messaggi anche con il suono della campanella di sistema (beep). A parole sembra una vaccata ma vi giuro che funziona... stressa da morire!
leave usa un modo abbastanza singolare per interpretare gli orari che gli passate, mi spiego meglio; se siamo di pomeriggio e diamo un comando del tipo:
:~$ leave 0830leave non intende "0830" come le otto e trenta minuti del mattino successivo ma come le otto e mezza della sera stessa (le venti insomma). Lo si capisce anche dall'output di conferma.
Alarm set for Tue Nov 27 20:30. (pid 7071)
Non tutti i sistemi, ormai, adottano leave nella installazione "standard".
Nel caso di Debian etch si può seguire la più canonica delle vie:
:~$apt-get update
:~$apt-get install leave
venerdì 23 novembre 2007
Google: dopo la rete la luna!
Google e X PRIZE Foundation stanziano un totale di 130milioni di dollari per la migliore missione lunare robotica privata.
Tutti possono partecipare al concorso e spedire il loro robottino sulla superfice della luna. Ovvio che sono richieste delle prestazioni minime per avere accesso ai premi. C'è tempo fino al 2012 o, se per allora nessuno avesse soddisfatto BigG & CO, anche fino al 2015. Il problema è: chi ha i soldi per tentare un'impresa del genere?
Se pensate che stia scherzando: http://www.googlelunarxprize.org/lunar/intl/ita/.
Tra gli obbiettivi "secondari" della missione anche quello di filmare/fotografare i rottami/residui delle missioni Apollo!
Vi pare poco?
Tutti possono partecipare al concorso e spedire il loro robottino sulla superfice della luna. Ovvio che sono richieste delle prestazioni minime per avere accesso ai premi. C'è tempo fino al 2012 o, se per allora nessuno avesse soddisfatto BigG & CO, anche fino al 2015. Il problema è: chi ha i soldi per tentare un'impresa del genere?
Se pensate che stia scherzando: http://www.googlelunarxprize.org/lunar/intl/ita/.
Tra gli obbiettivi "secondari" della missione anche quello di filmare/fotografare i rottami/residui delle missioni Apollo!
Vi pare poco?
giovedì 22 novembre 2007
screen: terminale multitasking!
Unix (ed i sistemi Unix-Like) è un sistema operativo multitasking e multiutente. L'interfaccia utente "preferenziale" di Unix è una Shell che gira su un terminale. La Shell è un'interfaccia a caratteri del tipo "linea di comando". Passi che più utenti si possono collegare contemporaneamente al sistema attraverso terminali, ma come fà un singolo utente a far girare più programmi sulla sua shell? Oggi come oggi, nell'era della finestra, sembra impossibile vero? Forse a qualcuno anche inutile!? Avvio il mio bel Server X col mio Desktop/Window Manager preferito e sono a cavallo!... e se mi devo connettere da remoto con ssh ad esempio?!? Situazione, questa, che emula bene l'uso dei vecchi terminali fisici. Nessun problema, una soluzione è screen!
Una delle "sciccherie" di screen è prorio quella di fornirci un terminale multitasking. Cioè un terminale in cui possiamo eseguire più programmi contemporaneamente. Passando dall'uno all'altro senza problemi e, sopratutto, senza interrompere il loro funzionamento.
Screen lavora a sessioni. Una sezione di screen può contenere diversi programmi in esecuzione (processi). Una sezione "nasce" con una chiamata a screen. Una sezione "muore" con la chiusura dell'ultimo processo ad essa associato.
Screen avvia una nuova sessione quando lo si chiama specificando un programma da avviare o senza nessun parametro (in questo caso avvia una istanza della shell di default *).
Consideriamo screen come un gestore di finistre a tutto schermo. Ogni finestra contine un programma. Una sessione contiene più finestre (almeno una).
Passo successivo, necessario prima di passare ad un poco di pratica, è capire la relazione tra sessione e soket. Chiariamoci da subito che questa nomenclatura è propria di screen e, quindi, può risultare ingannevole:
Una delle "sciccherie" di screen è prorio quella di fornirci un terminale multitasking. Cioè un terminale in cui possiamo eseguire più programmi contemporaneamente. Passando dall'uno all'altro senza problemi e, sopratutto, senza interrompere il loro funzionamento.
Screen lavora a sessioni. Una sezione di screen può contenere diversi programmi in esecuzione (processi). Una sezione "nasce" con una chiamata a screen. Una sezione "muore" con la chiusura dell'ultimo processo ad essa associato.
Screen avvia una nuova sessione quando lo si chiama specificando un programma da avviare o senza nessun parametro (in questo caso avvia una istanza della shell di default *).
:~$screenAvvio una finestra contenente una shell.
:~$screen joeAvvio una finestra contenente joe.
Consideriamo screen come un gestore di finistre a tutto schermo. Ogni finestra contine un programma. Una sessione contiene più finestre (almeno una).
Passo successivo, necessario prima di passare ad un poco di pratica, è capire la relazione tra sessione e soket. Chiariamoci da subito che questa nomenclatura è propria di screen e, quindi, può risultare ingannevole:
- Soket: ciò che screen chiama soket è in relatà, per il SO, una PIPE con nome.
- Sessione: una sessione di screen non è altro che un processo del SO che esegue screen.
1 soket=>1 sessione=> N finestre=> N programmi.
Per ragioni di sicurezza evitate sempre di abbandonare il sistema con sessioni di screen aperte. Chiudetele tutte se lasciate la macchina accessa, e sopratutto se rimane connessa alla rete. Screen è molto potente ma comporta dei rischi. Questo non deve scoraggiare il suo uso ovviamente. Per ora teniamoci a mente che screen non realizza soltanto un terminale multitasking.
Passiamo alla pratica:
Passiamo alla pratica:
Abbiamo visto due maniere per avviare screen. Per ora, onde evitare confusioni, useremo quella con parametro. Usiamo un programma "vistoso", tipo mc, per aiutarci.
Ora concentriamoci sulle soket, dovremmo averne una a questo punto. Come faccimao a controllare?
Adesso abbiamo la nostra sessione distaccata e vorremmo riattaccarla. Per fare ciò si usa l'opzione -r, che può essere accompagnata da parametro oppure no. Se si usa r senza parametro screen attaccherà al terminale in uso la prima sessione disponibile. Nel nostro caso v'è n'è una solamente quindi ci và più che bene.
A questo punto vedremo riapparire il nostro mc. Chiudiamolo e vedremo un output a shell del tipo:
Vediamo ora come dare un nome alle sessioni per meglio riconoscerle senza doversi ricordare i pid.
Ora è il momento di aggiungere delle nuove finestre alla nostra sessione. Per farlo usiamo il comando interattivo c quindi premiamo ctrl+a e c. Ci apparirà una shell (quella di default *), in una nuova finestra, attraverso la quale possiamo avviare il programma che preferiamo. Per comodità di chi scrive ammettiamo di avviare joe.
Possiamo spostarci da una finestra all'altra con diversi comandi. Tenete conto che screen tratta le finestre come se fossero inserite in una lista. Ogni finestra ha il suo numero. La prima che avete avviato sarà la numero 0, la seconda la numero 1, ecc... . La lista è ciclica, ossia dopo l'ultima finestra si torna alla prima e, di conseguenza, prima della prima c'è l'ultima.
Fatte le dovute premesse ecco la lista dei comandi.
Chiudere una finestra non è difficile, basta chiudere il programma, o la shell (exit), che essa contiene. Quando chiudiamo l'ultima finestra di una sezione terminiamo anche la sezione stessa ed il suo soket scompare.
Ora sappiamo:
Teniamo sempre a mente che screen altera un poco il comportamento dei programmi. Basti pensare al fatto che si impadronisce della combinazione ctrl+a. Alle volte è anche costretto a modificare, anche se solo in modo temporaneo, l'otput dei programmi per avvisarci di qualcosa. Proprio per ovviare a questi problemi screen prevede l'uso di file di configurazione che, volendo, ne alterano, anche di molto, il comportamento per poterlo adattare alle varie esigenze. Per ora però non vado oltre. Se non resistite alla curiosità non vi resta che dare un man screen.
Utenti Debian etch: potrebbe capitare che sulla vostra distribuzione screen non sia incluso di default... il procedimanto per installarlo è quello canonico!
(*)Controllare la shell di default:
:-$screen mcA prima vista è tutto come se avessimo avviato normalmente mc. Ora però premiamo ctrl+a e successivamente d. Vedremo che torniamo alla shell di "partenza" con questo output:
:~$ screen mcChe cosa è successo?
[detached]
:~$
- Abbiamo, tramite il primo comando, avviato una sessione di screen nella quale la prima finestra contiene un mc.
- Abbiamo usato un comando interattivo di screen per distaccare la sessione dal terminale.
Ora concentriamoci sulle soket, dovremmo averne una a questo punto. Come faccimao a controllare?
:~$screen -lsoppure
:~$screen -listCi dovrebbe apparire un otput del tipo:
There is a screen on:Analiziamo in particolare la seconda riga. Questa descrive la maniera di nominare le soket/sessioni di screen. Dobbiamo leggerla come:
4596.pts-0.stellascura (Detached)
1 Socket in /var/run/screen/S-mesillo.
[pid di screen].[terminale a cui è attaccata la sessione].[hostname] ([stato])
Chiariamo alla menopeggio il concetto di attaccato e staccato per una sessione rispetto ad un terminale. Quando una sessione è attaccata ad un terminale vuol dire che una delle sue finestre lo "occuperà". Sò che è riduttivo e in parte inesatto ma per ora vediamola così. Ricordiamoci che un processo (programma) può benissimo continuare a girare anche quando è staccato da un terminale.
Adesso abbiamo la nostra sessione distaccata e vorremmo riattaccarla. Per fare ciò si usa l'opzione -r, che può essere accompagnata da parametro oppure no. Se si usa r senza parametro screen attaccherà al terminale in uso la prima sessione disponibile. Nel nostro caso v'è n'è una solamente quindi ci và più che bene.
:~$screen -rSe, invece, avessimo più sessioni potremmo usare un comando del tipo:
:-$screen -r 4596.pts-0.stellascurao se volessimo usare solo il pid della sessione:
:-$screen -r 4596potremmo, addirittura, specificare solo il nome del terminale. Screen è "intelligente" e, se non forniamo informazioni ambigue (eg.: due sessioni con lo stesso terminale), riesce spesso a capire cosa vogliamo.
A questo punto vedremo riapparire il nostro mc. Chiudiamolo e vedremo un output a shell del tipo:
:~$ screen -rIl successivo controllo delle soket ci dirà che nessuna sessione è apera.
[screen is terminating]
mesillo@stellascura:~$ screen -list
No Sockets found in /var/run/screen/S-mesillo.
mesillo@stellascura:~$
Vediamo ora come dare un nome alle sessioni per meglio riconoscerle senza doversi ricordare i pid.
:~$screen -S pippo mcL'opzione in questione è -S con la S maiuscola. Ora distacchiamo la sessione e controlliamo le soket attive. Osserveremo un otput del tipo:
There is a screen on:Possiamo riattacare la sessione con:
8652.pippo (Detached)
1 Socket in /var/run/screen/S-mesillo.
:~$screen -r pippoCredo che con molte sessioni attive sia comoda questa possibilità.
Ora è il momento di aggiungere delle nuove finestre alla nostra sessione. Per farlo usiamo il comando interattivo c quindi premiamo ctrl+a e c. Ci apparirà una shell (quella di default *), in una nuova finestra, attraverso la quale possiamo avviare il programma che preferiamo. Per comodità di chi scrive ammettiamo di avviare joe.
Possiamo spostarci da una finestra all'altra con diversi comandi. Tenete conto che screen tratta le finestre come se fossero inserite in una lista. Ogni finestra ha il suo numero. La prima che avete avviato sarà la numero 0, la seconda la numero 1, ecc... . La lista è ciclica, ossia dopo l'ultima finestra si torna alla prima e, di conseguenza, prima della prima c'è l'ultima.
Fatte le dovute premesse ecco la lista dei comandi.
- n: ci si sposta alla finestra successiva.
- p: ci si sposta alla finestra precedente.
- n: (dove n è un numero da 0 a 9) ci si sposta alla finestra numero n.
Chiudere una finestra non è difficile, basta chiudere il programma, o la shell (exit), che essa contiene. Quando chiudiamo l'ultima finestra di una sezione terminiamo anche la sezione stessa ed il suo soket scompare.
Ora sappiamo:
- Avviare una sezione (con nome anche).
- Creare delle finestre.
- Muoverci tra le finestre.
- Chiudere le finestre e le sessioni.
- Staccare una sessione.
- Controllare le sessioni aperte.
- Attaccare una sessione.
Teniamo sempre a mente che screen altera un poco il comportamento dei programmi. Basti pensare al fatto che si impadronisce della combinazione ctrl+a. Alle volte è anche costretto a modificare, anche se solo in modo temporaneo, l'otput dei programmi per avvisarci di qualcosa. Proprio per ovviare a questi problemi screen prevede l'uso di file di configurazione che, volendo, ne alterano, anche di molto, il comportamento per poterlo adattare alle varie esigenze. Per ora però non vado oltre. Se non resistite alla curiosità non vi resta che dare un man screen.
Utenti Debian etch: potrebbe capitare che sulla vostra distribuzione screen non sia incluso di default... il procedimanto per installarlo è quello canonico!
:~$suNon dovrebbe nemmeno chiedervi di risolvere delle dipendenze.
passwd:
:~$apt-get update
:~$apt-get install screen
(*)Controllare la shell di default:
:~$echo $SHELL(**) Dovessimo mai passare al programma nella finestra proprio ctrl+a basterebbe usare ctrl+a e a.
Iscriviti a:
Post (Atom)