🚀 go-pugleaf

> Jest już tak, że do poważnych rzeczy - "produkcyjnych" - nadaje 
> się chyba tylko Linux.

A to nie jest tak od, no nie wiem, 15 lat?
Przecież Linux opanował niemal cały ekosystem serwerowy (a co za tym idzie chmurowy) właśnie z tych powodów, o których napisałeś.

Przy czym warto rozróżnić rzeczy "produkcyjne" desktopowe od serwerowych. Desktopowe to np. tworzenie tzw. "kontentu", do czego zwyczajowo Linux nadaje się tak sobie albo wcale, ale Mac zwyczajowo nadawał się bardziej, niż Windows. Natomiast w części serwerowej chyba nie ma kłótni, chociaż niektórzy jeszcze się kłócą czy Linux czy *BSD, albo który Linux.

> A to prowadzi do wniosku że zarówno C# jak 
> i Azure są zupełnie nieprzydatne, jako zbyt mocno osadzone w 
> ekosystemie Windows. 

A to nie jest tak od, no nie wiem, od zawsze?

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

slawek <x.y@org.org> wrote:

> MS robi naprawdę dużo aby nie dało się używać Windows.
> 
> Wyłączyłaś uprawnienia dla kamery? Aktualizacja je po cichu włączy
>  kamerę i mikrofon. Nie chcesz aby kopie fotek były wysyłane poza
>  twój komputer? Aktualizacja pomyśli za ciebie o zrobieniu backupu
>  na serwerze MS. (MS deklaruje że je ogląda, patrz EULA chmurki.)

NTG. Cross & FUT: pcoa.

-- 
Po upojnej nocy ze słonicą, mrówek ledwo żywy kładzie się pod drzewem.
Podchodzi do niego kolega.
- Cos taki wypompowany?
- Tak to jest, gdy chce się dogodzić ukochanej : buzi, dupci, buzi,
dupci, a kilometry lecą...

arnold@hooterville.invalid (Arnold Ziffel) Wrote in message:
> NTG


Ależ oczywiście że ta grupa.

Primo - jaki język wybrać - nawet nie pod konkretny projekt - ale
 jako instrument w opanowaniu którego chce się osiągnąć
 doskonałość - to jak najbardziej "programming". Przez około 10
 lat używałem C# do różnych rzeczy - nie powiem, całkiem znośny
 język (zwłaszcza porównując z VB.NET)... ale - między innymi - z
 przyczyn o jakich pisałem wcześniej - totalnie odradzam tracenie
 na C# czasu - to już Lispa się lepiej pouczyć.

Secundo - jakoś wcześniej nie potrzebowałem Azure. Noż toż może
 warto byłoby? Może akurat omija mnie coś Wielkiego i Wspaniałego
 (niczym twoja znajoma Słonica o której piszesz)? Ale gdy widzę
 jak gimbusy z MS kombinują - gdy de facto na dzień dobry mam
 płacić za coś co normalnie miałem i mam za darmo... To czuję się
 jakby mniej zainteresowany.

I żeby nie tego... Pierwsze MS Windows z jakimi los mnie zetknął
 to 2.0. Ale dziś widzę że jeżeli coś robić, to tylko takie rzeczy
 które są niezależne od. Bo szklarnia ogranicza, utrudnia i
 ogólnie. Jedyne co mi można zarzucić to fakt iż dostrzegam to
 nieco za późno. No ale lepiej późno, niż wcale.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message:
> > Jest już tak, że do poważnych rzeczy - "produkcyjnych" - nadaje > się chyba tylko Linux.A to nie jest tak od, no nie wiem, 15 lat?Przecież Linux opanował niemal cały ekosystem serwerowy (a co za tym idzie chmurowy) właśnie z tych powodów, o których napisałeś.


A i owszem.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

W dniu 24.12.2020 o 12:02, slawek pisze:

> I żeby nie tego... Pierwsze MS Windows z jakimi los mnie zetknął
>   to 2.0. Ale dziś widzę że jeżeli coś robić, to tylko takie rzeczy
>   które są niezależne od. Bo szklarnia ogranicza, utrudnia i
>   ogólnie. Jedyne co mi można zarzucić to fakt iż dostrzegam to
>   nieco za późno. No ale lepiej późno, niż wcale.

To, co zrobiła firma IBM (pozwoliła na produkcje sprzętów 
KOMPATYBILNYCH), doprowadziło do jednego z największych skoków 
cywilizacyjnych w historii ludzkości. Gdyby nie to, mielibyśmy dziś 
zamiast pecetów tuzin konkurujących ze sobą 64-bitowych Atari, 
Commodore, Amstrad i Sinclair (oczywiście inne firmy i inne nazwy). I 
żaden nie nadawałby się do wszystkiego, a portowanie oprogramowania 
wymagałoby lat.

Jakimś cudem przez pewien czas ludzie rozumieli, że ta kompatybilność to 
dobra ścieżka. A nawet, że wszystko powinno ze sobą współgrać również na 
bazie formatów, protokołów i języków.

Niestety, cywilizacje zaliczają wzloty i upadki.

Ja jakieś 10 lat będziemy znowu w tej krainie, gdzie ARM-owe Apple będą 
niekompatybilne z niczym, gdzie Linux nie będzie doganiał kolejnych 
zmian architektur sprzętowych, gdzie bloby driverowe będą go celowo 
destabilizowały, rynek przejmą kosteczki z wgranym firmware (obecnie 
takimi kosteczkami są smartfony, smarttv, tablety)  a każdy system 
stworzy sobie własny całkowicie niekompatybilny język programowania.

A przeciętny komputer po 2 latach nie da się zaktualizować, producent 
przestanie go wspierać, a wytworzenie alternatywnego open systemu będzie 
nieopłacalne, więc zaliczy złom i nawet za 50 lat miłośnicy vintage 
dadzą sobie spokój.

C(++), Python, może jakieś forki Javy. Może jeszcze w tym uda się 
wytworzyć jakieś w miarę przenośne softy w przyszłości.

Ewentualnie wszystko może pójść w stronę webassembly. Wtedy system 
będzie "dostarczycielem przeglądarki" w której wszystko będzie 
uruchamiane. A przeglądarka będzie softem na tyle kompleksowym, że nikt 
nie będzie w stanie napisać od zera nowej ;)

L.

On 03/01/2021 12:42, Luke wrote:
> To, co zrobiła firma IBM (pozwoliła na produkcje sprzętów 
> KOMPATYBILNYCH), doprowadziło do jednego z największych skoków 
> cywilizacyjnych w historii ludzkości.

Nie. Wygenerowało lata dominacji gównanego DOSa, de facto kradzionego 
CP/Ma. I to w czasach kiedy postęp informatyki na uczelniach oferował 
rozwiązania znacznie lepsze i nowoczesniejsze. Efektem "skoku 
cywilizacyjnego IBM" jest raczej zapaść informatyki na wiele lat i 
usunięcie z widoku znacznie bardziej nowoczesnych rozwiązań, które 
implementowano w równoległych systemach. IBM to wtedy taki chińczyk, 
zalewający świat skrajną tandetą. Wiele kosztów tej "rewolucji" płacimy 
do dzisiaj w swoich komputerach posiadając masę "technologii" w 
procesorze psu na budę potrzebnych, ale "kompatybilnych z CP/M, tfu, DOS".

> Ja jakieś 10 lat będziemy znowu w tej krainie, gdzie ARM-owe Apple będą 
> niekompatybilne z niczym

Nie dostrzegasz drugiej storony. Przed chwilą rynkiem zatrzesły 
informacje o tym jak sprawuje się RISC-V. Wygląda na to że reszta leży i 
kwiczy. Nie wykluczone, że to początek ścinki drzew na trumny do ARMa. A 
świat ma dość firmy ARM od bardzo dawna.

> Nie dostrzegasz drugiej storony. Przed chwilą rynkiem zatrzesły 
> informacje o tym jak sprawuje się RISC-V.

Znowu?
Znaczy - znowu zatrzęsły, i znowu nic z tego nie wynika?

> Wygląda na to że reszta leży i 
> kwiczy.

Reszta obsługuje cały działający na świecie soft. To całkiem nieźle, jak na "leżenie i kwiczenie".

> Nie wykluczone, że to początek ścinki drzew na trumny do ARMa. A 
> świat ma dość firmy ARM od bardzo dawna.

Tak bardzo mają dość, że najcenniejsza firma w branży postanowiła cały swój ekosystem na to przestawić?
Bez przesady.
Gdybyś powiedział, że świat ma dość Intela, to by to przynajmniej pasowało do reszty Twojego posta (o złogach z czasów DOSa). I nawet bym się z tym zgodził. Ale że ARM? Odwołam się do klasyka: pogłoski o śmierci ARM są mocno przesadzone. Pojeździmy tym pewnie jeszcze dekadę. 

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

On 03/01/2021 16:19, Maciej Sobczak wrote:
>> Nie dostrzegasz drugiej storony. Przed chwilą rynkiem zatrzesły
>> informacje o tym jak sprawuje się RISC-V.
> Znowu?

Tak. Po pierwsze przecieramy oczy ze zdumienia w kwestii wydajności/W 
[1], po drugie trwa wyścig zbrojeń kto zrobi pierwszy cpu wywalający ARM 
z embedded, na dobre.

> Znaczy - znowu zatrzęsły, i znowu nic z tego nie wynika?

Wręcz przeciwnie. Wynika to że na rynku EDA trwa własnie przetasowanie w 
kwestii podejścia do projektowania embedded i masa firm udostepnia 
narzedzia do RISC-V. I to wszystko stało się "nagle". 2-3 lata temu 
każdy kto mówił o zmierzchu ARMów był traktowany jak świr, a obecnie nie 
wygląda już to tak śmiesznie.

>> Wygląda na to że reszta leży i
>> kwiczy.
> Reszta obsługuje cały działający na świecie soft. To całkiem nieźle, jak na "leżenie i kwiczenie".

Soft łatwo przekompilować. Przy robieniu nowego softu to nie jest 
argument. Choć oczywiscie może być tak że firma ma tak żałosny kod że 
przekompilowanie jest równoznaczne z pełnym refaktoringiem, ale to 
miejmy nadzieje, tylko żałosne firmy.

Pamiętaj że RISC-V jest rewolucją w embedded a nie desktopach. Na razie.

