On 07/01/2021 14:55, Smok Eustachy wrote:
> Jaki procesor był niedziadoski?

W tamtych czasach? Czy ogólnie?

Z resztą bez znaczenia. MC68000 na przykład.

"[...] IBM considered the 68000 for the IBM PC but chose the Intel 8088
because the 68000 was not ready[...]".

MC68000 to 1979. IBP PC to 1981. Trudno powiedzieć co mieli na myśli
pisząc "not ready". Dla innych był ready.

>> ST mimo zupełnie innych zasobów gotówki. Team od MS-DOSa musiał być
>> chyba często na wakacjach, bo nic tam się nie działo.
> Obsługa szerokiego wachlarza sprzętu.

W 99% wypadków pisana w software, bo DOS nie miał śladu abstrakcji na
cokolwiek, poza bardzo wolnym dostępem do ekranu i prymityną abstrakcją
na dyski, a po "odkryciu" 32 bitów, ogólnie niemożliwą do użycia wprost.

DOS nie miał w sobie praktycznie śladu sterowników do czegokolwiek.
Bazował na BIOSach urządzeń i bezpośrednim dostępie. Pamiętasz BLASTER=
czy juz umknęło?

do góry

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

do góry

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.

do góry

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

Ale przecież do tego już mają rdzenie. Każdy. Np. Texas ma MSP430. Bardzo fajny, też
RISC, swoją drogą. Pobór prądu ma mniejszy, niż naturalny wyciek z typowej
konsumenckiej baterii. Czyli bateryjkę prędzej szlag trafi ze starości, niż z
wyładowania. I każdy poważny producent takie coś ma, w dodatku swoje, więc nie musi
się martwić o czyjeś licencyjne fanaberie. To po co jakiś RISC-V?

> POSIX w embedded nie jest dobry.

Nadal nie napisałeś, dlaczego.

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

Na pewno nie chcesz, żeby opracował na FreeRTOSie, bo to ma poziom poniżej
amatorskiego.
Ale ponieważ POSIX to jest tylko API a nie implementacja, to dlaczego nie? Mogę mieć
dobrej jakości implementację z interfejsem POSIX. Nadal nie napisałeś niczego, co by
temu przeczyło.

Przykładowo, dobrej jakości systemem do embedded z interfejsem POSIX jest QNX.
W szczególności, jest używany w systemach medycznych:

https://blackberry.qnx.com/en/software-solutions/emb
edded-software/medical

Więc jednak masz POSIX w urządzeniu medycznym. I dobrze.

> Ale musisz mieć abstrkację. Masz, prawda? Jak byś inaczej mógł
> to testować. Wiec musisz mieć.

Przecież napisałem, że mam. Nazywa się POSIX.

> Zaznajom się np. z Qt.

Już mnie kiedyś chciałeś do tego zachęcić, ale słabo wyszło.

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

Ręce opadają, nic nie rozumiesz.
To nie POSIX ma być przenośny, tylko programy napisane pod to API. I zapewniam, że
takie programy są przenośne pomiędzy systemami, które ten standard implementują.
Np. kod, który napisałem na Linuksie zadziałał od ręki na QNX. Radości było z tego
jak mało kiedy. Właśnie na tym polega ta przenośność.

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

Czyli dalej nie rozumiesz. Kto powiedział, że system ma mieć wszystkie funkcje?
Chodzi o to, że jeśli już ma np. funkcję inicjalizującą mutex, to niech ta funkcja
się nazywa pthread_mutex_init a nie ourMutexCreate. I jeśli system ma tylko 10 takich
funkcji, to niech one się nazywają tak jak 10 funkcji z POSIX. I to wystarczy, żeby
kod napisany na taki system można było bez żadnej modyfikacji przenieść albo zrobić
mu unit-testy na innym systemie, np. na Linuksie, bo akurat taki jest łatwiej
dostępny.

> > Albo korzystam ze standardów. Takim standardem jest POSIX.
> Dalej nie pojmujesz że posix nie jest abstrakcją.

Dalej nie przeczytałeś nawet pierwszego zdania z Wikipedii na ten temat. A dałem
linka.

> Abstrakcją jest
> MyTools::MyMutex a nie pthread_mutex.

To jest abstrakcja na abstrakcję. Też tak robię - ale to jest dodatkowy koszt,
którego nie musiałbym ponosić, gdyby systemy były zgodne ze standardami. A niestety
nie są, bo przecież fajniej jest mieć ourMutexCreate().
I teraz masz milion firm robiących systemy embedded i każda z nich robi wrapper
MyTools::MyMutex. Dlaczego? Ile jest interesujących systemów w użyciu, nawet
wliczając te dziadoskie typu FreeRTOS? No ile? To zobacz teraz, jaki jest stosunek
kosztów: milion firm robi własne abstrakcje do abstrakcji, bo w przybliżeniu 2-3
systemy koniecznie musiały mieć ourMutexCreate. Czyli sumaryczny koszt tych
wszystkich abstrakcji jest większy, niż to pod spodem. To jest choroba naszej branży.

> Abstrakcją może byc też Qt

Ale czemu sobie żałować? Zróbmy abstrakcję na to też. Przecież nie wszystkie
frameworki są zgodne, prawda? A co jak management zdecyduje, że zmieniamy Qt na coś
innego? I teraz, jeśli programiści nie są idiotami, to pójdzie sprawnie, bo mają
abstrakcje, tak?
Wszystkie Twoje argumenty można tu zastosować.

[POSIX]
> Przeczytałeś cos nie na temat. To jest abstrkacja do konkretnej rodziny
> systemów.

Konkretnej? Nie, żadnej rodziny tam nie było. Niektórych systemów w ogóle jeszcze nie
było, jak ten standard powstał.

> W tej rodzinie nie ma FreeRTOSa ani Widnowsa CE, a są one w
> embedded używane.

No są. Niestety. Bo po co być zgodnym ze standardami, skoro można mieć - *beż żadnej
wartości dodanej* - ourMutexCreate?
Ale o to można obwiniać tylko autorów tych systemów.
POSIX jest standardem. QNX spełnia ten standard. FreeRTOS nie spełnia tego standardu.
Co zrobić.

> Posix to NIE jest abstrakcja na systemy operacyjne.

Właśnie dokładnie tym jest.

> Co najwyżej na wąską
> grupę bardzo podobnych systemów, o nikłej uzytecznosci w embedded.

Nadal czekam na wyjaśnienie, dlaczego nie do embedded.
Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest. To ciekawe
bardzo. Funkcja się inaczej nazywa i już nie nadaje się do embedded. Kurdę, muszę
uważać, jak funkcje nazywam.

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

