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

Zbych
Guest

Thu Apr 30, 2020 7:33 am   



On 30.04.2020 08:45, heby wrote:
Quote:
On 29/04/2020 23:11, Zbych wrote:
A tak konkretnie to np. interfejs Renault Clip.
No i dalej nic o tym dupnym Corteksie.

Bo to było o FPGA.

Ale ja nie pytałem o FPGA.

Quote:
ceny spadają. Miałem w ręku fabryczny konwerter rs485 na ethernet. W
środku miał linuxa (podobno). Od podpięcia zasilania do zadziałania
potrzebował koło 30 sekund. Uwierzyłem na słowo w tego Linuxa, nijak
inaczej tego nie dało się wytłumaczyć.
I powinieneś się cieszyć, że masz tam porządnie napisany stos tcp,
który przeszedł niejeden chrzest bojowy a nie kolejne dzieło
wystrugane na kolanie.

Innymi słowy aby mieć porządny stos TCP/IP musisz mieć solidny procesor
z MMU, kilkadziesiąt MB biblitek do obsługi preemptive mutitaskingu,
filesystemu, logowania, praw dostępu, obsługi eventów, oopsy do kompletu
i koniecznie jakiegoś backdoora. I to wszystko aby przesłać kilka bajtów
z lewa na prawo.

Jeśli ten procesor i RAM kosztuje grosze to czemu nie? Wolę mieć
przetestowany soft, który pracuje na milionach serwerów 24/7 i który nie
klęknie po dostaniu kilku niezakończonych handshaków, albo stada
pofragmentowanych pakietów. A także taki, który będzie można rozbudować
o szyfrowanie transmisji, VPN jeśli będzie to konieczne.

heby
Guest

Thu Apr 30, 2020 8:05 am   



On 30/04/2020 09:33, Zbych wrote:
Quote:
Innymi słowy aby mieć porządny stos TCP/IP musisz mieć solidny
procesor z MMU, kilkadziesiąt MB biblitek do obsługi preemptive
mutitaskingu, filesystemu, logowania, praw dostępu, obsługi eventów,
oopsy do kompletu i koniecznie jakiegoś backdoora. I to wszystko aby
przesłać kilka bajtów z lewa na prawo.
Jeśli ten procesor i RAM kosztuje grosze to czemu nie?

Ponieważ każda z tych zbędnych warstw wprowadza dodatkowe miejsca gdzie:
a) czają sie błędy
b) nie da się czegoś zweryfikować
c) zwiększają czasy reakcji
d) zwiększają złożoność setki razy powyżej spodziewanej

W sytuacji gdy chcesz to wsadzić do urządzenia podlegającego jakiejś
certyfikacji każda z tych rzeczy jest kłopotliwa bądź niemożliwa do
przepchnięcia.

Quote:
Wolę mieć
przetestowany soft

Czyli Linux odpada. Chyba że zakładasz że "przetestowany" oznacza milion
instalcji Ubuntu do oglądania porno na pecetach. Obawiam się że
"przetestowany" może nie dotyczyć konkretnego niszowego rdzenia uC.

Quote:
, który pracuje na milionach serwerów 24/7

A one zaś wszystkie pracują na Twoich mikrokontolerach ...

Zaznaczam że fakt odpalenia się Linuxa na jakimś rdzeniu CPU nie oznacza
że będzie "przetestowany". W zasadzie błedy krytyczne spotykane są do
dzisiaj, a im mniej popularna platforma tym jest ich więcej. A że
platformy dla linuxa są skomplikowane z definicji, no to wiadomo że
łatwo nie będzie ...

Z drugiej strony jeśli weźmiesz jakiś procesor o prostej konstrukcji,
szanse na błędy w obsłudze hardware maleją. Możesz pisać na odpierdol i
zakładać że jak coś padnie to się najwyżej zrestartuje, ale są miejsca
gdzie jak coś padnie to spadnie. Na da się pisać bezbłednie, ale znamy
metody eliminacji błędów na etapie produkcji kodu, zdecydowana większosc
z nich nie jest w stanie ogarność złożonych systemów jak linux.

Quote:
i który nie
klęknie po dostaniu kilku niezakończonych handshaków

