W dniu piątek, 28 września 2012 12:33:42 UTC+1 użytkownik Maciej Sobczak napisał:
> W dniu piątek, 28 września 2012 10:54:11 UTC+2 użytkownik Roman W napisał:
>
>
>
> > Glowna roznica polega na tym, ze producent sterownikow do rozrusznika serca czy
samolotu prawnie odpowiada ze mozliwe fakapy, lacznie z mozliwa wizyta w wiezieniu,
natomiast jezeli sterownik dziala dobrze, to dostanie umowiona zaplate, ewentualnie
wyplacajac swoim programistom skromne bonusy na Swieta. Asymetria zachet jest taka,
ze bardziej sie oplaca byc 2x ostroznym niz szarzowac.
> >
> >
> > W finansach jest zupelnie odwrotnie: koles ktory napisze system do algotrading
ktory przegwizda $100mln kasy pracodawcy, w najgorszym wypadku straci prace.
Natomiast jezeli system zarobi $100mln, to bonusy moga wyniesc i 100% rocznej pensji.
Asymetria zachet jest taka, ze bardziej sie oplaca szarzowac, kosztem bezpieczenstwa.
Dopiero akcjonariusze, wierzyciele firmy (i czasami podatnicy) sa naprawde "on the
hook" jesli chodzi o fakapy, ale oni z kolei nie nadzoruja bezposrednio procesu
produkcji software'u.
>
> To jest chyba bardzo dobra analiza tego problemu.
> A może to nie jest problem? Skoro jest akceptowane przez zainteresowanych...

Nie przez wszystkich zainteresowanych.

RW

do góry

W dniu piątek, 28 września 2012 13:03:41 UTC+1 użytkownik Edek Pienkowski napisał:
> Z tego punktu widzenia nie tylko rozwiązania związane z
> zarządzaniem projektem, ale też techniczne mają wielki
> wpływ na powodzenie lub nie całości - tylko dlatego moim
> zdaniem warto dyskutować nad wyborem języka programowania.
> W idealnym świecie sferycznych programistów nie miałoby
> to większego znaczenia.

Ale wybor jezyka jest zawsze konsekwencja panujacej kultury i podejscia do kwestii
bezpieczenstwa. W typowym banku "wybor jezyka" oznacza wybor pomiedzy Java, C# i C++.
Nikt nie bedzie sie wyglupial z propozycjami typu Ada i uzasadnial ich wzgledami
bezpieczenstwa, bo uslyszy, ze marnuje czas grupy.

RW

do góry

On 2012-09-28 10:17, Maciej Sobczak wrote:
> Zastanów się najpierw *po co* istnieją bezpieczne języki.

Po to aby przeciwdziałać błedom programisty badź specyfikacji w jak
nalepszym stopniu.

Gdybysmy tworzyli oprogramowanie bez bledów takie języki nie mają racji
bytu. W związku z tym podstawowa cechą bezpiecznego języka jest
podwyższenie jakości poprzez eliminację błedów nawet kosztem wydajności
bądź wyprucia żył programisty poprzez udziwniona składnię.

> czyli do interakcji ze sterowanikami urządzeń albo wręcz do bezpośrednich odwołań
do pamięci

*G* prawda. Sterowanie rakietą poprzez algorytmy nawigacyjne *NIE*
polega na dziobaniu po gołej pamięci bądź zapalaniu bitów na porcie IO
uC albo sprawdzanie czy w milionie miejsc nastapil overflow. Sterowanie
rakietą polega na realizacji (zapewne) statycznego pamieciowo zadania
matematycznego. A jakiś drugorzędny duperelek zajmuje się częscią
łaczącą wyniki z elektroniką. W załaczonym przykładzie sterowania
rakietą nie ma śladu po *sterowaniu* w twoim sensie, jest natomiast ślad
po *obliczaniu*. Programista zaliczył fail, tym bardziej komiczny że
wypruto sobie żyły na użycie Ady która okazała się wydmuszką bo nic nie
dała. Prawdopodobnie dałbym osobiście radę naklepać bezpieczną klasę do
konwersji w C++ która dzięki prostym zabiegom *uniemożliwiła* by
programiście jej nie-użycie bez chamskich sztuczek. Głupi C++ potrafił
by lepiej zabezpieczyć przed radosną twórczością byłych programistów
demek. Żałosne.

>, bo właśnie tak wyglądają te interakcje na odpowiednio niskim poziomie.

Tutaj *nie* było niskiego poziomu. Jesli zaś ktoś matematykę i overflow
implementuje ręcznie na bitach jak w przytoczonym przykładzie to jest
idiotą.

> Otóż żeby dany język w ogóle się do tego nadawał
>, to musi udostępnić wszystkie narzędzia z rodziny
> memset, memcpy, reinterpret_cast oraz link z dowolnym symbolem.

Żadna z tych funkcji nie jest wymagana w liczeniu kąta otwarcia
przepustnicy lewej dyszy.

> Ada to wszystko umożliwia, ale trzeba o te rzeczy poprosić bardziej, niż w C. I to
"bardziej" jest właśnie miarą bezpieczeństwa, bo w C te rzeczy spadają programiście
na głowę same.
> Język, który tych narzędzi nie udostępnia *nie nadaje się do tworzenia bezpiecznych
systemów*.

