rzędzi

Pan J.F napisał:

Najczęściej mówią o tym ci od embraerów. Najczęściej.

"Inna kategoria softu". Resetowanie "całego samolotu" jednak nie dotyczy wszystkiego.

W dniu 14.12.2023 o 20:42, Piotr Gałka pisze:

To nie był temat 'jawności systemów operacyjnych' tylko jednego systemu. Się komuś nie podoba, że nie jest. Ale z tego, że drugi jest wcale nie wynika, by lepiej nadawał się do lokomotyw. Bo lepiej nadaje się ... w dyskusji padło.

Przecież to nie jest błąd. To swoiste zabezpieczenie. Można wyobrazić sobie, że oprogramowanie właśnie tak jest chronione zgodnie z wymaganiem biznesowym klienta zawartym w umowie. Bynajmniej nie jedynym wymaganiem, całe oprogramowanie jest realizacją takich wymagań. Do tego są jeszcze normy wpływające na sposób kodowania. Jak osoby spoza branży mogą w tym pomagać?

Uczestniczylem w procesie pochodnym, tj testowalem bezpieczenstwo w autach. Narzedzia z zeszlego wieku, fuszera na wielu etapach. Niestety zarzadzanie w waterfallu + restrykcyjne normy powoduja, ze cos, co jest widoczne golym okiem dla developera jako babol, musi czekac na etap testow formalnych, i o dziwo mimo pozornej oczywistosci czesto przechodzi dalej.

Dobrze pamietam materialy "marketingowe" aut autonomicznych sprzed czasow Tesli - po kilku latach "developmentu" auta kilku renomowanych firm nie potrafily przejechac po w miare prostej autostradzie kilku kilometrow. Albo inny material, na ktorym czujnik awaryjnego hamowania nie zadzialal jak powinien.

Automotive i lotnictwo to biznes sterowany przez Januszy-ignorantow, a pozorne bezpieczenstwo jest zapewniane przez niechec do jakichkolwiek innowacji. Nie polecam.

Nie, Windows nie ma śladu modułowości. Nawet wersja CE była pod tym względem żałosna. Rodzina OSów windowsa jest ciężka w konfiguracji do potrzeb innych niż machanie myszką w paincie.

Nic. To ten sam problem, jak otwiersza maskę i widzisz filtr powietrza na trytytkach. Jeździ? Jeździ!

Aby, w sytuacji awaryjnej, zarówno serwis jak i cenę zredukować.

Nie wiem jak się czujnikuje twory abstrakcyjne, więc się nie wypowiem.

W sytuacji kilku analogowych: padła kontrolka nawiewu, da się dojechac dalej.

Ponadto chciałbym zobaczyć te penele przy -25. Jeden już widziałem, w wypasionej koparce. Koparka odpaliła, ale pracować się nie dało, ekran nieczytelny przez około 10 minut, do czasu nagrzania kabiny.

W przypadku awarii nieistotnego indykatora, prowadzenie pociągu wynika zapewne z przepisów i regulaminów, ale nie jest wykluczone.

Jestem.

Czyli nie masz o tym pojęcia.

Nie.

Problem z Max-ami polegał na niedotestowaniu w wyniku decyzji białkowej, ignorowaniu problemu w wyniku decyzji białkowej i ogólnie, zależał od białka.

Gratuluję doboru źródła wiedzy o procedurach jakościowych w przemyśle lotniczym.

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.

Nie wiem o jakiej dacie, ale skoro nie udało się sprawdzić, to testowanie do dupy, fakt.

To nie ma nic wspólnego z procedurami testowania w profesjonalnych firmach (nie tylko w lotnictwie).