Za to klęknie bo kto zapomniał wyłaczyc loga aż zajechało cały
filesystem. Albo klęknie bo masz buga w preemptive multitaskingu który
wysoczył dopiero po 40 miesiącach nieprzerwanej pracy bo się hardwareowy
licznik przekręcił. Albo okazało się że to przerwanie nigdy nikomu nie
przyszło w tym samym momencie co operacja na Flashu, a Ty jesteś
pionierem. Możesz pozerkać na grupy dysusyjne OpenWRT gdzie ludzie
miewali dokładnie takie zabawne problemy z tym "przetestowanym linuxem"
jak przerwania rebootujące system, problemy z koherencją cache itd itp.
I oni w zasadzie implementują linuxa na takich małych pizdrykach, SoC. I
jakimś trafem fakt że milion instancji Ubuntu do oglądania porno nijak
nie poprawia stabilności jajka w SoC Atherosa.

Quote:
, albo stada
pofragmentowanych pakietów.

Co akurta jest oczywistym problemem do rozwiązania jak się pisze stos
TCP. Oczywiście można napisać kiepski stos TCP. Ale szczęśliwie lata
60te w programowaniu minęły, teraz mamy techniki zapewniajace jakość i
pilnujące specyfikacji.

Quote:
A także taki, który będzie można rozbudować
o szyfrowanie transmisji, VPN jeśli będzie to konieczne.

Ale tu nie było konieczne. Ot, ktoś wsadził napisany na odpierdol w
perlu serwer tcp->rs485 i skasował za "nowoczesny design". Dzień jak co
dzień.

Adam
Guest

Thu Apr 30, 2020 8:09 am   



W dniu 2020-04-30 o 08:40, heby pisze:
Quote:
On 29/04/2020 22:57, Mirek wrote:
A co w tym dziwnego?

"Dzięki" linuxowi dodano przeogromną warstwę zbędnego software.

Zaznaczam że urządzenie ma otworzyć port TCP i przesyłać bajty z prawa
na lewo. I nic więcej. Nie ma tam nawet konfiguracji przez jakiegoś
weba, tylko stosuje się aplikację na komputer do zmian, a tych zmian
jest aż jedna: czy adres z dhcp czy stały.

To na czym byś to zrobił?

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.

To nie jest problem wyssany z palca, byłem przekonany że problem braku
działania jest w moim kodzie. Dopiero właściciel tego cuda oświecił mnie
że potrzebuje 30 sek na wystartowanie.

Coś podobnego widuję u siebie.
Router Drayteka wstaje w kilka, góra kilkanaście sekund.
Natomiast różne acery, tp-linki czy inne podobne potrzebują nierzadko
ponad dwie minuty, pomimo, że ich funkcjonalność jest kilkukrotnie
mniejsza od najprostszego drayteka.

Ostatnio, co zobaczyłem: iluminofonię robiło się na kilku tranzystorach.
Włączało się i działała natychmiast.
Teraz do tego zaprząga się komputery jednoukładowe albo inne dziwolągi.
Startuje to długo, pokazuje czasem nie wiadomo co, potrafi się zawiesić.


--
Pozdrawiam.

Adam

Zbych
Guest

Thu Apr 30, 2020 8:45 am   



On 30.04.2020 10:05, heby wrote:

Quote:
Z drugiej strony jeśli weźmiesz jakiś procesor o prostej konstrukcji,
szanse na błędy w obsłudze hardware maleją. Możesz pisać na odpierdol i
zakładać że jak coś padnie to się najwyżej zrestartuje, ale są miejsca
gdzie jak coś padnie to spadnie. Na da się pisać bezbłednie, ale znamy
metody eliminacji błędów na etapie produkcji kodu, zdecydowana większosc
z nich nie jest w stanie ogarność złożonych systemów jak linux.

Ostatnio oglądałem fajną prezentację włamania do SoC odpowiedzialnego za
deszyfrowanie strumienia video. W środku klon prostego 6502, któremu
wystarczyło wstrzyknąć kod do pamięci RAM i "potrząsnąć" trochę
zasilaniem, żeby się wykrzaczył i zaczął wykonywać ten kod z RAMu. Ta
sama sztuczka nawet na Cortexie-M0 ma małą szansę powodzenia, dzięki
wykrywaniu dostępu do nieistniejących adresów i dużej przestrzeni
adresowej. Nie wspominając już o większych prockach z MMU.

