🚀 go-pugleaf

On 06/01/2021 17:02, 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?

To że ktoś jest właścicielem nie zawsze powoduje jakiekolwiek widoczne 
efekty działania. Co najwyżej AMD szybciej wembeduje RISC-V w swoje SoC.

> 40B$ to jest wystarczająco dużo powodu, żeby spodziewać się sterowników do GPU dla ARMa i jednocześnie nie spodziewać się ich do RISC-V.

Ależ zobaczymy. Nie można też wykluczyć że nvidia ma interes w NIE 
dawaniu rdzeni ARMa konkurencji.

>>> Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich system operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do peryferiów.
>> Innymi słowy wziął vendor-lockin? Przecież pisałem, ze zdrowy psychicznie.
> Oczywiście. To są bardzo racjonalne decyzje. A firma, która lepi swój system z kilku niepasujących do siebie vendor-lockinów>, wcale nie jest przez to bardziej racjonalna. Do tego potrzebuje więcej taśmy klejącej i ma gorszy support. Sam pisałeś o "bardzo drogich projektach EDA" - one są drogie, bo?

Bo potrzebują drogich specjalistów, bardzo drogich ipcores, bardzo 
bardzo drogich narzędzi i skrajnie drogiego prototypowania.

> Wszystko darmowe

W EDA *NIC* nie jest darmowe. Nawej najgorsze g..no jest płatne 
niebotyczne pieniądze, niewspółmierne do tego co potrafi.

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

>> Dodam też, że komunikacja z takimi biblitekami musi być napisana przez
>> abstrakcję, którą można łatwo podmienić. Nie została napisana przez
>> abstrakcję? Mówiłam przeciez że zdrowych...
> Ależ oczywiście, że przez abstrakcję. Przecież TI-RTOS ma interfejs POSIX. To bardzo dobra

POSIX nie jest "bardzo dobrą abstrakcją" bo sam jest bardzo niedobry z 
punktu widzenia embedded. To nie do tego.

>  Szkoda tylko, że inne RTOSy tej abstrakcji nie mają

I nic dziwnego, 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.

POSIXa też się zawija w abstrakcję w swoim kodzie. Chcesz mieć pełno 
pthread_mutex czy może Foo::Mutex? I co jest większym vendor-lockin?

> i nie da się przenieść takiego "przenośnego" projektu na inne klocki

Bo jest bardzo źle napisany.

> , z innym RTOSem. Albo z innym stosem TCP.

Bo jest bardzo, bardzo źle napisany.

Abstrakcji nie szukasz w 3-rd party. Abstrakcję robisz u siebie. Własnie 
po to aby od detali posix-nie posix nie uzależniać się w swoim kodzie, 
poza adapterami do konkretnego OSu.

W razie zmiany OSu, zmieniasz adapter.

> Itd. Pacz pan, przenośny program, a nie da się przenieść.

Nie jest przenośny. Jest vendor-lockin. Tutaj vendorem jest POSIX, 
przeciekajacy do kodu.

> Same abstrakcje

Jeśli w kodzie logiki swojego programu używasz bezpośrednio POSIXa to 
nie jest to abstrakcja, tylko IMPLEMENTACJA pod konkretny OS. Chcesz 
zmienic na inny OS nie będacy posixem, jesteś w d..pie.

>, wszystko otwarte, a projekty dalej drogie. Ciekawe, nie?

Nie, najzwyczajneij gówniany kod. Możliwe że z założenia, nie każdy musi 
od razu być uniwersalny.

>> Tak wygląda rynek laptopów: snoby oglądające pornole. Szczególnie Apple,
>> ich kompytery migrują w kierunku kompletnie bezuzytecznych do
>> profesjonalnej pracy
> 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ć. Kojarzysz "mała aferę" z DisplayLink? 
Rechotrałem godzinami czytają komentarze profesjonalistów od 
dicking-around siedzącymi przed swoimi jabłkami płacząc że im się popsuło.

>> A co kupują jak chcą odpalić ModelSima?
> Windowsa.

Linuxa.

> I nie ma w tym żadnego konfliktu, bo to nie są ci sami profesjonaliści.

Aha. Ale jakoś słyszę ciągle że AutoCAD i Photoshop są powodem bycia 
profesjonalnym.

>> Wystarczy zmienić kompilator w makefile.
> Ale tego makefile też nie mam.

No to zmienic kompialtor w *foo*.

> Problemem nie jest Twój czy mój kod. Problemem jest ten cudzy kod.

Jesteś od niego oddzielony abstrakcją. *ZAWSZE* oddziela się 3-rd party 
abstrakcją. Można tego nie robić z róznej przyczyny, ale wtedy to jest 
*dziadowski* kod.

Oczywiście nie muszę przecież przypomniać że oddzielanie się abstrakcją 
od wszystkeigo pomaga róznież w testowaniu. No ale skoro kod dziadowski, 
to może i testowania nie ma.

>> Sporo software ma pluginy pisane w pythone, tclu itd. I co teraz?
> 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. Wniosek: to nijaki argument. Zmienili tylko kompilator w makefile 
lub poprawili jakieś bugi i poszło.

>>> Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas.
>> Myślę że wyjąłeś sobie 1 mały detal z embedded i nazywać go
>> najważniejszym, olewając inne detale.
> A jakie są inne detale? Bo rozmawiamy o zmianie CPU, tak?

Rozmawiamy o embedded i zmienach embedded cpu. To nie jest *osobny* 
scalak, tylko zazwyczaj coś wciśnięte do jakiegoś ASICa zrobionego jako 
SoC, z masą skomplikowanych peryferiów w jednym kawałku krzemu.

> Bo ja dorzucam jeszcze konieczność zmiany karty graficznej, która mi nie zadziała z RISC-V, bo NVIDIA ma 40B$ powodów, żeby nie zadziałała. To już drugi detal.

Ale karty nvidia nie są na rynku embedded, a na rynku desktopów nie ma 
to znaczenia, pornole czy photoshop pójdą na czymkolwiek. To że 5% 
desktopów ma karty nvidi jest naprawdę mało istotne nad zastanawianiem 
się o przydatność RISC-V na desktopy.