RTV forum PL | NewsGroups PL

Stary komputer nowy samolot - to tylko pozornie OT

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Stary komputer nowy samolot - to tylko pozornie OT

Goto page Previous  1, 2, 3, 4  Next

Grzegorz Niemirowski
Guest

Thu Apr 30, 2020 12:22 pm   



heby <heby@poczta.onet.pl> napisał(a):
Quote:
Tak, wierzę że dołożenie zabezpieczeń sprzętowych i programowych do CPU
zwiększa szansę na wykrycie błędu i reakcję.
No wiec ma się to nijak do współczesnego świata. Zwiększanie poziomu
komplikacji hardware doprowadza albo do idiotycznych probelmów z
bezpieczeństwem (wyciakenia danych z powodu speculative execution / cache)
albo wręcz uszkadzania danych (row hammer) w tych super zabezpieczonych
kawałkach hardware z masą 3-literowych skrutów. Pomijam fakt że
skompikowany hardware jest skomplikowany z punktu widzenia programisty i
wymaga *znacznie* bardziej bugogennego kodu.

Czytasz na co odpisujesz? Była mowa o zwiększaniu a zabezpieczeń a Ty
odpowiadasz ogólnie o zwiększaniu kompikacji. Speculative execution nie jest
zabezpieczeniem tylko metodą zwiększenia wydajności. Zabezpieczeniem jest
np. DEP.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Janusz
Guest

Thu Apr 30, 2020 12:23 pm   





heby
Guest

Thu Apr 30, 2020 12:28 pm   



On 30/04/2020 14:22, Grzegorz Niemirowski wrote:
Quote:
Czytasz na co odpisujesz? Była mowa o zwiększaniu a zabezpieczeń a Ty
odpowiadasz ogólnie o zwiększaniu kompikacji.

Dobrze, wiec dodajesz paging z bitami excutable.

To nie jest za darmo. Musisz dopisać kod do obsługi. Czasami, jak w
przypadku debilnej architektury x86, to jest absurdalnie skomplikowany kod.

Quote:
Zabezpieczeniem jest np. DEP.

Właśnie Ci pokazałem ile ten DEP jest warty w zderzeniu z ROP. Masz
następną bzdurę która nie zabezpiecza a jedynie powoduje komplikacjie
kodu klienta i delikatnie spowalnia hackera.

https://samsclass.info/127/proj/rop.htm

Serio, uważasz że w tym samolocie albo w tej przelotce ethernet chodzi o
to aby zabezpieczeń skomplikowany system? A nie lepiej napisać *mało*
kodu i następnie metodami formalnymi stwierdzić że nie posiadają dziur,
błedów czy innych niespodzianek?

Irek.N.
Guest

Thu Apr 30, 2020 1:30 pm   



Jest mi też ciężko sobie wyobrazić, żebym mógł
Quote:
kiedykolwiek wejść na pokład tego samolotu albo co grosza wsadzić do
niego rodzinę. '

No to zabawmy się w grę "zaraza skończona".
Wykupujesz wczasy w jakiejś agencji turystycznej, a na lotnisku
dowiadujesz się, że to właśnie ten felerny. Co robisz, lecisz, czy
mówisz rodzinie "tym nie lecimy" i odwołujesz zapłacone już wczasy?

Miłego.
Irek.N.

heby
Guest

Thu Apr 30, 2020 1:33 pm   



On 30/04/2020 15:30, Irek.N. wrote:
Quote:
Wykupujesz wczasy w jakiejś agencji turystycznej, a na lotnisku
dowiadujesz się, że to właśnie ten felerny.

U mnie było jasno napisane jaki samolot, jakiego przewoźnika o jakiej
godzinie. Zmienili na 3 dni wcześniej, znajdując inny czarter, w którym
jeden z silników wyraźnie wibrował cała drogę mocniej. Wysiadać w
trakcie Wink ?

Irek.N.
Guest

Thu Apr 30, 2020 1:37 pm   





Irek.N.
Guest

Thu Apr 30, 2020 1:51 pm   



Quote:
Więc winien nie jest hardware tylko zespół dyletantów którzy nie
przetestowali kodu.

A nie szerzej?
Są chyba jakieś normy projektowania w tej branży? Wiem jakie są
wymagania w dziedzinie wykonawstwa elementów dla branży lotniczej
(znaczy trochę wiem).
Jak to jest możliwe, że w przypadku pojazdu który nie można ot tak
zatrzymać dla bezpieczeństwa pasażerów na poboczu - jak samochód
przykładowo, dopuszcza się pojedyncze układy czujników? W mniej
newralgicznych dziedzinach dubluje się, a tutaj wolno nie dublować? Nie
pasuje mi to... znaczy... śmierdzi na odległość.