Quote:
I oni w zasadzie implementują linuxa na takich małych pizdrykach, SoC. I
jakimś trafem fakt że milion instancji Ubuntu do oglądania porno nijak
nie poprawia stabilności jajka w SoC Atherosa.

I oczywiście potrafisz udowodnić, że problemem była ta część linuksa,
która jest wspólna dla miliona instalacji ubuntu a nie specyficzna dla
SoC Atherosa?

Quote:
, albo stada pofragmentowanych pakietów.

Co akurta jest oczywistym problemem do rozwiązania jak się pisze stos
TCP. Oczywiście można napisać kiepski stos TCP. Ale szczęśliwie lata
60te w programowaniu minęły, teraz mamy techniki zapewniajace jakość i
pilnujące specyfikacji.

A także taki, który będzie można rozbudować o szyfrowanie transmisji,
VPN jeśli będzie to konieczne.

Ale tu nie było konieczne. Ot, ktoś wsadził napisany na odpierdol w
perlu serwer tcp->rs485 i skasował za "nowoczesny design". Dzień jak co
dzień.

To, że ty nie potrzebowałeś, to nie znaczy że producent tych
przejściówek nie ma klientów, którzy tego nie potrzebują.

Grzegorz Niemirowski
Guest

Thu Apr 30, 2020 8:58 am   



heby <heby@poczta.onet.pl> napisał(a):
Quote:
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 ...

OK, ale ja się do Linuksa nie odnosiłem tylko do tych nieszczęsnych
Cortexów. Nie mówimy też o miganiu diodą.
Nie uważam, żeby możliwość programowania bardziej wypasionego
mikrokontrolera miała prowadzić do przerośniętego i bardziej zabugowanego
kodu. Starszy, prostszy mikrokontroler ma różne ograniczenia, które
utrudniają programowanie, mogą zwiększać ryzyko błędu i wydłużają czas
tworzenia kodu.

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

heby
Guest

Thu Apr 30, 2020 9:08 am   



On 30/04/2020 10:45, Zbych wrote:
Quote:
Ostatnio oglądałem fajną prezentację włamania do SoC odpowiedzialnego za
deszyfrowanie strumienia video. W środku klon prostego 6502, któremu
wystarczyło wstrzyknąć kod do pamięci RAM i "potrząsnąć" trochę
zasilaniem, żeby się wykrzaczył i zaczął wykonywać ten kod z RAMu. Ta
sama sztuczka nawet na Cortexie-M0 ma małą szansę powodzenia, dzięki
wykrywaniu dostępu do nieistniejących adresów i dużej przestrzeni
adresowej. Nie wspominając już o większych prockach z MMU.

Przepraszam Cie, ale to jest możliwe w prawie każdym CPU. Nawet w super
wypasionych x86 z super bezpiecznymi mechanizmami chronienia przed
wykonywaniem kodu z ram wymyślono np. obejście o nazwie
return-oriented-programming które jest absurdalnie ale działające i daje
konkretne efekty (jak hacking PS4). Ba, dzięki tej technice można
wykonywac "kod z ramu" majac do czyniena z architekturą która tego nie
potrafi sprzętowo (Harvard). Niezłe jaja nie?

Serio, dajesz wiarę że komplikacja CPU powoduje że coś nie da się
zhackowac? Że większa przestrzeń adresowa przed czymś chroni? Że, w
końcu o to zapytam, w duperelowatej przelotce RS485, której pies z
kulawą nogą nie będzie hackował, to w ogóle POTRZEBNE i jest argumentem
za uzyciem linixa czy Cortexa M500? Urządzenia oparte o Linxua hackuje
się łatwiej tylko dlatego że można wykorzystać znane podatności w
Linuxie, można znaleźć backdoory zostawiane przez idiotów w procesie
produkcji, można znaleźć zabezpieczenia które nia mają sensu itd itp.

W przelotce użyto linuxa bo była zrobiona na odpierdol. Nikomu on tam w
środku potrzebny nie jest, przelotka nie ma adnych zaawansowanych
funkcji poza otwarciem portu TCP i przerzucaniem bajtów z lewa na prawo.

