On 07/01/2021 22:13, Maciej Sobczak wrote:
>>> Nie wiem, czy są. Ale wiem, że NVIDIA kupiła ARMa.
>> I nagle zmieniła politykę czy tylko wyciska dalej co się da z licencji?
> A już jest powód, żeby zmieniać politykę?

Skoro tak, to aktualny właściciel jest mało ważny.

>> Ależ zobaczymy. Nie można też wykluczyć że nvidia ma interes w NIE
>> dawaniu rdzeni ARMa konkurencji.
> Może tak być. Ale, ale... Kto jest ich konkurencją?

AMD. I za chwile chińczycy.

> Producenci embedded?

Niektórzy. Na ten przykład nvidia produkuje SoC oparte o różne dziwne
technologie. "Dokładnie takie same" SoC produkują chińczycy i sprzedają
je kilka razy taniej. Stąd te wszystkie tanie adnroid boxy.

> No dobra. To po co komu ten RISC-V?

Aby się urwać od ARMa. Aby mieć więcej mocy z wata. Aby mieć źródło pod
kontrolą i nie patrzeć czy za 2 lata zapukają prawnicy albo czy kupi to
Orlen i udostepni licencje pod warunkiem biało-czerownej obudowy i
grania Mazurka po podłączeniu zasilania.

> Na rynku, na którym NIC nie jes darmowe, NIKT nie oczekuje, że będzie taniej.

Taniość jest trzeciorzędna w niektórych wypadkach. A w innych nie.
Różnie bywa.

Taki producent odpowiednika STM32 ale opartego o rdzeń RISC może ściąć
cenę swoich cpu o dolara, powiedzmy. A to robi różnicę kiedy ich
sprzedajesz setki milionów, choćby jako sterowniki dildo i szczoteczek
do zębów.

> Po prostu się wlicza koszty w cenę produktu, na całej długości łańcucha.

Zależy co produkujesz. Jeśli toalety na stacje kosmiczne to możesz sobie
wliczać w koszty wszystko. Ale jeśli mikrokontrolery do szczoteczek do
zębów, to już liczysz centy. Różnie.

> Więc kogo obchodzi RISC-V?

Różnych ludzi z różych powodów. ARM to taki vendor-lockin w branży. W
dodatku aktywnie zniechęca stosując agresywną politkę patentową i
spuszczając prawników z łańcucha jak ktoś za głośno protestuje.

>> POSIX nie jest "bardzo dobrą abstrakcją" bo sam jest bardzo niedobry z
>> punktu widzenia embedded. To nie do tego.
> Uuu, to nie dość, że już poobrażałeś wszystkich (że psychiczni) to teraz jeszcze
POSIX niedobry.

POSIX w embedded nie jest dobry. Pewnie, że można postawić Linuxa i
nazywać to "embedded" ale to tylko taki mały komputer w małym
pudełeczku. Z embedded to ma tyle wspólnego na ile to pojęcie napompujemy.

Osobiscie wolałbym aby mój respirator niekoniecznie pracował na POSIXie.

> Czy nie ustaliliśmy już w tych dyskusjach, że tylko my dwaj robimy dobrze?

Nie. Ja widzę świat tylko przez moje doświadczenia, które są zasadniczo
mocno inne niż innych, najzwyczajniej pracuje w dośc specyficznym i
hermetycznym miejscu. Nie twierdze że mam monopol na poglądy, ale zawsze
bedę tuptał nogą jak będe słyszał że profesjonalizmem albo niemożnością
tłumaczy sie dziadostwo, szczególnie w kodzie.

>> używanie POSIXa w embedded jest komplenie bez sensu w
>> większosci zastosowań. FreeRTOS składa się z wątków, schedulera, jakiś
>> mutexów i tyle.
> No, i każda z tych rzeczy może mieć API POSIX. Bo niby w czym funkcja
xSemaphoreCreateMutex jest lepsza od pthread_mutex_init?

Bez znaczenia. Jeśli masz na to abstrakcję może sobie pracować na
AmigaOS. Ale musisz mieć abstrkację. Masz, prawda? Jak byś inaczej mógł
to testować. Wiec musisz mieć.

