W dniu 09.12.2023 o 18:43, heby pisze:
> On 09/12/2023 18:26, Mirek wrote:
>> Nie chce mi się już kontrować na te nietrafione argumenty.
>
> Wiadomo.
>
>> Czyli co? Dziadostwo i druciarstwo ..\dupa\build?
>
> Nie. \\dupa\build to takie same dziadostwo jak "wezme linuxa do migania
> diodą".
>
> To nie jest szkodliwe, ale tylko do momentu kiedy zaczyna mieć wpływ na
> bezpieczeństwo. W normalnych warunkach odpierniczanie dziadowy podlega
> tylko pod ekonomię i możesz miec sytuacje, gdzie nie ma znaczenia jak
> dziadowski jest proces dev produktu czy polepiony drutem OS, o ile to
> tylko nastepny odtwarzacz mp3.
>
> Linux nie jest bezpieczny jako podstawa systemu RT sterującego czymś
> krytycznym. Mozesz oczywiscie dać argument 'ale miliony instalacji...".
>
> To sa instalacje na *innym* hardware, niż w pociagu. Nie znasz jego
> stabilnosci na niszowym procesorze i nie jesteś w stanie jej nawet w
> sensowny sposob obronić, ponieważ ilość kodu uniemożliwia jakiekolwiek
> analizy, ilość instalacji jest bliska zeru, a jądro i oprogramowanie
> tworzone były na x86, a nie na cokolwiek tam masz.
>
> Do sterownia funkcjami krytycznymi polecam jednak systemy które są do
> tego projektowane i mają okreslone cechy pozwalające mi czuć sie tam
> bezpieczniej kiedy projektuje cos, od czego potencjalnie zależy zycie
> czlowieka. I najlepiej uproszczone do granic możliwości, realizujące
> tylko to, co załozono i ani grama wiecej.
>
> 10x bardziej ufałbym lokomotywie sterowanej przez proste PLC niż
> lokomotywie sterowanej przez Linuxa. Strach przed GPFem w cronie
> niepokoi mnie bardziej niż awaria sterowanika produkowanego od
> dziesiecioleci.
>

...no przepraszam, że się wtrącę między "wódkę a zakąskę" :D

Heby - kiedy wymienialiśmy opinie n/t budowy systemu sterowania HA,
bardzo jednak upierałeś się na tym, że należy (przynajmniej w tamtym
przypadku) wykorzystać to co zostało już przez kogoś zbudowane,
"przepracowane" - bo poprostu - działa. Kiedy argumentowałem, że nie
chcę takich rozwiązań ponieważ nie widzę dla nich zastosowania w moim
przypadku kontrowałeś, że chcę "wymyślać koło na nowo".

W tym przypadku (chodzi o sterowanie pociągu) argumentujesz w drugą
stronę: dziwisz się, że producent poszedł "na łatwiznę" i zastosował coś
co działa (choć jest wykorzystywane w innym zakresie) i jednak (jako
producent) powinien zrobić coś całkowicie od nowa.

Gdzie w tym przypadku leży różnica pomiędzy szarym człowiekiem z
konkretnymi wymaganiami i "dużym graczem" który jednak idzie na skróty ?

--
Pozdrawiam - titanus

do góry

