W dniu środa, 26 września 2012 22:24:26 UTC+2 użytkownik Sebastian Biały napisał:

> > Znaczy si�: tak, mo�na w Adzie *wy��czy�* bezpieczniki.
>
> Dlatego bezpiecze�stwo jest pozorne.

Ręce opadają. Będziesz bił pianę do końca świata, bo można. Czapka też nie chroni
przed odmrożeniem uszu, bo można jej nie założyć.

> Ada niczego nie
> gwarantuje, a jedynie umo�liwia. To ju� samo z siebie jest wystarczaj�co
> podejrzane.

Otóż Ada gwarantuje, że domyślnie włączone bezpieczniki zadziałają poprawnie.
Gwarantuje też, że bezpieczniki wyłączone nie zadziałają.
Ja tu widzę same gwarancje. Można z nich skorzystać w obie strony.

> Mo�na by si� zastanawia� dlaczego j�zyk pozwoli� na wy�aczenie jednej z

> jego najbardziej eksponowanych cech

Bo jego najbardziej eksponowaną cechą jest to, że programistę wspomaga a nie
zastępuje. ABS i system kontroli w trakcji w samochodach też zwykle da się wyłaczyć.

Sorry, ale dotarliśmy do punktu, w którym nie potrafię dalej dyskutować. Nie potrafię
bronić czapki, której Jaś nie założył (gorzej: Jaś ją specjalnie zdjął, bo już miał
ją założoną) i odmroził sobie uszy.

> z pewnďż˝
> nutkďż˝ satysfakcji wywlekam tego suchara

Pamiętaj też o poduszkach powietrznych. Takie rzeczy trzeba piętnować.

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

do góry

On 25/09/2012 18:26, Sebastian Biały wrote:
[...]
> Że na czym polega bezpieczeństwo? Że nie można czegoś tam na coś
> zrzutować? Zerknij na ten kod z linka. Oni mieli w *d...* jakieś
> rzutowania, kontrole typow. Do tego kodu zatrudnili jakiegoś hakera
> wyjętego z przerwy w kodowaniu demek. Można to bylo bez utraty jakości
> napisać w asm.

Bezpieczeństwo nie musi polegać na tym, że się chroni program przed
programistą, który ma w dupie. Moim zdaniem dość sensowne jest też
podejście takie, że się zakłada, że programista nie ma w dupie,
natomiast tak w ogóle jest człowiekiem i może się pomylić, i właśnie
przed takimi pomyłkami ma chronić język. Problem programisty, który ma w
dupie, wydaje mi się, że lepiej rozwiązać na innym poziomie, niż język
programowania.

do góry

On 2012-09-26 22:54, Maciej Sobczak wrote:
> Sorry, ale dotarliśmy do punktu, w którym nie potrafię dalej dyskutować.

No i słusznie, bo ja tylko troluje dla sportu.

do góry

W dniu czwartek, 27 września 2012 00:08:02 UTC+2 użytkownik Sebastian Biały napisał:
> On 2012-09-26 22:54, Maciej Sobczak wrote:
>
> > Sorry, ale dotarliśmy do punktu, w którym nie potrafię dalej dyskutować.
>
>
>
> No i słusznie, bo ja tylko troluje dla sportu.

za madre to to szczerze mowiac nie bylo :O
powiedz moze jak wyobrazasz sobie bezpieczny
jezyk

do góry

On 2012-09-27 15:46, kenobi wrote:
>>> Sorry, ale dotarliśmy do punktu, w którym nie potrafię dalej dyskutować.
>> No i słusznie, bo ja tylko troluje dla sportu.
> za madre to to szczerze mowiac nie bylo :O
> powiedz moze jak wyobrazasz sobie bezpieczny
> jezyk

Taki którym nie jest możliwe *wyłączenie* procedur zapewniających
bezpieczeństwo? Tak na początek ...

do góry