>> Nie wykluczone, że to początek ścinki drzew na trumny do ARMa. A
>> świat ma dość firmy ARM od bardzo dawna.
> Tak bardzo mają dość, że najcenniejsza firma w branży postanowiła cały swój ekosystem na to przestawić?

Apple ma dośc pieniędzy aby rozmawiać z ARMem. Mniejsi producenci mają dość.

> Bez przesady.

Jeśli liczą się pojedyncze $ to koszt licencji ARMa jest poważną przeszkodą.

Jeśli startujesz nowy projekt może sie okazać że kompletnym 
nieporozumieniem jest embedowanie ARMa do SoC. Zamiast tego można 
wsadzić darmowego RISC-V, który *prawdopodobnie* będzie lepszy pod 
każdym względem, od wydajności, przez pobór mocy, po licencje (i z dnia 
na dzień widać, że to nie są obietnice bez pokrycia).

> Gdybyś powiedział, że świat ma dość Intela, to by to przynajmniej pasowało do reszty Twojego posta (o złogach z czasów DOSa).

Nie, zło jest dziełem nie Intela w całości (oni tylko zrobili obleśnie 
dziadowski klon 8080 dodając coraz to więcej śmieci w kolejnych 
generacjach). Winę ponosi wiele firm, w tym IBM i MS. To ta trójka w 
główne mierze wybrała architekturę pecetów opartą o tekture i dykte 
zaczynając od czegoś zbliżonego do ZX-Spectrum jeśli chodzi o poziom 
komplikacji i ciągnąć tą idityczną kompatybilność przez nastepne 50 
genaracji cpu.

Z resztą, może dzięki RISC-V uda się urwać i choć trochę rynku x86.

https://venturebeat.com/2020/10/29/sifive-unveils-plan-for-linux-pcs-based-on-risc-v-processors/

> Ale że ARM? Odwołam się do klasyka: pogłoski o śmierci ARM są mocno przesadzone. Pojeździmy tym pewnie jeszcze dekadę.

Ale nikt tu nie mówi o śmieci ARMa w tej chwili. Na razie ścinamy drzewa 
na trumny, bo koniec może być bliski, głównie w embedded/SoC. Indutry 
przeciera oczy ze zdumienia a inzynierowie w ARMie biegają w popłochu bo 
wystarczyła chwila nieuwagi i ktoś im udowodnił że mają kiepski produkt. 
To że w mało istotnych komputerach do oglądania porno marki Apple będzie 
się je dalej stosować, to nie wiem czy promil rynku jest.

Istotne jest jak zareaguje embedded + mobile.

[1] 
https://arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/

> > Reszta obsługuje cały działający na świecie soft. To całkiem nieźle, jak na "leżenie i kwiczenie".
> Soft łatwo przekompilować.

Sam sobie teraz zaprzeczyłeś. Właśnie najważniejszym powodem, dla którego ciągniemy te złogi technologiczne już którąś dekadę, jest to, że softu (w ogólności) nie da się przekompilować. I nawet te nowe ARMowe procki, które Apple sobie wystrugał, dalej muszą umieć puścić Intelowy soft. Bo nie da się go przekompilować.

> Przy robieniu nowego softu to nie jest 
> argument.

Z dużą dokładnością można powiedzieć, że nikt nie pisze nowego softu. Nawet (!) w embedded, gdzie na oko wydaje się, że warunki do tego są najlepsze, bo najłatwiej się odizolować. To jest dramat, wcale się nie nabijam. Wszyscy tylko dopisują nowy shit do starego shitu.

> > Tak bardzo mają dość, że najcenniejsza firma w branży postanowiła cały swój ekosystem na to przestawić?
> Apple ma dośc pieniędzy aby rozmawiać z ARMem. Mniejsi producenci mają dość.

Mniejsi producenci pójdą ścieżką wytyczoną przez tych większych. Zawsze tak było.

> Jeśli liczą się pojedyncze $ to koszt licencji ARMa jest poważną przeszkodą.

OK, jest to źródło presji. I jednocześnie pokazuje natychmiastowe rozwiązanie problemu. Kto ustala te koszty? Kto je może zmienić, nawet z dnia na dzień? Gdyby perspektywa utraty kawałka rynku stała się realna, to racjonalnym rozwiązaniem dla ARMa byłoby nawet wydzielenie całkiem darmowych licencji na jakiś dolny segment oferty, np. do jakiejś wydajności, taktowania, mocy, itp. Zupełnie na tej samej zasadzie, jak są darmowe (ale limitowane) konta na YouTubie albo GitHubie, itd.
Jeżeli problemem jest cena licencji, to jest to najmniejszy problem. I jeżeli "rewolucja" RISC-V się tylko na tym problemie opiera, to nie będzie żadnej rewolucji.

> Jeśli startujesz nowy projekt może sie okazać że kompletnym 
> nieporozumieniem jest embedowanie ARMa do SoC. Zamiast tego można 
> wsadzić darmowego RISC-V

A jak ten ARM do embedowania będzie darmowy? To po co ryzykować z czymś innym?

> Z resztą, może dzięki RISC-V uda się urwać i choć trochę rynku x86.

Jeśli jakiś kawałek rynku x86 jest do urwania, to ARM go urwie wcześniej, na kilka sposobów, rozciągających się szeroko od RaspberryPi po Apple'a. RISC-V będzie musiał konkurować o ten już urywany kawałek.

> To że w mało istotnych komputerach do oglądania porno marki Apple będzie 
> się je dalej stosować, to nie wiem czy promil rynku jest. 

Nie kapujesz. Ten promil jest nierozerwalnie sprzężony z całym rynkiem mobile.

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

W dniu 03.01.2021 o 12:53, heby pisze:

> Nie. Wygenerowało lata dominacji gównanego DOSa, de facto kradzionego 
> CP/Ma. I to w czasach kiedy postęp informatyki na uczelniach oferował 
> rozwiązania znacznie lepsze i nowoczesniejsze. 

Tak tak, to takie dyskusje jak o celowości reformy Balcerowicza.

Decyzja IBM była decyzją sprzętową. Dotyczyła produkcji podzespołów, nie 
miała nic wspólnego z DOS-em i ewentualną dominacją.

Czyli już od 1985 roku (premiera 386) można było na pecety napisać 
32-bitowe wielozadaniowce. To, że wtedy nikt nie był tym zainteresowany 
i wałkowano DOS to wynik tego samego mechanizmu, który trzyma dzisiaj 
ludzi przy Win32 mimo obecności komercyjnych i darmowych Unixów.

I dzięki tej decyzji sprzętowej na rynku powstała konkurencja łamiąca 
monopol cen.

L.

On 04/01/2021 19:02, Luke wrote:
> Decyzja IBM była decyzją sprzętową. Dotyczyła produkcji podzespołów, nie 
> miała nic wspólnego z DOS-em i ewentualną dominacją.

Intel zrobił 8086 w taki sposób aby dało się *automatycznie* translować 
oprogramowanie z 8080. I dokładnie w taki sposób zapełniono biblitekę 
programów na x86, a IBM musiał to doskonale wiedzieć. Najzwyczajniej je 
automatycznie translując z 8080 i licząc że reszta świata zrobi to samo. 
A ponieważ napatoczył się kradziony CP/M w podstaci DOSa to okazało się 
że można w ten sposób translować programy CP/Mowe właśnie i zrobić coś z 
niczego. Czyli wsadzić nowy procesor i zapełnić go gównianymi programami 
wyjętymi wprost z 8-bit na gównianą platformę sprzętową 8/16-bit+segmenty.

Intel projektując 8086 tak naprawdę wybrało go tylko dlatego że to było 
prawie to samo co 8080 + popieprzona adresacja. W zasadzie wybrał go 
mimo tej adresacji, bo trudno było to nazwać zaletą. Wybrał go tylko po 
to, aby mieć dostęp do oprogramowania 8-bit i programistów znajacych 
8080/Z80, majace zapewnić łatwy start. Zapewnił dziesięciolecia 
absurdów, kretynizmów, wstecznictwa w informatyce.

> Czyli już od 1985 roku (premiera 386) można było na pecety napisać 
> 32-bitowe wielozadaniowce. To, że wtedy nikt nie był tym zainteresowany 
> i wałkowano DOS to wynik tego samego mechanizmu, który trzyma dzisiaj 
> ludzi przy Win32 mimo obecności komercyjnych i darmowych Unixów.

To wynik zbiegów okoliczności, kilku oszustw i może szczypty ignorancji. 
IBM jak robił pierwszego peceta nie miał pojęcia jaki system go będzie 
napędzał i zwrócili się do firmy która  miała doświadczenia w pisaniu 
BASICa na C64. Wyszło jak widać, z resztą nawet nie dali rady go 
napisać, tylko "znaleźli" w dziwnych i niewyjaśnionych okolicznościach. 
Nie dało się sworzyć bardziej tragicznego systemu operacyjnego do PC, 
prawda jest taka że identyczne pod kątem złożoności systemy miały Atari 
czy Commodore i DOS niczym się nie wyróżniał poza dziedziczeniem po 
CP/Mie wszystkiego jak leci. Ludzie nie potrzebowali nic więcej, bo nie 
mieli pojęcia że coś więcej istnieje, choć w USA Maki pokazały że 
istnieje inny świat. Z jakiejś przyczyny żałosny filesystem ze znakiem 
zachęty był uważany u nas za bardziej "profesjonalny" niż normalne 
systemy operacyjne.

Ciekawe że DOS praktycznie się nie rozwijał. Wersja 6.22 wygląda na 
lekko odpicowaną wersję DOS 1.0. Nic tam specjalnie przez te lata nie 
poprawiono, dodano itd itp. Ani śladu nowoczesnych technologii, kerneli 
preemptive, wielozadaniowości, wielodostępu, wirtualizacji. Niebywałe. 
Co oni tam robili przez te wszystkie lata? DoubleSpace?

> I dzięki tej decyzji sprzętowej na rynku powstała konkurencja łamiąca 
> monopol cen.

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. Ale na pewno można było wsadzić lepszy system operacyjny, lub 
choć stworzyć system operacyjny *emulujący* CP/M a nie *będący* CP/M. 
Ale nie, wsadzono CP/M, z dokładnością do wektorów wywołań.