Wiem, bo widzę oba z miejsca, gdzie siedzę. Istnieje cały przemysł, niewidoczny dla suwerena z ulicy z uwagi na ceny licencji oprogramowania, zajmujący się produkcją narzędzi *TYLKO* to testowania, na dziesiątki sposobów, kodu krytycznego lub ważnego z innych przyczyn niż bezpieczeństwo. To rynek wart pieniądze bajeczne. I masa firm płaci za takie własnie rozwiązania, bo ogarnięcie procedur testowania w obecnym hardware/firmware krytycznym jest trudne do poskładania z narzędzi darmowych, a wielu wypadakch (hardware) niemożliwe. Praktycznie każda firma robiąca hardware jest zmuszona do testowania pochłaniajacego wiecej czasu niż samo tworzenie, bo kazdy bug oznacza dla nich utratę rynku.

Jeśli chodzi o automotive, to nawet darmowe projekty z githuba bywają profesjonalniej wytestowane, niż przeciętny sterownik samochodowy. To nie moja opinia, tylko ludzi z tego tematu z firm PL. Nie wiem jak reszta śwaita, ale nie spodziewam się czegoś innego. Ssanie na rynku automotive widoczne od ~5 lat jest na tyle silne, że wessało również Januszy programowania i ustanowiło ich w krótkim czasie kierownikami działów. Na to niewiele da się poradzić, że niedzielny programista Dephi nagle musi ogarniać zarządzanie ryzykiem i najzwyczajniej nie ma pojęcia o tej dziedzinie, a terminy gonią.

No i teraz nie wiadomo czy: a) nie zgadzasz się z tym i spuszczasz wodę w kiblu smartphone (uważaj na szybkę!) b) uważasz, że nie istnieje tradycyjna metoda spuszczania wody w kiblu c) uważasz, że tradycyjne spuszczanie wody w kiblu nie jest kompatybilne z automatyką

Tak, ten murzyn nazywa się właściciel. Nie wiem czy zadałeś sobie trud rozszyfrowania "SmartHome" ale wystepuej tam słowo "Home" które oznacza miejsce, gdzie ludzie ogólnie zbierają się w celu mieszkania i przebywają względnie często i długo.

Być może pomyliłes to z automatyką w przemyśle, ale jakoś trudno dać wiare, że można być aż tak nieuczciwym, aby pod SmartHome podpinać automatykę kilku obiektów. Jesli zaś masz kilka mieszkań, to gwarantuje Ci, że stać Cie również na lokalnego murzyna, co przyjdzie i naciśnie reset, a przy okazji kwiatki podleje.

O rodzinie Core słyszałeś? Bo jeśli nie to jaki sens wypowiadać się?

Nie, to jest "problem" diodki na bezpieczniku automatycznym. Świeci, spać nie daje. No komu to może być potrzebne...

No to właśnie dlatego są panele by nie było 40 indykatorów. Byłoby lepiej mieć ich 40, ale przecież nie po to by były bardziej zawodne.

Filmik dostałeś, znajdź sobie.

W pociągu?

Tak, jak w każdym współczesnym samochodzie. Zamiast pierdyliarda osobnych wskaźników daje się panele. Np w Twizy, nie ma ogrzewania a działa.

A jakie na tym panelu ETCS są nieistotne indykatory? Wszystko tam jest kluczowe dla prowadzenia ruchu. Już pisałem, pociągu nie da się zatrzymać na czerwonym jak nie masz tego na panelu. Musiałbyś jechać

40km/h, zablokowałbyś praktycznie ruch.

Ale to Ci system operacyjny nie przeszkadza w testowaniu programu, który napisałeś. I brak systemu niekoniecznie jest rozwiązaniem bo przyjdzie Ci napisać masę niskopoziomowego kodu na co braknie budżetu. Więc się jednak stosuje gotowe systemy operacyjne. Do wyświetlaczy linux wydaje się ok :-)

Tej, która zatrzymała pociągi w Polsce.

Wiadomo, napisałem w dalszej części, wystarczyło doczytać do końca i dopiero podejmować komentowanie.

No i jak mają oświetlenie w każdym pomieszczeniu i tam jeszcze jakieś inne odbiorniki to nie ma tylu murzynów by to wszystko ogarnąć dlatego właśnie robią automatykę.