Quote:
I oni w zasadzie implementują linuxa na takich małych pizdrykach, SoC.
I jakimś trafem fakt że milion instancji Ubuntu do oglądania porno
nijak nie poprawia stabilności jajka w SoC Atherosa.
I oczywiście potrafisz udowodnić, że problemem była ta część linuksa,
która jest wspólna dla miliona instalacji ubuntu a nie specyficzna dla
SoC Atherosa?

Tak, to jest ten mały fragment zajmujący się przyjmowaniem przerwań,
implementujący sekcje krytyczne, zajmujący się multitaskingiem,
specyficzny dla każdego rdzenia i bardzo często specyficzny dla
konkretnego SoCa. Do dzisiaj w tym małym, duperelowatym fragmencie kodu
czaiły się błedy, nawet na tej super wypasionej, przetestowanej
pornolami, platformie x86. Dasz wiarę?

Quote:
Ale tu nie było konieczne. Ot, ktoś wsadził napisany na odpierdol w
perlu serwer tcp->rs485 i skasował za "nowoczesny design". Dzień jak
co dzień.
To, że ty nie potrzebowałeś, to nie znaczy że producent tych
przejściówek nie ma klientów, którzy tego nie potrzebują.

Oczywiście, zawsze jest rynek dla dziadowskich rozwiązań, szczgólnie ze
sprawnym marketingiem. Oby to nie był rynek dla rozwiązań w lotnictwie.

heby
Guest

Thu Apr 30, 2020 9:16 am   



On 30/04/2020 10:58, Grzegorz Niemirowski wrote:
Quote:
Nie uważam, żeby możliwość programowania bardziej wypasionego
mikrokontrolera miała prowadzić do przerośniętego i bardziej
zabugowanego kodu.

Bierzesz wypasonego ARMa który ma MMU. Na dzien dobry dostajesz w łeb
sporką komplikacją kodu wynikajacą z pamieci wirtualnej. Możesz jej nie
używać, oczywiscie, ale co jesli urządzenia I/O są mapowane przez jakieś
MMUIO? Nagle musisz napisać dużo cholerne skomplikowanego kodu tylko po
to aby to obsługiwać. Coś co dawniej robione jako PORTD |= FOO; dzisiaj
urasta do kilkuset linijek zabawy w dostęp przez MMU, najpewniej z bugami.

Idź teraz i wlacz z przetestowaniem tego invitro.

Quote:
Starszy, prostszy mikrokontroler ma różne
ograniczenia, które utrudniają programowanie, mogą zwiększać ryzyko
błędu i wydłużają czas tworzenia kodu.

To wszystko zależy ile kodu, boiler plate, niesie ze sobą architektura.
Im większy CPU tym trudniej pisać to co chcesz bez zajmowania się
pierdołami dookoła. W skrajnych przypadkach, jak mikorontrolery na x86,
trzeba było się zajmować całym tym debilizmem jak tryby real, protected,
long, short i h... wie co jeszcze, żeby w końcu po kilku tygodniach
zamigać diodą.

Rozumiesz że każda linijka kodu, kazdy if, każdy zapis do rejestru,
każda akcja globalna to jest nowa ścieżka testowania i generuje coraz
trudniejsze w audytowaniu środowisko?

Jak ktoś miga diodą to pal sześć. Jak to lata samolotem to NIE chcę
skomplikowanego cpu na którym się pisze łatwiej. Bo się cieżej
*testuje*. Dziwne, że wiele osób zapomina o tym, że kod krytyczny
podlega restrykcyjnemu testowaniu a popieprzone architektury nie
usprawniają tego procesu. Wręcz uniemożliwiają w skończonym czasie.

Pawel \"O'Pajak\"
Guest

Thu Apr 30, 2020 10:12 am   



W dniu 2020-04-30 o 02:28, antispam@math.uni.wroc.pl pisze:
Quote:
Mozna powiedzic ze technicznie glownym problemem bylo oprogramowanie,
np. korekta miala byc rzedu 2 stopni a oprogamowanie bez zastanowienia
walilo 70.

Generalnie Benek uchodził za takiego, co uważa, że decyzje podejmuje
pilot, z kolei Arbuz miał filozofię, że pilot ma jedynie podziwiać
dyskotekę w kokpicie. I wszystko było dobrze, do czasu, aż Benek
postanowił pójść w ślady Arbuza.
No cóż, stara zasada serwisantów mówi: Jeśli coś dobrze działa, to nie
poprawiaj. Coś mi się zdaje, że nie byłby to wielki problem "wyczucie"
nowego samolotu bez tego felernego systemu.

