Spieszmy się kochać Windows

[slawek]

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.)
Chcesz aby komputer pracował 24/7? Aktualizacja może zrobić
reset, a po aktualizacj komputer może się uruchomić albo nie.
Wyłączyłeś demona? Aktualizacja włączy go i przy okazji rozp...i
wszystko co się da, pokasuje pliki, bo nie sprawdza
przydziałów

Jest już tak, że do poważnych rzeczy - "produkcyjnych" - nadaje
się chyba tylko Linux. A to prowadzi do wniosku że zarówno C# jak
i Azure są zupełnie nieprzydatne, jako zbyt mocno osadzone w
ekosystemie Windows.


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

[Maciej Sobczak]

Post by slawek
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.

Post by slawek
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?

[slawek]

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/

[Arnold Ziffel]

Post by slawek
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.

[slawek]

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/

[Luke]

Post by slawek
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.

[heby]

Post by Luke
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".

Post by Luke
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.

[Maciej Sobczak]

Post by heby
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?

Post by heby
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".

Post by heby
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ę.

[heby]

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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ść.

Post by Maciej Sobczak
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).

Post by Maciej Sobczak
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/

Post by Maciej Sobczak
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/

[Maciej Sobczak]

Post by heby

Post by Maciej Sobczak
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ć.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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.

Post by heby
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?

Post by heby
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.

Post by heby
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.

[heby]

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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ść?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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?

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
, 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.

Post by Maciej Sobczak

Post by heby
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.

[Maciej Sobczak]

Post by heby
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".

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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.

Post by heby
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.

Post by heby
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.

Post by heby
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.

Post by heby
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.

Post by heby
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ę".

Post by heby
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.

[heby]

Post by Maciej Sobczak
Ć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?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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?

Post by Maciej Sobczak
, to masz teraz Linuksa w Windowsie i... dalej Windows jest na każdym komputerze w biurze.

Bo są gry 3D i pasjans.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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ą.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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...

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
https://www.apple.com/final-cut-pro/

A co kupują jak chcą odpalić ModelSima?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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ć.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

[Maciej Sobczak]

Post by heby

Post by Maciej Sobczak
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.

Post by heby

Post by Maciej Sobczak
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?

Post by heby
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?

Post by heby
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.

Post by heby
A co kupują jak chcą odpalić ModelSima?

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

Post by heby
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.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
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.

[heby]

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
Wszystko darmowe

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

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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?

Post by Maciej Sobczak
i nie da się przenieść takiego "przenośnego" projektu na inne klocki

Bo jest bardzo źle napisany.

Post by Maciej Sobczak
, 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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
, 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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
A co kupują jak chcą odpalić ModelSima?

Windowsa.

Linuxa.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
Wystarczy zmienić kompilator w makefile.

Ale tego makefile też nie mam.

No to zmienic kompialtor w *foo*.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

[Maciej Sobczak]

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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ą.

Post by heby

Post by Maciej Sobczak
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?

Post by heby
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?

Post by heby
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?

Post by heby
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.

Post by heby
Abstrakcji nie szukasz w 3-rd party. Abstrakcję robisz u siebie.

Albo korzystam ze standardów. Takim standardem jest POSIX.

Post by heby
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()?

Post by heby
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.

Post by heby

Post by Maciej Sobczak
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?

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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.

[heby]

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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ć.

Post by Maciej Sobczak
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?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
Własnie
po to aby od detali posix-nie posix nie uzależniać się w swoim kodzie,
poza adapterami do konkretnego OSu.

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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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ą.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
Po prostu będzie jeszcze większy bałagan.

Raczej dodatkowy kompilator do makefile.

[Maciej Sobczak]

Post by heby
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?

Post by heby
POSIX w embedded nie jest dobry.

Nadal nie napisałeś, dlaczego.

Post by heby
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.

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

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

Post by heby
Zaznajom się np. z Qt.

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

Post by heby
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ść.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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.

Post by heby
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]

Post by heby
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ł.

Post by heby
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ć.

