On 10/01/2021 14:37, Smok Eustachy wrote:
>> Patrz na Apple.
>  Jakoś rynku nie podbiło

Zapytaj kogokolwiek w USA, co podbiło *tam* rynek.

do góry

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

Osobiście nie mam problemu z określeniem "POSIX subset".
Więc chcę, żeby januszowe RTOSiki implementowały "POSIX subset" - w takim zakresie, w
jakim w ogóle coś implementują.

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

I w konsekwencji program, który nie korzysta ze *wszystkiego* nie jest programem
POSIXowym?
A program, który nie korzysta ze *wszystkiego* z biblioteki standardowej C++ nie jest
programem w C++?

Ja ze słowem "subset" nie mam problemu, zwłaszcza w embedded.
Natomiast mam problem z niekompatybilnością bez wartości dodanej.

> > I niepotrzebnych rzeczy nie ma, zwłaszcza w systemach embedded.
> To po co tam wciskać POSIXa skoro używa się 5% jego api?

Dokładnie po to, co opisano w pierwszym zdaniu na wikipedii, któro nadal uporczywie
ignorujesz. Po to, żeby zapewnić "compatibility between operating systems".

> > Sam sobie zaprzeczasz. "W jakiejś implementacji"?
> Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior.

Czyli tego określenia też nie rozumiesz. Może podaj przykład.

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

Najpierw podaj przykład tego UB. Wtedy będzie wiadomo, co trzeba z tym UB zrobić,
żeby przestało być UB - a w dalszej kolejności jak to zweryfikować.

Ciekawe, że UB nie przeszkadza w osiągnięciu celu, którym jest przenośność. Tak jest
też w C albo w C++.

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

To, że może, to nie znaczy, że musi (patrz subset). A jeśli w ogóle nie ma read?
Mówimy o embedded.

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

Jest bazujący na API FreeRTOS z takiego powodu, że ktoś chce zarobić na tych
wszystkich ludziach, którzy zaczęli robić projekty na januszowym FreeRTOS i dotarli z
tymi projektami do punktu, w którym ktoś ich pyta o jakość (ale jak to?) a *nie są w
stanie przenieść tych projektów na inny system, bo są więźniami tego nieprzenośnego
API. Wtedy płacą cenę (w formie licencji za SafeRTOS) za januszostwo i olewanie
standardów.
A gdyby tak zaczęli, od początku, zgodnie ze standardami? To nie byliby skazani na tą
jedyną ofertę "nie do odrzucenia". To się nazywa ten vendor-lockin, o którym pisałeś.
Tutaj, oczywiście, wykażasz się odpornością na to zjawisko, bo napisałeś sobie
wrapper. Ja się wykażę odpornością, bo piszę pod standard. Możemy się pogodzić w tym,
że żaden z nas nie musi płacić za SafeRTOS.

> > 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!:
> }

Dalej nie rozumiesz. Nikt nie każdy RTOSowi zwracać wszystkich możliwych błędów.
Standard mówi, jakie błędy można zwrócić, a nie jakie trzeba. Więc jeśli jakiś RTOS
ma tylko 3 stany w swojej implementacji, to te trzy stany mogą się nazywać tak jak w
POSIX a nie inaczej "bo tak". Słowo klucz: "subset".

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

Albo i nie. Systemów POSIXowych jest chyba więcej, niż tych wspieranych przez Qt.
W szczególności, wspomniany przeze mnie TI-RTOS (od Texasa) ma interfejs POSIX a
raczej Qt tam nie zadziała.

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

pthread_mutex_init ma argument pthread_mutexattr_t, w dodatku przez wskaźnik, więc
możliwości funkcjonalne tego są właściwie nieograniczone. Może być NULL dla
zachowania domyślnego. Nie ma problemu, żeby w tej jednej funkcji zmieścić zarówno
bezargumentową inicjalizację, jak i specjalne ficzery.
Właśnie o to chodzi w standardach.

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

Nie napisałeś niczego, żeby to potwierdzić.