Właśnie tak jest w POSIX. pthread_mutex_t nie jest określony w standardzie i w
różnych implementacjach może być różnie zdefiniowany.

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

A x86 i DOS były popularniejsze swego czasu. Tylko że samodzielnie wylałeś na nie
tyle żółci, że powinieneś sam rozumieć, jaki jest związek popularności z wartością
merytoryczną.

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

Niestety nie jest to zgodne z moimi obserwacjami. Zmiana jednego systemu POSIX na
drugi system POSIX może być mało bolesna, ale zmiana OurRTOS na TheirRTOS to większy
problem, bo jak już ktoś miał gdzieś standardy, to zwykle w różnych, niezależnych
kierunkach. Wtedy to nie jest kwestia taniego wrappera. Zwłaszcza, jak to tego
dołożymy stos TCP. Np. popularnym partnerem dla dziadoskiego FreeRTOSa jest dziadoski
LwIP. To jest dopiero duet, wszystko wtedy opada.

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

Jeszcze cięższa, jak się nie ma kodu. O tej możliwości też cały czas mówimy, bo to
jest realna możliwość.

Ale trochę rozwlekła nam się ta dyskusja zrobiła, więc może skupmy się: dlaczego
POSIX nie jest dobry do embedded? Dlaczego funkcja, która się nazywa na literkę "p"
nie nadaje się do embedded a funkcja robiąca dokładnie to samo, ale na inną literkę
się nadaje?
"U mnie działa."

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

do góry

On 08/01/2021 22:42, Maciej Sobczak wrote:
>> 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.
> Ale przecież do tego już mają rdzenie.

Nie wiesz jakie mają kryteria. Jak dildo ma 40 programów i trzeba tak
pod 1Ghz FPU do tego?

> Texas ma MSP430

I sprzedają go jako IpCores coby sobie ASICowy SoC dorobić na około?

> To po co jakiś RISC-V?

Bo pewnego dnia Texas zatrudni na CEO Balmera, który znowu będzie rzucał
krzesłami?

Od jakiegoś czasu jest tendencja aby w miarę mozliwości nie zamykac się
ze swoimi projektami za bardzo. RISC-V to jest taki "opensource ARM".
Tak jest postrzegany. W razie jak na stanowisku CEO ARMa stanie świr,
mamy się gdzie ewakuować.

>> POSIX w embedded nie jest dobry.
> Nadal nie napisałeś, dlaczego.

Wiele systmów embedded:
a) nie ma plików
b) nie ma procesów
c) nie ma rurek
d) nie ma sygnałów
e) nie ma konsoli
f) a wniej interaktywnych poleceń

Ale ma 40 programów w dildo, albo 20 programów w respiratorze. W tym
drugim nawet formalnie weryfikowanych.

POSIXa w jakiejś implementacji ciężko będzie formalnie weryfikować, on
sam z siebie jest bardzo kiepski i mocno chaotyczny, oraz *NIE DO TEGO*.

>> Osobiscie wolałbym aby mój respirator niekoniecznie pracował na POSIXie.
> Na pewno nie chcesz, żeby opracował na FreeRTOSie, bo to ma poziom poniżej
amatorskiego.

Jednak wolę dalej FreeRTOSa nad POSIXa w respiratrorze, jesli już mam
wykitować z powodu OSa. Może sygnał przyjdzie w wątku z obsługa, a może
nie. POSIX? Nie, dziękuję.

> Ale ponieważ POSIX to jest tylko API a nie implementacja, to dlaczego nie?

Bo POSIX jest niezwykle trudny do weryfikacji. Z powodu komplikacji
swojego API.

> Mogę mieć dobrej jakości implementację

Możesz. A masz?

> z interfejsem POSIX. Nadal nie napisałeś niczego, co by temu przeczyło.

Weryfikacji formalnej by przeczyło. Z tego powodu czasem wybiera się
takie cuda na kiju jak jadra formalnie zweryfikowane (L4) i dziwaczne
metody kostrukcji scalaków.

Niekiedy, aby dostać jakiś konkretny certyfikat, musisz wykazac że dany
kawałek softu jest *dobrze* napisany. To kłopotliwe pojęcie, ale fakt że
wsadziłeś POSIXa do migania diodą lub kontroli oddechu może być powaznym
problemem w odpowiedzi na pytanie czy jest dobrze napisany.
Najzwyczajniej możesz nie dać rady jej formalnie udzielić. Dlatego
istnieją znacząco mniejsze systemy w któych masz na to jakąś szansę.

> Przykładowo, dobrej jakości systemem do embedded z interfejsem POSIX jest QNX.
> W szczególności, jest używany w systemach medycznych:
> https://blackberry.qnx.com/en/software-solutions/emb
edded-software/medical
> Więc jednak masz POSIX w urządzeniu medycznym. I dobrze.

Tak, istnieją systemy, narzędzia, cores certyfikowane. Nie ma problemu
aby były zgodne w jakiejś częsci z posix. Nic tak nie powoduje ulgi
doczesnej jak to że na moim respiratorze można zrobić fread z EINTR i
jest na to 15 ifów, a miało być 16.

>> Ale musisz mieć abstrkację. Masz, prawda? Jak byś inaczej mógł
>> to testować. Wiec musisz mieć.
> Przecież napisałem, że mam. Nazywa się POSIX.

Nie, to tylko kilka implementacji. Abstrakcja to nie jest.

>> Zaznajom się np. z Qt.
> Już mnie kiedyś chciałeś do tego zachęcić, ale słabo wyszło.

Nie namawiam, to tylko przykład co to jest abstrakcja na OS a nie
abstrkacja na rodzię OSów.

>> POSIX nie jest przenośny. Istnieje masa systemów z nim niezgodnych.
> Ręce opadają, nic nie rozumiesz.
> To nie POSIX ma być przenośny, tylko programy napisane pod to API.

Staje się wtedy tak samo nieprzenośne jak implementacja POSIXa. Na
przykład sa nieprzenośne na to i tamto.

> I zapewniam, że takie programy są przenośne pomiędzy systemami, które ten standard
implementują.

Czyli wąska grupa unixo-podobnych + duperele.

> Np. kod, który napisałem na Linuksie zadziałał od ręki na QNX.

A na freeRTOS? A na Windows CE?

Ok, ustalmy wobec tego że masz program *częściowo* przenośny. Tak lepiej?

> Właśnie na tym polega ta przenośność.

