Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #34255 > unrolled thread

Spieszmy się kochać Windows

Back to article view | Back to pl.comp.programming

Contents

  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

Page 1 of 4  [1] 2 3 4  Next page →

#34255 — Spieszmy się kochać Windows

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/

[toc] | [next] | [standalone]

#34257

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34261

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


A i owszem.


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

[toc] | [prev] | [next] | [standalone]

#34259

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

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

NTG. Cross & FUT: pcoa.

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

[toc] | [prev] | [next] | [standalone]

#34260

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


Ależ oczywiście że ta grupa.

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

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

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


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

[toc] | [prev] | [next] | [standalone]

#34277

W dniu 24.12.2020 o 12:02, slawek pisze:

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

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

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

Niestety, cywilizacje zaliczają wzloty i upadki.

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

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

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

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

L.

[toc] | [prev] | [next] | [standalone]

#34278

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34280

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34283

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

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

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

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

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

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

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

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

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

> Bez przesady.

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

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

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

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

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

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

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

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

Istotne jest jak zareaguje embedded + mobile.

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

[toc] | [prev] | [next] | [standalone]

#34288

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

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

> Przy robieniu nowego softu to nie jest 
> argument.

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

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

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

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

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

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34291

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> To po co ryzykować z czymś innym?

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

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

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

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

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

Desktopy? Nikt tego nie potrzebuje, poza kilkoma nerdami.

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34293

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

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

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

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

Ale ja kupuję programy już skompilowane.

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

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

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

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

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

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

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

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

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

Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich system operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do peryferiów. To, że Twoje kilka linijek kodu na wierzchu tego wszystkiego jest "przenośne", bo napisałeś je sobie w "języku wysokiego poziomu", który "zapewnia abstrakcje", to jest złudzenie optyczne.

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

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

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

albo po to:

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34294

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

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

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

Dokładnie to samo masz z armem.

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

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

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

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

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

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

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

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

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

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

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

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

Bo są gry 3D i pasjans.

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

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

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

Pozostałe sie nie zmieniają.

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

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

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

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

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

>> Jesli team od software jest zdrowy psychicznie to każe
>> sie że całą ta migracja zakończy się poprzez zmianę kompilatora w
>> makefile i puszczenia testów.
> Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich system operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do peryferiów.

Innymi słowy wziął vendor-lockin? Przecież pisałem, ze zdrowy psychicznie.

Dodam też, że komunikacja z takimi biblitekami musi być napisana przez 
abstrakcję, którą można łatwo podmienić. Nie została napisana przez 
abstrakcję? Mówiłam przeciez że zdrowych...

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

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

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

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

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

A co kupują jak chcą odpalić ModelSima?

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

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

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

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

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

Wystarczy zmienić kompilator w makefile.

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

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

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

> Pierdyliony pluginów.

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

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

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

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

>> Całośc RISC-V opiera się o dominacje w
>> embedded
> Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas.

Myślę że wyjąłeś sobie 1 mały detal z embedded i nazywać go 
najważniejszym, olewając inne detale.

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

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

[toc] | [prev] | [next] | [standalone]

#34309

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

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

> > Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich system operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do peryferiów.
> Innymi słowy wziął vendor-lockin? Przecież pisałem, ze zdrowy psychicznie. 

Oczywiście. To są bardzo racjonalne decyzje. A firma, która lepi swój system z kilku niepasujących do siebie vendor-lockinów, wcale nie jest przez to bardziej racjonalna. Do tego potrzebuje więcej taśmy klejącej i ma gorszy support. Sam pisałeś o "bardzo drogich projektach EDA" - one są drogie, bo? Wszystko darmowe i otwarte a projekty bardzo drogie. Ciekawe, nie?

> Dodam też, że komunikacja z takimi biblitekami musi być napisana przez 
> abstrakcję, którą można łatwo podmienić. Nie została napisana przez 
> abstrakcję? Mówiłam przeciez że zdrowych...