Tak więc po mojemu winny jest praktycznie każdy w łańcuszku w którym
powstał, a następnie mógł polecieć taki samolot. Mam tutaj na myśli
wszystkich od "początkowego pomysłu", po przez
konstruktorów/programistów, po kontrolę, certyfikację, kupującego, a na
pilotach skończywszy.

Takie moje zdanie w temacie.
Miłego.
Irek.N.

Irek.N.
Guest

Thu Apr 30, 2020 1:53 pm   



Quote:
U mnie było jasno napisane jaki samolot, jakiego przewoźnika o jakiej
godzinie. Zmienili na 3 dni wcześniej, znajdując inny czarter, w którym
jeden z silników wyraźnie wibrował cała drogę mocniej. Wysiadać w
trakcie Wink ?

No właśnie tutaj jest problem. Niby wszystko wiesz, masz sprawdzone,
jesteś skrupulatny. Ale z niezależnych od nikogo powodów nie da się
zrealizować planu i to w ostatnim momencie przed wsiadaniem. Co wtedy?
Nie wierzę, żę można zapisać w umowie zdanie "albo taki a taki samolot
tej a tej linii, albo umowa nieważna" ;)

Miłego.
Irek.N.

heby
Guest

Thu Apr 30, 2020 1:57 pm   



On 30/04/2020 15:51, Irek.N. wrote:
Quote:
Więc winien nie jest hardware tylko zespół dyletantów którzy nie
przetestowali kodu.
A nie szerzej?

Na koniec zawsze winna jest kontrola jakości. Moralnie to sobie mogą być
winni programiści, managerowie, księgowe itd itp. Ale to kontrola
jakości przepuściła bubla, JEŚLI to problem z software i zgadza się z
opisem z tego watku (za mała moc obliczeniowa, czyli brak testowania w
warunkach prawdziwej eksploatacji).

Zaznaczam, JEŚLI to problem z wydajnoscią sterowania. Bo prawda jest
taka że problem leżał też w czujniku i procedurach.

Janusz
Guest

Thu Apr 30, 2020 6:03 pm   



W dniu 2020-04-30 o 15:53, Irek.N. pisze:
Quote:
U mnie było jasno napisane jaki samolot, jakiego przewoźnika o jakiej
godzinie. Zmienili na 3 dni wcześniej, znajdując inny czarter, w którym
jeden z silników wyraźnie wibrował cała drogę mocniej. Wysiadać w
trakcie Wink ?

No właśnie tutaj jest problem. Niby wszystko wiesz, masz sprawdzone,
jesteś skrupulatny. Ale z niezależnych od nikogo powodów nie da się
zrealizować planu i to w ostatnim momencie przed wsiadaniem. Co wtedy?
Musisz sobie odpowiedzieć na ile cenisz zdrowie i życie swoje i rodziny,

czy warto ryzykować czy nie.
Może dlatego jeszcze nie latałem Smile
--
Janusz

Janusz
Guest

Thu Apr 30, 2020 6:15 pm   



W dniu 2020-04-29 o 21:55, heby pisze:
Quote:
On 29/04/2020 21:44, Janusz wrote:
Wszystko prawda ale, moc obliczeniowa za mała i błędy w oprogramowaniu
zawiniły w katastrofach.

Niedostatecznie testowano. Albo używano technik typowych dla "młodych i
dynamicznych zespołów programistów", czyli żadnych.

Problem spadku jakosci kody dotyczy chyba całego świata. Niby masz
programistę który od 10 lat pisze kod, a po chwili okazuje się że
napierniczał javascript. Taki odpowiednik pistoletu na wodę. I właśnie
go zatrudnili w embedded. "Bo ma doświadczenie w programowaniu".
To niestety prawda, ale tam podobno było za dużo obliczeń jak na te

komputery,
aribus okazuje się zastosował podobny myk tyle że dał 7 komputerów Smile
Zresztą opisaner jest to w artykule, który jest tłumaczeniem czyjegoś
bloga, ale widac że człowiek 'siedział' tam w środku albo kogoś miał bo
ma ciekawe informacje.

--
Janusz

Janusz
Guest

Thu Apr 30, 2020 6:28 pm   



W dniu 2020-04-29 o 20:59, Janusz pisze:
Quote:
Przeczytałem ciekawy blog, autor widac wi o czym pisze więc przyjmuję że
to nie fake_new. Więc do rzeczy

Jest sobie w usa duża firma samolotowa której główny konkurent w europie
w pewnym momencie zrobił lepszy samolot, więc jest wielka panika i praca
na szybko, samolot nowy się długo robi i testuje więc bierzemy to co już
jest i poprawiamy, co się może nie udać?
okazuje się że prawie wszystko.
Silniki za słabe, no to dajemy mocniejsze,
nie mieszczą się w gondolach no to przesuńmy je,
samolot stracił stateczność, no to sztucznie ją naprawmy, dajmy komputer,
co mamy? stare z '96 16bitowe jednostki,
za słabe? no to dajmy dwa,
Co się może nie udać?
Wszystko, dwa rozwalone samoloty i 346 ofiar zmusiło ich w końcu
do uziemienia wszystkich B737MAX.
https://antyweb.pl/dwa-16-bitowe-komputery-z-1996-maja-naprawic-konstrukcyjne-bledy-boeinga-737-max-nie-wiem-jak-wy-ale-ja-do-takiego-samoloty-nie-wsiade/