Całość tego wywodu jest w protesie do haseł typu "IBM dokonał 
największego skoku cywilizacyjnego". Nie, IBM, Intel i MS dokonali 
największego znanego mi wstecznictwa w historii informatyki, blokując na 
dziesięciolecia dostęp do nowoczesnych narzędzi i "zmuszając" ludzi do 
pracy w fake systemie operacyjnym wprost z 8-bit, z procesorem wprost z 
piekła pijanego wariata.

On 04/01/2021 18:59, Maciej Sobczak wrote:
>>> Reszta obsługuje cały działający na świecie soft. To całkiem nieźle, jak na "leżenie i kwiczenie".
>> Soft łatwo przekompilować.
> Sam sobie teraz zaprzeczyłeś.

W czym? Z mojego punktu widzienia i siedzenia soft łatwo przekompilować. 
Oczywisćie mowa o takim który jest obecnie w użytku. Jestem pewny że 
Lotus123 nie pójdzie na ARMie, tylko po co miałby tam iść?

> Właśnie najważniejszym powodem, dla którego ciągniemy te złogi technologiczne już którąś dekadę, jest to, że softu (w ogólności) nie da się przekompilować. I nawet te nowe ARMowe procki, które Apple sobie wystrugał, dalej muszą umieć puścić Intelowy soft. Bo nie da się go przekompilować.

Soft *współczesny* da się przekompilować. Soft stary bez problemu 
pójdzie na emulatorach, często szybciej niż na natywnych procesorach ze 
swojego czasu.

Softu, który nie da się przekompilować na nową architekturę, nie szkoda. 
Albo kiepski albo stary.

>> Przy robieniu nowego softu to nie jest
>> argument.
> Z dużą dokładnością można powiedzieć, że nikt nie pisze nowego softu.

Bo nie musi: języki wyższego poziomu zapewniły abstrakcję.

Lata 80 to bardzo dużo natywnyego asm. Wtedy moglibysmy biadolić nad 
kłopotami polegajacymi na napisaniu na nowo, ale też rozmiar był milion 
razy mniejszy. Ale obecnie? Znasz jakiś większy projekt w asm niż 
wstawki do C? Bo tylko wtedy argument "musimy napisać nowy soft" miałby 
sens.

>>> Tak bardzo mają dość, że najcenniejsza firma w branży postanowiła cały swój ekosystem na to przestawić?
>> Apple ma dośc pieniędzy aby rozmawiać z ARMem. Mniejsi producenci mają dość.
> Mniejsi producenci pójdą ścieżką wytyczoną przez tych większych. Zawsze tak było.

Nie, mniejsi producenci kupią GD32 zamiast STM32, jesli będzie o dwa 
centy tańszy. Kupią też RISC-V jeśli okaże się że będzie zapewniał o 1 
rok dłuższą pracę na baterii. Nikt nie będzie patrzyła na to, że firma 
dla snobów cośtam wybrała nowego do oglądania porno. Kogo to w ogóle 
obchodzi?

>> Jeśli liczą się pojedyncze $ to koszt licencji ARMa jest poważną przeszkodą.
> OK, jest to źródło presji. I jednocześnie pokazuje natychmiastowe rozwiązanie problemu. Kto ustala te koszty? Kto je może zmienić, nawet z dnia na dzień?

ARM może. Najważniejsze o co idzie w sytuacji z RISCV to *może* obniżka 
cen za ARM lub zmiana licencjonowania. A jeśli przy okazji jądro 
mikrokontrolerów zmienimy na lepsze/inne to naprawdę nie zrobi na nikim 
wrażenia. Oczywiście o ile softu nie piszą imbecyle, na co gwarancji nie 
ma w każdym wypadku, ale jest też najdzieja że tych wypadków jest mało.

> I jeżeli "rewolucja" RISC-V się tylko na tym problemie opiera, to nie będzie żadnej rewolucji.

RISC-V robi chyba rewolucję przypadkiem. Ogólnie industry jest 
zaskoczone że "z niczego" w ciągu zaledwie kilku lat wyrosła 
konkurencja, wydawało by się z najdoskonalszym procesorom embedded. A i 
desktopowce muszą uważać, RISC-V ma zacięcie na pokonanie ich w wersjach 
bardzo wielo rdzeniowych, do centrów obliczeniowych.

>> Jeśli startujesz nowy projekt może sie okazać że kompletnym
>> nieporozumieniem jest embedowanie ARMa do SoC. Zamiast tego można
>> wsadzić darmowego RISC-V
> A jak ten ARM do embedowania będzie darmowy?

Nie dość że narzędzia będą kosztowały to jeszcze licencja obecnie zjada 
koszta.

Jak będzie darmowy to RISC zrobi robotę. Postraszy.

Ale ja myśle że zrobi więcej. Kopnie w dupę ARMa. Boleśnie.

> To po co ryzykować z czymś innym?

Całośc rynku obecnie skupia się na produkcji narzędzi, tak aby to było 
*małe* ryzyko. Jesli team od software jest zdrowy psychicznie to każe 
sie że całą ta migracja zakończy się poprzez zmianę kompilatora w 
makefile i puszczenia testów.

>> Z resztą, może dzięki RISC-V uda się urwać i choć trochę rynku x86.
> Jeśli jakiś kawałek rynku x86 jest do urwania, to ARM go urwie wcześniej

ARM już go urwał. Jak RISC też ma chrapkę to mamy ciekawą sytuację. 
Współczesne systemy operacyjne nie mają dużego związku z x86 poza 
Windowsem, gdzie aplikacje znajduje się na wysypisku o nazwie Internet. 
Sklep im nie wyszedł, więc obecnie Windows jest jedynym powodem dla 
którego x86 ma resztkę sensu na PC, z uwagi na bardzo kiepski model 
dystrybucji softu. Na marginesie: które to PC szorują po dnie jeśli 
chodzi o zainteresowanie suwerena.

>, na kilka sposobów, rozciągających się szeroko od RaspberryPi po Apple'a. RISC-V będzie musiał konkurować o ten już urywany kawałek.

Wystarczy, że okaże się embedowalny do ASICów/FPGA i wykopie ARMa z tych 
zastosowań. Wystarczy że bedzie miał wiecej obliczeń/W i wykopie x86 z 
centrów obliczeniowych. Oba cele w zasięgu.

Desktopy? Nikt tego nie potrzebuje, poza kilkoma nerdami.

>> To że w mało istotnych komputerach do oglądania porno marki Apple będzie
>> się je dalej stosować, to nie wiem czy promil rynku jest.
> Nie kapujesz. Ten promil jest nierozerwalnie sprzężony z całym rynkiem mobile.

Przed chwilą nie był. Demonizujesz. Apple doskonale sobie poradziło z 
przejściem z x86 na ARM, znacznie lepiej niż głupi MS. To oznacza że w 
sumie jak by mieli jutro przejsc na RISC-V to mogę to zrobić w przerwie 
na kawę.

Abyśmy się zrozumieli: nie twierdze że RISC jutro przekręci rynek 
desktopów. Po pierwsze to niszowy rynek, po drugie nie mają takich celów 
(choć mają takie możliwości). Całośc RISC-V opiera się o dominacje w 
embedded gdzie ARM powoduje generowanie zbędnych kosztów na licencje 
oraz, prawdopodobnie, ma/ma mieć lepsze osiągi niż ARM (obliczenia/W).

Rynek embedded na gwałt produkuje narzędzia do RISC-V, ipcores, 
symulatory, emulatory, debuggery. ARM tego nie zatrzyma, chyba że rozda 
za darmo połowe swojego portfolio. Wątpię, to skrajne snoby.

> Softu, który nie da się przekompilować na nową architekturę, nie szkoda. 
> Albo kiepski albo stary.

Ćwiczenie.
1. NVIDIA znana jest z tego, że sterowniki do kart daje w formie binarnego bloba, a nie w postaci źródeł. Bo "IP protection", oczywiście. To oczywiście nie dotyczy tylko tego producenta, to jest powszechna praktyka.
2. NVIDIA kupuje ARMa.
Pytanie do ćwiczenia: kiedy NVIDIA będzie rozdawać sterowniki do swoich kart dla procesorów RISC-V?

No i teraz hipisi od RISC-V będą musieli jeszcze karty graficzne robić, żeby te cudowne procesory kogokolwiek zainteresowały. I tyle było z "urywania rynku x86".

> > Z dużą dokładnością można powiedzieć, że nikt nie pisze nowego softu.
> Bo nie musi: języki wyższego poziomu zapewniły abstrakcję. 

Ale ja kupuję programy już skompilowane.

> Ogólnie industry jest 
> zaskoczone że "z niczego" w ciągu zaledwie kilku lat wyrosła 
> konkurencja, wydawało by się z najdoskonalszym procesorom embedded.

Język C od dekad ma konkurencję w postaci doskonalszych języków, których nikt nie używa. DOS miał konkurencję w innych systemach, których nikt nie używał. Itp. Względy merytoryczne są drugorzędne. Albo i trzeciorzędne.

> desktopowce muszą uważać, RISC-V ma zacięcie na pokonanie ich w wersjach 
> bardzo wielo rdzeniowych, do centrów obliczeniowych.

Ciekawe, co NVIDIA sądzi na ten temat. Zwłaszcza na ten temat bardzo wielo rdzeniowy.

> Jak będzie darmowy to RISC zrobi robotę. Postraszy. 

I dobrze, bo presja jest dobra. Ale zobacz, jak Linux postraszył Windowsa, to masz teraz Linuksa w Windowsie i... dalej Windows jest na każdym komputerze w biurze. A Microsoft zarabia miliardy sprzedając przestrzeń w chmurze, w której wykorzystuje darmowe Linuksy. Microsoft zarabia na darmowych Linuksach.
Myślę, że ze strachu NVIDIA też będzie zarabiać miliony dzięki darmowym RISC-V.

> Całośc rynku obecnie skupia się na produkcji narzędzi,

Nie szkodzi. CPU to nie jest jedyna rzecz, którą trzeba kupić. Zwykle kupuje się więcej różnych rzeczy. I wtedy kupuje się u takiego producenta, który da ogólnie dobrą cenę za ogólną lojalność. Np. jak kupujesz cały silikon u Texasa, to pewnie lepiej (w pieniądzach) kupić u Texasa też CPU. I wtedy to Texas decyduje, jakie CPU sprzeda. I jeszcze narzędzia dorzuci.
W projektach przemysłowych liczy się Total Cost of Ownership, a nie to, kto ma o centa taniej jedną część, która nie pasuje do całej reszty.