Ależ oczywiście, że przez abstrakcję. Przecież TI-RTOS ma interfejs POSIX. To bardzo dobra i sprawdzona abstrakcja (dlatego bardzo racjonalne było to wziąć). Szkoda tylko, że inne RTOSy tej abstrakcji nie mają i nie da się przenieść takiego "przenośnego" projektu na inne klocki, z innym RTOSem. Albo z innym stosem TCP. Itd. Pacz pan, przenośny program, a nie da się przenieść. Same abstrakcje, wszystko otwarte, a projekty dalej drogie. Ciekawe, nie?

> Tak wygląda rynek laptopów: snoby oglądające pornole. Szczególnie Apple, 
> ich kompytery migrują w kierunku kompletnie bezuzytecznych do 
> profesjonalnej pracy

Klikasz w złym miejscu. https://www.apple.com/pl/mac-pro/specs/
Jak dla mnie, ma wystarczająco dużo złącz.

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

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

> Wystarczy zmienić kompilator w makefile.

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

> Sporo software ma pluginy pisane w pythone, tclu itd. I co teraz?

Nie zrozumiałeś. Pluginy do obróbki dźwięku albo obrazu (albo video) nie są pisane w Pythonie.

> > Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas.
> Myślę że wyjąłeś sobie 1 mały detal z embedded i nazywać go 
> najważniejszym, olewając inne detale.

A jakie są inne detale? Bo rozmawiamy o zmianie CPU, tak?
Bo ja dorzucam jeszcze konieczność zmiany karty graficznej, która mi nie zadziała z RISC-V, bo NVIDIA ma 40B$ powodów, żeby nie zadziałała. To już drugi detal.

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

[toc] | [prev] | [next] | [standalone]

#34310

On 06/01/2021 17:02, Maciej Sobczak wrote:
> Nie wiem, czy są. Ale wiem, że NVIDIA kupiła ARMa.

I nagle zmieniła politykę czy tylko wyciska dalej co się da z licencji?

To że ktoś jest właścicielem nie zawsze powoduje jakiekolwiek widoczne 
efekty działania. Co najwyżej AMD szybciej wembeduje RISC-V w swoje SoC.

> 40B$ to jest wystarczająco dużo powodu, żeby spodziewać się sterowników do GPU dla ARMa i jednocześnie nie spodziewać się ich do RISC-V.

Ależ zobaczymy. Nie można też wykluczyć że nvidia ma interes w NIE 
dawaniu rdzeni ARMa konkurencji.

>>> Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich system operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do peryferiów.
>> Innymi słowy wziął vendor-lockin? Przecież pisałem, ze zdrowy psychicznie.
> Oczywiście. To są bardzo racjonalne decyzje. A firma, która lepi swój system z kilku niepasujących do siebie vendor-lockinów>, wcale nie jest przez to bardziej racjonalna. Do tego potrzebuje więcej taśmy klejącej i ma gorszy support. Sam pisałeś o "bardzo drogich projektach EDA" - one są drogie, bo?

Bo potrzebują drogich specjalistów, bardzo drogich ipcores, bardzo 
bardzo drogich narzędzi i skrajnie drogiego prototypowania.

> Wszystko darmowe

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

> i otwarte a projekty bardzo drogie. Ciekawe, nie?

Nie, nic takiego nie istnieje jak "otwarte projekty darmowe" dotyczące 
rynku embedded. Ja nie mówie o miganiu diodą z RISC. Ja mówie o grubych 
graczach którzy projektują choćby dla lotnictwa czy medycyny. Tam nie ma 
nic za friko. NIC.

>> Dodam też, że komunikacja z takimi biblitekami musi być napisana przez
>> abstrakcję, którą można łatwo podmienić. Nie została napisana przez
>> abstrakcję? Mówiłam przeciez że zdrowych...
> Ależ oczywiście, że przez abstrakcję. Przecież TI-RTOS ma interfejs POSIX. To bardzo dobra

POSIX nie jest "bardzo dobrą abstrakcją" bo sam jest bardzo niedobry z 
punktu widzenia embedded. To nie do tego.

>  Szkoda tylko, że inne RTOSy tej abstrakcji nie mają

