Home » Media / Tech »Opinie » Citesti:

Despre bug-uri. Inteligenta software si etica programatorului dand fata cu realitatea hard(ware)

Mihai Badici noiembrie 16, 2013 Media / Tech, Opinie
21 comentarii 2,821 Vizualizari

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ă, von 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 embedded. Cum acum pentru sistemele embedded 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 embedded 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 embedded 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.

Ai informatii despre tema de mai sus? Poti contribui la o mai buna intelegere a subiectului? Scrie articolul tau si trimite-l la editor[at]contributors.ro



Currently there are "21 comments" on this Article:

  1. Harald spune:

    Realitatea e cam la modul următor: nici măcar un modul de RAM de 2 GB nu poate fi testat exhaustiv, adresă cu adresă. Și chiar dacă ar fi testat, aproximativ la fiecare 15 zile ar apărea câte o eroare generată de o particulă gamma, iar particulele gamma există pur și simplu, n-avem cum să le eliminăm.

    Iar asta e valabil și în viața de fiecare zi: există gropi pe stradă sau chiar pe trotuare, mai lipsește câte un capac de canal, câte un avion aterizează forțat pentru că i-au intrat păsări în motoare sau pentru că un doberman de pe aeroport a uitat calele de la roți în compartimentul trenului de aterizare etc. etc.

    Așa e viața. Nu vor dispărea niciodată bug-urile din software, așa cum nu vor dispărea niciodată defectele ascunse din produsele electronice, de exemplu. Pentru că în disputa dintre Heisenberg și Einstein, cu privire la Dumnezeu și liberul arbitru, a avut dreptate Heisenberg. În ciuda faptului că religioșii preferă să-l citeze pe Einstein (”Dumnezeu nu joacă zaruri”) :P

    • Mihai Badici Mihai Badici spune:

      Sigur, dar erorile din modulele RAM nu pot fi imputate programatorului , si la o adica nici fabricantului, pe cand daca aloc mai putina memorie unei variabile, e un bug clar imputabil mie. Daca din cauza lui bombardez un sat in Kabul…

      • Harald spune:

        Eu cred că e o abordare greșită, obsesia de a găsi vinovați pentru una sau alta, ca și sentimentul de culpabilitate exagerată pentru propriile greșeli. Ține de educația din copilărie, de prezența unui Părinte Critic prea puternic, ar spune Eric Berne. Oamenii ar trebui să fie mai liberi, inclusiv atunci când greșesc, în măsura în care greșeala este autentică, neintenționată. Nu am auzit să fi ajuns nimeni la închisoare, nici după accidentul lui Challenger, nici după cel al Columbiei, deși au murit oameni de fiecare dată.

        Nu e neapărată nevoie de bug-uri în software pentru ca mașina să accelereze singură, în urmă cu vreo 20 de ani mi s-a întâmplat asta la o mașină cu carburator, pentru că s-a rupt un arc care ținea tensionat cablul de accelerație și pedala s-a dus imediat la podea. Convingerea mea personală este că azi se întâmplă mult mai rar asemenea incidente, cu toate erorile de software. Însă noi nu apreciem progresul și reducerea incidentelor, noi am dezvoltat obsesia vinovăției. Cred că vreo 2-3 catastrofe naturale ne-ar aduce la realitate :P

        • Gamma spune:

          Subscriu – aceasta obsesie este contraproductiva dar deocamdata eu ma vad mai degraba asaltat de “planned obsolescence” decat de dispozitive ridicol de fiabile si scumpe .In privinta Toyota din pacate nu a fost de ajuns doar pedala defecta pentru ca acei oameni sa moara , a mai fost nevoie si de un intreg tren de viteza automatizat ce nu permitea scoaterea din viteza a masinii in cazul cand pedala este apasata si un buton de pornire-oprire care ar fi oprit motorul doar daca era apasat incontinuu timp de trei secunde , lucru necunoscut soferului care astefel a devenit ultima veriga in acest lant al slabiciunilor . Cateodata prea multa automatizare strica .

          • iosiP spune:

            Interesant este faptul ca ambele caracteristici mentionate, luate individual, sunt foarte logice (in conditii normale de functionare, desigur): prima evita riscul de a scoate masina din viteza in timpul unei depasiri (de exemplu) iar cea de-a doua evita oprirea intempestiva a motorului daca cineva apasa din greseala butonul de pornire-oprire.

            Ce-i drept, cu partea privind “lucru necunoscut soferului” sunt mai putin de acord, fiind adeptul principiului RTFM ;)

          • Harald spune:

            Ăsta e rezultatul excesului de automatizare, pe de-o parte mașinile ar merge foarte bine și cu cutie manuală, iar pe de altă parte decuplarea transmisiei ar trebui să rămână totuși o opțiune disponibilă. Mi mi se pare că eroarea de concepție a sistemului în ansamblu este principala problemă aici, nu bug-ul de software.

            Pentru cine a citit Jurassic Park, exact asta e tema cărții, ideea că o construcție eminamente artificială nu poate avea decât o singură soartă, distrugerea.

  2. vlad spune:

    Errata : se scrie “embedded”, nu “embeded”. Nu pare a fi o simpla scapare, cuvantul apare de mai multe ori in text. Chiar sunt curios, care-i traducerea uzuala in romana pentru “embedded systems” ?

    • Mihai Badici Mihai Badici spune:

      Merci, am corectat.. E greu să ții pasul în limba română cu toți termenii tehnici care apar, eu cel puțin nu știu să existe un echivalent in română pentru embedded system, așa că în cazul de față varianta importului mi se pare cea mai potrivită. Din păcate cu limba engleză e o oarecare problemă atunci când incepi să declini sau să articulezi termenii ( la cei preluați din franceză nu prea aveam problema asta) dar în cazul de față “sistem” există în română.

    • penibil spune:

      Avem traducere : embedded = integrat
      embedded systems = sisteme integrate cel mai banal exemplu find BIOS-ul =)

      • Mihai Badici Mihai Badici spune:

        Sincer, cand zic “sistem integrat” numai la embedded nu ma gandesc. Poate ar merge “sistem dedicat” , dar si aici se pierde ceva, nu e clar ca se refera la circuite cu microprocesor, cum e in versiunea engleza. Nu sunt adeptul importurilor cu orice pret, dar cand pierzi in precizie mai bine renunti la traducere.

  3. phane spune:

    Softul poate fi creat pentru a fi mai testabil – mergând de la implementarea unor verificări de bază în program, până la implementarea unor module speciale pentru testarea automată. Iar în ce privește softul pentru interacțiunea cu utilizatorul, se pot imagina și executa baterii de teste destul de exhaustive.

    Dar testabilitatea și testarea implica niște costuri: de timp, de bani, de performanță a programului.

    De aceea, cred că de cele mai multe ori se face o alegere conștientă, în cazul programelor uzuale, de a prefera rapiditatea dezvoltării și costul redus, în defavoarea calității (care poate fi remediată ulterior – după ce folosești utilizatorii ca testeri, cu costuri zero). Evident, o testare tot se face – trebuie ca programul să meargă, în mare, înainte de a-i face release.

    Deci e vorba de filosofii de dezvoltare complet diferite pentru sistemele life-critical (unde testabilitatea și testarea sunt cruciale) și celelalte (unde testabilitatea nici nu e luată în calcul, iar testarea se face destul de superficial).

  4. Inginer spune:

    Nu „Van Neumann” ci John von Neumann.

    Cum puteti afirma, fara o analiza serioasa a ansamblului hardware-software si a comportamentului sau dinamic, ca depasirea de stiva “este foarte posibil, cazul sistemului de la Toyota”? Cauza poate fi una care necesita multe ore de testare si analiza, de catre oameni extrem de competenti. A „va da cu parerea” fara a cunoaste in detaliu cazul este ridicol pentru un pretins specialist.

    Scrieti: “Programatorii de azi nu au nevoie să știe prea multe despre sistemele pentru care scriu.” De cand cu sistemele multi si manycore, programatorii de elita trebuie sa stie tot mai multe detalii ale arhitecturii hardware pentru a o putea programa eficient (multi-obiectiv, adica performanta, energie etc.). Programarea paralela (explicitely multi-thread) reprezinta o mare provocare pentru oricine, atat in paradigma shared address cat si in cea de tipul message passing.

    Va recomand in mod constructiv sa reinvatati „masura” cuvintelor domnule inginer.

    • Mihai Badici Mihai Badici spune:

      Concluzia rezulta oarecum din raportul tehnic, in sensul ca s-au identificat situatii de acest gen. Evident, nu stim sigur, pentru asta ne-ar trebui date suplimentare, de aceea am zis probabil;
      In ceea ce priveste problemele cauzate de “decuplarea” intre software si hardware, imi mentin afirmatia. Necunoasterea completa a specificatiilor hardware e o cauza comuna a problemelor software. “Programatorii de elita” e un termen fara sens practic, producatorii de software angajeaza programatori pur si simplu. Iar excelenta se poate manifesta in multe directii in programare.

      • Inginer spune:

        N-ati zis “probabil” ci “foarte posibil” (dupa cum v-am citat si in prima mea interventie) ceea ce era de tot hazul. Nu prea sunteti atent la cuvintele utilizate… (Diferentele intre probabil si posibil sunt subtile. Spre ex. exista evenimente de probabilitate zero dar care sunt posibile. Paradoxal, nu?)

        Programatorii care mapeaza cvasi-optimal softurile pe masinile hardware se numesc conform terminologiei retelei de excelenta HiPEAC in Computer Architecture “efficiency programmers”. La ei m-am referit cand am spus “programatori de elita”.

        Citez din http://www.hipeac.net/system/files/hipeac-roadmap2011.pdf: “On the other hand, runtime libraries
        will become increasingly able to efficiently manage locality,
        using software algorithms that are more sophisticated
        than their hardware counterparts, while relying on hardware
        primitives that give explicit control of the communication to
        the software. This is a key task for efficiency programmers,
        who focus on optimizing critical pieces of code; productivity
        programmers, then, use these pieces in their code, with significant
        gains in performance. In some cases, the application
        is so important that it is justified to have efficiency programmers
        take the effort to explicitly manage locality. In the majority
        of cases where this is not the case, however, we must ensure
        that some combination of the compiler, runtime system,
        and hardware ensure that implicit communication is available.”

        • Mihai Badici Mihai Badici spune:

          Cred ca suntem amandoi de acord ca nu de astfel de programatori vorbim in cazul Toyota.
          Citez din raport:
          “Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching”.
          Cred ca iar am putea fi de acord ca e vorba de erori specifice programarii in C. Sigur ca exista si in assembler notiunea de adresare indexata- care ar putea fi echivalata cu folosirea pointerilor, dar in assembler sa reusesti sa dai “pointerii peste cap” mi se pare putin probabil…. dar, evident, posibil :) . Cand lucrezi in assembler cam stii exact cu ce registri lucrezi si cat de mari sunt.
          In mare insa am folosit cazul Toyota ca o ilustrare a situatiei in care sunt programarea si programatorii, nu cazul particular ma intereseaza, e posibil la altii sa fie lucruri si mai rele. Industria cere rezultate acum, investitorii nu au rabdare, e o presiune care duce de prea multe ori la neglijarea etapelor de testare, lucruri pe care le vedem zi de zi.

  5. un_batrin spune:

    Citeva observatii:
    Functia “autosave” exista de multa vreme inclusiv in microsoft offce, si si mai de mult prin Linux.
    Restartul este o specific microsoft. In ani de zile nu am avut nevoie de asa ceva in Linux niciodata.
    Windows este aparent pritenos. Nu poate fi prietenos un OS care incarca intentionat calculatorul cu gunoaie. Usor folosit doar pentru ca face ce vrea el si ce vrea utilizatorul pe baza principiului “utilizatorul este un timpit care nici nu stie ce vrea”.
    Van Nuemann este (John) von Neumann.
    In fine bug-urile sint inerente oricarui sistem informatic – a se vedea codul genetic (ADN) si uneori constituie motorul progresului (din nou ADN).

  6. ioan spune:

    Greseala neintentionata e una. Indiferenta privind greselile e alta.
    Sistemul binar este determinist. Se pot testa toate variantele conform specificatiilor, dar … costa…(exemplul cu numele utilizatorului nu mi se pare concludent : este o specificatie usor de mentionat a lungimii campului…) Pana la efectele datorate principiului lui Heisenberg e mult…si poate acestea ar putea fi acoperite -platite. Care este proportia de defecte care pot fi atribuite faptului ca un bit este interpretat fals datorita principiului Heisenberg in total defecte software? (deja este un defect hardware…)
    Totul a pornit de la acceptul vanzarii unui produs care din start nu este garantat. Ati cumpara un produs (alimentar de exemplu) din piata pe care ar scrie ca-l consumti pe propria raspundere, s-ar putea sa fie stricat, sa nu functioneze? (Evident, ar trebui sa aveti si posibilitatea sa alegeti totusi si altceva de mancare…)

    • Harald spune:

      Da, domnul meu, în practică exact așa se întâmplă: cumpăr un produs de patiserie de la Tesco și îmi scrie pe el că NU este garantat ”nut free”, că rețeta este ea ”nut-free” însă linia tehnologică pe care a fost produs nu este!

      Sistemul binar este determinist, dar numărul astronomic de adrese dintr-un modul RAM de 2GB face nepractică (și inutilă, de altfel) testarea TUTUROR variantelor, așa cum vreți dvs. La nivel filozofic, pasul următor este să negăm existența liberului arbitru :P

      • ioan spune:

        Nu e astronomic e 2 miliarde de adrese, respectiv 16 miliarde de biti perfect numarabili si testabili.(Nici macar numarul de atomi dintr-un mol… care nu au numai 2 stari si unde Heisenberg este util). Iar pt nemaipomenitele realizari tehnologice trebuie sa fie floare la ureche…

        • Harald spune:

          Când o să produceți dvs. calculatoare, așa să faceți, să testați individual fiecare modul de RAM. Pot să jur că Dell, Hewlett-Packard și Intel or să dea faliment în săptămâna imediat următoare :)

  7. Mircea spune:

    Interesant comentariul unui păţit (harpat ) la raportul tehnic accesat cu link-ul indicat :

    “My motto in life is, use digital technology for information and entertainment but not for mission critical operations when it can be avoided.”

    In sistemele serioase (sa le numim sisteme industriale) normele de protectie impun la masuri de siguranta metodele MECANICE. Software-ul este folosit pentru comunicatie, pentru reglare, semnalizare , indicare . Dar barierele de siguranta sunt de natura …mecanică / electromecanică cablata.