Pozdroofka,
Pawel Chorzempa
--
"-Tato, po czym poznać małą szkodliwość społeczną?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
******* >>> !!! UWAGA: ODPOWIADAM TYLKO NA MAILE:
moje imie.(kropka)nazwisko, ten_smieszny_znaczek, gmail.com

Marek
Guest

Thu Apr 30, 2020 10:23 am   



On Thu, 30 Apr 2020 11:08:44 +0200, heby <heby@poczta.onet.pl> wrote:
Quote:
return-oriented-programming które jest absurdalnie ale działające i
daje

Nie rozumiem jak to działa. Na stosie podkładamy adres wybranej i
pasującej instrukcji (gadżet) z istniejącej przestrzeni
(kodu/liba/whatever). Ale co dalej? Przecież CPU zrobi skok tam,
wykona tą instrukcje ALE pójdzie dalej. Jak niby połączyć w sensowną
całość (jeden kontekst) instrukcje które się chce wykonać?

--
Marek

heby
Guest

Thu Apr 30, 2020 10:47 am   



On 30/04/2020 12:23, Marek wrote:
Quote:
On Thu, 30 Apr 2020 11:08:44 +0200, heby <heby@poczta.onet.pl> wrote:
return-oriented-programming które jest absurdalnie ale działające i daje

Nie rozumiem jak to działa. Na stosie podkładamy adres wybranej i
pasującej instrukcji (gadżet) z istniejącej przestrzeni
(kodu/liba/whatever). Ale co dalej? Przecież CPU zrobi skok tam, wykona
tą instrukcje ALE pójdzie dalej. Jak niby połączyć w sensowną całość
(jeden kontekst) instrukcje które się chce wykonać?


Gadżet wygląda tak
[...]
-2. kod
-1. kod
0 adres wejścia
1. kod
2. kod
3. kod
4. return

Na stosie układasz listę adresów wejścia w rózne fragmenty istniejącego
kodu. Powoduje to wykonywanie się kawałków kodu, następnie dzięki return
nastepuje *uzyteczny* skok do innego gadżetu, bo return jest uzywany
jako jump. I tak w kółko, każdy "return" powoduje skok dalej, do
następnego. Wszystko gadety połaczone sa w jeden łańcuch, return
działają jak jump.

Marek
Guest

Thu Apr 30, 2020 11:05 am   



On Thu, 30 Apr 2020 12:47:08 +0200, heby <heby@poczta.onet.pl> wrote:
Quote:
Gadżet wygląda tak
[...]
-2. kod
-1. kod
0 adres wejścia
1. kod
2. kod
3. kod
4. return

Nie rozumiem, przecież idea mówi o tym, że gadżetem jest JEDNA
instrukcja (pod adresem 0 j.w.) + return a w/w instrukcje 1. 2....
do return to instrukcje w dalszym fragmencie np. liba ALE z innego
kontekstu, które mogą popsuć to co się zrobi "at 0".

--
Marek

heby
Guest

Thu Apr 30, 2020 11:31 am   



On 30/04/2020 13:05, Marek wrote:
Quote:
Nie rozumiem, przecież idea mówi o tym, że gadżetem jest JEDNA
instrukcja

Nie. gadżetem jest zakończenie funkcji zawierajace użyteczny kod, razem
z return. Może zawierać jedną instrukcję i return, może zawierać kilka
instrukcji (z czego uzyteczna instruckja bądź instrukcje mogą być w
środku bezuzytecznych) i return.

Ogólnie to jest dowolna, przydatna, końcówka funkcji. Nie ma okreslonego
ile zawiera instrucji. Ile potrzebujesz, jeśli jest użyteczna.

Celem zazwyczaj jest przestawienie jakiegoś bitu we właściym miejscu
które pozwoli z normalnego kodu na dostęp gdzieś dalej. Często te
"liniowe" wykonywanie kodu może być wystarczające do tak prostych
zastosowań. Przy odpowiednich gadźetach możesz zrobić wszystko,
zazwyczaj gadżety są turing-complete.

