Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #29637
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Newsgroups | pl.comp.programming |
| Subject | Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 |
| Date | 2017-04-27 19:53 +0200 |
| Organization | ATMAN - ATM S.A. |
| Message-ID | <odtb6q$445$1@node2.news.atman.pl> (permalink) |
| References | (6 earlier) <485788e8-89fb-4b37-a38c-924662107718@googlegroups.com> <odo0is$9aj$1@node1.news.atman.pl> <90c9e163-335e-4a23-a369-6a940ad1dc97@googlegroups.com> <odqhim$sgp$1@node1.news.atman.pl> <ed68da9e-067a-43d0-804c-619f24779251@googlegroups.com> |
On 4/27/2017 3:16 PM, Maciej Sobczak wrote: >> Myślę że ten wypadek pokazuje jak pusty jest mit o bezpieczeństwie Ady. > Ten wypadek pokazuje, że jak się nie korzysta z mechanizmów języka, to nie będzie pozytywnych efektów Czyli nie pisali w Adzie. Dziwne, bo się tym wielu ludzi chwalilo, na newsach też często czytam że krytyczny soft pisze się w Adzie. > Parafrazując - samochód utonął w rzece razem z kierowcą a Ty pokazujesz >, jak pusty jest mit o bezpieczeństwie poduszek powietrznych. Inaczej: mit Ady doprowadza do twierdzeń z gatunku "moj samochód ma poduszki powietrzne, więc nie zatonie". Zauważ że decyzje biznesowe dotyczące wyboru technologii prawie nigdy nie podlegają osobie która ma o nich pojęcie. W korpo w szczegolnosci, w ESA nie wiem, może. >>> I gdzie ostatnio widziałeś praktykę pisania takich symulatorów? >> *WSZĘDZIE*. > Bad news: nie wszędzie byłeś. Brawo. > W szczególności nie byłeś tam, gdzie się tego nie robi. To obniża efektywność tej dyskusji. Nie, nie obniża, przeciez to trolowanie. Pokazuje jednak dośc istotne zjawisko: wszedzie powinno się doprowadzać do testow z uzyciem jakiegoś inputu rzeczywistego. W przypadku rakiety symulacja nie była by trudna do zrobienia. Policzenie na kartce siły ciągu, przyspieszenia i kilku innych parameterów też jest w zasiegu. Nie zrobiono tego. Mimo że wystarczający model wykrywający takie bugi jest w zasiegu studenta mechaniki/fizyki. > W Twoim trollowaniu są proste błedy logiczne - w tym samym poście twierdzisz >, że systemy krytyczne piszą idioci i jednocześnie że "wszędzie" pisze się symulatory procesów fizycznych. Wszedzie pisze się testy. Przynajmniej wszedzie w ciezkiej i drogiej informatyce. Akuratnie nie musza być symulatorami fizyki, bywają. Taki matlab kroi z tego niebotyczną kasę. > Może przyjmij jakąś jedną spójną wersję. Nawet błędną, ale jedną. Proszę: caly świat testuje oprogramowanie in vitro poza esą ktora robi to na hura. O ile w przypadku Ariane 5 to mogła być wpadka jakich wiele, to następna, prawie identyczna zaczyna zastanawiać. Zrobili testy tego kodu *PO* katastrofie sondy. Zabawne, naprawdę. Wychodzi na to że się dało i to dosc szybko, przetestować kod. Mnie by nie było stać na wysyłanie w ciemno kodu z tonami podpisów. >>> Cały czas o tym piszę. To nie jest wina tego języka. >> Język jest winien tworzenia idiotycznej atmosfery bezpieczeństwa > Nie. To wybór języka wynika z tej atmosfery. Atmosfera była wcześniej i jest niezależna od użytego języka. > Naprawdę. Tu bez wątpienia mogło by godzinami rozmawiać kilku filozofów co z czego wynika. > Dlatego właśnie w projektach w C nie jest lepiej - a byłoby >, bo przecież z tego co piszesz, wtedy nie byłoby "idiotycznej > atmosfery bezpieczeństwa" i obniżania jakości. Więc jakość powinna > być wyższa. A wiadomo, że nie jest. Czyli znowu masz błąd logiczny w Twoim trollowaniu. Nigdzi nie pisałem o uzywaniu C więc ciezko się wywodzi o czyjejś logice na podstawie wyssanych z palca cytatów. Co do jakości: więcej testowania niekoniecznie ją podnosi. Gdyby testowani Ariane5 invitro to kod dalej by wyglądał jak wypociny hackera od asm. Zmniejsza tylko szanse na błąd takiego kalibru. >> Kiedyś czytalem wypociny pewnego przygłupa od Ady który twierdził że >> język jest tak znakomity że już nawet nie testują częsci kodu bo wiadomo >> że działa dobrze. > Wykorzystanie statycznych metod analizy Nie wykorzystują. Pisza i od razu jest dobrze, tak powiedział. > pozwala obniżyć rygor pokrycia testami Pod warunkiem że bugi tkwią w składni lub algorytmice. Gorzej gdy w zakresach. Ale obniżyć zawsze warto, wiadomo, jak oszczędzać to na rzeczach krytycznych. > i to wynika z procesów a nie z zastosowanego języka. Takie strategie stosuje się > niezależnie od użycia Ady, w C również. I nie dotyczy to tylko latania w kosmos, > ale również np. cywilnej branży lotniczej. Mówisz np o DO-254. No więc coś Ci powiem o tym. Akuratnie ilośc testowania kodu w hardware i software rośnie. Nigdy tak wiele nie testowano i robimy tego coraz więcej. Mozna powiedzieć że testowanie eksplodowalo jakieś 10 lat temu i ta eksplozja trwa. Wyrosły ogromne metodyki, od korporacyjnych po detaliczne, jak testować *każdy* aspekt kodu/hardware. Od testow jednostkowych przez radomizacje, po symulacje fizyki i obieg dokumentów. Nikt tu niczego nie ogranicza. Wręcz przeciwnie. EDA rośnie prawie wyłącznie w dziedzinie weryfikacji. Obecnie hardware i software zlewają sie w jedno, wiec dotyczy to rownież firmware embedded. > To są ciekawe tematy, ale jeśli chcesz podyskutować, to przestań trollować. Czasem trzeba. Inaczej programisci Ady będa chodzili tak samo nadęci jak programiści VHDLa mimo że świat jest hektary dalej w metodach weryfikacji niż silne typowanie i ładne exceptiony. > Na pytania chętnie odpowiem, ale z trollowaniem nie chce mi się walczyć. Nie ma pytań: ESA dała dupy dwukrotnie w ten sam sposób. Nie pomogła im Ada bo na idiotów nie ma rady. Spuśc troche powierza. Zarobiłem zaczepkę z mrugnięciem i od razu zaczynasz straszliwą dyskusję i edukowanie kogo popadnie i kiwaniem palcem. Zważ że inni mają tez jakieś punkty widzenia i czasem trzeba odsunąć się od swojej pracy żeby zobaczyć jak wiele błedow popełniamy w programowaniu. Ja widze jak się weryfikuje hardware/firmware w dużej skali, z miejsca gdzie siedzę. Nie zgadzam się z tym że na tym się oszczędza. Nie, pompuje się mld dolarow w weryfikacje na całym świecie, wiele procent tej weryfikacji zalezy rownież od symulatorów fizyki. Powstało tysiące firm dostarczających narzedzia aby robić to lepiej, szybciej. Wszyscy weryfikują. To jest teraz ważniejsze od pisania kodu.
Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 szykcech@gmail.com - 2017-04-22 09:12 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Wojciech Muła <wojtek.mula@gmail.com> - 2017-04-22 13:24 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-23 10:29 +0200
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-24 05:29 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Michal <michal@kleczek.org> - 2017-04-24 07:16 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-24 15:24 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Roman Tyczka <noemail@because.no> - 2017-04-25 08:29 +0200
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-04-25 08:44 +0200
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 michal@kleczek.org - 2017-04-25 05:19 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-26 06:46 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 michal@kleczek.org - 2017-04-26 13:59 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-25 19:21 +0200
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-04-26 08:58 +0200
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-26 06:53 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-26 18:23 +0200
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-27 06:16 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-27 19:53 +0200
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-27 23:09 -0700
Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-24 20:19 +0200
csiph-web