Nie. Ale może takie masz warunki pracy, w których interesuje Cie
przenośnośc z Ubuntu na NetBSD i wtedy POSIX faktycznie można uznać za
jakiś rodzaj abstrakcji. Ja nie mam takiego komfortu. Nie tylko ja.

>> 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.
> Czyli dalej nie rozumiesz. Kto powiedział, że system ma mieć wszystkie funkcje?

Czyli nie jest zgodny z POSIX?

> Chodzi o to, że jeśli już ma np. funkcję inicjalizującą mutex, to niech ta funkcja
się nazywa pthread_mutex_init a nie ourMutexCreate.

Wycinasz przenośność na nieposixy.

> I jeśli system ma tylko 10 takich funkcji, to niech one się nazywają tak jak 10
funkcji z POSIX.

Nie, to już za daleko. Przecieka Ci implementacja przez abstrkację.
Dotyczy ona nie tylko nazw, ale przede wszystkim sposobu użycia. W sumie
bez znaczenia czy masz pthread_mutex_init nazwany dupa. Istotne jest że
w innym systemie (niezgodnymz POSIX) może w ogóle nie itnieć inicjacja
poza miejscem deklaracji, albo istnieć przyjmująca paramter resursive.
Itd itp. Przeciekanie POSIXa do kodu to nie tylko nazwy, to sposoby ich
używania.

Dlatego masz class MyMutex a nie void MyMutexInit(). To drugie
faktycznie nic by nie dało.

> zrobić mu unit-testy na innym systemie, np. na Linuksie, bo akurat taki jest
łatwiej dostępny.

A na windowsie?

>>> Albo korzystam ze standardów. Takim standardem jest POSIX.
>> Dalej nie pojmujesz że posix nie jest abstrakcją.
> Dalej nie przeczytałeś nawet pierwszego zdania z Wikipedii na ten temat. A dałem
linka.

Przeczytałem. Zmartwie Cie równiez. Na codzień piszę kod na POSIXie i
Windowsie *jednoczesnie*. Powiedzmy że mam zielone pojęcie gdzie POSIX
jest przenośny. Powiedzmy że nieco powyżej średniej, mam to pojęcie.
Nijak nie udało mi się zawołać funkjci Posixowych w Windowsie.
Najwyraźniej Wikipedia pisze od rzeczy lub nie pojmujesz o co chodziło
autorom.

>> Abstrakcją jest
>> MyTools::MyMutex a nie pthread_mutex.
> To jest abstrakcja na abstrakcję.

To jest abstrakcja na więcej implementacji OSów niż tylko POSIX.

> Też tak robię - ale to jest dodatkowy koszt

Kosztuje mnie absolutnie 0 czasu w runtime, absolutnie 0 czasu w
pisaniu. Ba, jest tańszy niż POSIX bo mogę używać RAII, więc robie mniej
błedów emulując ręcznie RAII, tak jak chce POSIX.

> I teraz masz milion firm robiących systemy embedded i każda z nich robi wrapper
MyTools::MyMutex. Dlaczego?

Aby się uniezależnić od OSa. Aby móc przeprowadzić unit testy. Aby móc
łatwiej znaleźć błedy. Aby szybciej pisać kod. Aby łatwiej go czytać.
Aby łatwiej go refaktorować.

Zgadnij dlaczego mamy (wreszcie) std:: z obsługą wątków, i to nie jest
POSIX like API. Najwidoczniej ktoś kombinuje jak ja - abstrakcja na OS.

> Ile jest interesujących systemów w użyciu, nawet wliczając te dziadoskie typu
FreeRTOS? No ile?

Co najmniej kilkanaście. Twoje POSIXy, Win32/64, mikroskopijne RTOSy,
dedykowane dziwadła jak L4 i systemy pisane pod zagadnienie, np. do
lotów kosmicznych. I pewnie masę, których nie wymieniam, bo przecież
znam je tylko z tego że się obiły o uszy.

> To zobacz teraz, jaki jest stosunek kosztów: milion firm robi własne abstrakcje do
abstrakcji

Które kosztują, zwyczajowo prawie nic i dzięki temu, że sa pisane z
myslą o czymś nowoczesniejszym niż kompilatory z lat 70, pozwalaja
dodatkowo zredukować koszta pisania kodu, używając nowocześniejszych
technik generujacych mniej błedu. std::lock_guard jest nieskończenie
lepszym wyborem niż ręczne dziubdzianie mutex lock/unlock w posixie.

Nie robią własnych. Wiele z tych abstrakcji jest już napisanych:
boost/std i masa pomniejszych dupereli.

> , bo w przybliżeniu 2-3 systemy koniecznie musiały mieć ourMutexCreate

Zniknąłeś pozostałe zalety.

>. Czyli sumaryczny koszt tych wszystkich abstrakcji jest większy

Jest prawie zerowy. Przykładowo moja abstrakcja na rurki, zajeła mi 2h
do napisania i otestowania i od lat nie zmieniłem w niej bajta. Ta sama
funkcjonalność, reimplemntowana ręcznie kończy się deadlockiem bo ktoś
zapomniał ponowić ::read, bo wyleciał EINTR.

Koszta takich bugów są niebotyczne, bo wylatują tylko przy pełni
księżyca w Kambodży podczas monsunów. Po to owijamy, między innymi,
POSIXa w dodatkową abstrakcję wysokopoziomową, aby chronić się od
popełniania w kółko tych samych błedów tego dziwdowskiego interfejsu.

Zauważyłeś ile jest makr które "ułatwiają" pracę z funkcjami POSIXowymi?
To dlatego, że to jest wyjątkowo żałosne API i nawet najbardziej
zatwardziali unixiarze w końcu poddali się, wrapując te klocki w makra.

> To jest choroba naszej branży.

Nie. Pisanie na wysokim poziomie nie jest chorobą.

>> Abstrakcją może byc też Qt
> Ale czemu sobie żałować? Zróbmy abstrakcję na to też.

Oczywiście że się robi i na to abstrkację. Chcesz aby po Twoim kodzie
latały QString czy std::string? Co jest bardziej niebezpieczne?

Wybór może być biznesowy. Przykładowo kilka lat temu zamieszanie z
licencjonowaniem Qt spowodowało że "ludzie" poważnie zastanowili się czy
warto się od Qt uzależnić. I zauważyli że część abstrakcji z Qt można
znaleźc w boost/std.

> Przecież nie wszystkie frameworki są zgodne, prawda?

Nie są. Dlatego najlepiej oddzielić wartwę logiki od wartwy GUI aby w
razie czego "łatwo" GUI wymienić. To rodzaj sztuki, w prewnym sensie
robienie abstrkacji na GUI uważam za znacznie trudniejsze niż na OS.

