Forum Debian Users Gang

Weźmy na przykład kernela i Torvaldsa. Chyba każdy powie, że on się zna na tym co robi, prawda? xD A mimo to kiedyś na jakimś *confie gadał o błędzie, który był w kernelu i powodował zwięchę czy coś. Debugowali to kilka tygodni i w końcu ustalili, że jakiś pojedynczy bit był za te dziwne problemy odpowiedzialny. Może to trochę przypomina House M.D., ale jeśli by ci się pacjent "powiesił", to raczej nic byś już nie mógł zrobić, a tym bardziej testować na nim różnych rozwiązań, czy przeglądać wszystkie jego organy w poszukiwaniu błędu. xD To jest właśnie różnica między IT i wszystkim innym — my tutaj możemy sobie na to pozwolić i nie musimy wszystkiego znać na pamięć, bo IT, to nie technologia informacji ale umiejętność zarządzani nią. Jeśli to potrafisz, to bez problemu sobie w IT poradzisz, jak nie, to i do chirurgii się nie pchaj, no może najwyżej jako pacjent. xD

A w chirurgii też trochę można uczyć się doświadczalnie.

Człowiek uczy się tylko przez doświadczenie. I w IT i w medycynie wszyscy się uczą przez doświadczenie ale to, że te wszystkie papierki, które od nas wymagają w medycynie by móc ludzi leczyć, to jest właśnie za sprawą taką, że człowiek ma jedno życie i nie możesz sobie przed operacją wcisnąć ESC -> save game, a w przypadku gdy wyciąłeś nie ten płat czołowy co trzeba, to ESC -> load game i jedziesz jeszcze raz (ewentualnie F5 i F6 xD). To dalatego się wszyscy pchają do IT, bo po pierwsze jest to nowa gałąź, a po drugie o wiele lżej ta branża znosi problemy. Krótko mówiąc, możesz się pomylić i nikt z tego powodu nie wyciągnie wobec ciebie większych konsekwencji.

Zdaję sobie sprawę, że tak skomplikowane rzeczy jak przeglądarki czy popularne systemy operacyjne nie mogą być wolne od błędów, bo są zbyt skomplikowane, ale już jakieś stosunkowo małe oprogramowanie w urządzeniach medycznych jednak powinno być wolne od błędów. Może się to zmieni w przyszłości...

Nie zmieni się. Człowiek nie jest w stanie przewidzieć wszystkich okoliczności, które będą wpływać na pracę programu. Możesz sobie dać pełno warunków ale to tak jak gra w szachy. Na początku ciężko jest popełnić błąd ale im grasz dłużej daną partie, tym ryzyko pomylenia się podchodzi pod 100%. Tak samo jest w programowaniu. Ktoś kiedyś napisał, że tylko "hello world" nie ma błędów, choć ja mam co do tego wątpliwości, okażę się za 100lat kto miał rację. xD Tak czy inaczej, pamiętaj, że te urządzenia medyczne muszą pracować w pewnych warunkach i bardzo rzadko są to warunki idealne, w sensie nieproblematyczne pod żadnym względem. Spróbuj uderzyć takie urządzenie, albo niech karetka wjedzie na jakiś wybój i jak się wtedy zachowa urządzenie, do którego dotrze jakaś porcja drgań? Różnie. xD A jak będziesz to skrypcił i próbował jakoś przewidzieć warunki w jakich to urządzenie może pracować, to uczynisz je bardziej skomplikowanym, a tu już bardzo łatwo o błędy. By poprawić ten stan rzeczy, trzeba człowieka wyeliminować z procesu programowania. Jest to jednostka wielce nieefektywna i cholernie zawodna. Jakoś musimy z tym żyć, póki komputery nie staną się samoświadome i nie zaczną się same uczyć. xD

formalna zgodność z założeniami nie oznacza bezbłędności założeń.

btw. formalnie bezbłędnym systemem był o ile pamiętam venus... ktoś oprócz historyków o tym wie?

2376

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:27:17)

Druga sprawa, że to zależy co znaczy błąd.

Ja rozumiem błąd jako nieprzewidziane, często niepożądane, działanie jakiejś aplikacji.

