Despre bug-uri. Inteligenta software si etica programatorului dand fata cu realitatea hard(ware) de Mihai Badici Deși zilele trecute l-am asigurat pe un cititor că la mașini nu ma pricep, o știre citită întâmplător săptămana trecută pe Slashdot mi-a atras atenția. Este vorba de procesul în care firma Toyota este acuzată că anumite deficiențe la pedala de accelerație pot duce la accelerare neintenționată și aceasta ar fi cauza unor accidente mortale. Raportul tehnic este acuzator, pentru curioși poate fi consultat aici De când computerele au intrat în viața noastră, ne-am obișnuit să tratăm bug-urile software ca pe ceva inerent domeniului. Este normal ca uneori programul cu care lucrăm să se blocheze, luînd cu el o oră de lucru sau mai mult ( mai nou cam toate editoarele și nu numai au introdus providențialul autosave care minimizează pierderile) iar câteodată sistemul are nevoie de un restart pentru a mai elibera din memoria blocată de câte un program care uită să o mai dea înapoi. Celebrul ecran albastru al Microsoft a devenit aproape un icon al firmei; el reprezintă prețul plătit de noi, utilizatorii, pentru a beneficia de un sistem de operare prietenos și simplu de folosit. Mărturisesc că, după atâta amar de ani petrecut alături de calculatoare, microcontrolere si orice altă jucărie care implică un microprocesor, încă mă mai mir că programele de calculator în general funcționează. Trebuie ca miile sau sutele de mii de octeți de cod citiți de pe hard disk-uri să fie corecte, trebuie ca fiecare octet din cei câțiva gigabytes de RAM pe care computerul meu îi are să fie corect și să fie citit corect pentru ca sistemul să nu intre în bălării cum numim uneori situația în care procesorul începe să execute cod de la cu totul altă locație de memorie, care nu are nici o legătură cu programul nostru, ba poate nici măcar nu reprezintă un program, pentru că în arhitectura clasică, Van Neumann, codul și datele se găsesc în aceeași memorie fizică. Sigur că există diverse mecanisme de protecție care verifică datele citite, dar, ca să citez din EULA: “There is no warranty”. Prezența bug-urilor în orice sofware de larg consum e o constantă favorizată de mai mulți factori, o listă pe care nu o putem epuiza aici. Pe de o parte e factorul uman. Software-ul e scris de oameni, iar oamenii greșesc. Există proceduri de test pentru software, dar în prea puține cazuri acestea pot acoperi toată gama valorilor sau situațiilor de intrare. Îmi amintesc cu un zâmbet cum pe la începuturile carierei de administrator de sistem – după ce lucrasem destulă vreme în limbaj de asamblare pentru microcontrollere, am scris un mic progrămel care citea dintr-o bază de date utilizatorii pentru serverul de mail. Cum veneam dintr-o zonă în care memoria era puțină, am alocat doar 40 de caractere pentru numele utilizatorului, din obisnuință. Sistemul a funcționat așa vreo cinci ani, până a venit un angajat nou, al cărui nume – fatalitate! – era mai lung. Și care nu se putea autentifica nicidecum. Probabil că dacă nu ar fi venit acel coleg, nu aș fi știut niciodată că acel progrămel de zece rânduri are un bug. O problemă mai delicată însă este decuplarea tot mai accentuată a software-ului de hardware. Programatorii de azi nu au nevoie să știe prea multe despre sistemele pentru care scriu. O mare parte a detaliilor specifice este mascată de diverse biblioteci sau apeluri de sistem. Din cauza asta, unele presupuneri – mai cu seamă aceea că avem suficientă memorie in stivă pentru a face oricâte apeluri de funcții – s-ar putea dovedi false atunci când trecem de la sisteme de tip PC la embeded. Cum acum pentru sistemele embeded se foloseste C, bazat pe apeluri repetate de funcții, epuizarea memoriei poate surveni oricând. Este foarte posibil, cazul sistemului de la Toyota. Uneori programatorii de dispozitive embeded mai sar peste câte un test, pentru a economisi timpi de procesor. Folosită cu precauție, metoda poate fi acceptabilă, mai ales dacă poți controla valorile de intrare. Din păcate însă, atunci când vorbim de colective mari, o astfel de informație se pierde, iar uneori codul se reutilizează în alte părți, pierzându-se din vedere constrângerile inițiale. Dar, dacă prezența gândacilor în software-ul nostru de birou poate fi cumva acceptabilă , așa cum ne-am obișnuit și cu gândacii reali care mai trec prin casele noastre uneori, și mai ales poate fi cuantificată în termeni de calitate/preț ( cât ar costa un software de birou care să fie complet testat ?) prezența lor în dispozitivele embeded ridică multe probleme de natură juridică, ba chiar deontologică. În cazul procesului Toyota e vorba de accidente cu victime. Este foarte posibil ca accidentele, sau o parte din ele, să nu aibă prea mare legătură cu bug-urile semnalate în raport. Dar ele există, au fost depistate, și o umbră de îndoială va exista totdeauna. Dacă nu au făcut victimele din prezent,există posibilitatea să facă în viitor. Dacă ne gândim că în prezent există mai multe firme care experimentează masinile fără șofer, că deja armatele moderne folosesc drone pentru bombardamente sau că centralele nucleare sunt în cea mai mare parte automatizate, ne dăm seama că bug-urile nu sunt doar o problemă minoră. Cel puțin nu în toate domeniile. Sigur că o parte din aceste dispozitive – pedala de exemplu- au un set limitat de intrări si pot fi complet testate. Probabil că aici vor trebui reglementări legale, pentru că operația respectivă costă, deci dacă nu e impusă tuturor producătorilor, totdeauna se va găsi un iresponsabil care va vinde mai ieftin. Altele însă, ca dronele sau mașinile fără șofer, nu pot fi testate complet, așa cum nici noi, șoferii umani nu putem fi testați și câteodată mai producem vreun accident. Aici, problemele de natură juridică și etică sunt complexe și soluțiile dificil de imaginat. În tot cazul, juriștii viitorului nu vor muri de foame. contributors.ro/editorial/despre-bug-uri-inteligenta-software-si-etica-programatorului-dand-fata-cu-realitatea-hardware/
Posted on: Sat, 16 Nov 2013 14:40:06 +0000
Trending Topics
Recently Viewed Topics
© 2015