W dniu czwartek, 27 września 2012 19:01:36 UTC+2 użytkownik Sebastian Biały napisał:
> On 2012-09-27 15:46, kenobi wrote:
>
> >>> Sorry, ale dotarliśmy do punktu, w którym nie potrafię dalej dyskutować.
>
> >> No i słusznie, bo ja tylko troluje dla sportu.
>
> > za madre to to szczerze mowiac nie bylo :O
>
> > powiedz moze jak wyobrazasz sobie bezpieczny
>
> > jezyk
>
>
>
> Taki którym nie jest możliwe *wyłączenie* procedur zapewniających
>
> bezpieczeństwo? Tak na początek ...

spodziewalem sie wlasnie takiej odpowiedzi
(bo poniekad bylo wczesniej napisane), no
i powiedzmy ze ma to troche sensu ale tak
naprawde wtedy zwroc uwage powinienes
winic nie tyle jezyk a jedynie ten przelacznik czy moze praktyke jego wylaczania
- to czy taki wylacznik powinien byc czy
nie to troche inna sprawa,

ja tam nie bardzo ekscytuje sie takimi
tematami - mz podejscie do bezpieczenstwa
bym robil jak mowiłem (a tego typu wyskoki
z myleniem pojec sorrrki ale mnie troche
denerwuja jako strata czasu)

do góry

W dniu czwartek, 27 września 2012 19:01:36 UTC+2 użytkownik Sebastian Biały napisał:

> > powiedz moze jak wyobrazasz sobie bezpieczny
> > jezyk
>
> Taki którym nie jest możliwe *wyłączenie* procedur zapewniających
> bezpieczeństwo? Tak na początek ...

Tak na początek to leżysz. Znowu.

Zastanów się najpierw *po co* istnieją bezpieczne języki.

Otóż wbrew temu co sądzą teoretycy z uniwersytetów, bezpieczne języki nie służą do
tego, żeby w nich drukować rekurencyjne choinki, tylko do tego, żeby czymś
*sterować*. W większości przypadków tam, gdzie mówi się o bezpieczeństwie, chodzi o
szeroko rozumiane interakcje z procesami fizycznymi.
Istnieje oczywiście też rynek bezpiecznych systemów informacyjnych, np. związanych z
finansami, gdzie fakapy powodują straty pieniężne, ale ponieważ główni aktorzy tych
rynków regularnie udowadniają, że im to wisi, więc w praktyce nie jest to target dla
bezpiecznych technologii. Targetem dla bezpiecznych technologii są systemy
sterowania. Samolotami, elektrowniami, hamulcami, rozrusznikami serca, itd.

I teraz zastanów się, jakie cechy musi mieć język programowania, żeby się w ogóle to
tego nadawał - czyli do interakcji ze sterowanikami urządzeń albo wręcz do
bezpośrednich odwołań do pamięci, bo właśnie tak wyglądają te interakcje na
odpowiednio niskim poziomie.

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.
Tylko tyle i aż tyle.
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*.

Proste?

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

do góry

W dniu piątek, 28 września 2012 09:17:25 UTC+1 użytkownik Maciej Sobczak napisał:
> Istnieje oczywiście też rynek bezpiecznych systemów informacyjnych, np. związanych
z finansami, gdzie fakapy powodują straty pieniężne, ale ponieważ główni aktorzy tych
rynków regularnie udowadniają, że im to wisi, więc w praktyce nie jest to target dla
bezpiecznych technologii. Targetem dla bezpiecznych technologii są systemy
sterowania. Samolotami, elektrowniami, hamulcami, rozrusznikami serca, itd.

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.

RW

do góry

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...

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

do góry

Dnia Fri, 28 Sep 2012 04:33:42 -0700, Maciej Sobczak napisal:

> 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...

Chyba sam mówiłeś o podwykonawcach. Stosując ten motywacyjny
punkt widzenia, nie wszyscy biorący udział w tworzeniu dowolnego
urządzenia w tym oprogramowania mają taką samą motywację. Ba,
powiedziałbym że każdy uczestnik jako osoba i jako grupa
czy podmiot ma inną.

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.

--
Edek

do góry