Post by heby
Posix to NIE jest abstrakcja na systemy operacyjne.

Właśnie dokładnie tym jest.

Post by heby
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.

Post by heby
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.

Post by heby
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ą.

Post by heby
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.

Post by heby
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."

[heby]

Post by Maciej Sobczak

Post by heby
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?

Post by Maciej Sobczak
Texas ma MSP430

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

Post by Maciej Sobczak
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ć.

Post by Maciej Sobczak

Post by heby
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*.

Post by Maciej Sobczak

Post by heby
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ę.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
Mogę mieć dobrej jakości implementację

Możesz. A masz?

Post by Maciej Sobczak
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ę.

Post by Maciej Sobczak
Przykładowo, dobrej jakości systemem do embedded z interfejsem POSIX jest QNX.
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

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

Czyli wąska grupa unixo-podobnych + duperele.

Post by Maciej Sobczak
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?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

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

A na windowsie?

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
, bo w przybliżeniu 2-3 systemy koniecznie musiały mieć ourMutexCreate

Zniknąłeś pozostałe zalety.

Post by Maciej Sobczak
. 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.

Post by Maciej Sobczak
To jest choroba naszej branży.

Nie. Pisanie na wysokim poziomie nie jest chorobą.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
[POSIX]

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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?

Post by Maciej Sobczak
POSIX jest standardem. QNX spełnia ten standard. FreeRTOS nie spełnia tego standardu. Co zrobić.

Odciąć się abstrakcją.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest.

Bo jest nieprzenośne na inne embedded.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
Zwłaszcza, jak to tego dołożymy stos TCP

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

Post by Maciej Sobczak
. 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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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!

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
"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.

[Maciej Sobczak]

Post by heby

Post by Maciej Sobczak

Post by heby
POSIX w embedded nie jest dobry.

Nadal nie napisałeś, dlaczego.

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.

Post by heby
Ale ma 40 programów w dildo

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

Post by heby
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.

Post by heby
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)

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

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

Post by heby

Post by Maciej Sobczak
Mogę mieć dobrej jakości implementację

Możesz. A masz?

Przecież już pisałem.

Post by heby

Post by Maciej Sobczak
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().

Post by heby
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).

Post by heby
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).

Post by heby
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)

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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"?

Post by heby
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.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
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.

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

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

Post by heby
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

[heby]

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
I niepotrzebnych rzeczy nie ma, zwłaszcza w systemach embedded.

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

Post by Maciej Sobczak
Nie zmienia to faktu, że nadal QNX jest POSIX.

Jak zrobisz make all_shit_included to na pewno jest.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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?

Post by Maciej Sobczak
, 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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
Bo widzisz - POSIX to API. Natomiast FreeRTOS to konkretny system.

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

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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!:
}

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
Pokaż na przykładzie FreeRTOS

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

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
, gdyby twórcy januszowych RTOSików

A twórcy januszowych Windowsów?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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".

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

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

Możesz powiedzie gdzie go sobie przypisuje?

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

[Maciej Sobczak]

Post by heby
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ą.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
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".

Post by heby

Post by Maciej Sobczak
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.

Post by heby

Post by Maciej Sobczak
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++.

Post by heby
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.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
Od kiedy API utrudnia weryfikację? W jaki sposób?

switch ( fooResult )
{
}

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

Post by heby
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.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
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ć.

Post by heby

Post by Maciej Sobczak
, 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.

Post by heby

Post by Maciej Sobczak
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.

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być

Idealista.

Inżynier. :-)

Post by heby
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]

Post by Maciej Sobczak

Post by heby
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:

Loading Image...

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.

[heby]

Post by Maciej Sobczak
Osobiście nie mam problemu z określeniem "POSIX subset".

Super. To wiele wyjaśnia.

Post by Maciej Sobczak
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?

Post by Maciej Sobczak

Post by heby
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".

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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).

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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!

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
z takiego powodu, że ktoś chce zarobić na tych wszystkich ludziach

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

Post by Maciej Sobczak
, 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?

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
A gdyby tak zaczęli, od początku, zgodnie ze standardami?

