Il 10/06/2014 20:14, bodr...@mail.dm.unipi.it ha scritto:
ahi, ahi, ahi... top quoting... questo è male ;-)
Così' va meglio?
Ora veniamo al dunque.
Il Mar, 10 Giugno 2014 9:38 am, fran...@modula.net ha scritto:
Non importa se poi l'errore è del tuo comando o della shell o di chissà
cosa: il fatto è che il sistema, nel suo complesso, può produrre
risultati diversi da quelli che ci aspettiamo.
Invece importa, se l'errore non è nel mio comando, non puoi imputare il
bug al mio software.
Non è sempre facile attribuire l'errore a questo o a quel programma. Per
esempio, ho un softwarein un determinato momento prevede di ricevere il
valore "x" o il valore "y".
Gli perviene il valore "z" e il programma va abend. L'errore è di chi
fornisce l'input o di chi non lo controlla? Io penso che l'errore sia di
entrambi.
Naturalmente l'esempio è banale, ma mi serve per dire che un software
vive di interazioni e, per quanto può, deve prevedere i comportamenti
anomali. Chiaramente non può prevederli tutti (qualcosa devono fare
anche gli altri, no?) e da qui la sua incompletezza.Poi, via via che un
errore si verifica per un evento imprevisto o per un errore interno), e
se le correzioni non peggiorano la situazione, l'incompletezza
diminuisce. Resta da vedere se c'è l'incompletezza sparirà completamente
durante il suo ciclo di vita.
Voglio anche sottolineare che non sempre quelli che per alcuni sono
errori lo sono anche per altri: dipende dall'orizzonte che abbiamo di
fronte.
Per esempio, mi pare di ricordare che anni indietro, inviando una
determinata stringa a una determinata porta di un noto sistema operativo
non open source, si presentava il BSOD.
Potrebbe essere stato l'errore di un programmatore (questo comportamento
anomalo fu poi corretto) ma anche no: vai a saperlo....
Questa regola "relativistica" secondo me deve essere applicata anche
agli errori e vulnerabilità analiticamente reperibili nel codice
sorgente, non solo a quelli empiricamente verificabili nei compilati.
Poi si può disquisire anche se errori e vulnerabilità sono la stessa
cosa (nel caso di OpenSSH certamente, in altri casi non saprei).
voglio solo dire che la complessità del
software non è completamente dominabile e che anche in questo campo si
procede per errori e correzioni come in qualsiasi altro ambito
scientifico.
Io penso si debba distinguere tra scienza e tecnologia.
La scienza dovrebbe procedere per teorie, verifiche e dimostrazioni
Anch'io concordo con Popper.
Le teorie scientifiche vengono spesso dimostrate (o falsificate) da
esperimenti empirici.
Sarei quindi più propenso a dividere fra scienze pure e scienze
applicate: il processo di validazione/falsificazione resta però lo stesso.
Voglio aggiungere un pò di teoria dell'errore: una misura empirica non è
mai corretta.
Esiste la misura e un range di oscillazione in più e/o in meno, da
applicare in relazione allo strumento usato e altri parametri.
Di solito le misure sono ripetute più volte, e da queste,
statisticamente, si ricava la misura che definiamo "accettabile".
Però si parla di misura "accettabile" e non di misura senza errrori:
anche se lo fosse, senza errori, non avremmo alcun modo per saperlo.
Penserei di poter applicare questro parametro anche al software: può
essere accettabile o non accettabile in relazione alle specifiche e a
degli standard di riferimento ma il fatto che sia accettabile e che
normalmente funzioni come richiesto non mi può portare a definirlo 100%
"error free": se anche lo fosse non avremmo alcun modo per saperlo.
meglio dire che non esiste un metodo automatico che possa essere usato
per dimostrare la correttezza di un software qualsiasi.
CompCert [ http://compcert.inria.fr/ ] è un progetto estremamente
interessante: si tratta di un compilatore la cui correttezza è (quasi
completamente) certificata da sistemi di dimostrazione automatica!
E' il "quasi completamente" che (mi) dà fastidio. Peraltro occorrerebbe
che i sistemi di certificazione automatica fossero certificati a loro
volta da altri sistemi e così via, in una ricorsione infinita.
A meno che il sistema di certificazione (umano o artificiale poco
importa) non riesca a certificare anche sé stesso: però la vedo dura
[Kurt Godel].
Quindi cari colleghi programmatori, mettettetevi il cuore in pace e
rassegnatevi al vostro destino di cacciatori di insetti (io l'ho già
fatto da lustri).
Luciano
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org
To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5398b585....@modula.net