I nic dziwnego, używanie POSIXa w embedded jest komplenie bez sensu w 
większosci zastosowań. FreeRTOS składa się z wątków, schedulera, jakiś 
mutexów i tyle.

POSIXa też się zawija w abstrakcję w swoim kodzie. Chcesz mieć pełno 
pthread_mutex czy może Foo::Mutex? I co jest większym vendor-lockin?

> i nie da się przenieść takiego "przenośnego" projektu na inne klocki

Bo jest bardzo źle napisany.

> , z innym RTOSem. Albo z innym stosem TCP.

Bo jest bardzo, bardzo źle napisany.

Abstrakcji nie szukasz w 3-rd party. Abstrakcję robisz u siebie. Własnie 
po to aby od detali posix-nie posix nie uzależniać się w swoim kodzie, 
poza adapterami do konkretnego OSu.

W razie zmiany OSu, zmieniasz adapter.

> Itd. Pacz pan, przenośny program, a nie da się przenieść.

Nie jest przenośny. Jest vendor-lockin. Tutaj vendorem jest POSIX, 
przeciekajacy do kodu.

> Same abstrakcje

Jeśli w kodzie logiki swojego programu używasz bezpośrednio POSIXa to 
nie jest to abstrakcja, tylko IMPLEMENTACJA pod konkretny OS. Chcesz 
zmienic na inny OS nie będacy posixem, jesteś w d..pie.

>, wszystko otwarte, a projekty dalej drogie. Ciekawe, nie?

Nie, najzwyczajneij gówniany kod. Możliwe że z założenia, nie każdy musi 
od razu być uniwersalny.

>> Tak wygląda rynek laptopów: snoby oglądające pornole. Szczególnie Apple,
>> ich kompytery migrują w kierunku kompletnie bezuzytecznych do
>> profesjonalnej pracy
> Klikasz w złym miejscu. https://www.apple.com/pl/mac-pro/specs/
> Jak dla mnie, ma wystarczająco dużo złącz.

I nagle przestają działać. Kojarzysz "mała aferę" z DisplayLink? 
Rechotrałem godzinami czytają komentarze profesjonalistów od 
dicking-around siedzącymi przed swoimi jabłkami płacząc że im się popsuło.

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

Linuxa.

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

Aha. Ale jakoś słyszę ciągle że AutoCAD i Photoshop są powodem bycia 
profesjonalnym.

>> Wystarczy zmienić kompilator w makefile.
> Ale tego makefile też nie mam.

No to zmienic kompialtor w *foo*.

> Problemem nie jest Twój czy mój kod. Problemem jest ten cudzy kod.

Jesteś od niego oddzielony abstrakcją. *ZAWSZE* oddziela się 3-rd party 
abstrakcją. Można tego nie robić z róznej przyczyny, ale wtedy to jest 
*dziadowski* kod.

Oczywiście nie muszę przecież przypomniać że oddzielanie się abstrakcją 
od wszystkeigo pomaga róznież w testowaniu. No ale skoro kod dziadowski, 
to może i testowania nie ma.

>> Sporo software ma pluginy pisane w pythone, tclu itd. I co teraz?
> Nie zrozumiałeś. Pluginy do obróbki dźwięku albo obrazu (albo video) nie są pisane w Pythonie.

Nie są, a Mac przeskoczył na ARMa i reszta 3rd-party zrobiła to chwile 
potem. Wniosek: to nijaki argument. Zmienili tylko kompilator w makefile 
lub poprawili jakieś bugi i poszło.

>>> Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas.
>> Myślę że wyjąłeś sobie 1 mały detal z embedded i nazywać go
>> najważniejszym, olewając inne detale.
> A jakie są inne detale? Bo rozmawiamy o zmianie CPU, tak?

Rozmawiamy o embedded i zmienach embedded cpu. To nie jest *osobny* 
scalak, tylko zazwyczaj coś wciśnięte do jakiegoś ASICa zrobionego jako 
SoC, z masą skomplikowanych peryferiów w jednym kawałku krzemu.