No właśnie nie, to Ty pomyliłeś "automatykę" z "brakiem automatyki" i wymyśliłeś sobie jakieś absurdalne "automatyka w przemyśle kontra automatyka w domu" jak to ciągle automatyka, która jest komuś potrzebna albo nie jest i tyle.

W dniu 15.12.2023 o 12:26, heby pisze:

Lepsza od twojej, tam się wypowiadają specjaliści od wypadków i testowania systemów, a ty kim jesteś, randomem iternetowym któremu się wydaje że wszystko wie. Więc żegnam ozięble.

W dniu 15.12.2023 o 12:29, heby pisze:

A jakie testowanie jest nie do dupy? Należy wszystkie testy przeprowadzić dla każdej możliwej daty w kombinacji z każdą możliwą godziną (z dokładnością do milisekundy)? W omawianym przypadku akurat wystarczyłoby testowac z rozdzielczością miesiąca ale przecież mogą być bardziej specyficzne błędy lub "błędy", np. o 13:13 w piątek trzynastego podczas ostatniej kwadry Księżyca, albo po n-tym przejściu przez 0 wskazań któregoś z czujników.

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.

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

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.

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.

Tak. W czasie jej powstawania istniał taki żart:

- Microsoft podobno pracuje nad systemem operacyjnym bez GUI. Prawie im się udało, tylko wymaga GUI.

Faktycznie, jakieś wersje nie dało się obsługiwać bez myszki i klawiatury, bo MS nigdy nie był na to przygotowany i nie udostępniał konsolowych odpowiedników wielu funkcji.

Ot, "modułowość".

No ustalilismy, że maszynista będzie dyktował dmesg przez telefon na serwis. Znaczy ktoś ustalił, ja nie.

Nie, to kwestia definicji zawodności. Udpalenie jednej kontrolki jest znacznie mniejszą awarią niż upalenie panelu LCD. Ba, wielu ludzi wymieni tą kontrolkę bez fatygowania serwisu, na miejscu.

Tak, w pociągach są nawiewy. Nie wiem czy mają kontrolki, ale tutaj rzecz w tym, że awaria nieistotnego elementu zwiazanego z komfortem, nie jest problemem. Jesli wszystko masz w panelu, to awaria oznacza awarię typu katastrofa.

Ktoś, kto produkuje przemysłowe panele, a producenta mamy bodaj i w PL, zapewne rozwiązuje ten problem dostarczając całe środowisko, certyfikowane do pracy tego typu, cieżko testowane i raczej niskoawaryjne.

A tutaj mamy Linuxa z wystajacymi messages. Jesli miałbym z tego powodu gdybać o jakości reszty, to może raczej nie warto zaczynać.

Twizyy może nie musi mieć kąta widoczności blisko 180. Operator koparki tak. Może podpowiem: panel w koparce nie dał się odczytać inaczej, niż gapiąc się prawie na wprost, a nawet wtedy ledwo ledwo. Operator zazwyczaj wypalał papieroska aż się kabina zagrzała i wtedy mógł widzieś i to co na panelu i to co na łyżce, kiedy się wychylał.

A system to jakiś budowlany, do nawigacji i precyzyjnych robót. Nie znam się na tym aby podać nazwę. Wot, LCD z touchscreenem i jakimiś pokrętłami.

Bez znaczenia jakie. W przypadku składów podmiejskich produkowanych w PRL nit nie robił dramy z powodu niedziałajacej kontroli ogrzewania kabiny. Tam kontrolka jest osobnym elementem. Się naprawi przy najbliższej okazji.

