Re: Spieszmy się kochać Windows

Newsgroups	pl.comp.programming
Date	2021-01-08 13:42 -0800
References	(10 earlier) <rt2n1n$p3j$1@dont-email.me> <51e942ab-1057-44f7-88bf-c82c5417f3c1n@googlegroups.com> <rt4oer$b83$1@dont-email.me> <f1e32e30-9f24-4f20-aa82-b346d9212958n@googlegroups.com> <rt82ve$lqf$1@dont-email.me>
Message-ID	<4fa0a2e5-f76b-4c57-a8d1-4c0ab25ea4e6n@googlegroups.com> (permalink)
Subject	Re: Spieszmy się kochać Windows
From	Maciej Sobczak <see.my.homepage@gmail.com>

Show all headers | View raw

> Taki producent odpowiednika STM32 ale opartego o rdzeń RISC może ściąć 
> cenę swoich cpu o dolara, powiedzmy. A to robi różnicę kiedy ich 
> sprzedajesz setki milionów, choćby jako sterowniki dildo i szczoteczek 
> do zębów.

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

> POSIX w embedded nie jest dobry.

Nadal nie napisałeś, dlaczego.

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

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

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

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

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

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

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

> Zaznajom się np. z Qt.

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

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

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

> Zaś wszystkei zgodne maja mała użytecznośc w embedded. POSIX jest do 
> stacji roboczych a nie migania diodami lub kontroli oddechu. Naprwadę, 
> nie potrzebujesz parentpid i fopen w respiratorze.

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

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

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

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

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

> Abstrakcją może byc też Qt

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

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

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

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

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

> Posix to NIE jest abstrakcja na systemy operacyjne.

Właśnie dokładnie tym jest.

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

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

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

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

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

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

> Pewnego dnia januszowy RTOSik zostanie zamieniony na mirkowy CE bo taki 
> się zwidziało właścicielowi biznesu. Jesli Janusz nie był iditiotą to 
> zmiana na to CE może być mało bolesna.

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

> Pamiętaj o czym rozmawiamy: stwierdziłeś że zmiana procesora to nie 
> tylko zmiana makefile, tylko bardzo ciezka rzecz. 
> 
> No więc to cieżka rzecz, jak się ma dziadowski kod.

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

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

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

Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Spieszmy się kochać Windows slawek <x.y@org.org> - 2020-12-06 10:41 +0100
  Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2020-12-06 13:26 -0800
    Re: Spieszmy się kochać Windows slawek <x.y@org.org> - 2020-12-24 12:05 +0100
  Re: Spieszmy się kochać Windows arnold@hooterville.invalid (Arnold Ziffel) - 2020-12-16 09:26 +0000
    Re: Spieszmy się kochać Windows slawek <x.y@org.org> - 2020-12-24 12:02 +0100
      Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-03 12:42 +0100
        Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-03 12:53 +0100
          Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-03 07:19 -0800
            Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-03 16:45 +0100
              Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-04 09:59 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-05 09:18 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-05 12:06 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-05 22:51 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-06 08:02 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-06 17:28 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-07 13:13 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-07 23:46 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-08 13:42 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-09 01:23 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-09 07:48 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-09 18:53 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-10 07:56 -0800
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-10 08:25 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-10 18:05 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-11 08:41 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-11 18:07 +0100
                Re: Spieszmy się kochać Windows Maciej Sobczak <see.my.homepage@gmail.com> - 2021-01-12 09:43 -0800
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-13 07:14 +0100
          Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-04 19:02 +0100
            Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-04 20:35 +0100
              Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-06 10:58 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-06 14:28 +0100
                Re: Spieszmy się kochać Windows fir <profesor.fir@gmail.com> - 2021-01-06 08:32 -0800
                Re: Spieszmy się kochać Windows fir <profesor.fir@gmail.com> - 2021-01-07 04:27 -0800
                Re: Spieszmy się kochać Windows Smok Eustachy <smok@wurg.pl> - 2021-01-07 14:55 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-07 15:03 +0100
                Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-09 20:57 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-09 21:28 +0100
                Re: Spieszmy się kochać Windows Smok Eustachy <smokeustachy@WURG.pl> - 2021-01-10 14:37 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-10 15:43 +0100
                Re: Spieszmy się kochać Windows Smok Eustachy <smok@wurg.pl> - 2021-01-10 21:07 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-10 21:49 +0100
                Re: Spieszmy się kochać Windows Smok Eustachy <smok@wurg.pl> - 2021-01-11 09:24 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-11 12:33 +0100
                Re: Spieszmy się kochać Windows Mateusz Viste <mateusz@xyz.invalid> - 2021-01-11 13:03 +0100
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-11 13:26 +0100
                Re: Spieszmy się kochać Windows Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> - 2021-01-11 11:37 +0000
                Re: Spieszmy si? kocha? Windows antispam@math.uni.wroc.pl - 2021-01-23 02:50 +0000
                Re: Spieszmy si? kocha? Windows heby <heby@poczta.onet.pl> - 2021-01-26 16:25 +0100
                Re: Spieszmy si? kocha? Windows antispam@math.uni.wroc.pl - 2021-01-26 23:40 +0000
                Re: Spieszmy si? kocha? Windows heby <heby@poczta.onet.pl> - 2021-01-27 11:53 +0100
                Re: Spieszmy się kochać Windows Marcin Debowski <agatek@INVALID.zoho.com> - 2021-01-15 08:21 +0000
                Re: Spieszmy się kochać Windows heby <heby@poczta.onet.pl> - 2021-01-15 19:20 +0100
                Re: Spieszmy się kochać Windows Marcin Debowski <agatek@INVALID.zoho.com> - 2021-01-16 03:07 +0000
                Re: Spieszmy się kochać Windows Luke <luke@luke.net> - 2021-01-23 09:48 +0100
                Re: Spieszmy się kochać Windows Wojciech Bancer <wojciech.bancer@gmail.com> - 2021-01-23 21:44 +0100
                Re: Spieszmy się kochać Windows Maciek Godek <godek.maciek@gmail.com> - 2021-01-25 02:28 -0800
                Re: Spieszmy się kochać Windows Roman Tyczka <romantyczka@hate.you.spammer> - 2021-01-30 19:31 +0100
                Re: Spieszmy się kochać Windows Marek <fake@fakeemail.com> - 2021-02-21 17:51 +0100
              Re: Spieszmy się kochać Windows Smok Eustachy <smok@wurg.pl> - 2021-01-07 14:50 +0100
        Re: Spieszmy się kochać Windows Marcin Debowski <agatek@INVALID.zoho.com> - 2021-01-05 12:23 +0000

csiph-web