Widzę że nikt nie przeczytał zalinkowanego odnośnika bo by wiedział że

ta historia sie na tym (czyli dwu katastrofach i uziemieniu wszystkich
samolotów) nie skończyła otóż firma wzieła się za naprawę:

"Jeśli wydaje się wam, że tym razem postanowiono podejść do problemu
odpowiedzialnie, pamiętając do czego doprowadziła poprzednia prowizorka,
jesteście w błędzie. Skoro zawiodło oprogramowanie, to znaczy, że po
prostu trzeba je naprawić. Tyle tylko, że aby software działał
niezawodnie, trzeba zapewnić mu odpowiedni hardware. Tymczasem wygląda
na to, że w Boeingu podeszli do sprawy tak jak poprzednio, byle tanio,
byle szybko i byle nie trzeba przechodzić zbyt wielu badań ze strony
regulatorów lotniczych."
"Testy pierwszych poprawek oprogramowania, które wysłano do akceptacji
FAA, zakończyły się katastrofą. Komputery pokładowe poddane
stress-testowi generowały przekłamania jednego bitu, które w
konsekwencji mogły prowadzić do wyłączenia systemu kontroli czy
wprowadzić samolot w niekontrolowane nurkowanie. Poza tym systemy
pokładowe wykładały się w trakcie uruchamiania, nie ładując poprawnie
wszystkich modułów. Jeden z europejskich regulatorów wykrył, że całość
potrafiła się zawiesić w czasie działania autopilota. Musicie przyznać,
że nie takich efektów oczekuje się od 24-letniego, zweryfikowanego w
dziesiątkach innych samolotów, bezpiecznego komputera pokładowego."
"Jak sugeruje autor raportu i podpowiada zdrowy rozsądek, Boeing
wprowadzając coraz to nowe poprawki, przeciążył cały system. Dwa stare
komputery nie są w stanie przeliczyć tak dużej ilości nowych danych i
generują błędy. Dla porównania podano, że przekleństwo Boeinga, czyli
wspomniany już Airbus A320neo, korzysta z podobnie antycznych komputerów
pokładowych, ale ma ich na pokładzie aż siedem. Boeing jednak ciągle
upiera się, że już za chwilę naprawią wszystko oprogramowaniem, a
wszyscy będą żyli długo i szczęśliwie."

"Patrząc na poczynania zarządu Boeinga, można dojść do wniosku, że
śmierć ponad 300 osób niczego ich nie nauczyła. Wszystko co robią, to
upychanie kolanem robionych pod presją czasu łat na oprogramowanie,
byleby samoloty szybko mogły wznieść się na niebo. Nie załapali chyba,
że cała afera spowodowała, że nawet patrząca dotąd przez palce na ich
poczynania FAA, tym razem nie da się zrobić w konia. Jej prestiż został
przez tę aferę mocno naruszony i nie może sobie pozwolić na kolejną
kompromitację. Do tego regulatorzy z innych krajów prowadzą już własne,
niezależne badania i nie zaakceptują w ciemno opinii wydanej przez
amerykańską agencję."

Jak widać firma dalej jest w czarnej du.ie :)


--
Janusz

heby
Guest

Thu Apr 30, 2020 7:08 pm   



On 30/04/2020 20:15, Janusz wrote:
Quote:
aribus okazuje się zastosował podobny myk tyle że dał 7 komputerów Smile

Najwidczniej na tym hardware można było polegać.

Mirek
Guest

Thu Apr 30, 2020 9:29 pm   



On 30.04.2020 10:09, Adam wrote:

Quote:
Router Drayteka wstaje w kilka, góra kilkanaście sekund.

A konkretnie który model?
Bo one raczej na Linuxie są, więc to akurat nie najlepszy przykład do
tematu.

--
Mirek.

Mirek
Guest

Thu Apr 30, 2020 9:44 pm   



On 30.04.2020 08:40, heby wrote:

Quote:
Na małych biblitekach TCP które nie wymagają Linuxa. Wstawał by w
milisekundę, używałby mniejszego CPU, byłby łatwiej ogarnialny
softwareowo, ufałbym mu bardziej.


Jak nie potrzebujesz uwierzytelniania, szyfrowania, odporności na różne
dziwne sytuacje w sieci i potrzebujesz to resetować co kilka sekund to ok.

--
Mirek.

Goto page Previous  1, 2, 3, 4  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Stary komputer nowy samolot - to tylko pozornie OT

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map