Comenteaza:







Do NOT fill this !

Autor

Mihai Badici


Mihai Badici

Absolvent al Facultății de Electronică si Telecomunicații București ( 1991) si doctorand al aceleiași facultăți. Administrator de sistem cu peste zece ani de experienț... Citeste mai departe


MIHAI MACI – Cel de-al doilea volum din Colectia Contributors.ro

"Atunci când abdică de la menirea ei, școala nu e o simplă instituție inerțială, ci una deformatoare. Și nu deformează doar spatele copiilor, ci, în primul rând, sufletele lor. Elevul care învață că poate obține note mari cu referate de pe internet e adultul de mâine care va plagia fără remușcări, cel care-și copiază temele în pauză va alege întotdeauna scurtătura, iar cel care promovează cu intervenții va ști că la baza reușitei stă nu cunoașterea, ci cunoștințele. Luate indi­vidual, lucrurile acestea pot părea mărunte, însă cumulate, ele dau măsura deformării lumii în care trăim și aruncă o umbră grea asupra viitorului pe care ni-l dorim altfel." - Mihai Maci

E randul tau

Că incompetența și corupția sînt legate, merg mînă în mînă, stau la aceeași masă, etc., ...

de: vintila mihailescu

la "Corupție sau incompetență?"

Cauta articole

decembrie 2016
Lu Ma Mi Jo Vi Du
« Noi    
 1234
567891011
12131415161718
19202122232425
262728293031  

Valentin Naumescu – Marile schimbari. Crize si perspective in politica internationala. Editie bibliofila

contributors.ro

Contributors.ro este intr-o permanenta cautare de autori care pot da valoare adaugata dezbaterii publice. Semnaturile noi sunt binevenite cata vreme respecta regulile de baza ale site-ului. Incurajam dezbaterea relaxata, bazata pe forta argumentelor.
Contact: editor[at]contributors.ro

(An essay by Vladimir Tismaneanu and Marius Stan)