Te narzędzia na szczęscie udostepnia asm. I nic dziwnego że ten kawałek
algorytmu naklepano w stylu asm. Zapewne resztę też. I tyle było z tej Ady.

> Proste?

Jednak za bardzo to uprościłeś. Uprościłeś do systemów embedded
zajmujących się *bezpośrednim* sterowaniem. To tylko pewien zbiór
problemów. Niekompletny.

do góry

W dniu piątek, 28 września 2012 19:35:26 UTC+2 użytkownik Sebastian Biały napisał:

> > Zastanów się najpierw *po co* istnieją bezpieczne języki.
>
> Po to aby przeciwdziałać błedom programisty badź specyfikacji w jak
> nalepszym stopniu.

No właśnie. Ze znanych mi języków Ada robi to lepiej, niż inni.

> > czyli do interakcji ze sterowanikami urządzeń albo wręcz do bezpośrednich odwołań
do pamięci
>
>
> *G* prawda. Sterowanie rakietą poprzez algorytmy nawigacyjne *NIE*
> polega na dziobaniu po gołej pamięci bądź zapalaniu bitów na porcie IO
> uC albo sprawdzanie czy w milionie miejsc nastapil overflow.

Te rzeczy są konieczne.

> Sterowanie
> rakietą polega na realizacji (zapewne) statycznego pamieciowo zadania
> matematycznego.

Tak by było, gdyby rakiety latały tylko na papierze. Tymczasem one latają w świecie
rzeczywistym i oprócz rozwiązywania zadań matematycznych muszą wziąć na klatę różne
upierdliwości tego rzeczywistego świata, takie jak np. upływ czasu. Czy hasło "system
czasu rzeczywistego" coś Ci mówi?

Pisałem wcześniej o interakcjach z procesami fizycznymi i cały czas przy tym
jesteśmy. Upływ czasu jest procesem fizycznym, z którym interakcje polegają nie na
tym, że się grzebie po portach I/O, ale na tym, że program ma być w określonych
punktach *na czas*. To dosyć niskopoziomowy problem. Z tego co rozumiem nt. Ariane 5,
to właśnie takie niskopoziomowe rozważania doprowadziły do decyzji o wyłączeniu
bezpiecznika. Gdyby tego nie można było zrobić, to (tak tylko przypuszczam, ale nie
mam podstaw zakładać, że rozważania wydajnościowe wyciągnęli sobie z czapki) program
nie spełniłby zadanych ograniczeń. Czyli nie byłoby go.

> A jakiś drugorzędny duperelek zajmuje się częscią
> łaczącą wyniki z elektroniką.

Drugorzędny? Duperelek? I w czym ten duperelek jest napisany, co?

Do rozważenia są dwie alternatywy:

1. Piszemy w bezpiecznym języku i łączymy go z modułami (tzw. duperelkami) napisanymi
w niebezpiecznym języku, np. w C albo w asm.

2. Piszemy wszystko w bezpiecznym języku i lokalnie wyłączamy bezpieczniki na
potrzeby niskopoziomowych interakcji (uwaga: upływ czasu też tu się wlicza).


Jaką niby wartość dodaną w dziedzinie bezpieczeństwa ma pierwsze rozwiązanie? Bo nie
widzę.

Natomiast w drugim przypadku widzę wartość dodaną w postaci jednolitości rozwiązania,
co ułatwia znalezienie i zastosowanie chociażby narzędzi do analizy statycznej. Znam
narzędzia, które radzą sobie z jednorodnym kodem, natomiast nie znam takich, które
sensownie analizują zlepek modułów napisanych w kilku językach. Dostępność narzędzi
to kolejny punkt na drodze do większego bezpieczeństwa i ten drugi wariant daje tu
większe możliwości. Ada jest bezpieczniejsza właśnie przez to, że to, co chciałbyś
zrobić w C, możesz dalej robić w Adzie.

> Prawdopodobnie dałbym osobiście radę naklepać bezpieczną klasę do
> konwersji w C++ która dzięki prostym zabiegom *uniemożliwiła* by
> programiście jej nie-użycie bez chamskich sztuczek.

Jeśli ta niemożność uniemożliwiłaby spełnienie oczekiwań związanych z koniecznością
interakcji z procesami fizycznymi, to Twoja klasa nie nadawałaby się do robienia
bezpiecznych systemów. Natomiast chamskie sztuczki w C++ *zawsze* są możliwe, bo do
dyzpozycji są wskaźniki i reinterpret_cast (oraz memcpy, itd.). Zapewniam Cię, że ten
sam programista, który wyłączył bezpieczniki w Adzie, poradziłby sobie z Twoją
niehakowalną klasą. W obu przypadkach ominięcie bezpiecznika można uznać za chamskie.

> Głupi C++ potrafił
> by lepiej zabezpieczyć

Nie, nie potrafiłby. Użycie systemu typów jako mechanizm ochronny miałby podobną
skuteczność i podobnie nie zatrzymałby zdeterminowanego programisty.

> przed radosną twórczością byłych programistów
> demek.