To by nigdy nie wystarowali.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

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

I kompiluje sie pod kilkoma rodzinami OSów.

Post by Maciej Sobczak
Ja się wykażę odpornością, bo piszę pod standard.

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

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
Od kiedy API utrudnia weryfikację? W jaki sposób?

switch ( fooResult )
{
}

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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
Słowo klucz: "subset".

Słowo klucz: zmiana na inny OS.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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".

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
, 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.

Post by Maciej Sobczak
Tak to jest jak się uwierzy komuś, kto olewa standardy.

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

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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ć.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być

Idealista.

Inżynier. :-)

O tak.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
Natomiast specjalnie nieprofesjonalne jest na siłę nieprzestrzeganie standardów, "bo nie".

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

[Maciej Sobczak]

Post by heby

Post by Maciej Sobczak
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.

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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

Post by heby
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.

Post by heby

Post by Maciej Sobczak

Post by heby
Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior.

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

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

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

To samo.

Post by heby
A ci co zaczeli na januszowym Linuxie?

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

Post by heby

Post by Maciej Sobczak
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.

Post by heby
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.

Post by heby

Post by Maciej Sobczak
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.

Post by heby

Post by Maciej Sobczak
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.

[heby]

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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 ...

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
, zwłaszcza w embedded

O tam jest wiele rzeczy na opak, to prawda.

Post by Maciej Sobczak
, ż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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak
Wracając, PSE51 pozwala systemom takim jak FreeRTOS mieć API POSIX.

Korutynowy?

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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?

Post by Maciej Sobczak

Post by heby
A ci co zaczeli na januszowym Linuxie?

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

Na przykład na Windows?

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
Niestety.

Nie udawaj zmartwionego :D

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
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?.

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by heby

Post by Maciej Sobczak
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.

[Maciej Sobczak]

Post by heby
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.

[heby]

Post by Maciej Sobczak

Post by heby
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.

Post by Maciej Sobczak
Skończył mi się limit energii na prostowanie Twojego trollowania.

Widzę.

Post by Maciej Sobczak
Do następnego razu.

Nie wiem czy mi się chcę.

[Luke]

Post by heby
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.

[heby]

Post by Luke
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.

Post by Luke
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?

Post by Luke
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.

[Luke]

Post by heby
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...

Post by heby
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.

Post by heby
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ł.

Post by heby
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.

[heby]

Post by Luke

Post by heby
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".

Post by Luke
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".

Post by Luke

Post by heby
Niebywałe. Co oni tam robili przez te wszystkie lata? DoubleSpace?

Nic.

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

Post by Luke
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.

Post by Luke

Post by heby
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.

Post by Luke
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.

[fir]

Post by heby
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

[fir]

Post by fir

Post by heby
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

[Smok Eustachy]

W dniu 06.01.2021 o 14:28, heby pisze:
/..../

Post by heby
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?

Post by heby

Post by Luke

Post by heby
Niebywałe. Co oni tam robili przez te wszystkie lata? DoubleSpace?

Nic.

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

Post by Luke
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.

[heby]

Post by Smok Eustachy
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.

Post by Smok Eustachy

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?

[Luke]

Post by heby

Post by Luke
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.

Post by heby

Post by Luke

Post by heby
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.

Post by heby

Post by Luke
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.

Post by heby

Post by Luke

Post by heby
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.

Post by heby
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.

[heby]

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

A co było niewolne?

Post by Luke

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

Skoro DOS ludziom wystarczał

Nie wystarczał. Patrz na Apple.

Post by Luke
i nie było konkurencji

Patrz na Apple.

Post by Luke
, był brak rozwoju.

Czyli stracone lata.

Post by Luke
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.

Post by Luke
Hardware była.

Raczej tylko kolonowali kiepski design.

Post by Luke
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ł.

Post by Luke
Bo ludzie i tak będą kupowali.

Bo gry były.

Post by Luke
Gdybym IBM nie uwolnił sprzętu

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

Post by Luke
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.

Post by Luke

Post by heby
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