> Bo ja dorzucam jeszcze konieczność zmiany karty graficznej, która mi nie zadziała z RISC-V, bo NVIDIA ma 40B$ powodów, żeby nie zadziałała. To już drugi detal.

Ale karty nvidia nie są na rynku embedded, a na rynku desktopów nie ma 
to znaczenia, pornole czy photoshop pójdą na czymkolwiek. To że 5% 
desktopów ma karty nvidi jest naprawdę mało istotne nad zastanawianiem 
się o przydatność RISC-V na desktopy.

[toc] | [prev] | [next] | [standalone]

#34316

> > Nie wiem, czy są. Ale wiem, że NVIDIA kupiła ARMa.
> I nagle zmieniła politykę czy tylko wyciska dalej co się da z licencji? 

A już jest powód, żeby zmieniać politykę? Ta nasza dyskusja na pewno takim powodem nie jest.

> Ależ zobaczymy. Nie można też wykluczyć że nvidia ma interes w NIE 
> dawaniu rdzeni ARMa konkurencji.

Może tak być. Ale, ale... Kto jest ich konkurencją? Producenci embedded? Od kiedy?
Producenci embedded będą dla nich nowym dochodowym klientem a nie konkurencją.

> > i otwarte a projekty bardzo drogie. Ciekawe, nie?
> Nie, nic takiego nie istnieje jak "otwarte projekty darmowe" dotyczące 
> rynku embedded. Ja nie mówie o miganiu diodą z RISC. Ja mówie o grubych 
> graczach którzy projektują choćby dla lotnictwa czy medycyny. Tam nie ma 
> nic za friko. NIC.

No dobra. To po co komu ten RISC-V?
Na rynku, na którym NIC nie jes darmowe, NIKT nie oczekuje, że będzie taniej. Taka dziwna, rozumiesz, społeczność.
Po prostu się wlicza koszty w cenę produktu, na całej długości łańcucha. Ostatecznie i tak płaci podatnik, jeśli mówimy o tych konkretnych branżach. Więc kogo obchodzi RISC-V?

> POSIX nie jest "bardzo dobrą abstrakcją" bo sam jest bardzo niedobry z 
> punktu widzenia embedded. To nie do tego.

Uuu, to nie dość, że już poobrażałeś wszystkich (że psychiczni) to teraz jeszcze POSIX niedobry.
Czy nie ustaliliśmy już w tych dyskusjach, że tylko my dwaj robimy dobrze?

> używanie POSIXa w embedded jest komplenie bez sensu w 
> większosci zastosowań. FreeRTOS składa się z wątków, schedulera, jakiś 
> mutexów i tyle. 

No, i każda z tych rzeczy może mieć API POSIX. Bo niby w czym funkcja xSemaphoreCreateMutex jest lepsza od pthread_mutex_init?
Ja wiem, w czym jest gorsza. Otóż kod działający na POSIX nie kompiluje się na FreeRTOS. I trzeba robić "abstrakcje", co jest o tyle idiotyczne, że POSIX już jest abstrakcją. No ale po co projekty mają być tanie, skoro mogą być drogie?

> POSIXa też się zawija w abstrakcję w swoim kodzie.

No właśnie się pytam, po co? Rozumiem, że rejestr w mikrokontrolerze do mrugania LEDem można opakować, bo w każdym uC się mruga inaczej. Ale po co zawijać coś, co już jest przenośną, niezależną od implementacji abstrakcją? To jest chore.

> Abstrakcji nie szukasz w 3-rd party. Abstrakcję robisz u siebie.

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

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

Dalej mylisz pojęcia (żadna nowość, w sumie):

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

"The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems."

Ostatnie 4 słowa są kluczowe.
A teraz mam robić abstrakcję do tej abstrakcji, bo każdy januszowy RTOSik musi koniecznie mieć ourMutexCreate()?
 
> Nie jest przenośny. Jest vendor-lockin. Tutaj vendorem jest POSIX