> Jesli team od software jest zdrowy psychicznie to każe 
> sie że całą ta migracja zakończy się poprzez zmianę kompilatora w 
> makefile i puszczenia testów.

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. To, że Twoje kilka linijek kodu na wierzchu tego wszystkiego jest "przenośne", bo napisałeś je sobie w "języku wysokiego poziomu", który "zapewnia abstrakcje", to jest złudzenie optyczne.

> Przed chwilą nie był. Demonizujesz. Apple doskonale sobie poradziło z 
> przejściem z x86 na ARM,

Apple to już ćwiczył, więc ma wprawę - wcześniej przechodzili z PowerPC na x86. Ale wbrew temu co sądzisz o snobach oglądających pornole, akurat te prawdziwe snoby kupują te komputery raczej po to:

https://new.steinberg.net/cubase/

albo po to:

https://www.apple.com/final-cut-pro/

itp., jest tego oczywiście więcej.
I o ile widzę oczami wyobraźni jak ci producenci portują swoje produkty na nowe procki Apple'a, to entuzjazmu na portowanie na RISC-V się nie spodziewam. I nie, nie chodzi tylko o "przekompilowanie i puszczenie testów". Te produkty mają za sobą całe ekosystemy pluginów, od tzw. "firm trzecich". Pierdyliony pluginów. I weź teraz przekonaj ich twórców, że mają zrobić osobne wersje na RISC-V, bo jacyś hipisi chcą robić "rewolucję".

> Całośc RISC-V opiera się o dominacje w 
> embedded

Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas. Bo to u nich się robi zakupy a nie na GitHubie. I to od nich zależy, czy RISC-V zrobi rewolucję, czy nie zrobi.

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

On 05/01/2021 21:06, Maciej Sobczak wrote:
> Ćwiczenie.
> 1. NVIDIA znana jest z tego, że sterowniki do kart daje w formie binarnego bloba, a nie w postaci źródeł. Bo "IP protection", oczywiście. To oczywiście nie dotyczy tylko tego producenta, to jest powszechna praktyka.
> 2. NVIDIA kupuje ARMa.
> Pytanie do ćwiczenia: kiedy NVIDIA będzie rozdawać sterowniki do swoich kart dla procesorów RISC-V?

To pytanie zadaj wobec R-PI który będzie miał złacze PCI-E i da się do 
niego wsadzić kartę NVidi. Są sterowniki NVidi pod linuxa, na arm? 
Ojejkujejku! Nie będzie cyberpunka na r-pi?

> No i teraz hipisi od RISC-V będą musieli jeszcze karty graficzne robić, żeby te cudowne procesory kogokolwiek zainteresowały. I tyle było z "urywania rynku x86".

Dokładnie to samo masz z armem.

Rynek x86 to nie tylko gry. Dekoder x265 i blitter do pasjasa w gpu 
załatwia 80% potrzeb biur. Brak GPU załatwia 100% potrzeb wirtualizacji 
ukrytych giełd narkotyków, w torze.

>> Bo nie musi: języki wyższego poziomu zapewniły abstrakcję.
> Ale ja kupuję programy już skompilowane.

Bo taki masz system dystrybucji w zabawkowym systemie operacyjnym. Są 
inne, np Android ma w połowie skompilowane. Jeszcze inne mają kod 
źródłowy. W zasadzie mało kto ma skompilowane, licząc tak możliwie szeroko.

>> Ogólnie industry jest
>> zaskoczone że "z niczego" w ciągu zaledwie kilku lat wyrosła
>> konkurencja, wydawało by się z najdoskonalszym procesorom embedded.
> Język C od dekad ma konkurencję w postaci doskonalszych języków, których nikt nie używa.

Przeginasz. Język C ma konkurencje w postaci C++ której używa sie 
powszechnie, również w embedded (acz tam problemem jest raczej białko 
niż technologia). Starasz się zniknąć zmianę na rynku, ale ona tam jest, 
od dziesięcioleci. jest wiele języków używanych powszechnie w róznych 
niszach.

> DOS miał konkurencję w innych systemach, których nikt nie używał.

Przeginasz. W USA Maki były znacznie bardziej powszechne niż piedołowaty 
DOS, w wielu zastosowaniach. To że u nas ich nie było, było oczywiste. U 
nas musiało być tanio, bo dewizy.

>> desktopowce muszą uważać, RISC-V ma zacięcie na pokonanie ich w wersjach
>> bardzo wielo rdzeniowych, do centrów obliczeniowych.
> Ciekawe, co NVIDIA sądzi na ten temat. Zwłaszcza na ten temat bardzo wielo rdzeniowy.

Dokładnie co teraz: nie istnieje sens robienia klastra obliczeniowego na 
GPU do zastosowań ogólnych ponieważ GPU mają bardzo wiele wad i nie są 
"duża iloscią rdzeni", jak wielu sądzi. Czasem są przydatne, a czasem 
komplenie nieużyteczne. Beda miały swoją niszę, mają ją z resztą już w 
tej chwili.

>> Jak będzie darmowy to RISC zrobi robotę. Postraszy.
> I dobrze, bo presja jest dobra. Ale zobacz, jak Linux postraszył Windowsa

Nie przypominam sobie. Linux w '99 miał gry z akceleracją 3D?

>, to masz teraz Linuksa w Windowsie i... dalej Windows jest na każdym komputerze w biurze.

Bo są gry 3D i pasjans.

> Myślę, że ze strachu NVIDIA też będzie zarabiać miliony dzięki darmowym RISC-V.

NVidia ma obecnie na głowie AMD który stuknął ją znowu w łeb. Jesli 
kogoś się boją, to raczej konkurencji w 3D a nie konkurencji w 
klastrach, które są raczej kwesią hałasu medialnego.

>> Całośc rynku obecnie skupia się na produkcji narzędzi,
> Nie szkodzi. CPU to nie jest jedyna rzecz, którą trzeba kupić.

Pozostałe sie nie zmieniają.

> Zwykle kupuje się więcej różnych rzeczy. I wtedy kupuje się u takiego producenta, który da ogólnie dobrą cenę za ogólną lojalność.

Fajnie, ale ciezko znaleźc producenta który oferuje *wszystko*. Naprawdę 
cieżko. Ten ma symualtor i cpu, tamten weryfikację formalną, ale ma inne 
cpu, ten ma debugger do ARMów, ale nie ma symulatora itd itp.

Może to zabrzmi śmiesznie, ale wiele bardzo drogich projektów w EDA 
powstaje poprzez sklejenie wielu niespójnych narzędzi gumą do żucia i 
duża ilością perla.

> W projektach przemysłowych liczy się Total Cost of Ownership, a nie to, kto ma o centa taniej jedną część, która nie pasuje do całej reszty.

O ile to Total jest naprawdę Total. Możesię okazać że to kilka luźnuch 
narzędzi, jak to obecnie jest powszechne.

>> Jesli team od software jest zdrowy psychicznie to każe
>> sie że całą ta migracja zakończy się poprzez zmianę kompilatora w
>> makefile i puszczenia testów.
> 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.

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

> To, że Twoje kilka linijek kodu na wierzchu tego wszystkiego jest "przenośne", bo napisałeś je sobie w "języku wysokiego poziomu", który "zapewnia abstrakcje", to jest złudzenie optyczne.

Albo praktyka na codzień. Zależy gdzie siedzisz.

>> Przed chwilą nie był. Demonizujesz. Apple doskonale sobie poradziło z
>> przejściem z x86 na ARM,
> Apple to już ćwiczył, więc ma wprawę - wcześniej przechodzili z PowerPC na x86. Ale wbrew temu co sądzisz o snobach oglądających pornole

Tak wygląda rynek laptopów: snoby oglądające pornole. Szczególnie Apple, 
ich kompytery migrują w kierunku kompletnie bezuzytecznych do 
profesjonalnej pracy (złacza, klawiatura, znikanie fukncji itd itp). 
Niech sobie wsadzają Z80 jesli chcą. Obawiam się że nikogo to nie 
interesuje.

> https://www.apple.com/final-cut-pro/

A co kupują jak chcą odpalić ModelSima?

> itp., jest tego oczywiście więcej.

Wiadomo. Zapomniałeś dorzucić klasyka profesjonalizmu, czyli Autocada. 
Który w porównaniu z wieloma naprawde profesjonalnymi apliakcjami 
wygląda znacząco mniej imponująco.

> I o ile widzę oczami wyobraźni jak ci producenci portują swoje produkty na nowe procki Apple'a, to entuzjazmu na portowanie na RISC-V się nie spodziewam.

I on nigdy nie nastapi. To był argument teoretyczny: twierdzenie że 
zmiana architektury procesora jest problemem, jest idityczne. Nie jest. 
Ba, doświadczasz tego na codzień: kompilacja kodu na x86 i x86-64, dwie 
komplenie różne ISA, nie stanowi *żadnego* problemu, poza kiepskim 
kodem. API OS jest takie samo.

Gdyby, teoretycznie, Apple przeszedł na RISC-V, API systemu było by 
takie samo.

Wystarczy zmienić kompilator w makefile.

No i oczywiście zapominam o vendor-lockin, ale przecież nie rozmawiamy o 
chorych apliakcjach.

> I nie, nie chodzi tylko o "przekompilowanie i puszczenie testów". Te produkty mają za sobą całe ekosystemy pluginów, od tzw. "firm trzecich".

Vendor-lockin. Jeśli programiści mieli choć cień mózgu, to dawno się od 
tego odgrodzili abstrakcją. "Firmy trzecie" same sie zgłoszą, jeśli są 
coś warte, aby ich pluginy zastosować.

> Pierdyliony pluginów.

Skoro wybrali model pracy z okolic "niech kompilują te kolesie w 
Indiach, ojej, właśnie umarli" to dlaczego uważasz że to jest sensowny 
argument?

Sporo software ma pluginy pisane w pythone, tclu itd. I co teraz? Ten 
argument świadczy o tym że łatwo przejść, twój że ciężko, prawda po środku.

> I weź teraz przekonaj ich twórców, że mają zrobić osobne wersje na RISC-V, bo jacyś hipisi chcą robić "rewolucję".