Post by Luke
Przy czym im nie chodziło o
dominację na rynku nigdy.

I jakoś zdominowali rynek w USA.

Post by Luke

Post by heby
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ć.

Post by Luke
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.

[Smok Eustachy]

Post by heby

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

A co było niewolne?

Post by Luke

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

Skoro DOS ludziom wystarczał

Nie wystarczał. Patrz na Apple.

Post by Luke
i nie było konkurencji

Patrz na Apple.

Jakoś rynku nie podbiło

[heby]

Post by heby
Patrz na Apple.

 Jakoś rynku nie podbiło

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

[Smok Eustachy]

Post by heby

Post by heby
Patrz na Apple.

  Jakoś rynku nie podbiło

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

Ile ma % a ile pecety?

[heby]

Post by Smok Eustachy

Post by heby

Post by heby
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.

[Smok Eustachy]

Post by heby

Post by Smok Eustachy

Post by heby

Post by heby
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.

[heby]

Post by Smok Eustachy
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...).

Post by Smok Eustachy
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.

Post by Smok Eustachy
Tak donosi Wiki.

Takie czasy były.

[Mateusz Viste]

Post by heby
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.

Post by heby
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

[heby]

Post by Mateusz Viste

Post by heby
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.[...]".

[Krzysztof Mitko]

Post by Smok Eustachy

Post by heby

Post by Smok Eustachy

Post by heby

Post by heby
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/>

[a***@math.uni.wroc.pl]

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.

[heby]

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl
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.

[a***@math.uni.wroc.pl]

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl
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.

[heby]

Post by a***@math.uni.wroc.pl
No Sinclair Ql to byla wtopa

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

Post by a***@math.uni.wroc.pl

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.

Post by a***@math.uni.wroc.pl
, przy 32 kB sytem lepiej dzialal z jednym zadaniem
na raz.

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

Post by a***@math.uni.wroc.pl
Wielozadaniowosc + GUI

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

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl

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.

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl

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.

Post by a***@math.uni.wroc.pl
Dokladniej
- 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.

Post by a***@math.uni.wroc.pl
- 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.

Post by a***@math.uni.wroc.pl
- solidna blaszana obudowa z zasilaczem w srodku

Zupełnie jak w Apple II

Post by a***@math.uni.wroc.pl
- miejsce na karty rozszerzen w srodku

Zupełnie jak Apple II.

Post by a***@math.uni.wroc.pl
- 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ść.

Post by a***@math.uni.wroc.pl
- 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.

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl

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.

Post by a***@math.uni.wroc.pl
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.

Post by a***@math.uni.wroc.pl
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.

[Marcin Debowski]

Post by Luke
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.

A kiedy oni ten sprzęt "uwolnili"?

[heby]

Post by Marcin Debowski
A kiedy oni ten sprzęt "uwolnili"?

IBM zaprojektował swoje cudo techniki jako "otwarte". Można więc
powiedzieć że "od razu".

Martwi mnie tylko ignorowanie, że Apple też pozwalało na klony. Może
bardziej kontrolujac, ale mimo to Apple II produkowano wszędzie włącznie
z CCCP ...

[Marcin Debowski]

Post by heby

Post by Marcin Debowski
A kiedy oni ten sprzęt "uwolnili"?

IBM zaprojektował swoje cudo techniki jako "otwarte". Można więc
powiedzieć że "od razu".

Im chyba zależało na czasie, więc co zrobili to posładali do kupy różne
rozwiązania. Wikipedia twierdzi, że nie było z tym związanego, żadnego
patentu, czyli w zasadzie to nic nie uwalniali. Kwestia dyskusyjna czy
to była celowa polityka czy nie.
https://en.wikipedia.org/wiki/IBM_Personal_Computer

Tu nb. taki paragraf dot. o czym wcześniej pisaliście:
Several CPUs were considered, including the Texas Instruments TMS9900,
Motorola 68000 and Intel 8088. The 68000 was considered the best
choice,[17] but was not production-ready like the others.[18] The IBM
801 RISC processor was also considered, since it was considerably more
powerful than the other options, but rejected due to the design
constraint to use off-the-shelf parts.