Czyli dalej, uporczywie, mylisz pojęcia. POSIX nie jest vendorem. Vendorem jest np. Texas Instruments. Albo np. Ja&Szwagier Sp. z o.o. Natomiast POSIX jest standardem, dzięki któremu programy łatwiej[*] jest przenosić z jednego OSa na drugiego.

[*] Co oczywiście nie przeszkadza OSom konkurować parametrami albo ficzerami, ani programom korzystać z ich unikalnych ficzerów. Tylko że wtedy programy stają się nieprzenośne na życzenie, a nie z przymusu.

> > Klikasz w złym miejscu. https://www.apple.com/pl/mac-pro/specs/
> > Jak dla mnie, ma wystarczająco dużo złącz.
> I nagle przestają działać.

USB-C przestanie działać?
Może inaczej: któro ze złącz w powyższym Macu, które można znaleźć też na pececie windowsowym, przestanie działać?
Bo chyba chodziło o to, że w Macu jest mniej złącz, niż w pececie? Czy o co chodziło?

> > Nie zrozumiałeś. Pluginy do obróbki dźwięku albo obrazu (albo video) nie są pisane w Pythonie.
> Nie są, a Mac przeskoczył na ARMa i reszta 3rd-party zrobiła to chwile 
> potem.

Nie, nie zrobiła. Właśnie w tym rzecz. I ten proces będzie trwał bardzo długo, dla niektórych pewnie się nigdy nie skończy.
I dlatego Apple ma w ofercie obie platformy *równocześnie*. Bo naprawdę nie da się przekompilować cudzego kodu.

> Rozmawiamy o embedded i zmienach embedded cpu.

No i ja dalej tej zmiany w najbliższym czasie nie widzę. Rozszerzenie oferty, może i tak. Ale to żadna rewolucja, bo i tak wszyscy producenci mają różne alternatywy, dla różnych segmentów rynku. Po prostu będzie jeszcze większy bałagan.

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

[toc] | [prev] | [next] | [standalone]

#34317

On 07/01/2021 22:13, Maciej Sobczak wrote:
>>> Nie wiem, czy są. Ale wiem, że NVIDIA kupiła ARMa.
>> I nagle zmieniła politykę czy tylko wyciska dalej co się da z licencji?
> A już jest powód, żeby zmieniać politykę?

Skoro tak, to aktualny właściciel jest mało ważny.

>> Ależ zobaczymy. Nie można też wykluczyć że nvidia ma interes w NIE
>> dawaniu rdzeni ARMa konkurencji.
> Może tak być. Ale, ale... Kto jest ich konkurencją?

AMD. I za chwile chińczycy.

> Producenci embedded?

Niektórzy. Na ten przykład nvidia produkuje SoC oparte o różne dziwne 
technologie. "Dokładnie takie same" SoC produkują chińczycy i sprzedają 
je kilka razy taniej. Stąd te wszystkie tanie adnroid boxy.

> No dobra. To po co komu ten RISC-V?

Aby się urwać od ARMa. Aby mieć więcej mocy z wata. Aby mieć źródło pod 
kontrolą i nie patrzeć czy za 2 lata zapukają prawnicy albo czy kupi to 
Orlen i udostepni licencje pod warunkiem biało-czerownej obudowy i 
grania Mazurka po podłączeniu zasilania.

> Na rynku, na którym NIC nie jes darmowe, NIKT nie oczekuje, że będzie taniej.

Taniość jest trzeciorzędna w niektórych wypadkach. A w innych nie. 
Różnie bywa.

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

> Po prostu się wlicza koszty w cenę produktu, na całej długości łańcucha.

Zależy co produkujesz. Jeśli toalety na stacje kosmiczne to możesz sobie 
wliczać w koszty wszystko. Ale jeśli mikrokontrolery do szczoteczek do 
zębów, to już liczysz centy. Różnie.

> Więc kogo obchodzi RISC-V?

Różnych ludzi z różych powodów. ARM to taki vendor-lockin w branży. W 
dodatku aktywnie zniechęca stosując agresywną politkę patentową i 
spuszczając prawników z łańcucha jak ktoś za głośno protestuje.