Jak już pisałem, nie znam nikogo z tego zespołu, więc nie wypowiadam się nt.
przeszłości zawodowej tych ludzi.

> Żałosne.

Na razie pokazałeś tylko, że nigdy nie widziałeś systemu sterowania. W szczególności
systemu sterowania czasu rzeczywistego.

> Tutaj *nie* było niskiego poziomu. Jesli zaś ktoś matematykę i overflow
> implementuje ręcznie na bitach jak w przytoczonym przykładzie to jest
> idiotą.

Ten program był poprawny, bo był przeznaczony dla poprzedniego modelu rakiety i tam
wpisywał się w zadane warunki techniczne. Nie widzę powodu, dla którego można by tego
programistę nazwać idiotą - napisał program w zgodzie z danymi. Natomiast to, że ten
moduł bezrefleksyjnie użyto w nowszej rakiecie, w której warunki techniczne były już
inne, to błąd wdrożeniowy. Ktoś wykorzystał słabsze cegły do budowy większego budynku
- to nie wykonawca cegieł jest tu idiotą, tylko ten koleś, który wybrał złe cegły.
Język pomógłby, gdyby miał włączony bezpiecznik.

> > Otóż żeby dany język w ogóle się do tego nadawał
> >, to musi udostępnić wszystkie narzędzia z rodziny
> > memset, memcpy, reinterpret_cast oraz link z dowolnym symbolem.
>
> Żadna z tych funkcji nie jest wymagana w liczeniu kąta otwarcia
> przepustnicy lewej dyszy.

Co najmniej jedna z nich jest wymagana, żeby ta dysza faktycznie sie otworzyła. Bez
tych ficzerów rakieta poleci tylko na papierze.

> Te narzędzia na szczęscie udostepnia asm.

Rozumiem - czyli bezpieczne rozwiązanie to połączenie bezpiecznego języka z asm, tak?

Pomińmy fakt, że już samo łączenie języków to jazda bez pasów dokładnie równoważna
reinterpret_cast, bo ze względu na rozdzielność systemu typów właśnie to trzeba
zrobić na granicy języków.

Po prostu zaplątałeś się we własne gacie w tej dyskusji.

> > Proste?
>
> Jednak za bardzo to uprościłeś. Uprościłeś do systemów embedded
> zajmujących się *bezpośrednim* sterowaniem. To tylko pewien zbiór
> problemów. Niekompletny.

Tak. Ale wystarczy do wykazania, że nie masz racji odrzucając Adę w całości. Twoje
stwierdzenie, że Ada jest do niczego, było ogólne - mi wystarczy wskazać jeden
przykład, żeby Twój ogólny kwantyfikator wyłożyć.
Tym przykładem są... bezpieczne systemy. Ot, ironia.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

Czy da się zasymulować w Google zawijanie linii do usenotwego 70
char perline? Ja tak tylko pytam.

Dnia Fri, 28 Sep 2012 13:39:39 -0700, Maciej Sobczak napisal:

> W dniu piątek, 28 września 2012 19:35:26 UTC+2 użytkownik Sebastian
> Biały napisał:
>
>> > Zastanów się najpierw *po co* istnieją bezpieczne języki.
>>
>> Po to aby przeciwdziałać błedom programisty badź specyfikacji w jak
>> nalepszym stopniu.
>
> No właśnie. Ze znanych mi języków Ada robi to lepiej, niż inni.

Heh. Haskell?

>> > czyli do interakcji ze sterowanikami urządzeń albo wręcz do
>> > bezpośrednich odwołań do pamięci
>>
>>
>> *G* prawda. Sterowanie rakietą poprzez algorytmy nawigacyjne *NIE*
>> polega na dziobaniu po gołej pamięci bądź zapalaniu bitów na porcie IO
>> uC albo sprawdzanie czy w milionie miejsc nastapil overflow.
>
> Te rzeczy są konieczne.
>
>> Sterowanie rakietą polega na realizacji (zapewne) statycznego
>> pamieciowo zadania matematycznego.
>
> Tak by było, gdyby rakiety latały tylko na papierze. Tymczasem one
> latają w świecie rzeczywistym i oprócz rozwiązywania zadań
> matematycznych muszą wziąć na klatę różne upierdliwości tego
> rzeczywistego świata, takie jak np. upływ czasu. Czy hasło "system czasu
> rzeczywistego" coś Ci mówi?

Mi mówi, i polega na czym innym. Na nie wykonywaniu potencjalnie
kosztownych operacji w wątkach realtime, tylko w wątkach nie-realtime.

> Pisałem wcześniej o interakcjach z procesami fizycznymi i cały czas przy
> tym jesteśmy. Upływ czasu jest procesem fizycznym, z którym interakcje
> polegają nie na tym, że się grzebie po portach I/O, ale na tym, że
> program ma być w określonych punktach *na czas*. To dosyć niskopoziomowy
> problem. Z tego co rozumiem nt. Ariane 5, to właśnie takie
> niskopoziomowe rozważania doprowadziły do decyzji o wyłączeniu
> bezpiecznika. Gdyby tego nie można było zrobić, to (tak tylko
> przypuszczam, ale nie mam podstaw zakładać, że rozważania wydajnościowe
> wyciągnęli sobie z czapki) program nie spełniłby zadanych ograniczeń.
> Czyli nie byłoby go.