Rynek ich przekona. Dokładnie tak, jak w tym momencie, kiedy to piszę, 
rynek przekonuje aby te wszystkie pluginy do photoshopa przekompilować 
na gwałt na ARMa, bo snoby znowu kupiły zabawki.

>> Całośc RISC-V opiera się o dominacje w
>> embedded
> 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.

> Bo to u nich się robi zakupy a nie na GitHubie.

No i widzisz, nie pojmujesz. Własnie zakupy robi się "na githubie" tylko 
że ceny są w milionach dolarów i nazywa się to ipcores/weryfikacja. 
Raczej nie dostaniesz cennika. To nie dla nas. I to jest embedded. To 
czy krzem zrobią w SMC czy Samsungu, nikogo nie obchodzi, poza księgowymi.

W dniu 04.01.2021 o 20:35, heby pisze:

> Intel zrobił 8086 w taki sposób aby dało się *automatycznie* translować 
> oprogramowanie z 8080. I dokładnie w taki sposób zapełniono biblitekę 
> niczego. Czyli wsadzić nowy procesor i zapełnić go gównianymi programami 
> wyjętymi wprost z 8-bit na gównianą platformę sprzętową 8/16-bit+segmenty.

No proszę, ktoś wypuszcza produkt wstecznie zgodny z dotychczasowymi 
rzeczami, zły i niedobry...

> To wynik zbiegów okoliczności, kilku oszustw i może szczypty ignorancji. 
> IBM jak robił pierwszego peceta nie miał pojęcia jaki system go będzie 
> napędzał i zwrócili się do firmy która  miała doświadczenia w pisaniu 
> BASICa na C64. Wyszło jak widać, z resztą nawet nie dali rady go 
> napisać, tylko "znaleźli" w dziwnych i niewyjaśnionych okolicznościach. 

Czyli potwierdzasz moją wersję - decyzja IBM była SPRZĘTOWA.

> 
> Ciekawe że DOS praktycznie się nie rozwijał. Wersja 6.22 wygląda na 
> lekko odpicowaną wersję DOS 1.0. Nic tam specjalnie przez te lata nie 
> poprawiono, dodano itd itp. Ani śladu nowoczesnych technologii, kerneli 
> preemptive, wielozadaniowości, wielodostępu, wirtualizacji. Niebywałe. 
> Co oni tam robili przez te wszystkie lata? DoubleSpace?

Nic. W kwestii rozwoju Windows czy Office też długo nie robiono nic. 
Dopiero konkurencja zmuszała do rozwoju. I nagle, kiedy Linux zaczął 
działać konkurencyjnie stabilniej, Windows też się poprawił.

> 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 albo ktoś inny, 
aby uniknąć tej wielkiej porażki? Ale konkrety, nie "coś innego". Z 
uwzględnieniem ówczesnych cen, potrzeb użytkowników i ich mentalności.

L.

On 06/01/2021 10:58, Luke wrote:
>> Intel zrobił 8086 w taki sposób aby dało się *automatycznie* 
>> translować oprogramowanie z 8080. I dokładnie w taki sposób zapełniono 
>> biblitekę niczego. Czyli wsadzić nowy procesor i zapełnić go 
>> gównianymi programami wyjętymi wprost z 8-bit na gównianą platformę 
>> sprzętową 8/16-bit+segmenty.
> No proszę, ktoś wypuszcza produkt wstecznie zgodny z dotychczasowymi 
> rzeczami, zły i niedobry...

On nie był kompatybilny na poziomie binariów tylko na poziomie kodu w 
asm trzymał jako taką możliwosc translacji.

To nie jest nic złego, ale jednocześnie cały procesor był obudowany tą 
koncepcją. I to wygenerowało sytuację jaką mieliśmy w latach 90. Męcząc 
się w ciansych, 16 bit segmentach, jak procesory 8-bit. To nie jest 
"rewolucja" tylko "wstecznictwo".

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

>> Niebywałe. Co oni tam robili przez te wszystkie lata? DoubleSpace?
> Nic.

Nic? Czekaj, czyli potwierdzasz tezę o zapaści?

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

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

> aby uniknąć tej wielkiej porażki? Ale konkrety, nie "coś innego". Z 
> uwzględnieniem ówczesnych cen, potrzeb użytkowników i ich mentalności.

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 
była powodem męk piekielnych przez całe lata 90 z których ledwo udało 
się wybrnąć. Rewolucja nastapiła nie DZIEKI IBM tylko MIMO IBM i całej 
reszcie wielkiej trójki.

> > Pytanie do ćwiczenia: kiedy NVIDIA będzie rozdawać sterowniki do swoich kart dla procesorów RISC-V?
> To pytanie zadaj wobec R-PI który będzie miał złacze PCI-E i da się do 
> niego wsadzić kartę NVidi. Są sterowniki NVidi pod linuxa, na arm? 

