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:

• Processore (ALU)
• Memoria (RAM)
  
• Dispositivi esterni o periferiche

Nei dispositivi esterni vanno a cadere anche: dischi rigidi, schermi, floppy, lettori ottici, schede audio, ecc... Insomma non solo la "roba" che stà al di fuori del case. Tutti i computer sono infatti basati su uno stesso schema: La macchina di Von Neumann. Anche se in questa astrazione si elencano a volte anche le unità di Input/Output, la macchina è costituita nel suo intimo solo da processore e memoria. La forza di questa macchina è proprio nella sua semplicità!

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).

Fare dei calcoli massivi vuol dire fruttare bene la macchina. Leggere e scrivere dalla memoria "rallenta" un poco le operazioni ma è ancora accettabile e comunque indispensabile (gli informatici potrebbero avere da ridire; avete ragione ma certo non scrivo ste robe per voi!). Le operazioni di Input/Output sono talmente lente da costringere il processore a tempi morti scandalosi. Queste pause forzate sono talmente lunghe che il processore potrebbe tranquillamente eseguire la parte di calcolo di un'altro programma o più. Ed ecco l'ideona. Sospendere l'esecuzione di un programma in attesa di I/O e cominciare, o continuare, l'esecuzione di uno che invece deve sfruttare a pieno la CPU.

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.
  

Questa è una lista volutamente semplicistica, ma già rende l'idea.
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.

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.

:~&leave +15

Per ricordarci di andarcene fra 15 minuti.

:~&leave 2115

Per ricordarci che dobbiamo sortire alle 21:15.
Se dovessimo invocare leave senza argomenti sarebbe lui stesso a chiederci esplicitamente quando avvertirci.

:~$ leave
When do you have to leave?

La 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:

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.
Just one more minute!
Time to leave!
[...]
That was the last time I'll tell you.  Bye.

Dopo lo scadere certe versioni/implementazioni ripetono sempre "Time to leave!" altre invece si sbizzarriscono con messaggi più vari.

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 0830
Alarm set for Tue Nov 27 20:30. (pid 7071)

leave 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.

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

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?

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 *).

:~$screen

Avvio una finestra contenente una shell.

:~$screen joe

Avvio 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.

Fatti i dovuti chiarimenti ora continuiamo ad usare la terminologia di screen. Per screen ogni sessione è associata ad un socket. Questo fatto è necessario per un uso più avanzato di screen di quello che voliamo fare noi, almeno per ora. Tuttavia dovremo comunque conoscere questo aspetto per poter controllare le sessioni che andiamo ad avviare. Allora, schematizzando:

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:

Abbiamo visto due maniere per avviare screen. Per ora, onde evitare confusioni, useremo quella con parametro. Usiamo un programma "vistoso", tipo mc, per aiutarci.

:-$screen mc

A 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 mc
[detached]
:~$

Che cosa è successo?

• 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.

Questo secondo punto merita delle spiegazioni. Per "comandare" le finestre di screen non si usa il mouse ma la tastiera. Per impartire a screen un comando lo si deve "avvertire" prima. Avvertirlo significa specificare che l'input è per lui e non per il programma che gira nella finestra. Per "avvertire" screen che stiamo per impartirgli un comando si usa la combinazione di tasti ctrl+a **. A questo punto diamo il comando d che sta per "detach", è un poco come mettere in pausa un'intera sessione. Cioè come accontonarla temporanemente. Mentre la sessione è staccata, e noi quindi non stiamo lavorando in nessuna finastra, il nostro mc continua a girare indisturbato; se fosse un wget continuerebbe a scaricare ad esempio. Qui già si possono intuire altre potenzialità di screen.

Ora concentriamoci sulle soket, dovremmo averne una a questo punto. Come faccimao a controllare?

:~$screen -ls

oppure

:~$screen -list

Ci dovrebbe apparire un otput del tipo:

There is a screen on:
4596.pts-0.stellascura  (Detached)
1 Socket in /var/run/screen/S-mesillo.

Analiziamo in particolare la seconda riga. Questa descrive la maniera di nominare le soket/sessioni di screen. Dobbiamo leggerla come:

[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 -r

Se, invece, avessimo più sessioni potremmo usare un comando del tipo:

:-$screen -r 4596.pts-0.stellascura

o se volessimo usare solo il pid della sessione:

:-$screen -r 4596

potremmo, 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 -r
[screen is terminating]
mesillo@stellascura:~$ screen -list
No Sockets found in /var/run/screen/S-mesillo.

mesillo@stellascura:~$

Il successivo controllo delle soket ci dirà che nessuna sessione è apera.
Vediamo ora come dare un nome alle sessioni per meglio riconoscerle senza doversi ricordare i pid.

:~$screen -S pippo mc

L'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:
8652.pippo      (Detached)
1 Socket in /var/run/screen/S-mesillo.

Possiamo riattacare la sessione con:

:~$screen -r pippo

Credo 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.

Quindi, nel nostro esempio: con p torniamo a mc, con n andiamo a joe, con 0 ancora a mc e con 1 a joe di nuovo. Ben s'intende che, essendo questi comandi dinamici, vanno tutti, e sempre, preceduti da ctrl+a.

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.
  

Abbiamo visto solo parte delle funzioni di screen. Ed abbiamo imparato a sfruttarlo solo in maniera base. Infatti screen è uno strumento potente quasi al limite del pericoloso a volte. Parte delle potenzialità di screen si sono certamente intuite fin qui, ma per ora ci accontentiamo del nostro bravo terminale multitasking!

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!

:~$su
passwd:
:~$apt-get update
:~$apt-get install screen

Non dovrebbe nemmeno chiedervi di risolvere delle dipendenze.

(*)Controllare la shell di default:

:~$echo $SHELL

(**) Dovessimo mai passare al programma nella finestra proprio ctrl+a basterebbe usare ctrl+a e a.

Demoni e Draghi

deamon e dragon

deamon come processi in background:

Molti utenti di sistemi Unix-Like, ma non solo, hanno spesso sentito parlare di deamons. In sistemi derivati da CTSS (sistema operativo del 1961) questo termine stà ad indicare programmi (sarebbe meglio dire processi) che "girano" in background. Ossia processi la cui esecuzione non è immediatamente visibile all'utente. Un processo avviato in background non occupa la shell, esempio:
Avviamo programma in modo "normale"

:~$programma

e vediamo che questo "copre" la shell che abbiamo usato per avviarlo ,impedendoci di usarla, fino al termine della sua esecuzione. Proviamo a mettrlo in background.

:~$programma &
[1] 1234
:~$

La shell è ancora usabile anche mentre programma stà eseguendo le sue operazioni. Aggiungendo & alla righa di comando si dice alla Shell di non attendere la fine del processo appena avviato per continuare a svolgere il suo compito. La righa con cui la Shell risponde (che dipende anche dalla shell che usate, se non è Bash potrebbe differire un poco) è da interpretarsi così:

• numero del processo nella lista dei figli della shell
• pid del processo appena avviato

Quando programma terminerà la shell vi avviserà con un output del tipo:

[1]+  Done                    programma

Anche quì dipende un poco dal tipo di shell.

Ora sappiamo eseguire processi in bachground.
Però non tutti i programmi hanno senso in bachground. Ad esempio un ls fatto in background non differisce molto da uno eseguito "normalmente", si ottine solo uno sconvolgimento del normale output della shell. Anche un editor (vi, joe, nano, pico, ecc...) possono essere "sbattuti" in background... ma per ottenere cosa se non una prova!?
Di solito si "demonizzano" i processi che faranno, in un qualche modo, un servizio tipo server. Esempio tipico potrebbe essere Apache, famosissimo web server, che "gira nascosto" nel sistema attendendo una richiesta di qualcuno.

La differenza, solo un concetto:

Sostanzialmente demoni e draghi sono entrambi processi in background. Come pure in pratica. La differenza stà nel loro compito, o nel loro modo di operare se si vuole. Un processo in background diviene un demone o un drago a seconda del compito che svolge, quindi anche in base al codice (preogramma) che esegue.

Tipico esempio di un demone è un server (eg.: Apache). Un processo sempre presente ma che attende una "chiamata" per eseguire il suo compito, e poi tornare a dormire. Insomma un demone (deamon) si attiva in base alla volontà degli utenti.

Tipico esempio di drago (dragon) è cron, un processo in bachground che eseguie uno scheduler tipico dei sistemi Unix-Like. Cron, come tutti i draghi, non attende connessioni o richieste di alcun genere dagli utenti (o dai client degli utenti) ma si attiva, e compie i suoi compiti, secondo una "sua" logica, nel caso di cron il tempo che passa.

Quindi, volendo schematizzare: (vedetela sempre dalla prospettiva degli utenti o user)

• demone: aspetta richieste per eseguire il suo compito.
• drago: esegue le sue operazioni in base a una logica slegata dalle richieste degli utenti.

Pochi si ricordano dei draghi:

Il termine demone (deamon) è ancora oggi usatissimo nella cultura Unix. Il termine drago (dragon) è, invece, andato quasi perso; si è finito per chiamre demoni anche i draghi, ad esempio molte guide e how-to riportano cose del tipo: "il demone cron". Anche perchè la differenza è veramente sottile e, per un end-user soprattutto, quasi inesistente o quantomeno insignificante.
Tuttavia Unix è ormai una Cultura. O, se preferite, Unix ha creato una cultura. Comunque il discorso non cambia, è giusto, a parere mio, che certe persone ricordino le tradizoni e le parole che vanno in disuso, in qualsisi campo ci si trovi, e che condividano questa, più o meno esigua, ricchezza con chi vuole divenirne custode a sua volta.

Voglio comunque tornare, in futuro, al discorso dei singolari nomi, e non solo, che la Cultura Unix ha introdotto... ma adesso il tempo scarseggia.

Che cosa fanno i miei utenti? (w)

Un comando molto poco conosciuto da chi usa Unix come workstation è w. Esatto, un solo carattere! Sostanzialmente questo minuto (almeno nella sintassi base) comando serve a rispondere alla domanda: "che cosa stanno facendo gli utenti attualmente connessi al sistema?". Domanda che certo si fanno molto spesso gli amministratori di sistemi "multiutenza", che sicuramente conoscono il comando.

Anche se ad un utente Home-Desktop il comando w può sembrare pressochè inutile vale comunque la pena ricordarlo.
Bisogna ricordarsi che Unix è un sistema fortemente portato alla multiutenza e viene usato, ancora oggi, su macchine sulle quali molti utenti possono lavorare contemporaneamete. Il sistema di login di Unix infatti non serve soltanto a gestire utenti diversi, quindi con profili e privilegi diversi, che possono accedere alla macchina in tempi diversi, come avviene in altri sistemi.
Ora, in un contesto simile, ad un amministratore un comando come w può tornare molto utile.

Passiamo alla pratica:
La sintassi più semplice di who è quella senza nessuna opzione o parametro.

mesillo@stellascura:~$ w
17:55:44 up 58 min,  2 users,  load average: 0,08, 0,10, 0,09
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
mesillo  :0       -                16:58   ?xdm?   1:21m  0.29s x-session-manager
mesillo  pts/0    :0.0             17:30    0.00s  0.00s  0.00s w

In questo modo otteniamo la lista di tutti gli utenti connessi attualmente alla macchina. Andiamo con ordine ed analizziamo la prima righa (detta anche header).

• ora attuale
• tempo da cui il sistema è avviato
• numero di utenti connessi
• carico medio del sistema nell'ultimo minuto
• carico medio del sistema negli ultimi cinque minuti
• carico medio del sistema nell'ultimo quarto d'ora

Segue una riga che riassume il significato delle colonne sottostanti.
Poi arrivano i dati salienti.

• nome dell'utente (o meglio login-name)
• terminale a cui è connesso
• host da cui è connesso
• l'ora in cui si è connesso
• tempo di inattività (indicativamente da quanto tempo non preme un tasto)
• tempo di tutti i processi agganciati al terminale in questione (seconda colonna), compresi quelli in background attivi.
• tempo del processo in esame (colonna successiva what)
• comando dato per avviare il processo in esame (eg: ls -l pippo/)

Esistono anche delle opzioni e parametri che w accetta, la più semplice è l'username.
Quindi, se io volessi vedere solo le informazioni relative all'utente "pippo" dovrei dare un comando del tipo:

:~$w pippo

Utile se ho molti utenti connessi.
Per una lista completa delle opzioni vi rimando alla pagina di manuale di w.

:~$man w

Una opzione in particolare però và citata per una sua particolarità; -f. Infatti questa opzione dovrebbe servire a visualizzare, nell'output, la colonna FROM (terza). Questa colonna in certi casi, dipende da come è stato compilato w nel vostro sistema, è sempre presente nell'output di "default". Se il vostro w è così fatto (eg.: Debian etch) l'opzione -f sarà comunque ritenuta valida ma non sortirà nessun effetto (ovviamente!).

Adesso non vi resta che giocare un poco con w.

Renuclearizzare L'Italia!

Nel 1988, con un referendum, l'Italia ha deciso di rinunciare al Nucleare. Ossia alla possibilità di produrre energia usando come fonte la Fissione Atomica.
Al contrario di molti altri paesi, dove si è deciso solo di non costruire nuove centrali, nel Bel Paese sono state "smantellate" anche le 4 centrali già esistenti e produttive.
La scelta di molti paesi, già "nuclearizzati" o in via di "nuclearizzazione", in quello stesso periodo, è da attribuirsi in gran parte (almeno a parere mio) al disastro di Cernobyl.
Tuttavia è anche vero che l'energia Nucleare non ha mai goduto di buona fama, agli occhi delle masse, fin dal suo esordio. E proprio nel suo, infame, esordio che forse è da ricercare la paura che essa incute. Il primo esempio di energia Nucleare che il mondo ha osservato è stato quello delle Bombe Atomiche di Hiroshima e Nagasaki. Da allora questa tecnologia, di cui la massa sapeva poco o nulla, è indelebilmente legata all'immagine della Bomba, quindi a un qualcosa di nefasto. Ancora oggi la gran parte della gente associa, nella sua mente, qualsiasi cosa legata alla tecnologia "Atomica" a: morte, distruzione e sofferenze orribili. Ancora oggi, per l'uomo "moderno" del 2000, persiste questa diffidenza assoluta nell'Atomico. Ciò che è Atomico è male! Niente di più falso, sopratutto in una società come la nostra che accetta efferati crimini ambientali in nome del profitto!

Come ogni tecnologia anche l'Atomica ha i suoi rischi. Questo è innegabile. Ma siamo sicuri che siano superiori a quelle delle obsolete e inefficenti tecnologie che usiamo tutti i giorni senza riserbe? E se si, di quanto?
Non è forse pericoloso immetere tonnellate di gas serra in atmosfera bruciando a cielo aperto ciò che Madre Natura aveva relegato sotto terra? Non è forse pericoloso riversare in mare robaccia chimica? Non è forse pericoloso contaminare Acqua e suolo?
Sapete cosa veramente io ritengo il più grande pericolo? Il non voler informarsi e pensare!
Se è vero che con il "Nucleare" si fanno le bombe è altrettanto vero che esistono molte altre tecnologie in grado di produrre ordigni bellici... perchè non le boicottiamo tutte?

Da Cernobyl sono passati 21 anni, le tecnologie saranno pure migliorate! o no? Vent'anni fà il mondo era molto diverso. Ed è pure vero che gli Impianti Italiani erano, già all'epoca, ben'altra cosa che la centrale Stalin di Cernobyl in Ucraina!
Questa famigerata Centrale aveva 4 reattori funzionati, e altri due in costruzione, del tipo BMRK 1000. Tipo di reattore di vecchia concezione, già all'epoca, e mai usato fuori dell' ex-Unione Sovietica. Infatti si conoscevano già bene, parlo del 1986, i problemi che questa macchina dava a basse potenze. Oltre ai problemi intrinsechi di questo tipo di reattore, e delle strutture che avrebbero dovuto isolarlo dal mondo esterno in caso di necessità, l'incidente all'unità 4 fù dovuto anche al comportamento che tennero i "tecnici", non adeguatamente formati e prudenti, durante il periodo immediatamente precedente il tragico evento. L'esplosione è avvenuta durante l'esecuzione, maldestra, di un test atto a simulare proprio una situzione di difficoltà. Anche se i rettori BMRK sono meno sicuri di quelli che venivano usati in Italia non sono certo privi di dispositivi di sicurezza. In quel "test" il reattore 4 venne privato del sistema che, se fosse stato attivo, avrebbe provveduto automaticamante a "spegnere" il nocciolo. E questa non fù l'unica imprudenza commessa. I rettori, molti ancora funzionati tutt'oggi, di tipo BMRK sono stati comunque modificati dopo l'incidente del 1986. In definitiva si può affermare che l'incidente di Cernobyl non solo poteva essere evitato, ma è stato addirittura "cercato" per certi versi. Non voglio dilungarmi oltre sulla spiegazione degli avvenimenti dell'86, se desiderete approfondire un buon punto di partenza potrebbe essere questo: http://www.fisicamente.net/index-500.htm.

Ritornado al nostro amato Stivale: non riesco a capire come l'Italia sia stata l'unica nazione a smantellare le centrali già esistenti. Questo ha prodotto un deficit energetico praticamente "istantaneo", a cui si è dovuto sopperire andando a comperare energia all'estero senza possibilità di riorganizzarsi con nuove strutture interne al paese. Ribadisco che tutti gli altri paesi che hanno deciso di "denuclearizzarsi", nello stesso periodo, lo hanno fatto bloccando la costruzione di nuovi reattori, e non smantellando quelli ormai attivi. Ma quando si tratta di costi il Bel Paese non deve essere mai secondo a nessuno!

La mia opinione è che "ormai" (credo sia vero da molto tempo) l'Energia Atomica sia un "rischio" accettabile. Anzi, sono profondamente convinto che sia molto più accettabile il "rischio" dell'Atomica che le sicure conseguenze dell'uso dei combustibili fossili per la produzione di energia. Certo molti di voi saranno rimasti affascinati dall'auto elettrica, ma se si usa l'energia prodotta da una centrale a carbone, per caricare il proprio veicolo elettrico, allora non si è capito nulla! Esistono certo le fonti rinnovabili, come quella della luce solare, ma per il momento non sembrano poter soddisfare l'immenso fabbisogno energetico dell'uomo moderno. Nell'attendere che la Scienza e la Tecnologia ci facciano dono di una fonte rinnovabile, pulita e abbondante di energia, un qualche reattore potrebbe aiutarci a non avvelenare del tutto l'aria, l'acqua e la terra.

Ormai la tecnica si è evoluita molto in questo campo. Sono sorti nuovi tipi di reattori (vedi quello a Torio o quelli autofertilizzanti) e nuove tecniche per lo smaltimento (già nel 1993 è stata individuata una tecnica per ridurre il tempo di decadimento a 50 anni invece che a millenni) e riutilizzo delle scorie. Non di molti girni fà è la notizia che un gruppo di ricercatori Italiani, civili e militari, avrebbe trovato il modo di innescare la fissione in elementi non radiottivi per mezzo di ultrasuoni. Questa tecnica potrebbe essere usata per eliminare le scorie in un primo tempo e poi, più avanti, per produrre reattori "puliti".

La Scienza e la Tecnica fanno passi da gigante, perchè non sfruttare questi progressi?

Se ci pensate bene siamo comunque circondati da Reattori Nucleari e consumiamo comunque l'elettricità da essi prodotta, perchè continure ad acquistare questo prezioso bene dall'estero?

Ben vengano: pannelli solari, centrali geotermiche, centrali eoliche, ecc... ma se queste non possono sopperire a tutto il fabbisogno energetico allora risulta assurdo continure a bruciare combustibili fossili (dannosi e costosissimi) ed a seccare grandi fiumi (come il Po, in secca da un anno abbondante), per alimentare i bacini idroeletrici a discapito di agricoltura ed ambiente, quando abbiamo a portata di mano una tecnologia, ormai collaudatissima, che ci può aiutare. Anche la Francia, nostra vicina, stà costruendo nuove centrali con l'aiuto dell'Italia... perchè non in patria allora?

Anche se ad alcuni possono rimanere dei dubbi sulla sicurezza del Nucleare, io non posso che continure a pensare che, allo stato attuale delle cose, la denuclearizzazione sia assolutamente anacronistica e autolesionistica per un paese che si considera "avanzato" come il nostro.

Italia perde Android!

[edit]
Mi devo correggere. In realtà avevo capito male. Google dichiara di essere alle prese con delle procedure burocratice, non meglio precisate, ma di star ancora tentando di aprire il concorso in Italia. Mi scuso!
[/edit]

Non ho parole... finalmente una grande azienda dell'informatica, BigG, dava agli sviluppatori italiani una grande possibilità di mettersi in gioco... con un progetto Open oltretutto... ma come al solito la burocrazia ammazza sogni e buone intenzioni nel Bel Paese... e Google si ritira!

Vi faccio notare che Google è sempre stata un'azienda molto aggressiva e determinata nel portare a termine i suoi progetti... ma nel nostro paese si possono solo pagare tasse!!!... e che nessuno provi a dare delle possibilità ai non raccomandati!!!... azzo, che vogliamo svilupparci!?!... nono, a noi piacciono le tasse!!!... noi vogliamo finire come Cuba!!!

Links:
http://punto-informatico.it/p.aspx?i=2113769
http://www.corriere.it/scienze_e_tecnologie/07_novembre_14/concorso_google_android_italia_esclusa.shtml

Rimborso si... rimborso no...

Da tempo si parla della possibilità di farsi rimborsare un S.O. preinstallato, su un nuovo computer, in caso se ne volesse adottare un'altro.

Però la HP adotta, da un annetto circa, un particolare contratto di vendita per cui il software e l'hardware sono da considerarsi inscindibili... mah, che altro si inventeranno?

Per fortuna in Italia un giudice si è accorto che questo contratto di vendita contraddice la stessa licenza (EULA) del software che prevede il rimborso, previa restituzione.

Vi rimando al questa sezione del sito della ADUC per i particolari: http://www.aduc.it/dyn/rimborsowindows/.

Perchè le case prodruttici di computer non prevedono la possibilità di vendere macchine prive di software? Infondo questo non aumenterebbe affatto i costi di produzione... ed eviterebbe a tutte le parti le stenuanti procedure per la restituzione di software indesiderato.

Abbonamenti Trenitalia

Oggi è giorno di abbonamento! Mi alzo 5 minuti prima del solito e vado a farmi il solito salasso mensile... beh, 5 euro in più quasi!

Dico "quasi" 5 perchè non mi ricordo più il vecchio prezzo con esatezza... 51 euro e qualcosa comunque... ora sono 56,10! (Adria - Coronella)

Chi dal Veneto fà il pendolare a Ferrara sà che gli conviene fare l'abbonamento verso Coronella. Anche se questo paesino è la fermata successiva a Ferrara si trova oltre la regione e vengono applicate le tariffe nazionali che sono più convenienti! (strano che in Veneto si paghi di più!... mai capitato prima!)
Ora gli abbonameti costano uguali!... ci hanno fregato!... niente più trucchetto!

Ultimamente muoversi in treno costa sempre di più in Italia, le multe sui treni sono sempre più salate, i controlli sui biglietti vengono fatti anche a terra, ecc...

Ma voi avete visto un miglioramento del servizio?... io no!
Le stazioni fanno schifo, i treni ritardano di continuo, la sicurezza nelle stazioni è pressochè nulla... e noi intanto paghiamo di più!

In tre anni da pendolare ho visto crescere la mia spesa mensile per il trasporto di 8 euro circa, se non di più... ci sono meno treni rispetto a 3 anni fà... le stazioni fanno schifo uguale... e son spariti i treni interregionali!

Perchè quelli che una volta erano interregionali adesso son chiamati regionali? Forse per pagare meno il personale di bordo?... qualcuno mi sà rispondere?

Questo post confuso non è che l'inizio di una serie... l'uso dei mezzi pubblici dovrebbe essere incentivato, non mi sebra che Trenitalia lo stia facendo... e se lo sta facendo spigatemi come, io non capisco!