Przewidywanie czasy wykonania nie jest magią. Przynajmniej od 1 roku
studiów.

>> A jakiś drugorzędny duperelek zajmuje się częscią łaczącą wyniki z
>> elektroniką.
>
> Drugorzędny? Duperelek? I w czym ten duperelek jest napisany, co?

To zależy od implementacji, ale często w C. Minimalny kod.

> Do rozważenia są dwie alternatywy:
>
> 1. Piszemy w bezpiecznym języku i łączymy go z modułami (tzw.
> duperelkami) napisanymi w niebezpiecznym języku, np. w C albo w asm.
>
> 2. Piszemy wszystko w bezpiecznym języku i lokalnie wyłączamy
> bezpieczniki na potrzeby niskopoziomowych interakcji (uwaga: upływ czasu
> też tu się wlicza).
>
>
> Jaką niby wartość dodaną w dziedzinie bezpieczeństwa ma pierwsze
> rozwiązanie? Bo nie widzę.
>
> Natomiast w drugim przypadku widzę wartość dodaną w postaci jednolitości
> rozwiązania, co ułatwia znalezienie i zastosowanie chociażby narzędzi do
> analizy statycznej. Znam narzędzia, które radzą sobie z jednorodnym
> kodem, natomiast nie znam takich, które sensownie analizują zlepek
> modułów napisanych w kilku językach. Dostępność narzędzi to kolejny
> punkt na drodze do większego bezpieczeństwa i ten drugi wariant daje tu
> większe możliwości. Ada jest bezpieczniejsza właśnie przez to, że to, co
> chciałbyś zrobić w C, możesz dalej robić w Adzie.

Mało wiesz o statycznej analizie. I o projektach typu Arianne. Po
pierwsze, stosuje się rozwiązania typu "mamy 3 implementacje i porównujemy
wyniki" - jeżeli dwa dają te same wyniki, engage. Po drugie, istnieje
coś takiego jak abstrakcja (w kontekście OS na przykład). Problem polega
nie na braku narzędzi, ale na stopniu skomplikowania powiązań, gdzie
niskopoziomowe IO ma jasną i prostą abstrakcję a problemy leżą w
granicach statycznej analizy. Matematycznych, nie "czy możemy coś
sparsować" - to byłby kiepski żart.

>> Prawdopodobnie dałbym osobiście radę naklepać bezpieczną klasę do
>> konwersji w C++ która dzięki prostym zabiegom *uniemożliwiła* by
>> programiście jej nie-użycie bez chamskich sztuczek.
>
> Jeśli ta niemożność uniemożliwiłaby spełnienie oczekiwań związanych z
> koniecznością interakcji z procesami fizycznymi, to Twoja klasa nie
> nadawałaby się do robienia bezpiecznych systemów. Natomiast chamskie
> sztuczki w C++ *zawsze* są możliwe, bo do dyzpozycji są wskaźniki i
> reinterpret_cast (oraz memcpy, itd.). Zapewniam Cię, że ten sam
> programista, który wyłączył bezpieczniki w Adzie, poradziłby sobie z
> Twoją niehakowalną klasą. W obu przypadkach ominięcie bezpiecznika można
> uznać za chamskie.

Chyba nigdy nie pracowałeś w zorganizowanym projekcie o dużych wymaganiach
niezawodności. Prosto jak to tylko możliwe: powyższe daje się zapewnić
mając jednego świadomego reviewera na 20 wytresowanych małp tudzież
specjalistów od innych rzeczy niż programowanie. Czyli jest trywialne.

>> Głupi C++ potrafił by lepiej zabezpieczyć
>
> Nie, nie potrafiłby. Użycie systemu typów jako mechanizm ochronny miałby
> podobną skuteczność i podobnie nie zatrzymałby zdeterminowanego
> programisty.

J.w.

>> przed radosną twórczością byłych programistów demek.
>
> Jak już pisałem, nie znam nikogo z tego zespołu, więc nie wypowiadam się
> nt. przeszłości zawodowej tych ludzi.
>
>> Żałosne.
>
> Na razie pokazałeś tylko, że nigdy nie widziałeś systemu sterowania. W
> szczególności systemu sterowania czasu rzeczywistego.

Systemy realtime są proste w obsłudze. To wszystko, co musi wiedzieć
programista _używający_ RTOS, w przeciwieństwie do implementatora
RTOS.

>> Tutaj *nie* było niskiego poziomu. Jesli zaś ktoś matematykę i overflow
>> implementuje ręcznie na bitach jak w przytoczonym przykładzie to jest
>> idiotą.
>
> Ten program był poprawny, bo był przeznaczony dla poprzedniego modelu
> rakiety i tam wpisywał się w zadane warunki techniczne. Nie widzę
> powodu, dla którego można by tego programistę nazwać idiotą - napisał
> program w zgodzie z danymi. Natomiast to, że ten moduł bezrefleksyjnie
> użyto w nowszej rakiecie, w której warunki techniczne były już inne, to
> błąd wdrożeniowy. Ktoś wykorzystał słabsze cegły do budowy większego
> budynku - to nie wykonawca cegieł jest tu idiotą, tylko ten koleś, który
> wybrał złe cegły.
> Język pomógłby, gdyby miał włączony bezpiecznik.

