zook

Jest wifi calling I inne takie. Ja nie jestem tylko pewien czy standart wifi przewiduje odpowiednio szybkie przełączenie między stacjami 'bazowymi'. W sensie jedziesz 60 km/h i czy telefon (czy czego akurat używasz) nadąży z przełączaniem między routerami tak żeby utrzymać stałe połączenie.

Otóż to, jeszcze operator mógłby dodać "drugą linię" dedykowaną pod obsługę takiego rozwiązania żeby użytkownik nie tracił nic z swojego pasma. Samo wifi też musiało by przejść pewną modernizację żeby umożliwić sprawne przełączanie między takimi improwizowanymi "stacjami bazowymi", bo o ile wiem nie jest to mocna strona wifi. Choć tutaj dość szybko moglibyśmy zapychać dostępne kanały wifi, i problem niejako zaczyna od nowa.

Trochę w swojej idei podobne jest do Node-RED. A może to Node-RED jest podobny do Simulinka.

Klucz szyfrujący jest generowany w oparciu o pin który ma maksymalnie o 16 cyfr to śmieszne mało. Tu przyznam że nie sprawdzałem w kodzie i wieże że człowiek który zgłosił to na githubie jako błąd nie robi nad w konia. Klucz nie obsługuje u2f czyli nie zabezpiecza posiadacz przez pushingiem. Największa przewaga kluczy sprzętowych nad menadżerami haseł jest to że klucz sprawdza czy program pytający o hasło ma w ogóle prawo zapytać o to hasło.

Gdzieś w kodzie mogą istnieć błędy które umożliwiają łatwe i nieautoryzowane zgranie bazy z kluczami. Z tego co widziałem na githubie są pewne zastrzeżenia co do skuteczności szyfrowania tej bazy, konkretnie chodzi o niskiej losowości hasło na podstawie którego generowany jest klucz szyfrujący. Edukacyjnie projekt jest jak najbardziej okey, ale do zastosowań 'produkcyjnych' czyli również do korzystania na co dzień niestety to się nie nadaje. Projektowi też brakuje tego co jest obecne w tego typu kluczach, czyli protokołu u2f który jest czymś więcej niż wysłaniem ciągu znaków przez wirtualną klawiaturę. Hasła ztego co zrozumiałem są hasłami a nie certyfikatami wygenerowanymi na podstawie między innymi unikatowego klucza sprzętowego, co też jest sporą wadą.

Muszę się zgodzić z Harnas, w dziedzinie bezpieczeństwa/szyfrowania nie ma miejsca na eksperymenty. Należy korzystać tylko z rozwiązań stworzonych przez ludzi którzy wiedzą co robią. Oczywiście projekt jest jak najbardziej godny polecenia, ale przy założeniu że nie będziemy go używać poza zastosowaniami edukacyjnymi czy podobnymi.

Package on package (PoP) jest powszechna metoda upychania komponentów w dzisiejszych czasach, nawet rpi było tak budowane do modelu 3, gdzie stwierdzono że chyba z powodów odprowadzania ciepła układ pamięci zostanie przeniesiony na drugą stronę płytki. Konkretnie chodzi o lutowanie pamięci nad SoC-iem ma to na celu zminimalizowanie opóźnień i wpływów innych układów do poziomu bliskiego temu który występował by w zintegrowanym układzie z jednoczesnym zachowaniem elastyczności związanej z wykonaniem i wykorzystaniem osobnych układów. To o czym ja piszę to dwie płytki PCB ułudzie jedna na drugiej. Nie jestem pewien czy ten typ konstrukcji jest gdzieś indziej powszechnie wykorzystany. https://www.techinsights.com/about-techinsights/overview/blog/apple-iphone-x-teardown/ Jedna metoda oczywiście nie wyklucza drugiej.

Bodajże w iPhone x i wyższych modelach zastosowano konstrukcje złożoną z dwóch płytek połączonych razem, tam oczywiście rozdzielone były 'powietrzem'. Nie jest też ten pomysł nowością robiło się tak płytki w technikum kiedy to ciężko było o jednostkowe profesjonalnie wykonane płytki o wielu warstwach. Czy jest to przyszłość branży? Raczej nie, bo taniej i łatwiej jest zrobić klasyczne pcb z wielu warstw. Być może metoda znajdzie swoje zastosowanie gdy warstwę pomiędzy dwoma płytkami wypełni się czymś innym niż trzecia. Dla hobbystów jest to jakaś metoda na zmniejszenie powierzchni płytki kosztem jej wysokości, bądź właśnie wykonanie w taki sposób 'obudowy'.

W innych dystrybucjach (czy raczej na sprzęcie innym niż rpi) powinny zadziałać. Czy to jest kwestia dosyć specyficznego procesu uruchamiania rpi? Osobiście nigdy nie miałem problemu z hasłem na malince tak więc brak mi doświadczenia w tym temacie.

su passwd pi Nie zadziała? Oczywiście w 'konsoli ratunkowej'. Jestem z dala od domu i nie mam nawet jak sprawdzić.

Po angielsku nie może być? Nie wiem co się zadziało, teraz powinno być bardziej zrozumiałe.

Reakcja ze strony SanDisk to nie wszystko, muszą pojawić się jeszcze sprzęty (telefony) z wyprowadzonym PCIe w czytniku. Zresztą karta pamięci i tak mija się z celem w Androidzie skoro i tak nie można instalować na karcie aplikacji.

Trochę nekromancji. Nie mogę się z tym zgodzić mikrokontrolery powszechnie mają w swoim rom-ie (nieistotne jest to czy jest to rom faktyczny czy wydzielona sekcja flash) różnica jest taka że w toku normalnego wykonywania kodu ten bootloader jest nieaktywny.

Ja tak planuje nabyć jak będzie dostępna, bardzo interesujące mnie połączenie. Ciekawe jestem tylko kilku szczegółów co do których jeszcze się nie doczytałem. Np. czy istnieje możliwość uruchomienia kodu na M4 z pamięci ram całego systemu. Zdaje się też że nie jest to raspberry pi z zintegrowanym uC tylko dokładnie na odwrót i ideowo to uC jest tu ważniejszy a rdzenie A mają służyć jako prosty sposób na stworzenie HMI.

Orientuje się ktoś czy w tego typu konstrukcjach istnieje jakiś w miarę nieskomplikowany sposób na dostanie się do rdzenia M4 i wykorzystanie go do 'czegoś swojego' ?