On 15/12/2023 13:57, io wrote:
>> Andrzej ze szwagrem czasami są sepcjalistami i mogą faktycznie
>> sprawdzić lepiej, bo mają do sprawdzenia 1000x mniej linijek kodu i
>> 1000[...]000x mniej sytuacji randomowych, hazadrów wątkowych,
>> allokacji RAMu i mają szance na pokrycie blisko 100% kodu testami. Co
>> w przypadku Linuxa jest niemożliwe.
> Ale to Ci system operacyjny nie przeszkadza w testowaniu programu, który
> napisałeś.

OS powoduje:
1) inny rozkład schedulera wątków w mojej apliakcji
2) dostarcza allokator pamieci, który może np. przykryć błędy
przekroczenia zakresu czy urwanej referencji
3) zmienia zachowanie istotnych elementów (kilka lat temu Linux zmienił
zachowanie rurek do których piszą dwa+ wątki, powodując katastrofę kilku
programów w sposób subtelnie niepowtarzalny)
4) zmienia zależnosci czasowe powodujac ukrywanie lub eksponowanie bugów
w kodzie usera
5) zmienia obsługę sytuacji UB (np. wyjątek w wątku bez catch powodujący
różne katastrofy, niektóre przezabawne).

OS jest dostatecznie skomplikowany, aby zapewnić całkowitą randomiczność
w działaniu wielu funkcji w user space. O ile prawidłowo napisany
program jest uodporniony prawidłową architekturą i kodowaniem, to
przeciętny program może się wysypać tylko dlatego, że nagle z read()
zaczeły przeychodzi EINTR którysz wcześniej nikt nie widział i nie
zastosował prawidłoych zabezpieczeń. Bardzo trudno napisać większą
aplikację kompletnie bez błędów i przewidzieć każdą sytuację.
Występowanie tych błędów może mieć duży związek z OSem pod spodem.
Zazwyczaj problemy wyscigów w wątkach (i to niekoniecznie w samym
programie) objawiaja się zupełnie przypadkowo, w sposób trudny w
powtórzeniu. Z resztą, oprogramowanie poważne zwyczajowo jest testowane
na wszystkich wspieranych OSach. Dla przykładu, crash na RedHat i tylko
na nim miał związek z nadepnięciem pointerem na kawałek RAMu poza
tablicą, a na kazdym innym Linuxie przechodziło bez śladu. Pomógł
valgrind. Niby Linux to Linux, ale nie.

Taki OS. Preemptive, skomplikowany, w nastu wersjach, itd itp.

> I brak systemu niekoniecznie jest rozwiązaniem bo przyjdzie
> Ci napisać masę niskopoziomowego kodu na co braknie budżetu.

Problem nie w pisaniu kernela od zera.

Problem w interesujacym wyborze Linuxa, jako bazy do rysowania kilku
kresek. Takich baz jest kilka. Dlaczego akurat Linux?

Zwróć uwagę, że nie ma do tej pory argumentu za. Jest tylko argument "bo
można". No ale po co? Zaoszczędzisz może jakieś pieniądze, ale wladujesz
sie na potencjalne miny związane z przesadnym wypełnieniem samego Linuxa
masą śmieci niezwiązanych z rysowaniem kresek. Można go docinać, ale
taki system nie zapewnia wtedy argumentu "szwagrowi działa" bo szwagier
ma inną wersję.

> Więc się
> jednak stosuje gotowe systemy operacyjne. Do wyświetlaczy linux wydaje
> się ok :-)

Zależy co to wyświetla. Okoliczna tablica autobusów wyświetla czasami
oopsa z Linuxa, a okoliczny bilbord męczy się z niemożnością załadowania
bibliteki dll. To rownież system zrobione na odpier..., ponieważ
posiadają funkcję, które są niepotrzebne w danym zastosowaniu, ale
jednocześnie utrudniają one, albo nawet uniemożliwiają pracę urządzenia.

>>> No właśnie widzimy skutki: taki flow i testowanie, że nawet daty nie
>>> udało się poprawnie sprawdzić.
>> Nie wiem o jakiej dacie, ale skoro nie udało się sprawdzić, to
>> testowanie do dupy, fakt.
> Tej, która zatrzymała pociągi w Polsce.

Jak już wyjasniłem kilka razy: fakt, że ktoś tą datę w ogóle w kodzie
wprowadził, może świadczyć o kompletnym bałaganie w kodzie, bo tego nie
da się ukryć w prawidłowym flow. Nie spodziewam się tam ani śladu
testowania automatycznego na poziomie testowania systemów krytycznych.
Rozmawiamy sobie luźno o testowaniu tylko dlatego, że pojawił się jakiś
koncept OpenSource w urządzeniach krytycznych i o ile sam koncept jest
ok, to nie mam pojęcia, dlaczego od razu musi oznaczać Linuxa. Linux to
wspaniały OS, ale nie w każdym zastosowaniu.