Ok. Smoke and mirrors i bezpieczniki Ady.

>> > Otóż żeby dany język w ogóle się do tego nadawał
>> >, to musi udostępnić wszystkie narzędzia z rodziny
>> > memset, memcpy, reinterpret_cast oraz link z dowolnym symbolem.
>>
>> Żadna z tych funkcji nie jest wymagana w liczeniu kąta otwarcia
>> przepustnicy lewej dyszy.
>
> Co najmniej jedna z nich jest wymagana, żeby ta dysza faktycznie sie
> otworzyła. Bez tych ficzerów rakieta poleci tylko na papierze.

J.w., automatyka na poziomie przemysłowym jest dobrze przećwiczona.

>> Te narzędzia na szczęscie udostepnia asm.
>
> Rozumiem - czyli bezpieczne rozwiązanie to połączenie bezpiecznego
> języka z asm, tak?
>
> Pomińmy fakt, że już samo łączenie języków to jazda bez pasów dokładnie
> równoważna reinterpret_cast, bo ze względu na rozdzielność systemu typów
> właśnie to trzeba zrobić na granicy języków.
>
> Po prostu zaplątałeś się we własne gacie w tej dyskusji.

Wcale ale to wcale nie. Język to narzędzie, nikt nie każe młotkiem
bić się w palec. Problemy są na innym zupełnie poziomie.

>> > Proste?
>>
>> Jednak za bardzo to uprościłeś. Uprościłeś do systemów embedded
>> zajmujących się *bezpośrednim* sterowaniem. To tylko pewien zbiór
>> problemów. Niekompletny.
>
> Tak. Ale wystarczy do wykazania, że nie masz racji odrzucając Adę w
> całości. Twoje stwierdzenie, że Ada jest do niczego, było ogólne - mi
> wystarczy wskazać jeden przykład, żeby Twój ogólny kwantyfikator
> wyłożyć.
> Tym przykładem są... bezpieczne systemy. Ot, ironia.

Nie rozumiem ironii, ale nikt nie odrzuca Ady. Problem jest zupełnie
gdzie indziej: Ada nic więcej nie daje. Porównywanie samego języka
z innym nie ma podstaw w temacie systemów tego typu. Realia są
po pierwsze dużo bardziej skomplikowane, a po drugie ci goście nie
są "aż tak głupi" jak zakładasz.

--
Edek

do góry

W dniu piątek, 28 września 2012 22:28:11 UTC+1 użytkownik Edek Pienkowski napisał:
> Czy da się zasymulować w Google zawijanie linii do usenotwego 70
> char perline? Ja tak tylko pytam.

Google Groups jest coraz gorsze.

> Dnia Fri, 28 Sep 2012 13:39:39 -0700, Maciej Sobczak napisal:
> > W dniu piątek, 28 września 2012 19:35:26 UTC+2 użytkownik Sebastian
> > Biały napisał:
> >
> >> > Zastanów się najpierw *po co* istnieją bezpieczne języki.
> >>
> >> Po to aby przeciwdziałać błedom programisty badź specyfikacji w jak
> >> nalepszym stopniu.
> >
> > No właśnie. Ze znanych mi języków Ada robi to lepiej, niż inni.
> Heh. Haskell?

Haskell nie nadaje sie do zastosowan praktycznych, to jezyk akademicki. Lazy
evaluation powoduje, ze bardzo ciezko jest przewidziec, jak szybko sie wykona i ile
pamieci bedzie potrzebowal niewinnie wygladajacy kawalek kodu.

> > rzeczywistego świata, takie jak np. upływ czasu. Czy hasło "system czasu
> > rzeczywistego" coś Ci mówi?
>
> Mi mówi, i polega na czym innym. Na nie wykonywaniu potencjalnie
> kosztownych operacji w wątkach realtime, tylko w wątkach nie-realtime.

A watki realtime beda grzecznie czekaly, az ten "kosztowny" skonczy obliczenia? Wrog
ktory usiluje zestrzelic Twoj samolot, tez grzecznie poczeka, az skonczysz obliczenia
w watku nie-realtime?

> Przewidywanie czasy wykonania nie jest magią. Przynajmniej od 1 roku
> studiów.

Zalezy w jakim jezyku. W C++ z funkcjami wirtualnymi mozesz miec problem, bo wolajac

p->f();

nie wiesz z gory, ktora implementacja f() sie wykona.

> >> A jakiś drugorzędny duperelek zajmuje się częscią łaczącą wyniki z
> >> elektroniką.
> >
> > Drugorzędny? Duperelek? I w czym ten duperelek jest napisany, co?
>
> To zależy od implementacji, ale często w C. Minimalny kod.

Oprogramowanie do Mars Rover napisano wylacznie w C, btw.

> Mało wiesz o statycznej analizie. I o projektach typu Arianne. Po
> pierwsze, stosuje się rozwiązania typu "mamy 3 implementacje i porównujemy
> wyniki" - jeżeli dwa dają te same wyniki, engage. Po drugie, istnieje