> >, gdyby twórcy januszowych RTOSików
>
> A twórcy januszowych Windowsów?

Również. https://www.integrasources.com/blog/windows-ce-end-o
f-life-medical-devices/

Tak to jest jak się uwierzy komuś, kto olewa standardy.

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

Mocka muteksa? A po co? Normalny muteks po prostu działa, bo... no właśnie, bo jest
standardowy.

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

Znowu manipulujesz. Aplikacja jest napisana na jakiś system embedded. A konkretnie na
POSIXowy system. Sprzedam ją bez problemu. To, że być może testy nieformalne (!) były
puszczane na Cygwinie, nie ma żadnego znaczenia.

> pozerkaj jak bardzo
> wieli ból dupy mają twórcy cygwina z powodu niekompatybilnosci POSIXA z
> WinApi

Nie jest to problemem dla *subsetu*, którego używam w projektach embedded.

> POSIX to jest taki standard z przypadku. Microsoft
> nie ma śadu powodu aby go używac.

Za to ludzie, którzy użyli Windowsa CE, mają teraz powody, żeby się przenosić gdzie
indziej.

> > Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być
> Idealista.

Inżynier. :-)

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

Specjalnie nie jest, jest po prostu racjonalne, o ile w ogóle trzeba na jakimś API
polegać.
Natomiast specjalnie nieprofesjonalne jest na siłę nieprzestrzeganie standardów, "bo
nie".

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

do góry

> > A twórcy januszowych Windowsów?
> Również. https://www.integrasources.com/blog/windows-ce-end-o
f-life-medical-devices/
>
> Tak to jest jak się uwierzy komuś, kto olewa standardy.

Ciekawostka, dopiero teraz do mnie to dotarło, w tym artykule jest propozycja kilku
scenariuszy ratunkowych na okoliczność zgonu Windowsa CE, nawet ładny obrazek jest:

https://www.integrasources.com/media/files/django-ck
editor-5/Commercial_OSes.png

Jako trzy opcje migracji z Windowsa CE podano QNX, Integrity (Green Hills) i VxWorks
(Wind River). Każdy z tych trzech to... POSIX, o czym z dumą informują producenci na
swoich stronach.

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

do góry

On 10/01/2021 16:56, Maciej Sobczak wrote:
> Osobiście nie mam problemu z określeniem "POSIX subset".

Super. To wiele wyjaśnia.

> Więc chcę, żeby januszowe RTOSiki implementowały "POSIX subset"

A jeśli sa z nim niezgodne, tak fundamentalnie? Na przykłąd są
cooperative-multitasking a nie preemptive? Co wtedy? Nie pisać softu na
cooperative bo ktoś 50 lat temu zrobił dziadowskie api?

>> Każda konfiguracja, inna niż *wszystko*, nie jest już POSIXem.
> I w konsekwencji program, który nie korzysta ze *wszystkiego* nie jest programem
POSIXowym?

Nie. Bo to nie działa w tą stronę. Musisz mieć pełny POSIX aby nazywać
to "POSIX". nie musisz używać całego PISOXu aby mówić "potrzebuje POSIXU".

> A program, który nie korzysta ze *wszystkiego* z biblioteki standardowej C++ nie
jest programem w C++?

Nie, to najzwyczajniej głupota.

Ale kompilator nie majacy RAII nie jest kompilatorem C++. To analogia w
tą samą stronę co "POSIX bez pipes". POSIX bez pipes to nie POSIX.
Możesz sobie użyć tego "subset". To dalej nie POSIX.

>>> I niepotrzebnych rzeczy nie ma, zwłaszcza w systemach embedded.
>> To po co tam wciskać POSIXa skoro używa się 5% jego api?
> Dokładnie po to, co opisano w pierwszym zdaniu na wikipedii, któro nadal uporczywie
ignorujesz. Po to, żeby zapewnić "compatibility between operating systems".

Które nie działa, w szczególności embedded.

Mam wrażenie że tuptasz ze złością nózką krzycząc "wszystko powinno być
POSIXem" a tu bach, prawie nic w emebdded nie jest, i tylko troche, w
większym świecie, jest.