> Ja wiem, w czym jest gorsza. Otóż kod działający na POSIX nie kompiluje się na
FreeRTOS.

Nic dziwnego, skoro nie ma abstrakcji na system. Mój sie kompiluje na
posixie i na windowsie, tanim kosztem mogę dodać MacOsa. FeeeRTOSa nie
dodam bo nie ma potrzebnego hardware na platformach FreeRTOSowych. Czy
to czary?

> I trzeba robić "abstrakcje", co jest o tyle idiotyczne, że POSIX już jest
abstrakcją.

Nie jest abstrakcją na różne OSy. Jest tylko abstrakcją od hardware i
konkretnych implementacji OSu. NIE jest abstrakcja od systemu, bo sam
jest tym konkretnym systemem.

Zaznajom się np. z Qt. To jest abstrakacja na system. Średnia, ale
bardzo skuteczna, POSIX jest tylko jednym z paru implementacji możliwych
do użycia.

> No ale po co projekty mają być tanie, skoro mogą być drogie?

To nigdy nie działa w ten sposób. Koszt pisania z abstrkacją jest
mikroskopijnie wyższy niż refaktorowania tony g...na napisanego przez
team który wszędzie wciskał pthread_mutex razem z jedgo wszystkimi
cechami specjalnymi.

>> POSIXa też się zawija w abstrakcję w swoim kodzie.
> No właśnie się pytam, po co? Rozumiem, że rejestr w mikrokontrolerze do mrugania
LEDem można opakować, bo w każdym uC się mruga inaczej. Ale po co zawijać coś, co już
jest przenośną, niezależną od implementacji abstrakcją? To jest chore.

POSIX nie jest przenośny. Istnieje masa systemów z nim niezgodnych.

Zaś wszystkei zgodne maja mała użytecznośc w embedded. POSIX jest do
stacji roboczych a nie migania diodami lub kontroli oddechu. Naprwadę,
nie potrzebujesz parentpid i fopen w respiratorze.

>> Abstrakcji nie szukasz w 3-rd party. Abstrakcję robisz u siebie.
> Albo korzystam ze standardów. Takim standardem jest POSIX.

Dalej nie pojmujesz że posix nie jest abstrakcją. Abstrakcją jest
MyTools::MyMutex a nie pthread_mutex. Abstrakcją może byc też Qt, ale to
jest abstrkacja 3rd-party i niekoniecznie chcesz być zależny od decyzji
biznesowych Qt.

>> Własnie
>> po to aby od detali posix-nie posix nie uzależniać się w swoim kodzie,
>> poza adapterami do konkretnego OSu.
> Dalej mylisz pojęcia (żadna nowość, w sumie):
> https://en.wikipedia.org/wiki/POSIX
> "The Portable Operating System Interface (POSIX) is a family of standards specified
by the IEEE Computer Society for maintaining compatibility between operating
systems."

Przeczytałeś cos nie na temat. To jest abstrkacja do konkretnej rodziny
systemów. W tej rodzinie nie ma FreeRTOSa ani Widnowsa CE, a są one w
embedded używane.

Posix to NIE jest abstrakcja na systemy operacyjne. Co najwyżej na wąską
grupę bardzo podobnych systemów, o nikłej uzytecznosci w embedded.

Abstrakcja na systemy operacyje jest wysokopoziomowa. Tam gdzie nie
wiadomo czy mutex to int, handle, pointer czy foo.

> A teraz mam robić abstrakcję do tej abstrakcji, bo każdy januszowy RTOSik musi
koniecznie mieć ourMutexCreate()?

Januszowe RTOSiki są popularniejsze od grażynowych posixów.

Pewnego dnia januszowy RTOSik zostanie zamieniony na mirkowy CE bo taki
się zwidziało właścicielowi biznesu. Jesli Janusz nie był iditiotą to
zmiana na to CE może być mało bolesna. Jesli był idiotą to właśnie
przewalają przez miesiące biliony ton kodu szukając tych wszystkich
problemów sepcyficznych dla FreeRTOSa.

