W dniu 2020-04-29 o 21:55, heby pisze:
> 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 :)
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

do góry

W dniu 2020-04-29 o 20:59, Janusz pisze:
> 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-ma
ja-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

do góry

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

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

do góry

On 30.04.2020 10:09, Adam wrote:

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

do góry

On 30.04.2020 08:40, heby wrote:

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

do góry

W dniu 2020-04-30 o 23:29, Mirek pisze:
> On 30.04.2020 10:09, Adam wrote:
>
>> 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.
>

Drayteki serii 28xx, 29xx.
Owszem, są (prawdopodobnie) na linuxie, ale embedded.

Sprzedaję je od wielu już lat. Sprzęt taki, że kładzie się u klienta i
zapomina na całe lata.


--
Pozdrawiam.

Adam

do góry

On 30/04/2020 23:44, Mirek wrote:
>> 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.

Własnie odkryłeś specyfikację przelotki ethernet<>rs485.

Ale zapomiałeś jeszcze że linux przydaje się również tam gdzie wymagane
są głupie backdory, długie czasy odpalania, leżace odłogiem megabajty
flasha, podatności o których jeszcze nie wiesz, tajemnicze problemy z
okolic oopsów itd itp. Więc projekt musiałby mieć to wszystko jeszcze w
specyfikacji.

do góry

On 01.05.2020 11:29, heby wrote:

> Ale zapomiałeś jeszcze że linux przydaje się również tam gdzie wymagane
> są głupie backdory,

Mnie się Linux przydaje wszędzie, a backdora ma pewno nie potrzebuję tam
gdzie nie masz uwierzytelniania i szyfrowania.

--
Mirek.

do góry

heby <h...@p...onet.pl> wrote:
> On 29/04/2020 23:38, Grzegorz Niemirowski wrote:
> > OK, czyli dajmy programistom procki z 1 kB ROM i 64 bajtami RAM. Wtedy
> > nie b?d? pope?nia? b??d?w.
>
> B?edy kt?re przysz?y z Linuxem, s? wyeliminowane, zostajesz z milion
> razy mniejsz? baz? kodu nad kt?rym masz kontrol?, kt?ry mo?na podda?
> audytowi, mo?na zweryfikowa? formalnie, pokry? w 100% coverage testowym.
> W przypadku aplikacji krytycznych to mo?e by? kluczowe do dopuszczenia z
> zastowoaniach typu "samoloty".
>
> Dodatkowo 64 bajty ramu to zdecydowanie za du?o na miganie diod?.
>
> Nie wykluczam jednak ?e gdzie? znajd? projekt migania odiod? na R-Pi. No
> bo czemu w zasadzie nie ...

Czesciowo sie z toba zgodze. Uzycie Cortexa A do migania dioda
to przesada. Do prostego migania dioda sa Cortexy M. Cortexa A uzywa
sie jak trzeba diode wlaczac/wylaczac przez Internet

:)

--
Waldek Hebisch

do góry

On 01/05/2020 19:00, a...@m...uni.wroc.pl wrote:
> Cortexa A uzywa
> sie jak trzeba diode wlaczac/wylaczac przez Internet

Do tego używa się ESP8266 a nie jakiś mikrokontrolerów ! :)

do góry