> A co jak management zdecyduje, że zmieniamy Qt na coś innego?

To mam do przepisania jakieś 10% kodu, często tylko poprawienia.
Pozostały jest abstrakcyjny, przetestowany, nic się w nim nie zmienia.

> I teraz, jeśli programiści nie są idiotami, to pójdzie sprawnie, bo mają
abstrakcje, tak?

Nie, bo używanie Qt jest mocno zaraźliwe. Znacznie bardziej niż uzywanie
POSIXa. Wiec, o ile można część apliakcji skompilować w oderwaniu od Qt
(np. modele i częsciowo kontrolery) to już widoki będą wymagały wymiany.

Ale dalej, poprawna higiena ratuje 90% apliakcji.

> Wszystkie Twoje argumenty można tu zastosować.

Tak, Qt było przykładem jak wygląda abstrakcja na OS 3-rd party, a nie
wzorzec w dyskusji jak ją robić. Co napisałem wyraźnie. Uzycie Qt jako
abstrakcji to wybór biznesowy i niekoniecznie poprawny wszędzie i zawsze.

> [POSIX]
>> Przeczytałeś cos nie na temat. To jest abstrkacja do konkretnej rodziny
>> systemów.
> Konkretnej? Nie, żadnej rodziny tam nie było. Niektórych systemów w ogóle jeszcze
nie było, jak ten standard powstał.

I jakimś trafem mało który system suwerena ten standard implementuje,
podobnie w embedded OSa może w ogóle nie być, ba, może być napisany na
miejscu, do potrzeb. Nikt nie będzie implementował dziadowskich
koncepcji z POSIXa tylko dlatego że jest jakiś "standard" pochodzący z
mainframes.

>> W tej rodzinie nie ma FreeRTOSa ani Widnowsa CE, a są one w
>> embedded używane.
> No są. Niestety. Bo po co być zgodnym ze standardami, skoro można mieć - *beż
żadnej wartości dodanej* - ourMutexCreate?

Pisałem juz kilka razy o tej wartości dodanej. W sprawie zgodności z
POSIxem udaj się do MS. Zaznaczam, ze mimo lat dziubdziania Cywina i
ostatnio samego MS, POSIXa w windowsie nie zobaczysz, są fundamentalne
problemy z faktem że posix to nie przemyslany standard, tylko zbiór
aktualnie działajacego stanu jakiegoś wiekowego UNIXa, zamrożony i
nazwany "abstrakcją", pełen debilizmów i workaroundów.

> Ale o to można obwiniać tylko autorów tych systemów.

Zgadza się, jednak z jakiejś przyczyny WinApi, mimo stwojej śmieszności
w tak wielu kwestiach, nie ma kompletych bzdur w np. obsłudze pipes, jak
jest w unixie. Nie ma sygnałów wyskakujących w dowolnym wątku i
kopiących programistę prosto w dupę. Itd itp. Może jednak WinAPI było
bardziej przemyślane i nie po drodze im z POSIXem. To co, postulujesz
nie używać Windowsa w programowaniu bo niezgodny z tym zbiorem głupich
rozwiązań nazywancyh POSIX i oferujący swój własny zbiór głupich
rozwizań nazywanych WinAPI? A może jednak odciąc się od obydwu, co?

> POSIX jest standardem. QNX spełnia ten standard. FreeRTOS nie spełnia tego
standardu. Co zrobić.

Odciąć się abstrakcją.

>> Co najwyżej na wąską
>> grupę bardzo podobnych systemów, o nikłej uzytecznosci w embedded.
> Nadal czekam na wyjaśnienie, dlaczego nie do embedded.

Bo mało kiedy potrzebujesz mieć procesy, rurki, pliki w systemie
embedded. A jak ich nie masz, to nie masz POSIXa.

> Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest.

Bo jest nieprzenośne na inne embedded.

> To ciekawe bardzo. Funkcja się inaczej nazywa i już nie nadaje się do embedded.

Tak, właśnie odkryłeś na czym polega abstrakcja w wyjaśnieniu dla
przedszkolaka.

> Kurdę, muszę uważać, jak funkcje nazywam.

Dokładnie tak, jesteś na własciwym trope. Dodatkowo jeśli dodasz że
musisz uważać jakich typów są zmienne, jakich flag używasz itd itp to
szybko dojdzieszdo tego co to jest *prosta* abstrakcja na system
operacyjny. Tylko nie zakładaj że to koniec, dalsze tematy są bardziej
skomplikoane, ale do ogarnięcia. Tak, trzeba zacząć od uszelniania
szamba, aby POSIX nie przeciekał do kodu, a potem małymi krokami usuwasz
kod supportujący dziwactwa i przenosisz go do wspólnych miejsc i jesteś
już o krok od abstrakcji w której nie ma supportu dla EINTR czyli
przeciekania szamba.

>> Abstrakcja na systemy operacyje jest wysokopoziomowa. Tam gdzie nie
>> wiadomo czy mutex to int, handle, pointer czy foo.
> Właśnie tak jest w POSIX.

Dokładnie, nie czyni to z niego jednk abstrakcji na Windows.

>> 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.
> Niestety nie jest to zgodne z moimi obserwacjami. Zmiana jednego systemu POSIX na
drugi system POSIX może być mało bolesna, ale zmiana OurRTOS na TheirRTOS to większy
problem, bo jak już ktoś miał gdzieś standardy, to zwykle w różnych, niezależnych
kierunkach. Wtedy to nie jest kwestia taniego wrappera.

Nikt tu nie pisze o *darmowej* migracji. Owszem, napisałem niedawno o
zmianie kompilatora w makefile, ale to dotyczyło rekompilacji kodu na
Macu z x86 na ARM, kiedy API systemu się nie zmienia, zmienia się tylko
cpu i ABI. Wiele projektów embedded też będzie miało łatwo, bo nie
zależą od CPU.

Zmiana ma być mało bolesna. Przepisanie kilku adapterów nie kosztuje
mało, ale na pewno taniej niż przepisanie całego kodu zasranego
odwołaniami do POSIXa i logiką z EINTR.

> Zwłaszcza, jak to tego dołożymy stos TCP

To tego POSIX nie załatwił? A to niegrzeczny!

>. Np. popularnym partnerem dla dziadoskiego FreeRTOSa jest dziadoski LwIP. To jest
dopiero duet, wszystko wtedy opada.

Nie miałem przyjemnosci, chętnie sprawdzę na ile jest rozsądniejszy od
impelemntacji z unixów. Bo ta, moim skromnym zdaniem, wyznacza jednak
poziom podłogi. Nie da się gorzej.