W dniu 10.12.2023 o 00:08, titanus pisze:
> W dniu 09.12.2023 o 18:43, heby pisze:
>> On 09/12/2023 18:26, Mirek wrote:
>>> Nie chce mi się już kontrować na te nietrafione argumenty.
>>
>> Wiadomo.
>>
>>> Czyli co? Dziadostwo i druciarstwo ..\dupa\build?
>>
>> Nie. \\dupa\build to takie same dziadostwo jak "wezme linuxa do
>> migania diodą".
>>
>> To nie jest szkodliwe, ale tylko do momentu kiedy zaczyna mieć wpływ
>> na bezpieczeństwo. W normalnych warunkach odpierniczanie dziadowy
>> podlega tylko pod ekonomię i możesz miec sytuacje, gdzie nie ma
>> znaczenia jak dziadowski jest proces dev produktu czy polepiony drutem
>> OS, o ile to tylko nastepny odtwarzacz mp3.
>>
>> Linux nie jest bezpieczny jako podstawa systemu RT sterującego czymś
>> krytycznym. Mozesz oczywiscie dać argument 'ale miliony instalacji...".
>>
>> To sa instalacje na *innym* hardware, niż w pociagu. Nie znasz jego
>> stabilnosci na niszowym procesorze i nie jesteś w stanie jej nawet w
>> sensowny sposob obronić, ponieważ ilość kodu uniemożliwia jakiekolwiek
>> analizy, ilość instalacji jest bliska zeru, a jądro i oprogramowanie
>> tworzone były na x86, a nie na cokolwiek tam masz.
>>
>> Do sterownia funkcjami krytycznymi polecam jednak systemy które są do
>> tego projektowane i mają okreslone cechy pozwalające mi czuć sie tam
>> bezpieczniej kiedy projektuje cos, od czego potencjalnie zależy zycie
>> czlowieka. I najlepiej uproszczone do granic możliwości, realizujące
>> tylko to, co załozono i ani grama wiecej.
>>
>> 10x bardziej ufałbym lokomotywie sterowanej przez proste PLC niż
>> lokomotywie sterowanej przez Linuxa. Strach przed GPFem w cronie
>> niepokoi mnie bardziej niż awaria sterowanika produkowanego od
>> dziesiecioleci.
>>
>
> ...no przepraszam, że się wtrącę między "wódkę a zakąskę" :D
>
> Heby - kiedy wymienialiśmy opinie n/t budowy systemu sterowania HA,
> bardzo jednak upierałeś się na tym, że należy (przynajmniej w tamtym
> przypadku) wykorzystać to co zostało już przez kogoś zbudowane,
> "przepracowane" - bo poprostu - działa. Kiedy argumentowałem, że nie
> chcę takich rozwiązań ponieważ nie widzę dla nich zastosowania w moim
> przypadku kontrowałeś, że chcę "wymyślać koło na nowo".
>
> W tym przypadku (chodzi o sterowanie pociągu) argumentujesz w drugą
> stronę: dziwisz się, że producent poszedł "na łatwiznę" i zastosował coś
> co działa (choć jest wykorzystywane w innym zakresie) i jednak (jako
> producent) powinien zrobić coś całkowicie od nowa.
>
> Gdzie w tym przypadku leży różnica pomiędzy szarym człowiekiem z
> konkretnymi wymaganiami i "dużym graczem" który jednak idzie na skróty ?
>

No przecież napisał: w safety. Jeżeli potrzebujesz THR na poziomie SIL4
to realizujesz sterowanie z powieleniem funkcji, na różnych platformach
sprzętowych (także różnych systemach op.) i różnymi zespołami
programistów. I to na kolei jest praktykowane.

do góry

io <i...@o...pl.invalid> writes:

[...]
>
> Więc właśnie tak by to musiało być realizowane a hackerzy twierdzą że
> pobrali kod, zmodyfikowali i wgrali bez większego trudu, pociąg
> "naprawiony", więc zapomnij.

O ile ja dobrze rozumiem. To pobrali kod, zdebugowali, zrozumieli co
trzeba przestawić w danych (jakieś flagi czy coś) i przestawili. Kodu
nie zmieniali.
KJ

do góry

W dniu 10.12.2023 o 10:43, Kamil Jońca pisze:
> io <i...@o...pl.invalid> writes:
>
> [...]
>>
>> Więc właśnie tak by to musiało być realizowane a hackerzy twierdzą że
>> pobrali kod, zmodyfikowali i wgrali bez większego trudu, pociąg
>> "naprawiony", więc zapomnij.
>
> O ile ja dobrze rozumiem. To pobrali kod, zdebugowali, zrozumieli co
> trzeba przestawić w danych (jakieś flagi czy coś) i przestawili. Kodu
> nie zmieniali.

Możliwe. Możliwość zmodyfikowania i wgrania mogła być tylko czyjąś,
niekoniecznie trafioną konkluzją, którą gdzieś wyczytałem w tych
materiałach medialnych. Coś to tam zmienia.

do góry

On 10.12.2023 12:29, io wrote:
> W dniu 10.12.2023 o 10:43, Kamil Jońca pisze:
>> io <i...@o...pl.invalid> writes:
>>
>> [...]
>>>
>>> Więc właśnie tak by to musiało być realizowane a hackerzy twierdzą że
>>> pobrali kod, zmodyfikowali i wgrali bez większego trudu, pociąg
>>> "naprawiony", więc zapomnij.
>>
>> O ile ja dobrze rozumiem. To  pobrali kod, zdebugowali, zrozumieli co
>> trzeba przestawić w danych (jakieś flagi czy coś) i przestawili. Kodu
>> nie zmieniali.
>
> Możliwe. Możliwość zmodyfikowania i wgrania mogła być tylko czyjąś,
> niekoniecznie trafioną konkluzją, którą gdzieś wyczytałem w tych
> materiałach medialnych. Coś to tam zmienia.