Przeciez nie przetestujesz wszystkich kombinacji inputow, jakei moga sie przytrafic
podczas lotu rakiety kosmicznej.

RW

do góry

Dnia Fri, 28 Sep 2012 07:57:31 -0700, Roman W napisal:

> W dniu piątek, 28 września 2012 13:03:41 UTC+1 użytkownik Edek
> Pienkowski napisał:
>> Z tego punktu widzenia nie tylko rozwiązania związane z zarządzaniem
>> projektem, ale też techniczne mają wielki wpływ na powodzenie lub nie
>> całości - tylko dlatego moim zdaniem warto dyskutować nad wyborem
>> języka programowania.
>> W idealnym świecie sferycznych programistów nie miałoby to większego
>> znaczenia.
>
> Ale wybor jezyka jest zawsze konsekwencja panujacej kultury i podejscia
> do kwestii bezpieczenstwa. W typowym banku "wybor jezyka" oznacza wybor
> pomiedzy Java, C# i C++. Nikt nie bedzie sie wyglupial z propozycjami
> typu Ada i uzasadnial ich wzgledami bezpieczenstwa, bo uslyszy, ze
> marnuje czas grupy.

Ze wszystkich osób nie podejrzewałem z tej strony wypowiedzi typu
"wsyzscy znamy X, Y jest niepopularne, więc używamy X". Technologia
nie jest konkursem popularności. To też jest częścią kultury, albo
nie jest.

Wybór języka zawsze ma oparcie w dostępności programistów ze znajmością,
ale to nie jest jednowymiarowa decyzja - wybiera się język wraz z
"czym chata bogata". Na tym opiera się m.in. wybór programistów
kernela: "czym chata bogata" nam nie odpowiada, wybieramy proste
C, którego wszyscy są w stanie się nauczyć więc to jest największy
wspólny mianownik i dopasowujemy kulturę do kultury projektu. Decyzja
na pewno nie prosta jak drut i - co widać na załączonym obrazku -
niezbyt popularna, ale nie to jest istotne dla powodzenia projektu,
biorąc pod uwagę wszystkie czynniki w tym jak najbardziej ludzkie,
po prostu nie czynnik zwany "popularność" albo przynajmniej nie
"popularność w kręgach, które niosą ze sobą inne wartości" tylko
raczej "popularność w kręgach bardziej zbliżonych do tego,
co nam się podoba" - dla kernela w tym przypadku - albo nawet
"wybieramy tych z kulturą taką, że moda nie jest czynnikiem
w niej dominującym".

Wracając do Ady, nie wiem w jakich kręgach jest modna ani
dlaczego, sam się akurat z Adą bezpośrednio nie zetknąłem,
ale nie miałbym nic przeciwko, nawet gdyby mi niespecjalnie
"leżała".

--
Edek

do góry

On 2012-09-28 22:39, Maciej Sobczak wrote:
>> Sterowanie
>> rakietą polega na realizacji (zapewne) statycznego pamieciowo zadania
>> matematycznego.
> Tak by było, gdyby rakiety latały tylko na papierze.
> Tymczasem one latają w świecie rzeczywistym
> i oprócz rozwiązywania zadań matematycznych muszą wziąć
> na klatę różne upierdliwości tego rzeczywistego świata
>, takie jak np. upływ czasu. Czy hasło "system czasu rzeczywistego" coś Ci mówi?

Więcej niż myslisz. I musze przyznać, że gdyby software ariane był
"wyżyłowany co do cykla" to programiści nie powinni się zajmowac więcej
programowaniem. Wyłączanie (bo można!) systemów bezpieczeństwa żeby
zdobyć pare cykli więcej ...

> Pisałem wcześniej o interakcjach z procesami fizycznymi i cały czas przy tym
jesteśmy.
> Upływ czasu jest procesem fizycznym, z którym interakcje polegają nie na tym
>, że się grzebie po portach I/O, ale na tym, że program ma być w określonych
> punktach *na czas*.

Jeśli więc wymagana jest szybkośc to musisz pozegnać bezpieczeństwo. Oby
dwóch rzeczy nic nie zapewnia. Czasem można za free dostać
bezpieczeństwo statyczne, ale to potrafi byle C++.

> To dosyć niskopoziomowy problem.

Nawigacja nie jest problemem niskopoziomowym. Może byc problemem
wydajności obliczeń, ale nie niskopoziomowym.

>> A jakiś drugorzędny duperelek zajmuje się częscią
>> łaczącą wyniki z elektroniką.
> Drugorzędny? Duperelek? I w czym ten duperelek jest napisany, co?

W czymś *prostym* co pozwoli na formalną weryfikacje.

> Do rozważenia są dwie alternatywy:
> 1. Piszemy w bezpiecznym języku i łączymy go z modułami (tzw. duperelkami)
> napisanymi w niebezpiecznym języku, np. w C albo w asm.

Oczywiscie - sterowanie PWM przepustnicą zdecydowanie lepiej realizować
specjalizowanym kawałkiem elektroniki niż prosto z algorytmu nawigacji
dziobać porty I/O.