>> POSIX nie jest "bardzo dobrą abstrakcją" bo sam jest bardzo niedobry z
>> punktu widzenia embedded. To nie do tego.
> Uuu, to nie dość, że już poobrażałeś wszystkich (że psychiczni) to teraz jeszcze POSIX niedobry.

POSIX w embedded nie jest dobry. Pewnie, że można postawić Linuxa i 
nazywać to "embedded" ale to tylko taki mały komputer w małym 
pudełeczku. Z embedded to ma tyle wspólnego na ile to pojęcie napompujemy.

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

> Czy nie ustaliliśmy już w tych dyskusjach, że tylko my dwaj robimy dobrze?

Nie. Ja widzę świat tylko przez moje doświadczenia, które są zasadniczo 
mocno inne niż innych, najzwyczajniej pracuje w dośc specyficznym i 
hermetycznym miejscu. Nie twierdze że mam monopol na poglądy, ale zawsze 
bedę tuptał nogą jak będe słyszał że profesjonalizmem albo niemożnością 
tłumaczy sie dziadostwo, szczególnie w kodzie.

>> używanie POSIXa w embedded jest komplenie bez sensu w
>> większosci zastosowań. FreeRTOS składa się z wątków, schedulera, jakiś
>> mutexów i tyle.
> No, i każda z tych rzeczy może mieć API POSIX. Bo niby w czym funkcja xSemaphoreCreateMutex jest lepsza od pthread_mutex_init?

Bez znaczenia. Jeśli masz na to abstrakcję może sobie pracować na 
AmigaOS. Ale musisz mieć abstrkację. Masz, prawda? Jak byś inaczej mógł 
to testować. Wiec musisz mieć.

> Ja wiem, w czym jest gorsza. Otóż kod działający na POSIX nie kompiluje się na FreeRTOS.

Nic dziwnego, skoro nie ma abstrakcji na system. Mój sie kompiluje na 
posixie i na windowsie, tanim kosztem mogę dodać MacOsa. FeeeRTOSa nie 
dodam bo nie ma potrzebnego hardware na platformach FreeRTOSowych. Czy 
to czary?

> I trzeba robić "abstrakcje", co jest o tyle idiotyczne, że POSIX już jest abstrakcją.

Nie jest abstrakcją na różne OSy. Jest tylko abstrakcją od hardware i 
konkretnych implementacji OSu. NIE jest abstrakcja od systemu, bo sam 
jest tym konkretnym systemem.

Zaznajom się np. z Qt. To jest abstrakacja na system. Średnia, ale 
bardzo skuteczna, POSIX jest tylko jednym z paru implementacji możliwych 
do użycia.

> No ale po co projekty mają być tanie, skoro mogą być drogie?

To nigdy nie działa w ten sposób. Koszt pisania z abstrkacją jest 
mikroskopijnie wyższy niż refaktorowania tony g...na napisanego przez 
team który wszędzie wciskał pthread_mutex razem z jedgo wszystkimi 
cechami specjalnymi.

>> POSIXa też się zawija w abstrakcję w swoim kodzie.
> No właśnie się pytam, po co? Rozumiem, że rejestr w mikrokontrolerze do mrugania LEDem można opakować, bo w każdym uC się mruga inaczej. Ale po co zawijać coś, co już jest przenośną, niezależną od implementacji abstrakcją? To jest chore.

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

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

>> Abstrakcji nie szukasz w 3-rd party. Abstrakcję robisz u siebie.
> Albo korzystam ze standardów. Takim standardem jest POSIX.

Dalej nie pojmujesz że posix nie jest abstrakcją. Abstrakcją jest 
MyTools::MyMutex a nie pthread_mutex. Abstrakcją może byc też Qt, ale to 
jest abstrkacja 3rd-party i niekoniecznie chcesz być zależny od decyzji 
biznesowych Qt.

>> Własnie
>> po to aby od detali posix-nie posix nie uzależniać się w swoim kodzie,
>> poza adapterami do konkretnego OSu.
> Dalej mylisz pojęcia (żadna nowość, w sumie):
> https://en.wikipedia.org/wiki/POSIX
> "The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems."