A jak panel zgaśnie, to da się zatrzymac, czy hamulce też odpina i jadę na czerwonym?

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Mieszasz modułowość z dostępnością konsolowych narzedzi. Na dodatek bazujesz na wiedzy sprzed 20 lat. Teraz te narzędzia istnieją i klikać nie musisz. A to, że nie dało się GUI całkowicie wyciąć to może i jest zabawne, ale tak właściwie nie było po co tego robić. Ważne, że jest PowerShell i jest w nim opcja pracy zdalnej. A że jak uruchomisz Core i konsola wyświetlana jest w okienku graficznym, a nie w trybie tekstowym, to co z tego? Co do samej modułowości, to ona nie jest zwyczajnie potrzebna w tych segmentach rynku, w które celuje MS. A co do stworzenia od zera systemu bez GUI przez MS, to jak najbardziej taki system powstał, nazywał się Singularity.

Przykład GUI pokazuje, jak bardzo naciągane są brednie o "modułowości" windowsa. Nie możesz pozbyć się elementu który Ci jest zupełnie niepotrzebny w embedded. On nawet jest niepotrzebny w embedded z panelem. Potrzebujesz tylko subsystem graficzny, a nie menu start.

To monolit, od momentu kiedy zaczeli go pisać, do dzisiaj. Oni nawet renderowanie fontów robili w kernelu, z przyczyn zapewne absurdalnych (tak, wiem "wydajność"), wiec przy takim dziadostwie naprawdę cieżko mówić o modułowości.

Ale jest modułowy. Tylko się nie dało. Ale jest. Modułowy. Zasadniczo.

Mieszasz modułowość z pracą zdalną.

"modułowość", ale tym razem w kontekście np. embedded bez wyświetlacza.

Ot, taka technologia. Modułowa.

Ale przecież to nie ja twierdzę, że MS jest modułowy.

Ja twierdzę, że jest monolitem, zabetonowanym przez dziadowski design w stanie, kiedy nawet usuniecie Candy Crush Saga staje się zagadnieniem nad którym rozwodzimy się w necie. Być może to składnik kernela, kto wie, po tych fontach niczemu się już nie dziwię.

Z historią jak AmigaOS, BeOS i kilka innych fooOS.

Przypominam, że mowa była o Windows. I że modułowy. Bardzo.

Czyli "Świeci, spać nie daje. No komu to może być potrzebne".

To nie jest kwestia definicji. Te panele są po prostu bardziej niezawodne od pojedynczych kontrolek.

Człowieku, na tym panelu nie ma żadnego nawiewu. Ruch kolejowy nie jest sterowany maszynistą tylko infrastrukturą. Pociągi są wykrywane i identyfikowane balisami. Tory są otwierane na przejazdy pociągów, reszta pozostaje zamknięta. Zajmuje się tym interlocking. Jak panel przestaje działać to pociąg zatrzymuje się i tyle.

To nie ma sensu, weź oglądnij ten film co Ci podali !!!

A jak prądu w trakcji braknie podczas jazdy to jak hamuje?

Raczej obserwacja własna, że maszynistów z doświadczeniem w IT, a nawet maszynistów ze znajomością jezyka angielkiego technicznego, jest relatywnie mało.

Być może jakieś penale są. Czy ten jest? Wystający dmesg pozwala mi powątpiewać w stabilnośc software zbudowanego na zabawkowym Ubuntu czy innym Knoppixie.

Czyli nie pojmujesz abstrakcji. Zebrałeś wszystkie indykatory i wsadzięłeś je w jeden element. O ile osobne idykatory jest łatow naprawić, to ten jeden element, jak sam zauważasz, w przypadku awarii spowoduje zatrzymanie składu.

To ma sens, jesli panej jest zrobiony profesjonalnie, przetestowany, bez oszczędzania.

A tutaj mamy wystające dmesg.

Rozumiesz moje obawy?

:D

TBDU.

Ależ obejrzałem. A na marginesie: miało sens w latach 70,80,90. Nagle sens zniknął? Moim zdaniem przyszła moda na kokpity boeningów. Niedługo ride-by-wire i wyświetlacze HUD pojawi się pewnie i w rowerach z Auchan.

Pewnie pneumatycznie.

Ale postulujesz, że nie da się zatrzymać ppociągu na czerwonym, bo "komputer mówi nie". Do kitu z takim pociągiem.