>>> Sam sobie zaprzeczasz. "W jakiejś implementacji"?
>> Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior.
> Czyli tego określenia też nie rozumiesz. Może podaj przykład.

Proszę:

1:

Mam jedną rurę. Jedne deskryptor do zapisu i jeden do odczytu.

Zrób dwa wątki piszące do tego samego deskryptora do zapisu.

Określ jakie dane będą lądować po drugiej stronie.

2: Zwołaj ::read i loscią dancyh większą niż SSIZE_MAX (dozwolone).

> Ciekawe, że UB nie przeszkadza w osiągnięciu celu, którym jest przenośność. Tak
jest też w C albo w C++.

Nic dziwnego, nie używa się konstrukcji tego typu w poważnym sofcie.

>> Jeśli z ::read może wylecieć 20 róznych stanów to nie jest to dobre API.
> To, że może, to nie znaczy, że musi (patrz subset)

Oczywicie, jak widzę szybko redukujesz swojego POSIXa do jakiegoś
stabilnego iface, tak trzymaj!

>> 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.
> Jest bazujący na API FreeRTOS

OK, czyli nie POSIXie.

> z takiego powodu, że ktoś chce zarobić na tych wszystkich ludziach

Albo może są inne powody? Na przykład komplikacja?

>, którzy zaczęli robić projekty na januszowym FreeRTOS

A ci co zaczeli na januszowym Linuxie? Ich też będzie obrażał że mogli
od razu na pełnej profesce HP Unix? A na ch?

> Wtedy płacą cenę (w formie licencji za SafeRTOS) za januszostwo i olewanie
standardów.

Albo najzwyczajniej wliczyli to w projekt. Startujemy na OS, a potem
przejdziemy na CS.

> A gdyby tak zaczęli, od początku, zgodnie ze standardami?

To by nigdy nie wystarowali.

> To nie byliby skazani na tą jedyną ofertę "nie do odrzucenia".

Ale oni nie są to tego stopnia głupi żeby nie mieć abstrakcji na to
FreeTROS. Naprawdę, ludzie nie są aż tak głupi.

> To się nazywa ten vendor-lockin, o którym pisałeś.

Nie, poza jakimiś kiepsko napisanymi aplikacjami które uzależniły się od
FreeRTOSa albo POSIXa, to ogólnie nie jest problem.

> Tutaj, oczywiście, wykażasz się odpornością na to zjawisko, bo napisałeś sobie
wrapper.

I kompiluje sie pod kilkoma rodzinami OSów.

> Ja się wykażę odpornością, bo piszę pod standard.

I kompiluje się pod jadna rodziną OSów prawie nieprzydatną w embedded.

>>> 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!:
>> }
> Dalej nie rozumiesz. Nikt nie każdy RTOSowi zwracać wszystkich możliwych błędów.

Ale musisz mieć ich obsługę. W końcu piszesz coś komaptybilnego z POSIX,
prawda? A POSIX mówi że "Almost" wyleci w piątek po 16. A ty nie masz
case. To nie przejdzie przez review.

> Standard mówi, jakie błędy można zwrócić, a nie jakie trzeba.

A pisanie zgodnie ze standardem nie ma takiego komfortu. Musisz obsłuzyć
wszystko, inaczej nie przejdziesz certyfikacji.

A jak zmienisz OS to już w ogóle w dupie jesteś. Bo tam akurat "Almost"
zwraca się też we wtorek. Bo może.

> Więc jeśli jakiś RTOS ma tylko 3 stany w swojej implementacji, to te trzy stany
mogą się nazywać tak jak w POSIX a nie inaczej "bo tak".

Innymi słowy nie tylko jesteś API-locki ale jeszcze
implementation-lockin. Coraz lepiej.

> Słowo klucz: "subset".

Słowo klucz: zmiana na inny OS.

>> A program napisany w Qt jest jeszcze bardziej przenośny od tego w POSIXie.
> Albo i nie. Systemów POSIXowych jest chyba więcej, niż tych wspieranych przez Qt.

