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!
Iscriviti a:
Post (Atom)