Quote:
return to instrukcje w dalszym  fragmencie np. liba ALE z innego
kontekstu, które mogą popsuć to co się zrobi "at 0".

Dobieranie gadżetów tak by wzajmenie nie niszczyły sobie danych na
których pracujesz jest istotą tej sztuczki. Z tego co słyszalem jest
jakiś dodatek do Ghidra (a może do ida pro? nie pamietam) wspomagający
wyszukiwanie gadżetów w istniejącym kodzie.

Polecam:

https://cturt.github.io/ps4.html

Zbych
Guest

Thu Apr 30, 2020 11:48 am   



On 30.04.2020 11:08, heby wrote:

Quote:
Serio, dajesz wiarę że komplikacja CPU powoduje że coś nie da się
zhackowac? Że większa przestrzeń adresowa przed czymś chroni?

Tak, wierzę że dołożenie zabezpieczeń sprzętowych i programowych do CPU
zwiększa szansę na wykrycie błędu i reakcję.

Równie dobrze mógłbyś mnie przekonywać że komplikowanie konstrukcji
windy przez dokładanie hamulców bezpieczeństwa jest bez sensu bo:
1. komplikuje konstrukcję i zwiększa ilość testów
2. hamulce mogą mieć błędy konstrukcyjne
3. hamulce marki Linux używane w windach towarowych to już w ogóle
tragedia, bo można je zablokować śrubokrętem. Co najwyżej można użyć
drewnianego klina wystruganego w garażu, bo pan Mieczysław pokrył go w
100% testami i ma na to papier.

heby
Guest

Thu Apr 30, 2020 12:14 pm   



On 30/04/2020 13:48, Zbych wrote:
Quote:
Serio, dajesz wiarę że komplikacja CPU powoduje że coś nie da się
zhackowac? Że większa przestrzeń adresowa przed czymś chroni?
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.

Quote:
Równie dobrze mógłbyś mnie przekonywać że komplikowanie konstrukcji
windy przez dokładanie hamulców bezpieczeństwa jest bez sensu bo:
1. komplikuje konstrukcję i zwiększa ilość testów
2. hamulce mogą mieć błędy konstrukcyjne
3. hamulce marki Linux używane w windach towarowych to już w ogóle
tragedia, bo można je zablokować śrubokrętem. Co najwyżej można użyć
drewnianego klina wystruganego w garażu, bo pan Mieczysław pokrył go w
100% testami i ma na to papier.

Problem polega na tym że porówniae powinno być pociągnięte dalej:

Pan Mieczysław potrzebuje hamował koło zamachowe w swoim stołowym modelu
silnika parowego.

Ma do wyboru użyć kawałka drewna, co przetestowano już na milion sposóbo
albo
wybrać hamulec brake-on-wire na bazie linuxa na czymś z okolicy Ryzena.

Pan Mieczysław wybiera Ryzena. Bo kto by nie chciał nowocześnie?

Natomiast gdybyś się nieco postarał, to porównanie prawidłwoe jest inne:

Mieczysław LTD od 30 lat produkuje sterowniki hamulców ręcznych do
samolotów. Hamulce są oparte o jakiegoś starego MIPSa z 4kB RAMu, ale za
to są odporne na promieniowanie kosmiczne, zweryfikowane formalnie na
poziomu software i hardware dzieki czemu dopuszczone do latania
stosownymi certyfikatami, w dodatku pracują reduntantnie a ich
konstrukcja umożliwia ekslopatację przez kilkadziesiąt lat bez
sewisowania, a z uwagi na to że kod jest niezmienny, ustalono również że
będzie wypalony w ROMie dzięki czemu nie straszne mu rozbłyski gamma,
pioruny czy nawet toksyczne wydzieliny mniej kontrolowanego końca
przewodu pokarmowego. Dzięki tym prymitywnym urządzeniom każdy samolot
może bez problemu zahamować zaraz po zaciągnięciu mimo że ich moc
obliczeniowa jest milion razy mniejsza niż w smarfonie od oglądania
porno dowolnego pasażera i troche siara.

heby
Guest

Thu Apr 30, 2020 12:15 pm   



On 30/04/2020 14:14, heby wrote:
Quote:
skrutów

Łomatko! Przepraszam, jeśli ktoś opluł monitor.

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