Przeczytałeś cos nie na temat. To jest abstrkacja do konkretnej rodziny 
systemów. W tej rodzinie nie ma FreeRTOSa ani Widnowsa CE, a są one w 
embedded używane.

Posix to NIE jest abstrakcja na systemy operacyjne. Co najwyżej na wąską 
grupę bardzo podobnych systemów, o nikłej uzytecznosci w embedded.

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

> A teraz mam robić abstrakcję do tej abstrakcji, bo każdy januszowy RTOSik musi koniecznie mieć ourMutexCreate()?

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

Pewnego dnia januszowy RTOSik zostanie zamieniony na mirkowy CE bo taki 
się zwidziało właścicielowi biznesu. Jesli Janusz nie był iditiotą to 
zmiana na to CE może być mało bolesna. Jesli był idiotą to właśnie 
przewalają przez miesiące biliony ton kodu szukając tych wszystkich 
problemów sepcyficznych dla FreeRTOSa.

Co kto woli. Przecież nie ma problemu aby pisać nieprzenośnie, jesli to 
jednorazowy projekt.

Pamiętaj o czym rozmawiamy: stwierdziłeś że zmiana procesora to nie 
tylko zmiana makefile, tylko bardzo ciezka rzecz.

No więc to cieżka rzecz, jak się ma dziadowski kod.

>> Nie jest przenośny. Jest vendor-lockin. Tutaj vendorem jest POSIX
> Czyli dalej, uporczywie, mylisz pojęcia. POSIX nie jest vendorem.

Bo to nie ma znaczenia. Może być OS-Lockin jeśli już takim purystą 
jesteś? Co to ma za znaczenie? Jesteś foo-lockin. Czy to interfejs, 
bibliteka 3rd-party czy procesor. Wsio rawno z punktu widzenia problemu.

> Natomiast POSIX jest standardem, dzięki któremu programy łatwiej[*] jest przenosić z jednego OSa na drugiego.

W obrębie mało przydatnej w embedded rodziny OSów.

Tak wiem, zaraz ktoś wyjmie z kieszeni jakiś przykład że gdzieś stosują 
Linuxa w embedded. Owszem. Gdzieś stosują.

>>> Klikasz w złym miejscu. https://www.apple.com/pl/mac-pro/specs/
>>> Jak dla mnie, ma wystarczająco dużo złącz.
>> I nagle przestają działać.
> USB-C przestanie działać?

Wyobraź sobie że tak się właśnie stało. Trach i po aktualizacji OS kilka 
tysięcy dolców na Twoim biurku zamieniło się w cegły.

Oczywiscie nie złacze. Tylko pewna cecha tego złacza, pozawlająca na 
przesyłanie obrazu. Czysto "softwareowa" awaria, nie przypadkowa. Nawet 
się nie zainteresowałeś co się stało, prawda? Podpowiem ponownie: 
DisplayLink. Poczytaj. To nawer patriotyczna firma jest.

Nie nie, oni dalej będa kupować Apple, to religia.

> Bo chyba chodziło o to, że w Macu jest mniej złącz, niż w pececie? Czy o co chodziło?

Nie. Chodziło o to że cwaniaczki od Apple wycyckały pewnego wieczoru 
tysiące "profesjonalistów" którzy podpinali zewnątrzne monitory do 
swoich laptopów myśląc że uzyskują w ten sposób profesjonalne narzedzie 
do dicking-around. I ktoś wyłaczył światło. Bez słowa. I to nie jest awaria.

>>> Nie zrozumiałeś. Pluginy do obróbki dźwięku albo obrazu (albo video) nie są pisane w Pythonie.
>> Nie są, a Mac przeskoczył na ARMa i reszta 3rd-party zrobiła to chwile
>> potem.
> Nie, nie zrobiła.

Wiec photoshop nie działa na M1 i tracą pieniądze? Serio, myslisz że 
będzie to trwało bardzo długo? Oni te swoje pluginy kompilowali w 
popłochu na ARMy jak tylko Apple pierdło coś w temacie ARMa.