Co kto woli. Przecież nie ma problemu aby pisać nieprzenośnie, jesli to
jednorazowy projekt.

Pamiętaj o czym rozmawiamy: stwierdziłeś że zmiana procesora to nie
tylko zmiana makefile, tylko bardzo ciezka rzecz.

No więc to cieżka rzecz, jak się ma dziadowski kod.

>> Nie jest przenośny. Jest vendor-lockin. Tutaj vendorem jest POSIX
> Czyli dalej, uporczywie, mylisz pojęcia. POSIX nie jest vendorem.

Bo to nie ma znaczenia. Może być OS-Lockin jeśli już takim purystą
jesteś? Co to ma za znaczenie? Jesteś foo-lockin. Czy to interfejs,
bibliteka 3rd-party czy procesor. Wsio rawno z punktu widzenia problemu.

> Natomiast POSIX jest standardem, dzięki któremu programy łatwiej[*] jest przenosić
z jednego OSa na drugiego.

W obrębie mało przydatnej w embedded rodziny OSów.

Tak wiem, zaraz ktoś wyjmie z kieszeni jakiś przykład że gdzieś stosują
Linuxa w embedded. Owszem. Gdzieś stosują.

>>> Klikasz w złym miejscu. https://www.apple.com/pl/mac-pro/specs/
>>> Jak dla mnie, ma wystarczająco dużo złącz.
>> I nagle przestają działać.
> USB-C przestanie działać?

Wyobraź sobie że tak się właśnie stało. Trach i po aktualizacji OS kilka
tysięcy dolców na Twoim biurku zamieniło się w cegły.

Oczywiscie nie złacze. Tylko pewna cecha tego złacza, pozawlająca na
przesyłanie obrazu. Czysto "softwareowa" awaria, nie przypadkowa. Nawet
się nie zainteresowałeś co się stało, prawda? Podpowiem ponownie:
DisplayLink. Poczytaj. To nawer patriotyczna firma jest.

Nie nie, oni dalej będa kupować Apple, to religia.

> Bo chyba chodziło o to, że w Macu jest mniej złącz, niż w pececie? Czy o co
chodziło?

Nie. Chodziło o to że cwaniaczki od Apple wycyckały pewnego wieczoru
tysiące "profesjonalistów" którzy podpinali zewnątrzne monitory do
swoich laptopów myśląc że uzyskują w ten sposób profesjonalne narzedzie
do dicking-around. I ktoś wyłaczył światło. Bez słowa. I to nie jest awaria.

>>> Nie zrozumiałeś. Pluginy do obróbki dźwięku albo obrazu (albo video) nie są
pisane w Pythonie.
>> Nie są, a Mac przeskoczył na ARMa i reszta 3rd-party zrobiła to chwile
>> potem.
> Nie, nie zrobiła.

Wiec photoshop nie działa na M1 i tracą pieniądze? Serio, myslisz że
będzie to trwało bardzo długo? Oni te swoje pluginy kompilowali w
popłochu na ARMy jak tylko Apple pierdło coś w temacie ARMa.

> I dlatego Apple ma w ofercie obie platformy *równocześnie*. Bo naprawdę nie da się
przekompilować cudzego kodu.

Bo taki system dystrybucji aplikacji: z wysypiska. Ale spokojnie, da sie
skompilować cudzy kod. Cudzymi rękami właśnie. Działa. Po prostu patrz
jak robią to firmy które straciły by pieniądze gdyby tego nie zrobili
zawczasu.

>> Rozmawiamy o embedded i zmienach embedded cpu.
> No i ja dalej tej zmiany w najbliższym czasie nie widzę.

Nie widzisz, bo też ten rynek nie jest do wygooglania. To jest coś
głęboko na poziomie aplikacji i narzędzie niedostepnych dla Kowalskiego,
dziejace się w tle, zasłonięte NDA.

> Po prostu będzie jeszcze większy bałagan.

Raczej dodatkowy kompilator do makefile.