On 10/12/2023 18:14, vamastah 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.

Ten kod nigdy nie był pisany z myślą o pociągach. On był pisany z myślą
o kernelowaniu kompili i dicking around.

> Im wiecej uzytkownikow, tym wieksza szansa na
> wylapanie bledow.

To głupie myślenie: architektura sterownika-komputera ma zaledwie kilku
użytkowników.

Linux roił się od błedów w momencie pojawienia się innych architektur.

Ba, część kodu krytycznego (wątki, wywołania systemowe itd) jest
specyficzna dla danej architektury i to że działa na x86 nie oznacza że
działa na procesorze Foo firmy Bar.

> Mozna sie wrecz pokusic o stwierdzenie, ze
> pasazerowie zyskaliby na bezpieczenstwie, gdyby zaczeto stosowac
> oprogramowanie na licencji open source.

To coś zupełnie innego niż Linux.

OpenSource tak.

Akurat Linux - niekoniecznie.

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

Posiadanie *wypasionego* systemu powoduje nieuchronne trendy do
wciskania do niego obsługi spryskiwaczy szyb i falowników silników w
jednym. Bo można zaoszczędzić pół centa.

Ten trend, nawet nie jest jakoś projektowany. Pojawia się samoczynnie,
kiedy projektem zaczynają interesować się księgowi.

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

Czyli łatwizna właśnie.

Zamaist robić trudniej, ale bezpieczniej, wsadzimy jakieś Ubuntu,
piszemy jakieś workaroundy w bashu i reszta dnia wolnego.

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

Producent, do ekspresu do kawy, wsadził Windows XP.

Uważasz że to rozsądne?

Zamiast podpiąc i nacisnac "kawa", teraz czekasz kilkanaście sekund, aż
to coś się uruchomi i wtedy naciskasz "kawa". Gdzie masz zysk?

Gdzie jest zysk z użycia Linuxa, startującego minutę i wyświetlającym
kilka kresek, nad oprogramowaniem wyświetlającym kilka kresek po
milisekundzie?

Czas pracy tak, ale w przypadku seryjnej produkcji asymptotycznie dąży
do zera.

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

Myślę, że nie pojmujesz problemu: Linux jest tak strasznie
skomplikowanym systemem, że nie jesteś w stanie go przetestować. Nie
istnieje fizyczna możliwość odpowiedzi na pytanie "czy to bezpieczne"
ponieważ ten system ma tryliony punktów swobody wzajemnie zazębiajacych
się i generujacych nowe stany.

W przypadku systemu specjalizowanego, pisanego od zera, możliwość
pełnego testowania jest możliwa, jesteś w stanie ogarnąć znaczą, a może
i nawet cała zawartość, poprawnymi procedurami testowania.

Są przypadki w przemyśle, kiedy wymagane jest testowanie systemu, który
czymś steruje, w sposób formalny.

Linuxa nie da się przetestować inaczej jak "yyyy, no szwagier i jego
milion kolegów używają i chyba działa".

To czasami jest wystarczające, ale czasami nie.

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

Ten przemysł to szerokie pojęcie. Machanie serwem w sortowni śmieci to
innych kaliber niż hamowanie składu na zderzeniu czołowym. To, że Linux
może być RT, to nie oznacza, że to jest do, co chciałbyś mieć w ukłądach
sterowania pociągiem. To nie ta skala bezpieczeństwa.

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

a) dla wygody? Odpala się z minutę. Jest słabo czytelny, na oko ten
ekran to jakieś tanie badziewie. Co złego w kilku kontrolkach i
wskaźnikach analogowych?

b) dla redundancji? A gdzie jest to pierwotne coś, co redundetuje?

c) Dla serwisanta? To po co one jest centralnie na konsoli?

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

Nie. Tutaj pytanie jest: jaki cel ma dublowanie wskaźników czytelnych,
bezpiecznych i sprawdzonych jakimś gównianym ekranem LCD.

W przypadku samolotu jestem w stanie pojąć argumentację: wskaźników jest
za dużo i się nie mieszczą, muszą być dynamiczne.

W przypadku pociągu tak nie jest.

Podpowiem: moda taka. Gówniana.