> I dlatego Apple ma w ofercie obie platformy *równocześnie*. Bo naprawdę nie da się przekompilować cudzego kodu.

Bo taki system dystrybucji aplikacji: z wysypiska. Ale spokojnie, da sie 
skompilować cudzy kod. Cudzymi rękami właśnie. Działa. Po prostu patrz 
jak robią to firmy które straciły by pieniądze gdyby tego nie zrobili 
zawczasu.

>> Rozmawiamy o embedded i zmienach embedded cpu.
> No i ja dalej tej zmiany w najbliższym czasie nie widzę.

Nie widzisz, bo też ten rynek nie jest do wygooglania. To jest coś 
głęboko na poziomie aplikacji i narzędzie niedostepnych dla Kowalskiego, 
dziejace się w tle, zasłonięte NDA.

> Po prostu będzie jeszcze większy bałagan.

Raczej dodatkowy kompilator do makefile.

[toc] | [prev] | [next] | [standalone]

#34318

> 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

[toc] | [prev] | [next] | [standalone]

#34319

On 08/01/2021 22:42, Maciej Sobczak wrote:
>> Taki producent odpowiednika STM32 ale opartego o rdzeń RISC może ściąć
>> cenę swoich cpu o dolara, powiedzmy. A to robi różnicę kiedy ich
>> sprzedajesz setki milionów, choćby jako sterowniki dildo i szczoteczek
>> do zębów.
> Ale przecież do tego już mają rdzenie.

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

> Texas ma MSP430

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

> To po co jakiś RISC-V?

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

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

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

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

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

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

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

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

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

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

> Mogę mieć dobrej jakości implementację

Możesz. A masz?

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

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

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

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

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

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

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

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

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

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

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

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

Czyli wąska grupa unixo-podobnych + duperele.

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

A na freeRTOS? A na Windows CE?

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

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

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

>> Zaś wszystkei zgodne maja mała użytecznośc w embedded. POSIX jest do
>> stacji roboczych a nie migania diodami lub kontroli oddechu. Naprwadę,
>> nie potrzebujesz parentpid i fopen w respiratorze.
> Czyli dalej nie rozumiesz. Kto powiedział, że system ma mieć wszystkie funkcje?

Czyli nie jest zgodny z POSIX?

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

Wycinasz przenośność na nieposixy.

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

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

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

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

A na windowsie?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zniknąłeś pozostałe zalety.

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

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

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

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

> To jest choroba naszej branży.

Nie. Pisanie na wysokim poziomie nie jest chorobą.

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

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

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

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

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

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

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

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

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

Ale dalej, poprawna higiena ratuje 90% apliakcji.

> Wszystkie Twoje argumenty można tu zastosować.

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

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

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

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

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

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

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

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

Odciąć się abstrakcją.

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

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

> Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest.

Bo jest nieprzenośne na inne embedded.

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

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

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

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

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

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

>> Pewnego dnia januszowy RTOSik zostanie zamieniony na mirkowy CE bo taki
>> się zwidziało właścicielowi biznesu. Jesli Janusz nie był iditiotą to
>> zmiana na to CE może być mało bolesna.
> Niestety nie jest to zgodne z moimi obserwacjami. Zmiana jednego systemu POSIX na drugi system POSIX może być mało bolesna, ale zmiana OurRTOS na TheirRTOS to większy problem, bo jak już ktoś miał gdzieś standardy, to zwykle w różnych, niezależnych kierunkach. Wtedy to nie jest kwestia taniego wrappera.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aby umożliwić unit testy.

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

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

> "U mnie działa."

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#34320

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

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

> Ale ma 40 programów w dildo

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

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

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

> Jednak wolę dalej FreeRTOSa nad POSIXa w respiratrorze,

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

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

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

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

Przecież już pisałem.

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

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

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

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

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

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

> Dlatego masz class MyMutex

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

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

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

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

"U mnie działa"?

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

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

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

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

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | pl.comp.programming

csiph-web