[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] software ed errori [Era: OpenSSL: Altro bug]



Il 10/06/2014 20:14, bodrato@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, franchi@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


Reply to: