> > 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ę? Ta nasza dyskusja na pewno takim powodem
nie jest.

> 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ą? Producenci embedded? Od kiedy?
Producenci embedded będą dla nich nowym dochodowym klientem a nie konkurencją.

> > i otwarte a projekty bardzo drogie. Ciekawe, nie?
> Nie, nic takiego nie istnieje jak "otwarte projekty darmowe" dotyczące
> rynku embedded. Ja nie mówie o miganiu diodą z RISC. Ja mówie o grubych
> graczach którzy projektują choćby dla lotnictwa czy medycyny. Tam nie ma
> nic za friko. NIC.

No dobra. To po co komu ten RISC-V?
Na rynku, na którym NIC nie jes darmowe, NIKT nie oczekuje, że będzie taniej. Taka
dziwna, rozumiesz, społeczność.
Po prostu się wlicza koszty w cenę produktu, na całej długości łańcucha. Ostatecznie
i tak płaci podatnik, jeśli mówimy o tych konkretnych branżach. Więc kogo obchodzi
RISC-V?

> 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.
Czy nie ustaliliśmy już w tych dyskusjach, że tylko my dwaj robimy dobrze?

> 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?
Ja wiem, w czym jest gorsza. Otóż kod działający na POSIX nie kompiluje się na
FreeRTOS. I trzeba robić "abstrakcje", co jest o tyle idiotyczne, że POSIX już jest
abstrakcją. No ale po co projekty mają być tanie, skoro mogą być drogie?

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

> Abstrakcji nie szukasz w 3-rd party. Abstrakcję robisz u siebie.

Albo korzystam ze standardów. Takim standardem jest POSIX.

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

Ostatnie 4 słowa są kluczowe.
A teraz mam robić abstrakcję do tej abstrakcji, bo każdy januszowy RTOSik musi
koniecznie mieć ourMutexCreate()?

> Nie jest przenośny. Jest vendor-lockin. Tutaj vendorem jest POSIX

Czyli dalej, uporczywie, mylisz pojęcia. POSIX nie jest vendorem. Vendorem jest np.
Texas Instruments. Albo np. Ja&Szwagier Sp. z o.o. Natomiast POSIX jest standardem,
dzięki któremu programy łatwiej[*] jest przenosić z jednego OSa na drugiego.

[*] Co oczywiście nie przeszkadza OSom konkurować parametrami albo ficzerami, ani
programom korzystać z ich unikalnych ficzerów. Tylko że wtedy programy stają się
nieprzenośne na życzenie, a nie z przymusu.

> > 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ć?
Może inaczej: któro ze złącz w powyższym Macu, które można znaleźć też na pececie
windowsowym, przestanie działać?
Bo chyba chodziło o to, że w Macu jest mniej złącz, niż w pececie? Czy o co chodziło?

> > 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. Właśnie w tym rzecz. I ten proces będzie trwał bardzo długo, dla
niektórych pewnie się nigdy nie skończy.
I dlatego Apple ma w ofercie obie platformy *równocześnie*. Bo naprawdę nie da się
przekompilować cudzego kodu.

> Rozmawiamy o embedded i zmienach embedded cpu.

No i ja dalej tej zmiany w najbliższym czasie nie widzę. Rozszerzenie oferty, może i
tak. Ale to żadna rewolucja, bo i tak wszyscy producenci mają różne alternatywy, dla
różnych segmentów rynku. Po prostu będzie jeszcze większy bałagan.

--
Maciej Sobczak * http://www.inspirel.com