>> 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.
> Jeszcze cięższa, jak się nie ma kodu.

Nie wydaje mi się, aby taki był temat dyskutowania.

> O tej możliwości też cały czas mówimy, bo to jest realna możliwość.

Pewnie, ktoś musi stworzyc puste repo na nowy projekt, jednak w dużych
firmach jest super jak można go zapełnić gotowcami z poprzeniego
projektu. I to wszystko dzięki abstrakcji. O dzieki Ci, abstrakcjo!

> Ale trochę rozwlekła nam się ta dyskusja zrobiła, więc może skupmy się: dlaczego
POSIX nie jest dobry do embedded?

Napisałem wyżej. Zawiera śmieci, które nie są użyteczne, oraz sam z
siebie jest wyjątkowo dziadowski.

> Dlaczego funkcja, która się nazywa na literkę "p" nie nadaje się do embedded a
funkcja robiąca dokładnie to samo, ale na inną literkę się nadaje?

Aby nie musieć zmieniać jej nazwy w 100 miejscach kiedy zmieniasz OS,
poprawiajac przy okazji kod supportujacy też 100 razy.

Aby udostepnić wysokopoziomy interfejs uzywajacy wspólczesnych jezyków
zamiast POSIXowego, kieskiego API.

Aby umożliwić unit testy.

Aby odstrzec że czasem ta funkcja nie może być wywołana w innym systemie
i trzeba pakować ją do wyższysz struktur języka.

Pisałem to chyba ze 100 razy. Prosze, nie pytaj więcej, jestem zmęczony.

> "U mnie działa."

U mnie też. Przeciez wymieniamy doświadczenia. Ty masz jakieś, ja mam
jakieś.

Ja nie mogę spobie pozwolić na komfort "tylko POSIX" bo inaczej trace
połowę klientów, dzięki temu wypracowałem metody uszczelniania szamba
POSIXa i WinAPI tak, aby nie przeciekały do kodu.

Ty najwidoczniej możesz sobie pozwolić na ogarnieniae abstrakcji w
POSIXowym OSie.

Stąd różne opinie. Moja w tym wypadku jest mojsza i tyle.

do góry

> >> POSIX w embedded nie jest dobry.
> > Nadal nie napisałeś, dlaczego.
> Wiele systmów embedded:
> a) nie ma plików
> b) nie ma procesów
> c) nie ma rurek
> d) nie ma sygnałów
> e) nie ma konsoli
> f) a wniej interaktywnych poleceń

No i?
Taki przykładowy QNX jest oparty o mikrojądro, gdzie te wszystkie rzeczy powyżej to
osobne usługi, których można nie mieć, to jest kwestia konfiguracji. I niepotrzebnych
rzeczy nie ma, zwłaszcza w systemach embedded.
Nie zmienia to faktu, że nadal QNX jest POSIX.
I dlatego dalej nie rozumiesz.

> Ale ma 40 programów w dildo

Zaczynam mieć wrażenie, że to jedyna rzecz, o której masz coś do powiedzenia.

> POSIXa w jakiejś implementacji ciężko będzie formalnie weryfikować

Sam sobie zaprzeczasz. "W jakiejś implementacji"? A jeśli mam formalnie zweryfikowaną
implementację, to czy w takiej implementacji będzie ciężko zweryfikować? Nadal nie
odróżniasz API od implementacji. POSIX to tylko API.

> Jednak wolę dalej FreeRTOSa nad POSIXa w respiratrorze,

A jest formalnie zweryfikowany? Bo widzisz - POSIX to API. Natomiast FreeRTOS to
konkretny system. I ten konkretny system nie jest zweryfikowany, nawet nieformalnie.
Dlatego zdecydowanie nie chcesz go w respiratorze.
(ale możesz chcieć SafeRTOS, którego napisali od nowa w tym celu)

> Bo POSIX jest niezwykle trudny do weryfikacji. Z powodu komplikacji
> swojego API.

Od kiedy API utrudnia weryfikację? W jaki sposób?

> > Mogę mieć dobrej jakości implementację
> Możesz. A masz?

Przecież już pisałem.

> > Np. kod, który napisałem na Linuksie zadziałał od ręki na QNX.
> A na freeRTOS? A na Windows CE?

A tam nie zadziałał od ręki, bo autorzy uznali, że musi być ourMutexCreate(), zamiast
pthread_mutex_init().

> Ok, ustalmy wobec tego że masz program *częściowo* przenośny. Tak lepiej?

Nie wiem, czy lepiej. Na pewno program napisany pod API POSIX jest bardziej przenośny
(bo działa na wielu systemach), niż program napisany pod FreeRTOS (bo działa tylko na
jednym).

> W sumie
> bez znaczenia czy masz pthread_mutex_init nazwany dupa. Istotne jest że
> w innym systemie (niezgodnymz POSIX) może w ogóle nie itnieć inicjacja
> poza miejscem deklaracji, albo istnieć przyjmująca paramter resursive.

Może czy istnieje? Pokaż na przykładzie FreeRTOS (skoro już o nim mówimy i chcesz go
w respiratorze).

> Dlatego masz class MyMutex

To mam z innego powodu. Otóż w programie C++ wolę mieć bardziej zunifikowane idiomy.
Np. zwalnianie tego muteksa w destruktorze. Ale robię to z powodu *podniesienia*
poziomu abstrakcji, a nie z powodu zapewnienia przenośności. Do przenośności
wystarczyłby POSIX, gdyby twórcy januszowych RTOSików nie mieli przerostu ego i
presji na wymyślanie własnych nazw.
Dlatego chciałbym mieć *jedną* implementację mojej klasy MyMutex. A nie kilka
różnych.
(oczywiście teraz mamy też std::mutex, ale dyskusja jest ogólna)

> > zrobić mu unit-testy na innym systemie, np. na Linuksie, bo akurat taki jest
łatwiej dostępny.
> A na windowsie?

"U mnie działa"?
Jeśli trzeba puścić unit testy, to Cygwin jest do tego jak najbardziej wystarczający.

> Na codzień piszę kod na POSIXie i
> Windowsie *jednoczesnie*. Powiedzmy że mam zielone pojęcie gdzie POSIX
> jest przenośny. Powiedzmy że nieco powyżej średniej, mam to pojęcie.
> Nijak nie udało mi się zawołać funkjci Posixowych w Windowsie.

"U mnie działa"?

> Zgadnij dlaczego mamy (wreszcie) std:: z obsługą wątków, i to nie jest
> POSIX like API.