Jeśli liczysz że Debian 3.1 i Debian 3.2 to rózne systemy, to faktycznie.

> W szczególności, wspomniany przeze mnie TI-RTOS (od Texasa) ma interfejs POSIX a
raczej Qt tam nie zadziała.

A ktoś go tam potrzebuje?

PS. Qt miało też własnego OSa.

>> Na przykład obok jest CreateMutex biorący 3 parametry.
> pthread_mutex_init ma argument pthread_mutexattr_t, w dodatku przez wskaźnik, więc
możliwości funkcjonalne tego są właściwie nieograniczone. Może być NULL dla
zachowania domyślnego. Nie ma problemu, żeby w tej jednej funkcji zmieścić zarówno
bezargumentową inicjalizację, jak i specjalne ficzery.
> Właśnie o to chodzi w standardach.

Nie, ktoś te 3 parametry w CreateMutex musi ustawić. Kto to zrobi?

To prosta funkcja, a już problemy.

Jak przejdziesz do named pipes, to okaże się że API POSIXa i API Win
jest fundalemntalnie rózne, nie tylko pod kątem paramterów, ale wzorca
użycia.

>>> 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.
> Nie napisałeś niczego, żeby to potwierdzić.

Ależ napisałem wielokrotnie. Jeden rzut oka na funkcje ::read wystarczy:

EINTR The call was interrupted by a signal before any data was read;

Innymi słowy ::read zajmuje się dodatkowo obsługą sygnałów. Nie kojarzę
innego, równie popsutego API. "Ta funkcja rysuje kwadraty i spuszca wodę
w kiblu, jednocześnie".

>>> , gdyby twórcy januszowych RTOSików
>> A twórcy januszowych Windowsów?
> Również. https://www.integrasources.com/blog/windows-ce-end-o
f-life-medical-devices/

Ale pytam o Windowsy współczesne.

> Tak to jest jak się uwierzy komuś, kto olewa standardy.

Niezupełnie, CE było bardzo popularnym systemem przez wiele lat.

>>> 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.
> Mocka muteksa? A po co? Normalny muteks po prostu działa, bo... no właśnie, bo jest
standardowy.

Wiec nie da się go łatwo testować.

>>> 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,
> Znowu manipulujesz. Aplikacja jest napisana na jakiś system embedded.

Albo nie.

> A konkretnie na POSIXowy system. Sprzedam ją bez problemu. To, że być może testy
nieformalne (!) były puszczane na Cygwinie, nie ma żadnego znaczenia.

Ma, pewnieważ cygwin zachowuje się inaczej niż każdy inny system
POSIXowy, głównie z uwagi na to że jego emulacja POSIXa na windowsie
jest słaba.

>> pozerkaj jak bardzo
>> wieli ból dupy mają twórcy cygwina z powodu niekompatybilnosci POSIXA z
>> WinApi
> Nie jest to problemem dla *subsetu*, którego używam w projektach embedded.

Ten "subset" pojawił się stosunkowo niedawno w tej dyskusji, i chyba
całe szczęscie że znalazłeś ten workaround, inaczej była by bida.

>> POSIX to jest taki standard z przypadku. Microsoft
>> nie ma śadu powodu aby go używac.
> Za to ludzie, którzy użyli Windowsa CE, mają teraz powody, żeby się przenosić gdzie
indziej.

Przez wiele lat nie mieli tych powodów.

>>> Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być
>> Idealista.
> Inżynier. :-)

O tak.

>> Tupanie nogą że świat nie jest POSIXowy i na siłe uzależnianei się od
>> tego kipeskiego API nie jest specjalnie profesjonalne.
> Specjalnie nie jest, jest po prostu racjonalne, o ile w ogóle trzeba na jakimś API
polegać.

Można nie polegać, o czym cała ta dyskusja. Mam wrażenie że ten POSIX to
taka kwestia religijna. Trzeba na nim polegać bo na czymś trzeba. No
więc nie, można być ateistą i nie wierzyć w ani jedno OS API.