No skoro poleciał nie tam gdzie trza, to jest to nieprzewidziane działanie. czyli błąd. xD Niekoniecznie musi to się odnosić do faktycznego błędu w kodzie (chodzi o składnie, itp), po prostu nie działa tak jak powinien i trza to fixnąć. xD

@uzytkownikubunt:

Co do sytuacji, w których krytyczne oprogramowanie (np w urządzeniach medycznych wycenianych na duże kwoty) ma jakieś błędy, czasem proste i oczywiste, a nikt z programistów za to nie idzie do więzienia... cóż, nie podoba mi się to. Zdaję sobie sprawę, że tak skomplikowane rzeczy jak przeglądarki czy popularne systemy operacyjne nie mogą być wolne od błędów, bo są zbyt skomplikowane, ale już jakieś stosunkowo małe oprogramowanie w urządzeniach medycznych jednak powinno być wolne od błędów. Może się to zmieni w przyszłości po takich akcjach, jak wydanie certyfikatów przez Symanteca pozwalających podszywać się pod Google'a (zdaje się wyrzucono chociaż kogoś z pracy) albo oszustwa Volkswagena.

Zdefiniuj "stosunkowo małe oprogramowanie", takie ECU w aucie wydaje się prostym systemem, prawda? W zasadzie odczyt zawartości tlenu przed i po spalaniu mieszanki, kilka sond, kilka linii kodu implementujących sprzężenie zwrotne i tyle... tak może jest w moim Saxo, albo innym starociu, ale w nowych autach jest tak:

http://www.edn.com/design/automotive/4423428/Toyota … -consequences

Cytat z powyższej strony:

Embedded software used to be low-level code we'd bang together using C or assembler. These days, even a relatively straightforward, albeit critical, task like throttle control is likely to use a sophisticated RTOS and tens of thousands of lines of code.

Dodajmy że w maszynach medycznych zwykle jest tego sporo więcej niż w ECU auta...

Dlatego czym jest to "małe" oprogramowanie pytam się? Czym to mierzyć? Ilością kodu? Złożonością? Ja tutaj nie widzę dobrego miernika... (czy BASIC w C64 to było małe czy duże oprogramowanie :) ? )

Faktem jest że programiści bardzo rzadko ponoszą odpowiedzialność karną ale to wynika z kilku czynników:

1. Zwykle w zespole jest wiele osób i rzadko kiedy tylko jedna z nich pracuje nad danym kodem - czy mamy zamknąć programistę, testera, project managera, a może wszystkich? Co jeśli ktoś przez moment pracował nad kodem a potem odszedł np. do innej firmy - czy powinien odpowiadać za to że jego następca nie wyłapał problemów?
2. Kod X musi zwykle polegać na kodzie Y - w takiej sytuacji nie zawsze jest łatwo określić kto dokładnie dał tyłka (czy twórca X czy Y), zwłaszcza jak dokumentacja jest "rozmyta" (standard) albo mamy subtelny błąd (np. to co przytoczył @morfik odnośnie kernela)
3. Spora ilość testów jest w ogóle porzucana ze względu na decyzje odgórne, bo "czas (nierealistyczny, który góra ustaliła) się skończył"... i kogo wtedy pociągnąć do odpowiedzialności?
4. Ciężko określić co jest a co nie jest rażącym błędem w programowaniu... czy brak średnika to rażący błąd? Czy nie zwolnienie pamięci? Czy wyjście indeksem poza zakres tablicy?
5. Jak samemu zauważyłeś - choćbyś nie wiem jak testował, babol i tak może się zdarzyć, ludzie to (niestety jeszcze) nie cyborgi

Rozmyte podejście do odpowiedzialności nie jest tylko domeną IT bo doświadczenie pokazało że najłatwiej jest zwalić wszystko na jednostkę, tylko to nie rozwiązuje problemów, dlatego - o ile nie popełniono rażących błędów - zwykle ani lekarz nie odpowiada karnie za śmierć pacjenta, ani kontroler lotów za rozbity samolot, ani pilot, ani twórcy maszyny...

Żeby nie było - nie bronię tego co jest, ale szczerze - nie potrafię sobie wyobrazić jak miało by to wyglądać...

Pozdrawiam.

Ostatnio edytowany przez Huk (2015-11-14 19:22:17)