A niby jak by miało być "like"? POSIX to jest API dla języka C. Logiczne jest, że API
w std:: będzie inne. I dobrze.

> Najwidoczniej ktoś kombinuje jak ja - abstrakcja na OS.

Pominąłeś szczegół: ktoś z tym std:: kombinuje, że standardy są dobre. I ma nadzieję,
że autorzy implementacji będą tego standardu przestrzegać, bo od przestrzegania
standardu zależy przenośność końcowych programów, jak też obniżenie globalnych
kosztów. Nie przypisuj sobie tego pomysłu, bo do tej pory byłeś od niego daleko.

> > Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest.
> Bo jest nieprzenośne na inne embedded.

Jest przenośne bardziej (również na embedded), niż ourMutexCreate, który w ogóle nie
jest.

> Ty najwidoczniej możesz sobie pozwolić na ogarnieniae abstrakcji w
> POSIXowym OSie.

Też nie mogę. Bo ktoś olewał standardy.

> Stąd różne opinie. Moja w tym wypadku jest mojsza i tyle.

Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być. Stąd
nieporozumienie. ;-P

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

do góry

On 09/01/2021 16:48, Maciej Sobczak wrote:
>> a) nie ma plików
>> b) nie ma procesów
>> c) nie ma rurek
>> d) nie ma sygnałów
>> e) nie ma konsoli
>> f) a wniej interaktywnych poleceń
> No i?

To oznacza że POSIX nie jest dobrą abstrakcją na OS b wymaga tego
wszystkiego aby być POSIXem. Inaczej nie jest POSIXem.

> Taki przykładowy QNX jest oparty o mikrojądro, gdzie te wszystkie rzeczy powyżej to
osobne usługi, których można nie mieć, to jest kwestia konfiguracji.

Każda konfiguracja, inna niż *wszystko*, nie jest już POSIXem.

> I niepotrzebnych rzeczy nie ma, zwłaszcza w systemach embedded.

To po co tam wciskać POSIXa skoro używa się 5% jego api?

> Nie zmienia to faktu, że nadal QNX jest POSIX.

Jak zrobisz make all_shit_included to na pewno jest.

>> Ale ma 40 programów w dildo
> Zaczynam mieć wrażenie, że to jedyna rzecz, o której masz coś do powiedzenia.

Nie, to dwa odległe światy: dilda i respiratory. jedne można programować
byle jak, inne wymagają cięzkich certyfikacji. W obu stosuje sięte same
procesory, techniki, abstrkacje, i w ani jednym z nich nie ma POSIXa.

>> POSIXa w jakiejś implementacji ciężko będzie formalnie weryfikować
> Sam sobie zaprzeczasz. "W jakiejś implementacji"?

Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior. To jak się
zachowa, zależy od implemetacji, ba, nawet od wersji jądra, bibliteki,
interakcji usera czy co tam na niego wpływa.

> A jeśli mam formalnie zweryfikowaną implementację

Wątplię, aby ktoś formalnie weryfikował POSIXa. Z uwagi na UB. Ale może
sie mylę, znasz przykład?

>, to czy w takiej implementacji będzie ciężko zweryfikować?

Tak, ponieważ posix generuje bardzo dużo stanów które wymagają formalnej
oceny przejścia i obsługi. Tan interfejs jest bardzo ciezko weryfikować.

Jeśli z ::read może wylecieć 20 róznych stanów to nie jest to dobre API.

> Nadal nie odróżniasz API od implementacji. POSIX to tylko API.

Więc sprawdź jak zachowuje się na różnych systemach. No wiec różnie.

>> Jednak wolę dalej FreeRTOSa nad POSIXa w respiratrorze,
> A jest formalnie zweryfikowany?

Jest możliwy do weryfikacji łatwiej niż POSIX. I prawdopodobnie nie
używany i tak, bo to zabawka do dildo. Podobnie jak POSIX na mainframes.

> Bo widzisz - POSIX to API. Natomiast FreeRTOS to konkretny system.

I tu wchodzi abstrakcja, cała na biało.

> I ten konkretny system nie jest zweryfikowany, nawet nieformalnie. Dlatego
zdecydowanie nie chcesz go w respiratorze.
> (ale możesz chcieć SafeRTOS, którego napisali od nowa w tym celu)

Który to SafeRTOS jest bez wątpienia POSIX like. I w dodatku bazujący na
API FreeRTOS :D Ależ to życie jest złośliwe.

>> Bo POSIX jest niezwykle trudny do weryfikacji. Z powodu komplikacji
>> swojego API.
> Od kiedy API utrudnia weryfikację? W jaki sposób?

W taki sposób:

switch ( fooResult )
{
case Error:
case OtherError:
case UlikelyError:
case SomethingBroken:
case DoItAgainPlease:
case MabyeLater:
case OKButNotQuite:
case Almost:
case NeedRest:
case Interrupt!:
}

>>> Np. kod, który napisałem na Linuksie zadziałał od ręki na QNX.
>> A na freeRTOS? A na Windows CE?
> A tam nie zadziałał od ręki, bo autorzy uznali, że musi być ourMutexCreate(),
zamiast pthread_mutex_init().

Nie, autorzy mają inny rodzaj mutexa. Wątku. Rurki. To nie kwestia nazw,
tylko użytku.

>> Ok, ustalmy wobec tego że masz program *częściowo* przenośny. Tak lepiej?
> Nie wiem, czy lepiej. Na pewno program napisany pod API POSIX jest bardziej
przenośny (bo działa na wielu systemach), niż program napisany pod FreeRTOS (bo
działa tylko na jednym).

A program napisany w Qt jest jeszcze bardziej przenośny od tego w POSIXie.

>> bez znaczenia czy masz pthread_mutex_init nazwany dupa. Istotne jest że
>> w innym systemie (niezgodnymz POSIX) może w ogóle nie itnieć inicjacja
>> poza miejscem deklaracji, albo istnieć przyjmująca paramter resursive.
> Może czy istnieje?

Na w tym miejscu jest std::mutex mutex; bez śladu free function.

Na przykład obok jest CreateMutex biorący 3 parametry.

> Pokaż na przykładzie FreeRTOS

Nie, pokaże na dowolnym innym przykładzie, aby obalić Twoją tezę o braku
sensu abstrakcji na inicjacje mutexa.

>> Dlatego masz class MyMutex
> To mam z innego powodu. Otóż w programie C++ wolę mieć bardziej zunifikowane
idiomy. Np. zwalnianie tego muteksa w destruktorze. Ale robię to z powodu
*podniesienia* poziomu abstrakcji, a nie z powodu zapewnienia przenośności.