> 2. Piszemy wszystko w bezpiecznym języku i lokalnie wyłączamy bezpieczniki
> na potrzeby niskopoziomowych interakcji (uwaga: upływ czasu też tu się wlicza).

Czyli lokalnie nie jest bezpieczny. I tyle było z bezpieczeństwa.

> Jaką niby wartość dodaną w dziedzinie bezpieczeństwa ma pierwsze rozwiązanie?
> Bo nie widzę.

a) możliwy arbitraż separowany hardwareowo przed wykonaniem poleceń
b) możliwa implementacja asercji/constrains bez wiedzy algorytmu (np.
przepustnica otwarta więcej niż 90% przez 1 sek oznacza błąd, odpalam
procedurę awaryjną)
c) możliwa formalna weryfikacja fragmentów systemu

> Natomiast w drugim przypadku widzę wartość dodaną w postaci jednolitości
rozwiązania
>, co ułatwia znalezienie i zastosowanie chociażby narzędzi do analizy statycznej.
> Znam narzędzia, które radzą sobie z jednorodnym kodem, natomiast nie znam takich
>, które sensownie analizują zlepek modułów napisanych w kilku językach.
> Dostępność narzędzi to kolejny punkt na drodze do większego bezpieczeństwa
> i ten drugi wariant daje tu większe możliwości.

Małe duperelki wykonawcze mozna łatwiej formalnie zweryfikować niż
wielką kupę kodu. Rozbicie modułów softwareowych na kawałki hardwareowe
i ich osobna weryfikacja pozawala zminimalizować błedy. I powiem tak:
EDA jest o lata świetlne przez software w formalnej weryfikacji kodu.

> Ada jest bezpieczniejsza właśnie przez to, że to
>, co chciałbyś zrobić w C, możesz dalej robić w Adzie.

:D True true ...

>> Prawdopodobnie dałbym osobiście radę naklepać bezpieczną klasę do
>> konwersji w C++ która dzięki prostym zabiegom *uniemożliwiła* by
>> programiście jej nie-użycie bez chamskich sztuczek.

> Jeśli ta niemożność uniemożliwiłaby spełnienie oczekiwań związanych

... z bezpieczeństwem Ady to .... wyłaczmy bezpieczniki !

> Natomiast chamskie sztuczki w C++ *zawsze* są możliwe, bo do dyzpozycji
> są wskaźniki i reinterpret_cast (oraz memcpy, itd.).

Zupełnie jak w Adzie? Czekaj czekaj czy Ada jest nadzbiorem C++ w sensie
niskopoziomowego gówna? OMG!

> Zapewniam Cię, że ten sam programista, który wyłączył bezpieczniki w Adzie
>, poradziłby sobie z Twoją niehakowalną klasą.

A-ha ! Czyli oba są niebezpieczne !

> W obu przypadkach ominięcie bezpiecznika można uznać za chamskie.

I możliwe. Game over.

> Na razie pokazałeś tylko, że nigdy nie widziałeś systemu sterowania.

Telepatia jest niezdrowa.

> W szczególności systemu sterowania czasu rzeczywistego.

Może nie widziałem, ale jakieś tam napisałem.

>> Tutaj *nie* było niskiego poziomu. Jesli zaś ktoś matematykę i overflow
>> implementuje ręcznie na bitach jak w przytoczonym przykładzie to jest
>> idiotą.
>
> Ten program był poprawny, bo był przeznaczony dla poprzedniego modelu rakiety
> i tam wpisywał się w zadane warunki techniczne. Nie widzę powodu, dla którego
> można by tego programistę nazwać idiotą - napisał program w zgodzie z danymi.
> Natomiast to, że ten moduł bezrefleksyjnie użyto w nowszej rakiecie, w której
> warunki techniczne były już inne, to błąd wdrożeniowy. Ktoś wykorzystał słabsze
> cegły do budowy większego budynku - to nie wykonawca cegieł jest tu idiotą,
> tylko ten koleś, który wybrał złe cegły.

Bo wszystko Panie, to wina tych kolesi od kasy. Jezyk bezpieczny wszak był.

> Język pomógłby, gdyby miał włączony bezpiecznik.

Gdyby.

>>> Otóż żeby dany język w ogóle się do tego nadawał
>>> , to musi udostępnić wszystkie narzędzia z rodziny
>>> memset, memcpy, reinterpret_cast oraz link z dowolnym symbolem.
>> Żadna z tych funkcji nie jest wymagana w liczeniu kąta otwarcia
>> przepustnicy lewej dyszy.
> Co najmniej jedna z nich jest wymagana, żeby ta dysza faktycznie sie otworzyła.
Bez tych ficzerów rakieta poleci tylko na papierze.
>
>> Te narzędzia na szczęscie udostepnia asm.
>
> Rozumiem - czyli bezpieczne rozwiązanie to połączenie bezpiecznego języka z asm,
tak?

To oznacza że Ada pozwala na to samo co ASM. Jak widać w przykładzie
powyżej pozwala na dziobanie po bitach wektora i ręczną obsługę overflow
- zupełnie jak asm. I w końcu ktos wpadl na pomysł: Skoro mamy Adę to
możemy *bezpiecznie* s..dolić kod. I s..dolił.

