🚀 go-pugleaf

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