Czyli jak najszybciej i z gotowych podzespołów.

ALe dalej:
During the design process IBM avoided vertical integration as much as
possible, choosing for example to license Microsoft BASIC despite having
a version of BASIC of its own for mainframes, due to the better existing
public familiarity with the Microsoft version.[29].

Czyli generalnie wygląda na szybką interwencję marketingową niż na
jakieś perspektywiczne planowanie.

Post by heby
Martwi mnie tylko ignorowanie, że Apple też pozwalało na klony. Może
bardziej kontrolujac, ale mimo to Apple II produkowano wszędzie włącznie
z CCCP ...
http://youtu.be/PMXKy5vrMJM

Ignorowanie przez interlokutora? :) Różnica głownie taka, że Apple dawał
licencje, jak widać niekorzystne dla siebie. IMB nie miał czego
licencjonować.

[Luke]

Post by Marcin Debowski
A kiedy oni ten sprzęt "uwolnili"?

Oczywiście wedle niektórych nigdy. W praktyce na samym początku.

https://medium.com/lessons-from-history/a-world-without-the-ibm-pc-9db63c27b85e

Czytając ten artykuł przypomniały mi się argumentacje zwolenników Sama
Coupe (tak, był taki ośmiobitowiec).

Jeszcze raz podsumuję, co uważam - gdyby nie PC, żyli byśmy dziś w kręgu
zamkniętych obozów tajnych architektur, nieprzenośnego oprogramowania,
takie problemy "czy kupić spectrum, C64 czy Atari, każdy ma wady i
zalety" przeniósł by się do następnego wieku, a każdy ze współczesnych
komputerów kosztowałby nadal tyle, ile najdroższy Apple. Komputery
byłyby takimi smart-tv, a każdy telefon kosztowałby tyle, co najdroższy
ajfon, wszak nie byłoby linuxa (chyba że w 90% składającego się z
łaskawie skompilowanych blobów) i nikt nie miałby interesu zrobić androida.

EOT. Każdy niech sobie dalej uważa, co chce ;)

L.

[Wojciech Bancer]

On 2021-01-23, Luke <***@luke.net> wrote:

[...]

Post by Luke
Jeszcze raz podsumuję, co uważam - gdyby nie PC, żyli byśmy dziś w kręgu
zamkniętych obozów tajnych architektur, nieprzenośnego oprogramowania,
takie problemy "czy kupić spectrum, C64 czy Atari, każdy ma wady i
zalety"

A teraz mamy "czy kupiź PS5, Xbox, czy Nintendo Switch, każdy ma wady
i zalety". Nie? A Apple ze swoim M1 chyba jednak właśnie zaczyna
zamiatać rynek (znowu).

[Maciek Godek]

Post by Luke

Post by Marcin Debowski
A kiedy oni ten sprzęt "uwolnili"?

Oczywiście wedle niektórych nigdy. W praktyce na samym początku.
https://medium.com/lessons-from-history/a-world-without-the-ibm-pc-9db63c27b85e
Czytając ten artykuł przypomniały mi się argumentacje zwolenników Sama
Coupe (tak, był taki ośmiobitowiec).
Jeszcze raz podsumuję, co uważam - gdyby nie PC, żyli byśmy dziś w kręgu
zamkniętych obozów tajnych architektur, nieprzenośnego oprogramowania,
takie problemy "czy kupić spectrum, C64 czy Atari, każdy ma wady i
zalety" przeniósł by się do następnego wieku, a każdy ze współczesnych
komputerów kosztowałby nadal tyle, ile najdroższy Apple. Komputery
byłyby takimi smart-tv, a każdy telefon kosztowałby tyle, co najdroższy
ajfon, wszak nie byłoby linuxa (chyba że w 90% składającego się z
łaskawie skompilowanych blobów) i nikt nie miałby interesu zrobić androida.