> Pomińmy fakt, że już samo łączenie języków to jazda bez pasów dokładnie
> równoważna reinterpret_cast, bo ze względu na rozdzielność systemu typów
> właśnie to trzeba zrobić na granicy języków.

Łączenie językow przez hardware.

> Po prostu zaplątałeś się we własne gacie w tej dyskusji.

To tylko takie twoje wrażenie. Wymagane było by jednak uzycie
bezpiecznego systemu do oceny, na przykład przez arbitraż .... oh wait.

> Tak. Ale wystarczy do wykazania, że nie masz racji odrzucając Adę w całości.

Niczego nie odrzucam. Prowadzę tylko mała krucjatę wobez religijego
traktowania marnego języka jako zbawcy ludzości albo co najmniej
systemów sterowania. Prawda jest taka że nie posiadamy *żadnego*
bezpiecznego języka (może poza lispem :).

> Twoje stwierdzenie, że Ada jest do niczego

... na szczęscie nie ma miejsca.

do góry

Dnia Fri, 28 Sep 2012 15:19:19 -0700, Roman W napisal:

> W dniu piątek, 28 września 2012 22:28:11 UTC+1 użytkownik Edek
>> Dnia Fri, 28 Sep 2012 13:39:39 -0700, Maciej Sobczak napisal:
>> > W dniu piątek, 28 września 2012 19:35:26 UTC+2 użytkownik Sebastian
>> > Biały napisał:
>> >
>> >> > Zastanów się najpierw *po co* istnieją bezpieczne języki.
>> >>
>> >> Po to aby przeciwdziałać błedom programisty badź specyfikacji w jak
>> >> nalepszym stopniu.
>> >
>> > No właśnie. Ze znanych mi języków Ada robi to lepiej, niż inni.
>> Heh. Haskell?
>
> Haskell nie nadaje sie do zastosowan praktycznych, to jezyk akademicki.
> Lazy evaluation powoduje, ze bardzo ciezko jest przewidziec, jak szybko
> sie wykona i ile pamieci bedzie potrzebowal niewinnie wygladajacy
> kawalek kodu.

Są praktyczne zastosowania Haskella. Co ciekawe, "niewinnie wyglądający
kawałek kodu" to wrażenie subiektywne, jednym z pierwszych języków
których się nauczyłem był Scheme - polecam każdemu programiście
przejście choć jednego języka funkcyjnego i dowolny kod wygląda
po tym inaczej.

Ale może Haskell się nie nadaje.

>> > rzeczywistego świata, takie jak np. upływ czasu. Czy hasło "system
>> > czasu rzeczywistego" coś Ci mówi?
>>
>> Mi mówi, i polega na czym innym. Na nie wykonywaniu potencjalnie
>> kosztownych operacji w wątkach realtime, tylko w wątkach nie-realtime.
>
> A watki realtime beda grzecznie czekaly, az ten "kosztowny" skonczy
> obliczenia? Wrog ktory usiluje zestrzelic Twoj samolot, tez grzecznie
> poczeka, az skonczysz obliczenia w watku nie-realtime?

A jak policzyć coś zajmującego potencjalnie 10s w 0,1s? W RTOS jest
jasny podział, nie przeskoczy się kwestii czasu natomiast wiadomo,
co ile zabiera i jakie ma inne właściwości.

>> Mało wiesz o statycznej analizie. I o projektach typu Arianne. Po
>> pierwsze, stosuje się rozwiązania typu "mamy 3 implementacje i
>> porównujemy wyniki" - jeżeli dwa dają te same wyniki, engage. Po
>> drugie, istnieje
>
> Przeciez nie przetestujesz wszystkich kombinacji inputow, jakei moga sie
> przytrafic podczas lotu rakiety kosmicznej.

Inputy mają często nieskończenie wiele możliwości, ale są zbiorem.
Matematycznie daje się stwierdzić, czy jakiś inwariant lub dzielenie
przez zero zajdzie czy nie - geometrycznie szukając przecięć wynikających
z reprezentacji kodu we wszystkich miejscach. Nawet mając nieskończony
zbiór często daje się przewidzieć, że naruszenie inwariantu nie nastąpi,
albo nastąpi w jasno określonym matematycznie przypadku. Przynajmniej
dzisiaj to wiadomo, w oparciu głównie o programowanie liniowe, na podobnej
zasadzie jak jedna z metod optymalizacji pętli w gcc, gdy nie da
się przewidzieć ilości pętli i podobnych zmiennych, ale zna się ich
zależności.

--
Edek

do góry

On 2012-09-29 07:52, Sebastian Biały wrote:
> On 2012-09-28 22:39, Maciej Sobczak wrote:
Wiesz co, wszytkie te twoje "argmumenty" przeciwko Adzie da sie
zastosowac w dyskusji C vs. C++ przeciwko C++, gdzie przedstawiasz
zupelnie odmienne stanowisko. Wez wyluzuj i zastanow sie nad tym co
piszesz. A jezyk uniwersalny musi udostepniac niskopoziomowe operacje.



Pozdrawiam

Marek

do góry