On 30.04.2020 10:05, heby wrote:

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

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

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