W dniu 12.12.2023 o 16:00, heby pisze:
> On 12/12/2023 15:38, io wrote:
>>> Pamiętasz, jak przez N lat był byg, że dotknięcie ekranu 11 palcami
>>> powodowało GPFa? Jaką masz gwarancję że głośne gwizdanie nie
>>> wypierniczy sterowanika karty dzwiękowej? To tylko Linux. System,
>>> poza wyświetlaniem kilku kresek, robiący miliard bezużytecznych
>>> rzeczy pod maską.
>> Zbędne rzeczy można wyciąć jak się chce używać systemu do nietypowych
>> celów.
>
> Ilość powiązań elementów w kernelu Linuxia jest ogromna. Robiłem to
> kiedyś na małego SoCa, panel GT2440. Tam jest bardzo słaby procesor,
> mało ramu i bez cięcia nie dało rady zrobić tego, co chciałem (Java+Swing).
>
> Cięcie nie poszło tak, jak myślisz. Wybranie w opcjach kernela braku
> sieci, powoduje niemożnośc skompilowania wielu innych elelementów
> kernela. NIKT nie testował produkcyjnie takiego zestawu parametrów na
> takiej arch jak ja sobie ubzdurałem, aby go zredukować. Np. część IPC
> (rurki, shared memory) nie chciał się skompilować bez włączonego
> "Networking" i padał na linkowaniu. Część elementów nie chciał się
> skompilować do środka, a jedynie jako moduły, wiedy brakowało czegoś
> zupełnie niezwiązanego z tematem. Cześć po wycięciu powodowała oopsy w
> kernelu, albo co gorsza dalej, w user space. Najśmieszniejszy był
> emulator koprocesora: można było skompilować bez, system (busybox) wtedy
> nie chciał wstać. Z jakiegoś powodu busybox wymagał koprocesora FPU albo
> jego emualcji i do dzisiaj nie wiem po co. Kernel bez FPU normalnie się
> bootował.
>
> To trwało ze 3 miesiące, zanim udało się przyciąć kernel tak, aby
> zmieścił się, razem z Javą i Swingiem oferując jeszcze jakąś
> funkcjonalność takiego "panelu", o jaki mowa w pociągu, czyli kilka
> kresek, wskaźników, przycisków. I nigdy nie pracował w pełni stabilnie,
> raz na jakiś czas oopsował kernel. Nie udało mi się ziagnozować co było
> przyczyną, czy hardware czy kernel, ale stawiam na to, że za mocno
> wycięty kernel był niestabilny.

Być może linux nie jest najlepszym systemem do tego. Nie analizowałem
tego. Być może bardziej modułowy jest np Windows.

>
> Jestem sceptyczy co do "da się przyciąć" z uwagi na ciężkie
> doświadczenia właśnie z tym zagadnieniem, kolesie od pociągu nawet nie
> usunęli komunikatów kernela z ekranu.

I co z tego?

>
>>> Tak. Na wskaźniku, najlepiej kołowym, machnicznym, czytelnym w
>>> każdych warunkach. To, co robi ten ekran, to pokazuje takie własnie
>>> wskaźniki (m.in). Dlaczego nie ma wskaźników, a jest ekran? Co daje
>>> ten ekran dla bezpieczeństwa?
>> Bo jak masz tyle wskaźników to zawsze któremuś linka zardzewieje
>
> Wydaje mi się, że z tym problemem radzimy sobie nieźle. Ponadto on nie
> musi być sterowany linką. Może być sterowany napięciem. Tak się robi
> bardzo wiele wskaźników panelowych.

Po co to robić jak się ma 2 panele?

>
>> lub tp co pogarsza niezawodność a nie polepsza abstrahując kompletnie
>> od tego, że trudno zrealizować i modyfikować logikę takich wskaźników.
>
> Logika wskaźników? Nie, logikę robi sie w innej warstwie. Wskaźniki są
> do wskazywania co logika wymysliła i co czujniki widzą.

Ta, oczujnikowana krzwya hamowania :-)

>
>> Kiedyś tak mechanicznie odbywało się sterowanie ruchem kolejowym i
>> jeszcze niedawno były stacje gdzie ono działało, ale raczej nie jest
>> to przykład do naśladowania tak, jak nie są nim pociągi konne.
>
> Sterowanie pociągiem nie jest tym samym co rodzielanie ruchu. To
> przypomina bardziej jazdę samochodem. Ktoś zamienił zegarek wskazówkowy
> na wyświetlacz. Wskaźnik prędkosci na wyświetlacz. Kontrolkę na
> wyświetlacz. Zamienił wiele elementów na 1, który jak się uszkodzi, to
> padnie wszystko.

No i przyjedzie serwis, wymieni jeden panel, koniec tematu.

>
> Jak patrzę na penele sterujace np. rozdzielniami, to ciągle jeszcze
> widzę osobne indykatory, wskaźniki, mierniki. Tak jest bardziej
> niezawodnie i w przypadku sytuacji niespodziewanej, coś da się z tym
> zrobić.
>

No da się zatrzymać pociąg, ale nie normalnie go prowadzić.