Robisz to z obu powodów. std::foo jest przenośne z definicji.

> Do przenośności wystarczyłby POSIX

Nie chcesz takiej przenośności. POSIX to gówno. Pod wieloma względami to
zamrożone workaroundy z lat 70tych.

>, gdyby twórcy januszowych RTOSików

A twórcy januszowych Windowsów?

> Dlatego chciałbym mieć *jedną* implementację mojej klasy MyMutex. A nie kilka
różnych.

Nie ma takiej potrzeby. I tak masz dwie co najmniej. Przecięz masz
jeszcze mocka do testów.

>>> zrobić mu unit-testy na innym systemie, np. na Linuksie, bo akurat taki jest
łatwiej dostępny.
>> A na windowsie?
> "U mnie działa"?

Bo robisz je na cygwinie czy nie masz?

> Jeśli trzeba puścić unit testy, to Cygwin jest do tego jak najbardziej
wystarczający.

Ano właśnie, znalazłeś adapter do systemu operacyjnego. Bardzo milutko.
Nie sprzedasz jednak aplikcji napisanej na cygwinie, pozerkaj jak bardzo
wieli ból dupy mają twórcy cygwina z powodu niekompatybilnosci POSIXA z
WinApi i dlaczego w paru miejscach maja spinlocki.

>> Na codzień piszę kod na POSIXie i
>> Windowsie *jednoczesnie*. Powiedzmy że mam zielone pojęcie gdzie POSIX
>> jest przenośny. Powiedzmy że nieco powyżej średniej, mam to pojęcie.
>> Nijak nie udało mi się zawołać funkjci Posixowych w Windowsie.
> "U mnie działa"?

Nie, działa Ci w cygwnie. I nie dział wydajnie. Rownie dobrze mógłbyś
powiedzieć, że Ci działa w emulatorze odpalonym na windowsie. Ten sam
poziom "działania na windowsie".

>> Zgadnij dlaczego mamy (wreszcie) std:: z obsługą wątków, i to nie jest
>> POSIX like API.
> A niby jak by miało być "like"?

Bo to taka znakomita abstrakcja. Kazdy by chciał POSIXa w każdym dildo i
respiratorze, ale świat wyglada inaczej.

> POSIX to jest API dla języka C.

Nie tylko. Również dla ograniczonej klasy systemów, w tym w
szczególności posiadajacych konsolę z interakcją z userem.

>> Najwidoczniej ktoś kombinuje jak ja - abstrakcja na OS.
> Pominąłeś szczegół: ktoś z tym std:: kombinuje, że standardy są dobre.

Tak, ktoś kombinuje aby były *naprawdę* abstrakcyjne, a nie ściema, jak
POSIX.

> Nie przypisuj sobie tego pomysłu, bo do tej pory byłeś od niego daleko.

Możesz powiedzie gdzie go sobie przypisuje?

>>> Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest.
>> Bo jest nieprzenośne na inne embedded.
> Jest przenośne bardziej (również na embedded), niż ourMutexCreate, który w ogóle
nie jest.

Ale jest, to 1 linijka kodu dla POSIXa i 1 linijka kodu dla WinAPI. To
się nazywa adaper i itnieje w każdej implementacji interfejsu. W POSIXie
też istnieje adapter z pthread do przestrzeni kernela.

>> Ty najwidoczniej możesz sobie pozwolić na ogarnieniae abstrakcji w
>> POSIXowym OSie.
> Też nie mogę. Bo ktoś olewał standardy.

Nie olewa standardów. POSIX to jest taki standard z przypadku. Microsoft
nie ma śadu powodu aby go używac. Przyznał to Bill kiedy mówił że API
windwosa jest jedyne w swoim rodzaju i to jest *najważniejsze* co
Windows posiada. Inność. Dzieki czemu jest typowym vendor-lockin. Na
szczęscie od dawna potrafimy to obejść, dzięki abstrakcji na OS.

>> Stąd różne opinie. Moja w tym wypadku jest mojsza i tyle.
> Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być

Idealista.

Świad składający się z samych POSIXów byłby wyjątkowo gówniany, tak samo
jak składający się z WinAPI. Oba to zamrożone dawno temu workaroundy, w
tym wręcz krytyczne debilizmy.

Tupanie nogą że świat nie jest POSIXowy i na siłe uzależnianei się od
tego kipeskiego API nie jest specjalnie profesjonalne.

do góry

W dniu 06.01.2021 o 14:28, heby pisze:

>> Czyli potwierdzasz moją wersję - decyzja IBM była SPRZĘTOWA.
>
> To nie była decyzja. Wzieli co było i zrobili na kolanie byle co.
> Decyzja to by była gdyby rozpatrywali różne koncepcja hardware, systemów
> operacyjnych, rozszerzeń, planowali, badali.
>
> Tymczasme wzieli dziadowski procesor, nie mają pojęcia o systemie
> operacyjnym jak na nim będzie i wyciągając druty z CPU nazywając to
> "magistralą", zmuszając ludzi do ręcznego przydzielania IO i przerwań.
> Taki "komputer poskładany na kolanie przez studenta".
>

Nie piszę co oni wzięli, lecz że UWOLNILI.

>>> Niebywałe. Co oni tam robili przez te wszystkie lata? DoubleSpace?
>> Nic.
>
> Nic? Czekaj, czyli potwierdzasz tezę o zapaści?

Skoro DOS ludziom wystarczał i nie było konkurencji, był brak rozwoju.
Zapaść? Zdefiniuj ten termin. Był brak konkurencji software'owej.
Hardware była. Pecety taniały. Właśnie dzięki decyzji IBM.

>
>> W kwestii rozwoju Windows czy Office też długo nie robiono nic.
>
> Ależ robiono, jednak to dopiero *potem* było widać że cośtam dziubali z
> Windowsem 1.0 który był wyraźnie gorszy nawet od GUI Amigi i Atari ST
> mimo zupełnie innych zasobów gotówki. Team od MS-DOSa musiał być chyba
> często na wakacjach, bo nic tam się nie działo.

Od Windows 98 do Me oraz od wczesnych Office aż do 97 włącznie nawet nie
łatano dziur. Bo ludzie i tak będą kupowali.

Dopiero kiedy nagle się okazało, że ktoś używa Linuksa, który nawet
czasem stabilnie działa (koniec 90.), a dodatkowo nagle pojawił się
Openoffice (jesień 2000) nagle powstał XP oraz Office XP/2003, które
wreszcie zaczęły jako tako działać.