Ostatecznie chyba Newag wgrał "poprawki" do kilkunastu pociągów.
Co do hakerów, to tam piszą że nie do końca poznali kod, bo nie mieli
disasemblera. Jeżeli kod nie był obfuskowany, to dane takie jak
współrzędne geograficzne, data, czas, łańcuchy znaków itp, można łatwo
znaleźć bez tego. Wystarczy zmodyfikować jeden czy kilka bajtów w tym
miejscu żeby zdezaktywować działanie: np. datę zmienić na 30 lutego a
współrzędne zmienić na Antarktydę. Oczywiście o ile spójność kodu nie
jest sprawdzana. ale to też można obejść jeśli wiemy jak.
BTW: Pod DOS-em była taka gierka "Żużel" - ona świetnie wykrywała
niektóre wirusy, bo jak plik był zmodyfikowany to się nie chciała
uruchomić. Nie wiem czy sprawdzana była wielkość pliku czy suma
kontrolna, ale to działało.

--
Mirek.

do góry

On 09/12/2023 20:30, Zbych wrote:
>> Też raczej ukryłbym te komunikaty, ale jak widać można i tak.
> A ja bym nie ukrywał. W razie problemów przynajmniej widać co się dzieje.

Maszynista przedyktuje przez telefon w razie awarii lini IRQ na PCI-E?

do góry

On 10/12/2023 00:08, titanus wrote:
> Heby - kiedy wymienialiśmy opinie n/t budowy systemu sterowania HA,
> bardzo jednak upierałeś się na tym, że należy (przynajmniej w tamtym
> przypadku) wykorzystać to co zostało już przez kogoś zbudowane,
> "przepracowane" - bo poprostu - działa.

1) Hardware sterowanika w pociągu nie jest "przepracowane". Jest
niszowe. Przeciętny, brodaty nerd, piszący kod w jądrze Linuxa w życiu
go na oczy nie zobaczy. On pisze kod, który będzie pracował na nieznanej
architekturze i może nigdy nie zobaczyć buga, który własnie w tej chwili
implementuje.

2) Istnieje róznica między miganiem didoami a sterowaniem setką ton.

> Kiedy argumentowałem, że nie
> chcę takich rozwiązań ponieważ nie widzę dla nich zastosowania w moim
> przypadku kontrowałeś, że chcę "wymyślać koło na nowo".

Jesli robisz domowy projekcik, albo nawet kompercyjny, konsumencki
projekcik, typu zabawkowego, nalezy jak najwięcej czerpać z gotowców.
Zawieszenie się tabletu dziacku spowoduje tylko płacz i traumę u
przedszkolaka, gdy to samo w pociągu może doprowadzić do utraty życia.

Przepychanie wszystkich czujników i sterowania przez jeden, deliktny
system, jest naiwne. Linux, jako OS, może co najwyżej pełnić rolę
nadzorcy nad układami, ale układy powinny być autonomiczne i mieć
niezalezną możliwośc sterowania, pomijającą ten ekran (dotykowy?).

Podobnie, przepytachnie wszystkch ukłądów przez centralny komputer jest
naiwne. Znacznie bardziej neizawodne były by osobne elementy, pracujące
autonomiczne i co najwyżej oczujnikowane.

> W tym przypadku (chodzi o sterowanie pociągu) argumentujesz w drugą
> stronę: dziwisz się, że producent poszedł "na łatwiznę" i zastosował coś
> co działa (choć jest wykorzystywane w innym zakresie) i jednak (jako
> producent) powinien zrobić coś całkowicie od nowa.

To nie branża, gdzie wolno iść na łatwiznę.

> Gdzie w tym przypadku leży różnica pomiędzy szarym człowiekiem z
> konkretnymi wymaganiami i "dużym graczem" który jednak idzie na skróty ?

Bezpieczeństwo.

Aby była 100% jasność: w urządzeniach sterujących, szczególnie typu RT i
infrastrukturze krytycznej, nie ma miejsca na rozwiązania szybkie i
tanie, a takim jest Linux.

Może być tak, że wyświetlacz w pociągu nie jest krytyczny i można używać
pociąg bez niego. Wtedy nie ma problemu. Acz zaczyna wtedy pojawiać się
pytanie: to po co on tam jest?

do góry

On 10.12.2023 16:10, heby wrote:
> On 09/12/2023 20:30, Zbych wrote:
>>> Też raczej ukryłbym te komunikaty, ale jak widać można i tak.
>> A ja bym nie ukrywał. W razie problemów przynajmniej widać co się dzieje.
>
> Maszynista przedyktuje przez telefon w razie awarii lini IRQ na PCI-E?