> Natomiast specjalnie nieprofesjonalne jest na siłę nieprzestrzeganie standardów,
"bo nie".

To nie mój wybór. Suweren wybrał *również* inne systemy.

do góry

W dniu 10.01.2021 o 15:43, heby pisze:
> On 10/01/2021 14:37, Smok Eustachy wrote:
>>> Patrz na Apple.
>>   Jakoś rynku nie podbiło
>
> Zapytaj kogokolwiek w USA, co podbiło *tam* rynek.

Ile ma % a ile pecety?

do góry

On 10/01/2021 21:07, Smok Eustachy wrote:
>>>> Patrz na Apple.
>>>   Jakoś rynku nie podbiło
>> Zapytaj kogokolwiek w USA, co podbiło *tam* rynek.
> Ile ma % a ile pecety?

Wtedy? Na początku lat 80 nie było nic innego "profesjonalnego do domu"
niż Apple, wersja II dominowała. De facto to był własnie pecet tamtych
czasów.

do góry

W dniu 10.01.2021 o 21:49, heby pisze:
> On 10/01/2021 21:07, Smok Eustachy wrote:
>>>>> Patrz na Apple.
>>>>   Jakoś rynku nie podbiło
>>> Zapytaj kogokolwiek w USA, co podbiło *tam* rynek.
>> Ile ma % a ile pecety?
>
> Wtedy? Na początku lat 80 nie było nic innego "profesjonalnego do domu"
> niż Apple, wersja II dominowała. De facto to był własnie pecet tamtych
> czasów.

Apple wersja 2 ma ten sam procek co C64 i litery wyświetla tylko duże.
Tak donosi Wiki.

do góry

On 11/01/2021 09:24, Smok Eustachy wrote:
> Apple wersja 2 ma ten sam procek co C64

A PC odpicowany procesor stosowany z ZX Spectrum (np prawie, bo
odpicowali gorszy niz w ZX...).

> i litery wyświetla tylko duże.

A PC wyświetla tylko brzydkie literki w większosci instalacji (MDA), a w
obu można było dokupić lepsze karty grafiki. Przy czym Apple potrafiło
dzięki sztuczkom z sygnałem NTSC wyświetlać kolor OOTB. Oba miały
gniazda na karty.

> Tak donosi Wiki.

Takie czasy były.

do góry

Smok Eustachy wrote:

> W dniu 10.01.2021 o 21:49, heby pisze:
>> On 10/01/2021 21:07, Smok Eustachy wrote:
>>>>>> Patrz na Apple.
>>>>>   Jakoś rynku nie podbiło
>>>> Zapytaj kogokolwiek w USA, co podbiło *tam* rynek.
>>> Ile ma % a ile pecety?
>>
>> Wtedy? Na początku lat 80 nie było nic innego "profesjonalnego do domu"
>> niż Apple, wersja II dominowała. De facto to był własnie pecet tamtych
>> czasów.
>
> Apple wersja 2 ma ten sam procek co C64 i litery wyświetla tylko duże.
> Tak donosi Wiki.

Wg tego artykułu sprzedaż pecety przebiły sprzedaż C64 i zdobyły większość
rynku dopiero w 1985:


<https://arstechnica.com/information-technology/2012
/08/from-altair-to-ipad-35-years-of-personal-compute
r-market-share/2/>

--
They laughed at Columbus, they laughed at Fulton, they laughed at the
Wright Brothers. But they also laughed at Bozo the Clown.

do góry

2021-01-11 o 12:33 +0100, heby napisał:
> A PC wyświetla tylko brzydkie literki w większosci instalacji (MDA)

Akurat MDA wyświetla bardzo śliczne literki. Pozwala również na
sprzętowe podkreślanie. Bardzo fajna sprawa.

> a w obu można było dokupić lepsze karty grafiki.

W PC dostępne były (początkowo) tylko MDA i CGA - żadna nie jest
"lepsza", służą po prostu do różnych rzeczy. Ew. można mieć obie naraz,
co pozwala pracować w dual screen.

Mateusz

do góry