[Gfoss] softwares taumaturgici, ex Festa della geografia

Un aneddoto: un convinto sostenitore di un noto GIS proprietario alla
fine di una chiaccheirata ha detto che lui qgis lo usava piu' che altro
per aprire gli shp che causavano segfault nel suo GIS. Risalvandoli da
qgis riusciva poi a lavorarci nuovamente.

Forse sarebbe piu' utile che questo "convinto sostenitore del software
commerciale", cercasse di capire perche'
con un software si ottiene un "segfault" e con l'altro no.
Anziche assegnare a un determinato software delle capacita' taumaturgiche.

Provo a ipotizzare uno scenario:

supponiamo che il software A quando incontra un elemento geometrico
malcostruito generi errore e si fermi.
Supponiamo poi che vi sia un secondo software GIS che chiameremo B,
che nella medesima situazione non generi errore,
ma semplicemente si limita a ignorare il record saltandolo. E questo
lo faccia in silenzio senza dire nulla al tecnico fiducioso.

Il risultato e' che il primo sembra non funzionare, il secondo sembra
funzionare.

Quando poi l'utente usando il software B risalva lo shapefile, il
risultato e' che si trova davanti uno shapefile con un record in meno,
quello con
l'elemento errato.
Quello che appare e' che ora lo shapefile "magicamente" si riapre
anche con il software A.

Ma se il tecnico si pone la domanda del perche' uno si l'altro no,
indaga e puo' arrivare alla spiegazione, venendo a sapere che manca un
record e puo' quindi recuperare l'informazione persa.

Se invece si limita a credere alla buona sorte probabilmente non se ne
accorge ed'e' probabile che passerranno molti mesi prima che qualcuno
si accorga che manca quel record difettoso
(o quei records se sono piu' di uno)

ovviamente e' uno scenario ipotetico, pero' farebbe riflettere.
E' meglio il software che ti avvisa che vi e' un errore o e' meglio il
software che saltando tacitamente l'elemento errato non ti informa
del problema ?

Probabilmente e' meglio averli entrambi. Il primo perche' ti avvisa
che qualcosa e' successo e il secondo perche' ti consente di limitare
i danni.

Pero' il tecnico capace si pone domande e cerca di capire cosa e' successo.
Perche' non basta accontentarsi di riuscire a riaprirlo, occorre
sempre chiedersi perche'.

Ciao.

--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~

Andrea Peri ha scritto:

Un aneddoto: un convinto sostenitore di un noto GIS proprietario alla

...

Forse sarebbe piu' utile che questo "convinto sostenitore del software
commerciale", cercasse di capire perche'
con un software si ottiene un "segfault" e con l'altro no.

Beh, non pretendevo di farne uno studio: l'ho riferito come aneddoto
paradossale e divertente.

supponiamo che il software A quando incontra un elemento geometrico
malcostruito generi errore e si fermi.

...

Il risultato e' che il primo sembra non funzionare, il secondo sembra
funzionare.

In ogni caso l'errore non deve generare un crash, altrimenti e' un bug.
Salutoni.
pc
--
Paolo Cavallini, see: * http://www.faunalia.it/pc *

>....
> Beh, non pretendevo di farne uno studio: l'ho riferito come aneddoto
> paradossale e divertente.

Infatti lo e'.
Pero' trovo altrettanto giusto cercare di dare una spiegazione razionale.

>In ogni caso l'errore non deve generare un crash, altrimenti e' un bug.
>Salutoni.

Verissimo, pero' anche la ipotetica mancata segnalazione di un errore sui dati lo e'.

Mi permetto comunque di raccontarti anche io un aneddoto molto divertente seppure estraneo al mondo GIS e quindi mi scuso per l' OT.

15 anni fa' nel pieno dell' era DOS, si stavano affacciando i primi virus.
Un mio amico cerco' di inventare un antivirus innovativo.
Lo chiamo' "StopVirus", e effettivamente li stoppava inevitabilmente.

tecnicamente era molto pregevole,anche se il suo funzionamento in linea di principio era semplice.
Trattavasi di un programmino residente (tipico in un ambiente mono-task quale era DOS), che quando veniva attivato metteva la CPU in modalita' debug e riusciva quindi ad analizzare una per una ogni istruzione che la CPU eseguiva, prima della sua esecuzione.
Come antivirus effettivamente era sicurissimo, infatti i virus facevano inevitabilmente chiamate a INT12 e a INT21 per scrivere su disco.
Lui le intercettava prima della loro esecuzione e faceva aprire una finestra in cui avvisava e chiedeva conferma.

Unico neo, il computer che gia' era lento (non erano certo le cpu di oggi) diventava molto piu' lento, mostruosamente lento!

Venendo all'aspetto divertente.
In quei computers era in uso i famosi floppy-disk .
che pero' ogni tanto davano errore di lettura.
Ebbene, quando si attivava StopVirus, avveniva il miracolo che floppy-disk che prima erano illeggibili diventavano leggibili, permettendo di recuperare dati altrimenti persi per sempre.

Naturalmente dietro vi era una spiegazione tecnica.
Infatti StopVirus rallentando la macchina, rallentava anche le operazioni di lettura dei floppy, questo faceva si' che la testina indugiasse maggiormente su ogni traccia.
Questa permanenza maggiore rendeva aumentava la probabilita' che la traccia venisse alla fine letta (il numero di tentativi aumentava) anche in presenza di una magnetizzazione debole.
Ricordo che a Ingegneria ci facemmo proprio uno studio tecnico sopra con tanto di statistiche sulle probabilita' di successo :))

l'unico scontento era l'autore, che voleva creare un antivirus e sentirsi dire che il suo software come antivirus faceva schifo, ma era un ottimo "riparatore di dischetti" non lo entusiasmava per niente.

Ciao,

Paolo Cavallini ha scritto:

Andrea Peri ha scritto:

Un aneddoto: un convinto sostenitore di un noto GIS proprietario alla

...

Forse sarebbe piu' utile che questo "convinto sostenitore del software
commerciale", cercasse di capire perche'
con un software si ottiene un "segfault" e con l'altro no.

Beh, non pretendevo di farne uno studio: l'ho riferito come aneddoto
paradossale e divertente.

supponiamo che il software A quando incontra un elemento geometrico
malcostruito generi errore e si fermi.

...

Il risultato e' che il primo sembra non funzionare, il secondo sembra
funzionare.

In ogni caso l'errore non deve generare un crash, altrimenti e' un bug.
Salutoni.
pc

On Mon, Nov 17, 2008 at 09:57:57PM +0100, Andrea P. wrote:

metteva la CPU in modalita' debug
...
inevitabilmente chiamate a INT12 e a INT21 per scrivere su disco.

Andare in debug per intercettare due interrupt? Non era piu'
semplice e piu' efficiente modificare i due vettori di
interrupt e mettere un piccolo wrapper all'handler?

Vabbene... ho capito... mi cheto!

--
Niccolo Rigacci
Firenze - Italy