Nie wiem, czy są. Ale wiem, że NVIDIA kupiła ARMa. Za 40B$. To było raptem 4 miesiące temu, mogłeś przeoczyć w kwarantannie (https://nvidianews.nvidia.com/news/nvidia-to-acquire-arm-for-40-billion-creating-worlds-premier-computing-company-for-the-age-of-ai).
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.
Szansą dla RISC-V jest fakt, że niektórzy boją się dominacji NVIDII, bo nie traktują jej jako neutralnego gracza. Ale tam za duży hajs jest na stole, żeby to się łatwo zmieniło.

> > 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? Wszystko darmowe i otwarte a projekty bardzo drogie. Ciekawe, nie?

> 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 i sprawdzona abstrakcja (dlatego bardzo racjonalne było to wziąć). Szkoda tylko, że inne RTOSy tej abstrakcji nie mają i nie da się przenieść takiego "przenośnego" projektu na inne klocki, z innym RTOSem. Albo z innym stosem TCP. Itd. Pacz pan, przenośny program, a nie da się przenieść. Same abstrakcje, wszystko otwarte, a projekty dalej drogie. Ciekawe, nie?

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

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

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

> Wystarczy zmienić kompilator w makefile.

Ale tego makefile też nie mam.
Problemem nie jest Twój czy mój kod. Problemem jest ten cudzy kod.

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

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

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

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.

środa, 6 stycznia 2021 o 14:28:23 UTC+1 heby napisał(a):
> On 06/01/2021 10:58, Luke wrote: 
> 
> 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 
> była powodem męk piekielnych przez całe lata 90 z których ledwo udało 
> się wybrnąć. Rewolucja nastapiła nie DZIEKI IBM tylko MIMO IBM i całej 
> reszcie wielkiej trójki.

dos i wczesny windows to byla tragedia, ale win95 zmienil sytuacje bo to bylo cos
z tego roznego systemowego shitu do dzis sie nie udalo w pelni wyjsc...moim zdaniem
potrzebny jest lepszy wyzszy poziom systemu plikow tak by pliki mozna bylo katalogowac na 
'skrosne' sposob oraz potrzebny jest jakis system zapewniania integralnosci plikow zwiazanych w paczkach (obie idee mojego pomyslu choc pewnie niektorzy inni tez o tym mysla)  potrzebne sa tez takie rzeczy jak np w menadzeze zadan widok ile dany proces czyta bajtow z dysku lub z sieci z dokladnoscią do bajtu - bo user ma prawo do takich informacji, potrzeban jest tez wzmozona stara dobra komponentowosc i moznosc wymiany komponentu na inny wg uznania bo dzis to drastycznie slabo dziala

środa, 6 stycznia 2021 o 17:32:48 UTC+1 fir napisał(a):
> środa, 6 stycznia 2021 o 14:28:23 UTC+1 heby napisał(a): 
> > On 06/01/2021 10:58, Luke wrote: 
> > 
> > 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 
> > była powodem męk piekielnych przez całe lata 90 z których ledwo udało 
> > się wybrnąć. Rewolucja nastapiła nie DZIEKI IBM tylko MIMO IBM i całej 
> > reszcie wielkiej trójki.
> dos i wczesny windows to byla tragedia, ale win95 zmienil sytuacje bo to bylo cos 
> z tego roznego systemowego shitu do dzis sie nie udalo w pelni wyjsc...moim zdaniem 
> potrzebny jest lepszy wyzszy poziom systemu plikow tak by pliki mozna bylo katalogowac na 
> 'skrosne' sposob oraz potrzebny jest jakis system zapewniania integralnosci plikow zwiazanych w paczkach (obie idee mojego pomyslu choc pewnie niektorzy inni tez o tym mysla) potrzebne sa tez takie rzeczy jak np w menadzeze zadan widok ile dany proces czyta bajtow z dysku lub z sieci z dokladnoscią do bajtu - bo user ma prawo do takich informacji, potrzeban jest tez wzmozona stara dobra komponentowosc i moznosc wymiany komponentu na inny wg uznania bo dzis to drastycznie slabo dziala

mozna by ew zastanowic sie czemu ten system komponentowy na wspolczesnych windach niezbyt dziala.. nie wydaje sie to specjalnie trudne do zrobienia tak by bylo powszechne i ladnie dzialalo - mozna uzyc dllki spelniajacej pewne warunki jako komponentu (tj jako bazy na taki komponent) i raczej powino dzialac
trzebe tez oczywiscie dac miejsca i konwencje do podmienianie, przelaczania lub dolaczania takich komponentow
jest tez kwestia ze oczywiscie kawalek proramu moze wpasc w nieskonczona petlle lub scrashowac ale z reguly ta zasada zeby pisac programy tak by dzialaly poprawnie dziala , dwa ze winda mam wrazenie ciul lepiej moglaby zarzadzac tymi kraszami i zwlaszcza wpadaniem programow w loopy 0 dzis jak napisze sie apke ktora mieli loop bez oddawania kontroli w petli eventow to potrafi to zablokowac system na minute nim to da sie skillowac imo winda powinna raczej jakos mocniej wywlaszczac takie progamy by az tak nie gniotly systemu

dobre miejsce na dobry komponent w systemie to imo super ciekawa rzecz by byla ale dzis te pluginy (bo nawet nie komponenty) to nieprzyjemna babranina...winda powinan opracowac dobry system dolaczania komponentow na poziomie systemu

W dniu 06.01.2021 o 14:28, heby pisze:
/..../
> 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".
> 
Jaki procesor był niedziadoski?

>>> Niebywałe. Co oni tam robili przez te wszystkie lata? DoubleSpace?
>> Nic.
> 
> Nic? Czekaj, czyli potwierdzasz tezę o zapaści?
> 
>> 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.

Obsługa szerokiego wachlarza sprzętu.
> 

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?

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

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.

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

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

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

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.

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.

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_clones

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

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

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.

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

> > A twórcy januszowych Windowsów?
> Również. https://www.integrasources.com/blog/windows-ce-end-of-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-ckeditor-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

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

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?

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.

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.

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.

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

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

On 11/01/2021 13:03, Mateusz Viste wrote:
>> 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.

Bardzo mocno zahardkodowana. Nawet C64, który wszak miał małe i duże 
litery, mógł je redefiniować na cokolwiek. MDA nie. Zaleta MDA to 
"biznesowa" szerokośc obrazu, aczkolwiek do C64 i Atari były zewnętrzne 
karty gfx pozwalające na pracę w trybie 80 kolumn. Do Apple II też. Nic 
tu nowego nie wymyślono.

Dodatkowo MDA miała wyjątkowo upierdliwy ficzer, nawet jak być mógł je 
zredefiniować podeiniając eprom:

"[...]For characters C0h-DFh, the ninth pixel column is a duplicate of 
the eighth; for others, it's blank.[...]".

> > Osobiście nie mam problemu z określeniem "POSIX subset".
> Super. To wiele wyjaśnia.

Twórcy tego standardu też nie mają, patrz niżej.

> > Więc chcę, żeby januszowe RTOSiki implementowały "POSIX subset"
> A jeśli sa z nim niezgodne, tak fundamentalnie?

To nie zrobisz jednolinijkowej "abstrakcji". Plączesz się w argumentach.

> Nie. Bo to nie działa w tą stronę. Musisz mieć pełny POSIX aby nazywać 
> to "POSIX".

I tu znowu (a raczej wciąż) się mylisz.
Praktyka stosowania podzbiorów (czegokolwiek) jest tak powszechna, zwłaszcza w embedded, że branża nawet znalazła sobie seksowne określenie na to: profil. Różne rzeczy definiuje się dla wielu "profili", właśnie po to, żeby zaadresować różnice w zakresie wspieranej funkcjonalności.
I tak POSIX został podzielony na profile, z czego PSE51 jest najprostszym, zakładającym istnienie jednego, ale być może wielowątkowego procesu, bez systemu plików. To jest opisane w POSIX 1003.13-2008, który jest płatny, ale ślad tego znalazłem tutaj:

https://www.opengroup.org/testing/testsuites/POSIXProfiles.htm

Wizualizacja jest w slajdzie 17 tutaj:

https://www.opengroup.org/austin/docs/austin_279.pdf

Czyli PSE51 to jest profil POSIX stworzony właśnie po to, żeby odzwierciedlić istniejącą praktykę w postaci prostych RTOSików na mikrokontrolery. Jeżeli nadal uważasz, że POSIX nie nadaje się do embedded, bo tam nie ma np. systemu plików, to "you are not even wrong".
Wracając, PSE51 pozwala systemom takim jak FreeRTOS mieć API POSIX. No, chyba że autorzy koniecznie nie chcą. Ale jest kilka systemów, których autorzy chcieli:

https://unix.stackexchange.com/questions/431999/is-there-an-open-source-posix-pse51-compliant-rtos

> POSIX bez pipes to nie POSIX.
> Możesz sobie użyć tego "subset". To dalej nie POSIX.

Zamknijmy ten rozdział już. Masz wystarczająco dużo materiałów.

> >> Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior. 
> > Czyli tego określenia też nie rozumiesz. Może podaj przykład.
> Proszę: 
> 
> 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.

Jeżeli to jest UB, to mogę określić dowolnie. I zweryfikować to, co założyłem. Albo powiedzieć, że tej funkcjonalności w ogóle nie ma. I jej nie weryfikować, bo nie ma po co.
Podobnie jak np. z wyjechaniem poza tablicę w C++.

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

To samo.

> A ci co zaczeli na januszowym Linuxie?

Oni mogą przenieść swoje programy na inne systemy.

> > A gdyby tak zaczęli, od początku, zgodnie ze standardami?
> To by nigdy nie wystarowali.

Sam pisałeś, że każdy ma swoje własne doświadczenia.

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

I tu też się mylisz... Niestety.

> > Również. https://www.integrasources.com/blog/windows-ce-end-of-life-medical-devices/
> Ale pytam o Windowsy współczesne.

A jak pisałem wcześniej o współczesnych Macach to się rzucałeś że kiedyś komuś coś przestało działać. No i?
Ocena ryzyka jest częścią decyzji biznesowej. Jak komuś pasuje robić projekt embedded z Windowsem (czy z czymkolwiek innym, co nie spełnia żadnych standardów) w środku, to jego problem.

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

Więc skoro przez wiele lat nie trzeba się nigdzie przesiadać, to o czym rozmawiamy? Najwyraźniej o problemie, którego nie ma.

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

On 11/01/2021 17:41, Maciej Sobczak wrote:
>>> Więc chcę, żeby januszowe RTOSiki implementowały "POSIX subset"
>> A jeśli sa z nim niezgodne, tak fundamentalnie?
> To nie zrobisz jednolinijkowej "abstrakcji".

Zgadza się. Ale mogę zrobić dwulinijkową.

Natomias jak wdepniesz w POSIX, to ...

>> Nie. Bo to nie działa w tą stronę. Musisz mieć pełny POSIX aby nazywać
>> to "POSIX".
> I tu znowu (a raczej wciąż) się mylisz.
> Praktyka stosowania podzbiorów (czegokolwiek) jest tak powszechna

Wiadomo, pół c++ to też c++. Ćwierć też. Asymptotycznie.

> , zwłaszcza w embedded

O tam jest wiele rzeczy na opak, to prawda.

>, że branża nawet znalazła sobie seksowne określenie na to: profil. Różne rzeczy definiuje się dla wielu "profili", właśnie po to, żeby zaadresować różnice w zakresie wspieranej funkcjonalności.

Znakomicie. I teraz masz Twój kod, napisany pod profil A.

Trafia się OS z profilem B.

Jesteś w dupie.

> Czyli PSE51 to jest profil POSIX stworzony właśnie po to, żeby odzwierciedlić istniejącą praktykę w postaci prostych RTOSików na mikrokontrolery.

Cooperative? Bo wiesz cooperative jest relatywnie popularną metodą 
tworzenia watków w prostym RTOSiku. Nawet bardziej R niż preemptive.

> Jeżeli nadal uważasz, że POSIX nie nadaje się do embedded, bo tam nie ma np. systemu plików, to "you are not even wrong".

Nie, uwazam tylko że w tym momencie sam sobie zaprzeczyłeś pisząc że 
"POSIX" jest przenośny.

Jest tak przenośny że należy pisać na jego podzbiór i strasznie mocno 
uważać aby nie wdepnąc w inny podzbiór, węższy, albo bardziej różowy. W 
dodaku, ponieważ standard mówi że trzeba sprawdzić 20 stanów, to chcąc 
pisać przenośnie, naprawdę trzeba je wszystkie sprawdzać, bo inaczej 
jesteś nieprzenośny.

> Wracając, PSE51 pozwala systemom takim jak FreeRTOS mieć API POSIX.

Korutynowy?

>> POSIX bez pipes to nie POSIX.
>> Możesz sobie użyć tego "subset". To dalej nie POSIX.
> Zamknijmy ten rozdział już. Masz wystarczająco dużo materiałów.

Nie. Gdyby była dyskusja z okolic czy "subset POSIX można wykorzystać" 
to nie było by sprawy.

Ale Ty tutaj od wielu postów bredzisz że to jest przenośne tak strasznie.

No wiec istnienie wielu wartstw randomicznie implementowanych  POSIXów 
jest *zaprzeczeniem* przenośności, bo program napisany na A+B nie da się 
skompilować na wersji tylko A.

Nie dość, że POSIX jest gówniany, to jeszcze jest tak naprawde nieprzenośny.

>> 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.
> Jeżeli to jest UB, to mogę określić dowolnie. I zweryfikować to, co założyłem.

Na konkretnej implementacji POSIXa.

> Albo powiedzieć, że tej funkcjonalności w ogóle nie ma. I jej nie weryfikować, bo nie ma po co.

No widzisz, a tu dostajesz w łeb ostatnio łatką do kernela Linuxa, gdzie 
ta funkcjonalnośc zmieniła sie na zupełnie inną.

Działało i przestało, zupełnie bez ostrzeżenia.

POSIX. Bo można.

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

No nie zupełnie. Wolno Ci zawołać, ale nie wiadomo co się stanie. A jak 
trafisz na złośliwy posix gdzie SSIZE_MAX == 1?

>> A ci co zaczeli na januszowym Linuxie?
> Oni mogą przenieść swoje programy na inne systemy.

Na przykład na Windows?

>>> A gdyby tak zaczęli, od początku, zgodnie ze standardami?
>> To by nigdy nie wystarowali.
> Sam pisałeś, że każdy ma swoje własne doświadczenia.

Tak.

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

Wiadomo.

> Niestety.

Nie udawaj zmartwionego :D

>> Ale pytam o Windowsy współczesne.
> A jak pisałem wcześniej o współczesnych Macach to się rzucałeś że kiedyś komuś coś przestało działać. No i?

Że nic nie jest stabilne w OSie. I trzeba się naprawdę nagimastykować 
aby mieć pewnośc że niewiele może Cie zaskoczyć. Włacznie z ewaukacją w 
panice na inny OS jak się zacznie palić. Jak w WinCE.

> Ocena ryzyka jest częścią decyzji biznesowej.

Myslisz że frajerzu kupujący AirBooki i podpinający do nich 10 monitorów 
"oceniali ryzyko"? Nie przeceniasz nieco tych wszystkich korpo-iditów? 
Kupili, bo ładne.

Jest masa aplikacji kickstartowanych z oczywistym vendor-lockin, jak 
MFC. Wiele z tych apliakcji nigdy nie zdołało się wykopać z tego gówna. 
Oni coś tam oceniali biznesowo czy po prostu zatrudnili Heńka, co nic 
innego nie czaił i upierał się że za chwile cały swiat bedzie w MFC?.

> Jak komuś pasuje robić projekt embedded z Windowsem (czy z czymkolwiek innym, co nie spełnia żadnych standardów) w środku, to jego problem.

Albo narzucony odgórnie OS. Albo Heniek.

>>> 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.
> Więc skoro przez wiele lat nie trzeba się nigdzie przesiadać, to o czym rozmawiamy? Najwyraźniej o problemie, którego nie ma.

Ale nagle musieli.

I albo są w dupie, bo tuptali nogą że świat musi być jak windows/posix.

Albo mieli abstrakcję na OSa.

Życie.

> Znakomicie. I teraz masz Twój kod, napisany pod profil A. 
> 
> Trafia się OS z profilem B. 
> 
> Jesteś w dupie.

Czyli zamiast zainwestować parę sekund i kliknąć w te linki, wolisz się konsekwentnie kompromitować.
Profil B zawiera profil A. Ktoś to przewidział.

Skończył mi się limit energii na prostowanie Twojego trollowania.
Do następnego razu.

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

On 12/01/2021 18:43, Maciej Sobczak wrote:
>> Znakomicie. I teraz masz Twój kod, napisany pod profil A.
>> Trafia się OS z profilem B.
>> Jesteś w dupie.
> Czyli zamiast zainwestować parę sekund i kliknąć w te linki, wolisz się konsekwentnie kompromitować.
> Profil B zawiera profil A. Ktoś to przewidział.

U mnie profil A zawiera profil B. Nie wiem skąd wziąłeś odwrotną 
zależnośc, może to tylko problem zafiksowania się na głupim posixie, 
który musi być dobry, religijnie, choć jest ch..wy.

> Skończył mi się limit energii na prostowanie Twojego trollowania.

Widzę.

> Do następnego razu.

Nie wiem czy mi się chcę.

In pl.comp.programming heby <heby@poczta.onet.pl> wrote:
> 
> 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.

Podstawowy PC to 32 kB RAM.  Lepszy model to 64 kB.  Juz do
DOS potrzebny byl opcjonalny dodatek, czyli stacja dyskietek.
Na takiej maszynie system wielozadanowy czy GUI nie bedzie
dobrze dzialac.  W 1981 roku lepszy sprzet byl poza zasiegiem
mozliwosci finansowych wiekszosci klientow.

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

Do PC byly cztery opcje: ROM Basic (od Microsofta), bez prawdziwego
OS, PC (czy MS) DOS, CP/M i UCSD P-system.  Basic nie mial obslugi
dyskietek, wiec z dyskietkami byly trzy mozliwosci.  Jakby nie
bylo DOS-a to by zostaly dwie mozliwosci.  DOS wygral bo byl
najtanszy: Gates dal duzo nizsza cene niz konkurencja.

-- 
                              Waldek Hebisch

On 23/01/2021 03:50, antispam@math.uni.wroc.pl wrote:
> Podstawowy PC to 32 kB RAM.  Lepszy model to 64 kB.  Juz do
> DOS potrzebny byl opcjonalny dodatek, czyli stacja dyskietek.
> Na takiej maszynie system wielozadanowy czy GUI nie bedzie
> dobrze dzialac. 

Oczywiscie że może działać. Sinclair Ql, Geos, Apple II, itd itp. 
pokazały że nie ma najmniejszego problemu z limitowanym hardware. W 
zasadzie ilośc pamięci RAM nie ma śladu związku z ficzerami typu 
multitasking czy sensowny API do systemu. Nie tłumacz dziadsotwa jakie 
zrobił IBM&MS w tak kieski sposób. To nie jest wymówka że mieli *aż* 
32/64kB. Na pewno nie wymówka że zajumali 8-bit system operacyjny. Ba, 
wiele systemów na 8-bit miało bardziej robudowane API jak pierwszy DOS.

> W 1981 roku lepszy sprzet byl poza zasiegiem
> mozliwosci finansowych wiekszosci klientow.

Którzy swoją drogą na tony kupowali Aplle II, C64. IBM w zasadzie się od 
nich niczym nie różnił poza byciem skrajnie kiepskim i drogim we 
wszystkim, szczególnie na początku.

> DOS wygral bo byl
> najtanszy

Nie, DOS wygrał, bo był kradzonym API CP/Ma i można było na szybko 
poskładać na kolanie biblitekę programów z Z80. Tylko dlatego. Nie 
dorabiajmy filozofii, tam nie ma nic poza przypadkiem, kradzieżą, 
przyzwyczajeniem.

In pl.comp.programming heby <heby@poczta.onet.pl> wrote:
> On 23/01/2021 03:50, antispam@math.uni.wroc.pl wrote:
> > Podstawowy PC to 32 kB RAM.  Lepszy model to 64 kB.  Juz do
> > DOS potrzebny byl opcjonalny dodatek, czyli stacja dyskietek.
> > Na takiej maszynie system wielozadanowy czy GUI nie bedzie
> > dobrze dzialac. 
> 
> Oczywiscie ?e mo?e dzia?a?. Sinclair Ql, Geos, Apple II, itd itp. 
> pokaza?y ?e nie ma najmniejszego problemu z limitowanym hardware.

No Sinclair Ql to byla wtopa, niezaleznie od tego czy powiemy
ze dzialal czy nie dzialal to klienci nie kupowali.  Chyba ze
ma byc przyladem ze niby 32-bitowy procesor nie zrekompensowal
innych problemow.

> W 
> zasadzie ilo?c pami?ci RAM nie ma ?ladu zwi?zku z ficzerami typu 
> multitasking czy sensowny API do systemu. Nie t?umacz dziadsotwa jakie 
> zrobi? IBM&MS w tak kieski spos?b. To nie jest wym?wka ?e mieli *a?* 
> 32/64kB.

Ma zwiazek.  IBM to cwiczyl 15 lat przed PC: na maszynie z (az)
32 kB RAM i dyskiem twardym wielozadaniowac z zasadzie powinna
dzialac ale praktyce naprawde dobrze bylo dopiero jak mieli
128 kB, przy 32 kB sytem lepiej dzialal z jednym zadaniem
na raz.  Wielozadaniowosc + GUI byly rozwijane na maszynach
Xeroxa, z typowa konfiguracja 1M RAM i specjalizowanym procesorem
(duzo szybszym od tych z PC).  Macintosh mial wiecej RAM niz
PC, spora czesc systemu byla w ROM a dobrze sie sprzedawal
dopiero jak dodano wiecej RAM.  Przy tym Macintosh porzadna
wielozadanosc dostal dopiero w wersji OS X.  Oczywiscie
na malutkim hardware mozesz robic specjalizowane systemy
gdzie bedziesz mial wielozadanosc czy GUI, uzywajac
rozwiazania w stylu protothreads (do wielozadanosci)
czy kafelki (do GUI).  Ale praktyka pokazala ze nie
sa to sensowne rozwiazania dla systemu ogolnego przeznaczenia.

Akurat DOS nie robi przeszkod jak chcesz specjalizowana
wielozadanosc, po prostu nie uzywasz DOS i przejmujesz
kontrole nad sprzetem (ta czescia ktora potrzebujesz).

> Na pewno nie wym?wka ?e zajumali 8-bit system operacyjny. Ba, 
> wiele system?w na 8-bit mia?o bardziej robudowane API jak pierwszy DOS.

Rozbudowan API = wiecej kodu systemowego.  PC mial system w RAM
wiec oznaczalo to mniej RAM dla programu uzytkowego.

> > W 1981 roku lepszy sprzet byl poza zasiegiem
> > mozliwosci finansowych wiekszosci klientow.
> 
> Kt?rzy swoj? drog? na tony kupowali Aplle II, C64. IBM w zasadzie si? od 
> nich niczym nie r??ni? poza byciem skrajnie kiepskim i drogim we 
> wszystkim, szczeg?lnie na pocz?tku.

IBM to byl sprzet do pracy.  Do pracy C64 to dziadostwo.  Dokladniej
PC mial:
- monitor mono 80 znakow w lini na ktorym dalo sie pracowac
  caly dzien (owczesne kolorowe mialy mniejsza rozdzielczosc i
  migotaly)
- klawiatura jakiej oczekiwali ludzie szkoleni na maszynach do
  pisania i terminalach
- solidna blaszana obudowa z zasilaczem w srodku
- miejsce na karty rozszerzen w srodku
- dyskietki rozsadnej szybkosci (w C64 standartowa dyskietka
  jest ponizej wszelkiej krytyki)
- 1M przestrzeni adresowej procesora

Apple II byl lepszy niz C64 ale wcale nie tak tani.  Do tego
w zasadzie juz gdy PC wchodzil na rynek to Apple II to byla
konstrukcja nierozwojowa z wzgledu na procesor (oczywscie
Apple robilo nowe wersje ale bylo to dojenie rynku dopuki
przestarzala konstrukcja sie sprzedaje).

Klony pokazaly ze mozna zejsc w dol z cena PC, ale nie do
poziomu C64 (solidna konstrukcja kosztuje).  Przy tym
klony uzywaly nowsze uklady o wyzszej skali integracji
co obnizalo koszty (niedostepne dla oryginalnego PC).

Nie powiem ze lubie ceny oferowane przez IBM.  Ale gdy
PC wchodzil do firm to alternatywa nie bylo C64 (a zwykle
nawet nie Apple II).  Alternatywa byly minikomputery
(np. HP, DEC czy kilka z IBM) i terminale.  O ile
wiem PC ze zgodnoscia z terminalem 3270 mial podobna
cene jak ten termial.  Czyli dostawales potrzebny
termial + prawie za darmo funkcje PC.  Od minikomputerow
PC byl duzo tanszy a czesto wystarczlo to co PC potrafil.

> > DOS wygral bo byl
> > najtanszy
> 
> Nie, DOS wygra?, bo by? kradzonym API CP/Ma i mo?na by?o na szybko 
> posk?ada? na kolanie biblitek? program?w z Z80. Tylko dlatego. Nie 
> dorabiajmy filozofii, tam nie ma nic poza przypadkiem, kradzie??, 
> przyzwyczajeniem.

No, zwykle sie przyjmuje ze reimplementacja API jest legalna.
QDOS lamal prawa autorskie bo bylo to bezposrednie (mozliwe
z autowatyczne ale na pewno w duzej czesci bezmyslne) tlumaczenie
zdeasembowanego CP/M.  Nie jest jasne czy Gates jak kupowal QDOS
to wiedzial o zlamaniu praw autorskich (jak wiedzial to raczej
sie nie przyzna).  Zgodnosc z CP/M nie wyjasnia dlaczego
DOS wygral z CP/M (wersja dla 8086), przeciez CP/M powienin byc
lepiej zgodny z CP/M niz DOS (gdzie MS wprowadzil sporo zmian).
Zakup QDOS oznacza ze MS mial na starcie nizsze koszty.  Ale
sprzedaz ma finansowac rozwoj i tu MS mysle ze wydawal duzo
wiecej niz DR.  Wiec DR gdyby przewidzial rozwoj rynku to
mogl tez dac niska cene.  Ale mysle ze DR nie chcial
"psuc rynku" wypuszczajac tania wersje dla PC i liczyl
ze klienci zaplaca za lepsza zgodnosc.  Czyli raczej
zgodnosc byla mniej istotna.

-- 
                              Waldek Hebisch

On 27/01/2021 00:40, antispam@math.uni.wroc.pl wrote:
> No Sinclair Ql to byla wtopa

Ale miał udowodnić, że mały hardware nie ma nic do rzeczy.

>> zasadzie ilo?c pami?ci RAM nie ma ?ladu zwi?zku z ficzerami typu
>> multitasking czy sensowny API do systemu. Nie t?umacz dziadsotwa jakie
>> zrobi? IBM&MS w tak kieski spos?b. To nie jest wym?wka ?e mieli *a?*
>> 32/64kB.
> Ma zwiazek.  IBM to cwiczyl 15 lat przed PC: na maszynie z (az)
> 32 kB RAM i dyskiem twardym wielozadaniowac z zasadzie powinna
> dzialac ale praktyce naprawde dobrze bylo dopiero jak mieli
> 128 kB

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

Dali radę zrobić preemptive. Jakim cudem ja się pytam, skoro IBM musiał 
mieć 128kB dzięki opini bardzo ważnych i troche kiepskich inżynierów z 
IBM i jeszcze bardziej kiepskich z MS?

Chwile potem wpada 286 ze swoimi wirtualizacjami a na PC dalej pudrowany 
CP/M.

>, przy 32 kB sytem lepiej dzialal z jednym zadaniem
> na raz.

Co niczym się nie różni od preemtiove/cooperative z 1 zadaniem.

>  Wielozadaniowosc + GUI

Nie musiało być GUI. Dziadostwo IBM dotyczy OSa a nie nakładki graficznej.

> dopiero jak dodano wiecej RAM.  Przy tym Macintosh porzadna
> wielozadanosc dostal dopiero w wersji OS X.

Od zawsze mieli porządna wielozadaniowość w tej lini maszyn. Cooperative 
nie jest najgorszym konceptem w tamtym czasie, MS też to wybrał dla Win1-3.

> Ale praktyka pokazala ze nie
> sa to sensowne rozwiazania dla systemu ogolnego przeznaczenia.

Czepiłeś się tego multitaskingu, zapominając o miliardzie innych rzeczy. 
IBM nie dostarczył sensownej abstrakcji na sprzęt. Ba, nawet hardware 
nie pozwalał wybierać slotów, wpierniczając wszystko na te same druty i 
nazywając to magistralą. W efekcie, w połowie lat 90, selekcje musiały 
robić karty, zamiast magistrala. Jeden debilizm wygenerował skutek w 
postaci postawienia problemu na głowie i workaroudu który umożliwia 
śmierć ze śmiechu.

To samo w software. Jeden debilizm w postaci zawinięcia A20 (spowodowany 
głupią koncepcją segmentów/stron) wygenerował do *dzisiaj* 1000 sposobów 
na manipulowanie linią A20 aby 40-letni program mógł działać na 
najnowszym I15. Bo to ważne niezwykle.

> Akurat DOS nie robi przeszkod jak chcesz specjalizowana
> wielozadanosc, po prostu nie uzywasz DOS i przejmujesz
> kontrole nad sprzetem (ta czescia ktora potrzebujesz).

Fantastycznie. Jak chcesz zmienić Seicento na Mazdę to wystarczy 
zezłomować Seicento i kupić Mazdę. W niczym to faktycznie nie ogranicza! 
Genialna logika. Seicento jest dzięki temu znakomitą podwaliną pod kupno 
Mazdy.

>> Na pewno nie wym?wka ?e zajumali 8-bit system operacyjny. Ba,
>> wiele system?w na 8-bit mia?o bardziej robudowane API jak pierwszy DOS.
> Rozbudowan API = wiecej kodu systemowego.

Straszne.

>  PC mial system w RAM
> wiec oznaczalo to mniej RAM dla programu uzytkowego.

Nie, oznaczało to że można było wyładować ten kod który nie jest 
potrzebny. Dokładnie to robili z command com.

PC/MSDOS nie miał abstrakcji na nic poza dyskiem. Nawet na grafikę nie 
miał, to dostarczała karta.

Dlatego MSDOS to nie OS, tylko filesystem z command promptem. Mniej 
wiecej to samo, co sama stacja do C64.

>> Kt?rzy swoj? drog? na tony kupowali Aplle II, C64. IBM w zasadzie si? od
>> nich niczym nie r??ni? poza byciem skrajnie kiepskim i drogim we
>> wszystkim, szczeg?lnie na pocz?tku.
> IBM to byl sprzet do pracy.  Do pracy C64 to dziadostwo.

Niczym istotnym się nie różniły na poczatku.

>  Dokladniej
> PC mial:
> - monitor mono 80 znakow w lini na ktorym dalo sie pracowac
>    caly dzien (owczesne kolorowe mialy mniejsza rozdzielczosc i
>    migotaly)

Co załatwiało się stosowną kartą do C64/Apple/Atari. Patrz, to tak samo, 
jak na PC.

> - klawiatura jakiej oczekiwali ludzie szkoleni na maszynach do
>    pisania i terminalach

Która to w przypadku Apple II znacząco nie odstawała, switche były 
mechaniczne. PC, szczególnie klony, potrafiły mieć klawiaturę niemożliwą 
do używania.

> - solidna blaszana obudowa z zasilaczem w srodku

Zupełnie jak w Apple II

> - miejsce na karty rozszerzen w srodku

Zupełnie jak Apple II.

> - dyskietki rozsadnej szybkosci (w C64 standartowa dyskietka
>    jest ponizej wszelkiej krytyki)

Z uwagi na buga sprzętowego. Prędkosć dyskietki to tylko szybkosc 
kręcenia się nośnika i gęstość. Pierwsze stacje do PC nie były 
imponujące. DIR też trwał wieczność.

> - 1M przestrzeni adresowej procesora

Która polegałą na bezustannym stronicowaniu w sofcie. Dokładnie to samo 
potrafiły wszystkie systemy 8-bit - mogłeś sobie przełaczać strony RAMu 
w jakimś oknie, czyli to co robi 8086 za pomocą rejestru, tam robiło się 
za pomocą poke.

> Apple II byl lepszy niz C64 ale wcale nie tak tani.  Do tego
> w zasadzie juz gdy PC wchodzil na rynek to Apple II to byla
> konstrukcja nierozwojowa z wzgledu na procesor (oczywscie
> Apple robilo nowe wersje ale bylo to dojenie rynku dopuki
> przestarzala konstrukcja sie sprzedaje).

Róznica między 6502 i 8086 była praktycznie znikoma. Oba to procesory z 
punktu widzenia programisty to 8-bit i 16 bit adresu, 8086 część 
elektroniki stronicowania wsadził do środka i wygenerował masę problemów 
takich jak porównywanie pointerów. Pozwoliło to intelowi twierdzić że to 
procesor "o większym adresowaniu" gdzie w rzeczywistości dalej było 16 
bitów na adres i dodatkowy rejestr(y) na zmianę stron pamięci.

Nie, żadna istotna różnica. Programista w obu wypadkach był w dupie. Nie 
nastapiła żadna istotna rewolucja.

> Nie powiem ze lubie ceny oferowane przez IBM.  Ale gdy
> PC wchodzil do firm to alternatywa nie bylo C64 (a zwykle
> nawet nie Apple II).  Alternatywa byly minikomputery
> (np. HP, DEC czy kilka z IBM) i terminale.

Alternatywą były komputery pracujace do tej pory na CP/M. IBM świetnie 
się w to wpakował ponieważ sprzedali CP/M bez licencji na niego.

>> Nie, DOS wygra?, bo by? kradzonym API CP/Ma i mo?na by?o na szybko
>> posk?ada? na kolanie biblitek? program?w z Z80. Tylko dlatego. Nie
>> dorabiajmy filozofii, tam nie ma nic poza przypadkiem, kradzie??,
>> przyzwyczajeniem.
> No, zwykle sie przyjmuje ze reimplementacja API jest legalna.

Dlatego mówie o kradzieży API a nie kradzieży OSa od DR. O kradzieży OSa 
można mówić w przypadku samego MSDOSa, bo transakcja była co najmniej 
wątpliwa moralnie.

> Zgodnosc z CP/M nie wyjasnia dlaczego
> DOS wygral z CP/M (wersja dla 8086), przeciez CP/M powienin byc
> lepiej zgodny z CP/M niz DOS (gdzie MS wprowadzil sporo zmian).

To efekt motyla. Wystarczyło kilka tygodni zwłoki i pojawia się, w 
długiej skali, dominacja.

> mogl tez dac niska cene.  Ale mysle ze DR nie chcial
> "psuc rynku" wypuszczajac tania wersje dla PC i liczyl
> ze klienci zaplaca za lepsza zgodnosc.

Zgodności wprost nie było. Była wymagana rekompilacja. DR nie miał szans 
na zmuszenie ludzi do tej rekompilacji. Prawdopodobnie zdecydował 
przypadek że akurat MS, ponieważ był najzwyczajniej dołączony do PC.

Historia PC to historia żenady, przypadków, podejrzanych transakcji itd 
itp. Szukanie w tym logiki "dlaczego" jest błedem. Tam nie ma logiki. 
Wyszło jak wyszło. I nawet nie byli ani pierwsi ani wyjątkowi. Ot, 
skrajnie gówniany komputer przypadkowo stający się dominującym. Nic 
specjalnie dziwnego w latach 80 w IT.