Pamiętam te czasy, chwilami można było wyrzucić komputer przez okno. Np.
dokumenty były nieprzenośne (na innym komputerze w tym samym office
otwierały się inaczej, a ich wygląd zależał np. od zainstalowanego
sterownika domyślnej drukarki. Przenoszenie dyskietkami (kilkoma, bo już
chwilami na jednej się nie mieściły) do znajomego z kolorową drukarką
powodowało np. brak obrazków w dokumencie :) Nie, nie były to linki do
innych dokumentów. Tak to wszystko się po prostu chrzaniło. Zainstaluj
sobie takie vintage i się pobaw.

Oczywiście każdy nie miał innego wyjścia, bo nie było konkurencji, a Ami
Pro i TAG odeszły dawno w zapomnienie.

Gdybym IBM nie uwolnił sprzętu, robiliby od strony hardware co chcieli i
brali za to kasy ile chcieli. Bo mieliby monopol i ludzie nie mieliby
wyjścia. Nawet wyprodukowanie jakiejkolwiek karty ISA 8-bit wymagałoby
zgody albo opłat licencyjnych dla IBM. Oczywiście tak wysokich, jakby
chcieli.

>>> Dokładnie taka sama powstała by gdyby inny procesor wsadzono w PC, w
>>> dobrej cenie i otwarto platformę. Można dyskutować czy taki był wtedy
>>> na rynku.
>> Więc poproszę o konkrety - co powinien był zrobić IBM
>
> Aby powiedzieć "zapoczątkował rewolucję" należało by porozmawiać o
> udziale przypadku w tym całym biznesie.
>
> Bo dla mnie rewolucje zapoczątkował 100x bardziej Apple, dostarczając
> GUIowy system operacyjny, zamiast filesystemu z promptem godnego lat 70.

I poległ na początku, bo nic nie uwolnił. Przy czym im nie chodziło o
dominację na rynku nigdy.

> Nie rozumiesz czego się czepiam.
>
> Czepiam się piprzenia o wielkim zapoczątkowaniu rewolucji, itd itp. Nie,
> nic z tego gównianego MS-DOSa i x86 nie zostało do dzisiaj gdziekolwiek,
> poza żałosnym CMD windowsa, a cała ta rewolucja zapoczątkowana przez IBM

Rewolucją było UWOLNIENIE sprzętu. Nie architektura, nie dos. Tylko
UWOLNIENIE. Pozwolenie na produkcję sprzętów "kompatybilnych".

L.

do góry

On 09/01/2021 20:57, Luke wrote:
> Nie piszę co oni wzięli, lecz że UWOLNILI.

A co było niewolne?

>> Nic? Czekaj, czyli potwierdzasz tezę o zapaści?
> Skoro DOS ludziom wystarczał

Nie wystarczał. Patrz na Apple.

> i nie było konkurencji

Patrz na Apple.

>, był brak rozwoju.

Czyli stracone lata.

> Zapaść?

Wstecznictwo. Kiedy ludzie w końcówce lat 70 prjektują systemy
wielozadaniowe, preemptive multitasking, wielodostęp, GUI itd itp IBM
nasrał na to wszystko pudrując CP/M w dziadowskiej architektórze i
sprzedając prawie za darmo. Fizycznie są odpowiedzialni za zatrzymanie
rozwoju informatyki na wiele lat.

> Hardware była.

Raczej tylko kolonowali kiepski design.

> Od Windows 98 do Me oraz od wczesnych Office aż do 97 włącznie nawet nie
> łatano dziur.

Win 98 SE.

Me miał system aktualizacji i nawet w ograniczonej formie działał.

> Bo ludzie i tak będą kupowali.

Bo gry były.

> Gdybym IBM nie uwolnił sprzętu

NIkt nie ma pretencji IBM że uwolnił sprzęt. Pretensje można mieć że
uwolnił *taki* sprzęt.

> Nawet wyprodukowanie jakiejkolwiek karty ISA 8-bit wymagałoby
> zgody albo opłat licencyjnych dla IBM.

Nie ma to nijak związku z dziadowską architekturą x86 i dziadowskim
systemem operacyjnym.

Uwolnić mogli cokowliek, np. komputer oparty o MC68000. O mały włos tak
się nie stało.

>> Bo dla mnie rewolucje zapoczątkował 100x bardziej Apple, dostarczając
>> GUIowy system operacyjny, zamiast filesystemu z promptem godnego lat 70.
> I poległ na początku, bo nic nie uwolnił.

A świat klepał klony Apple II w ilościach hurtowych, wliczając w to
nieskoczone ilosci peryferiów do niego.

https://en.wikipedia.org/wiki/List_of_Apple_II_clone
s

> Przy czym im nie chodziło o
> dominację na rynku nigdy.

I jakoś zdominowali rynek w USA.

>> Czepiam się piprzenia o wielkim zapoczątkowaniu rewolucji, itd itp.
>> Nie, nic z tego gównianego MS-DOSa i x86 nie zostało do dzisiaj
>> gdziekolwiek, poza żałosnym CMD windowsa, a cała ta rewolucja
>> zapoczątkowana przez IBM
> Rewolucją było UWOLNIENIE sprzętu.

Też nie. Poskładany na kolanie komputer z żałosnego cpu i kilku układów
TTL trudno nazwać jakoś specjalnie rewolucyjnym.

Takich uwolnien z okolic "każdy może robić peryferia" było kilka w
świecie 8/16/32-bit. IBMowi się najzwyczajniej udało przebić, być może
tylko dlatego że dzięki małym kombinacjom MS zdobył pokaźną ilośc
software kiepskiej jakości na start i jakoś poleciało. Nie doceniasz
roli przypadku w losach świata. A jak by MS nie miał skąd zajumać QDOS,
to jaki mieli by rynek i skąd by wzieli OSa? Przecież nie potrafili sami
napisać.

> Nie architektura, nie dos. Tylko
> UWOLNIENIE. Pozwolenie na produkcję sprzętów "kompatybilnych".

Gdyby tego nie zrobili prędzej czy później uwolniło by się coś innego.

Tymczasem spuszczono ze smyczy najgosze możliwe rozwiązanie. I tyle było
z rewolucji.

do góry

W dniu 09.01.2021 o 21:28, heby pisze:
> On 09/01/2021 20:57, Luke wrote:
>> Nie piszę co oni wzięli, lecz że UWOLNILI.
>
> A co było niewolne?
>
>>> Nic? Czekaj, czyli potwierdzasz tezę o zapaści?
>> Skoro DOS ludziom wystarczał
>
> Nie wystarczał. Patrz na Apple.
>
>> i nie było konkurencji
>
> Patrz na Apple.

Jakoś rynku nie podbiło

do góry