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

Groups > pl.comp.programming > #34317

Re: Spieszmy się kochać Windows

Show all headers | View raw

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.

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