Patrząc na dotychczasowy kierunek rozwoju oprogramowania, jest to raczej wątpliwe.
Współcześnie zestaw instrukcji procesora czy adresy peryferiów są pomijalnym szczegółem,
o którym dzisiejsi programiści nawet nie wiedzą.

Dominują przenośne software'owe platformy oparte na maszynach wirtualnych, takie
jak JVM albo przeglądarka/JavaScript albo Unity, a swego czasu również Flash
(albo mniej udane próby wdrożeniowe, takie jak .NET/Xamarin, ale nawet niszowe
ciekawostki jak PICO8 czy Löve wpisują się w ten trend abstrakcji od sprzętu)

I to raczej one stanowią "zamknięte obozy" współczesnego świata (które -- poza bastionem
Apple -- wcale nie są aż takie zamknięte).

Nie wydaje mi się, żeby była w tym jakakolwiek zasługa IBM, i gdyby PC nigdy nie powstał,
raczej niewiele by to zmieniło (bo programiści tak samo by się denerwowali, że muszą utrzymywać
ten sam projekt na różne platformy, i stosowaliby takie same środki zaradcze)

Koloryt ośmiobitowców brał się z ograniczeń technologicznych: Commodore 64 miało inną paletę
barw, niż ZX Spectrum, ale obie możesz bez problemu emulować na maszynie z 24-bitowym kolorem,
bo 24-bitowa paleta przekracza ograniczenia naszej percepcji.

[Roman Tyczka]

Post by Maciek Godek

Post by Luke
Jeszcze raz podsumuję, co uważam - gdyby nie PC, żyli byśmy dziś w kręgu
zamkniętych obozów tajnych architektur, nieprzenośnego oprogramowania,
takie problemy "czy kupić spectrum, C64 czy Atari, każdy ma wady i
zalety" przeniósł by się do następnego wieku, a każdy ze współczesnych
komputerów kosztowałby nadal tyle, ile najdroższy Apple. Komputery
byłyby takimi smart-tv, a każdy telefon kosztowałby tyle, co najdroższy
ajfon, wszak nie byłoby linuxa (chyba że w 90% składającego się z
łaskawie skompilowanych blobów) i nikt nie miałby interesu zrobić androida.

Patrząc na dotychczasowy kierunek rozwoju oprogramowania, jest to raczej wątpliwe.
Współcześnie zestaw instrukcji procesora czy adresy peryferiów są pomijalnym szczegółem,
o którym dzisiejsi programiści nawet nie wiedzą.
Dominują przenośne software'owe platformy oparte na maszynach wirtualnych, takie
jak JVM albo przeglądarka/JavaScript albo Unity, a swego czasu również Flash
(albo mniej udane próby wdrożeniowe, takie jak .NET/Xamarin, ale nawet niszowe
ciekawostki jak PICO8 czy Löve wpisują się w ten trend abstrakcji od sprzętu)
I to raczej one stanowią "zamknięte obozy" współczesnego świata (które -- poza bastionem
Apple -- wcale nie są aż takie zamknięte).
Nie wydaje mi się, żeby była w tym jakakolwiek zasługa IBM, i gdyby PC nigdy nie powstał,
raczej niewiele by to zmieniło (bo programiści tak samo by się denerwowali, że muszą utrzymywać
ten sam projekt na różne platformy, i stosowaliby takie same środki zaradcze)

Czego świetnym przykładem była gra Another World:

https://fabiensanglard.net/anotherWorld_code_review/

ciekawa historia, polecam :-)

[Marek]

Post by Luke
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ę

Że co? Linux (kernel) praktycznie od samego początku był stabilny (w
porównaniu do dos/win). Najbardziej już powszechnie stosowaną wersję
1.2.* to lata 94-95 więc to był środek lat 90 a nie ich koniec.

[Smok Eustachy]

Post by heby

Post by Luke
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.

Był jeszcze 8088
Oprócz DOSa zaczeli robić Windows 16 bit. Śmieszne takie.

[Marcin Debowski]

Post by Luke

Post by slawek
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ś

Szkoda tylko, że jednocześnie tak dała dupy z OS/2.