Zrobi zdjęcie i wyśle geniuszu.

do góry

On Sun, 10 Dec 2023 16:20:02 +0100
heby <h...@p...onet.pl> wrote:

> Jesli robisz domowy projekcik, albo nawet kompercyjny, konsumencki
> projekcik, typu zabawkowego, nalezy jak najwięcej czerpać z gotowców.
> Zawieszenie się tabletu dziacku spowoduje tylko płacz i traumę u
> przedszkolaka, gdy to samo w pociągu może doprowadzić do utraty życia.

Wlasnie dlatego w przypadku pociagu tez trzeba korzystac z gotowca, o
ile takowy istnieje - istniejacy kod to kod sprawdzony przez
poprzedniego uzytkownika. Im wiecej uzytkownikow, tym wieksza szansa na
wylapanie bledow. Mozna sie wrecz pokusic o stwierdzenie, ze
pasazerowie zyskaliby na bezpieczenstwie, gdyby zaczeto stosowac
oprogramowanie na licencji open source.

> Przepychanie wszystkich czujników i sterowania przez jeden, deliktny
> system, jest naiwne. Linux, jako OS, może co najwyżej pełnić rolę
> nadzorcy nad układami, ale układy powinny być autonomiczne i mieć
> niezalezną możliwośc sterowania, pomijającą ten ekran (dotykowy?).

No zgadza sie, przy czym to nie jest problem stricte Linuxa, a
scentralizowanej architektury sprzetowej.

> Podobnie, przepytachnie wszystkch ukłądów przez centralny komputer
> jest naiwne. Znacznie bardziej neizawodne były by osobne elementy,
> pracujące autonomiczne i co najwyżej oczujnikowane.

Owszem.

> > W tym przypadku (chodzi o sterowanie pociągu) argumentujesz w drugą
> > stronę: dziwisz się, że producent poszedł "na łatwiznę" i
> > zastosował coś co działa (choć jest wykorzystywane w innym
> > zakresie) i jednak (jako producent) powinien zrobić coś całkowicie
> > od nowa.
>
> To nie branża, gdzie wolno iść na łatwiznę.

Tu nie chodzi o pojscie na latwizne, tylko o aspekt czysto praktyczny.
I tak jak pisalem wyzej, byloby wskazane zeby producent nie odkrywal
kola na nowo, a korzystal z tego, co juz wymyslono, niezaleznie od
tego, czy to jest soft, czy nowy design hardware'u.

> > Gdzie w tym przypadku leży różnica pomiędzy szarym człowiekiem z
> > konkretnymi wymaganiami i "dużym graczem" który jednak idzie na
> > skróty ?
>
> Bezpieczeństwo.

Nowy design nie gwarantuje bezpieczenstwa, wrecz przeciwnie.

> Aby była 100% jasność: w urządzeniach sterujących, szczególnie typu
> RT i infrastrukturze krytycznej, nie ma miejsca na rozwiązania
> szybkie i tanie, a takim jest Linux.

Oczywiscie, ze jest. W innym watku pisalem o patchach RT na kernel
Linuxa, stosowanych z powodzeniem w przemysle.

> Może być tak, że wyświetlacz w pociągu nie jest krytyczny i można
> używać pociąg bez niego. Wtedy nie ma problemu. Acz zaczyna wtedy
> pojawiać się pytanie: to po co on tam jest?

Dla wygody? Dla redundancji? Dla serwisanta?

Od pociagu mozesz odpiac wagon, tez pojedzie. Tez zapytasz "to po co
ten wagon byl?" ? Raz jechalem taborem TLK w wagonie bez drzwi, chyba
je urwalo gdzies po drodze. Tez zapytasz "to po co te drzwi, skoro
pociag dalej jedzie?" ? Itp. Itd.

do góry

W dniu 10.12.2023 o 18:02, Zbych pisze:

>>>> Też raczej ukryłbym te komunikaty, ale jak widać można i tak.
>>> A ja bym nie ukrywał. W razie problemów przynajmniej widać co się
>>> dzieje.
>>
>> Maszynista przedyktuje przez telefon w razie awarii lini IRQ na PCI-E?
>
> Zrobi zdjęcie i wyśle geniuszu.

Jak jest nastolatkiem ze smartfonem to owszem.
A jeśli jest sześdziesięciolatkiem bez?


Pozdrawiam

do góry