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.