🚀 go-pugleaf

W dniu 2016-09-26 o 01:56, Smok Eustachy pisze:
> Wywiad z por. Wosztylem:
> https://www.youtube.com/watch?v=YXiTFw8kl0g&feature=youtu.be
> http://www.tysol.pl/a797-s6-Artur-Wosztyl-dla-Tysol-pl-Nasz-wywiad-W-tym-momencie-dzieje-sie-Smolensk-2-video-
>
>
> Musiałbym się z nimi spotkać i z każdą osobą indywidualnie rozmawiać, by
> przekonać ludzi do swoich racji. Natomiast chcę powiedzieć jedną rzecz.
> To, co mnie spotkało i moją załogę, te wszystkie kłamstwa, które były
> rozpowszechniane na mój temat i na temat mojej załogi, wszystkie
> kłamstwa, manipulacje, naciągnięcia faktów, przeinaczanie dowodów
> rzeczowych, które miały wskazywać na moją winę, bo niestety tak to
> wyglądało, pokazuje, do jak wielkich manipulacji się posuwano od samego
> początku, aby udowodnić przez to tezę, niestety, winę załogi Tupolewa.


Czyli Windows 10 jest do dupy?

W dniu 26.09.2016 o 02:06, Tomasz Wójtowicz pisze:
/.../
> Czyli Windows 10 jest do dupy?

Nie ta grupa.

Na komórce Windows 10 jest lepsze niż ten cały Android. Ale Microsoft 
chciał sprzedawać drogie modele flagowe. A ludzie chcieli kupować tanie 
modele budżetowe.

Chodzą słuchy, że zużycie pamięci w Win10 to połowa tego, co w Andku.

Ale musieli zrąbać sklep, nie dali przycisku mute. I parę innych.

W dniu 2016-09-27 o 00:02, Smok Eustachy pisze:
> W dniu 26.09.2016 o 02:06, Tomasz Wójtowicz pisze:
> /.../
>> Czyli Windows 10 jest do dupy?
>
> Nie ta grupa.
>

To teraz pl.comp.os.advocacy jest o brzozach i helu? O tempora, o mores!

On 2016-09-27 00:02, Smok Eustachy wrote:
> Chodzą słuchy, że zużycie pamięci w Win10 to połowa tego, co w Andku.

Oczywiście, bo na Windowsie 10 bajt ma cztery bity.

W dniu 27.09.2016 o 18:29, Sebastian Biały pisze:
> On 2016-09-27 00:02, Smok Eustachy wrote:
>> Chodzą słuchy, że zużycie pamięci w Win10 to połowa tego, co w Andku.
>
> Oczywiście, bo na Windowsie 10 bajt ma cztery bity.
>
Ponoć jakieś wirtualizacje itp.

On 2016-09-27 23:47, Smok Eustachy wrote:
>>> Chodzą słuchy, że zużycie pamięci w Win10 to połowa tego, co w Andku.
>> Oczywiście, bo na Windowsie 10 bajt ma cztery bity.
> Ponoć jakieś wirtualizacje itp.

No bo wirtualny bajt to połowa rzeczywistego z powodu kompresji. Podobno 
tez z jednego miliampera na 3.7V wyciągają dwa razy więcej mocy w watach.

W dniu 28.09.2016 o 17:09, Sebastian Biały pisze:
> On 2016-09-27 23:47, Smok Eustachy wrote:
>>>> Chodzą słuchy, że zużycie pamięci w Win10 to połowa tego, co w Andku.
>>> Oczywiście, bo na Windowsie 10 bajt ma cztery bity.
>> Ponoć jakieś wirtualizacje itp.
>
> No bo wirtualny bajt to połowa rzeczywistego z powodu kompresji. Podobno
> tez z jednego miliampera na 3.7V wyciągają dwa razy więcej mocy w watach.
>
W swoim czasie na makówkach binarki były 2x większe bo zawierały kod na 
x86 i PPC

W dniu 2016-09-28 o 22:21, Smok Eustachy pisze:
> W dniu 28.09.2016 o 17:09, Sebastian Biały pisze:
>> On 2016-09-27 23:47, Smok Eustachy wrote:
>>>>> Chodzą słuchy, że zużycie pamięci w Win10 to połowa tego, co w Andku.
>>>> Oczywiście, bo na Windowsie 10 bajt ma cztery bity.
>>> Ponoć jakieś wirtualizacje itp.
>>
>> No bo wirtualny bajt to połowa rzeczywistego z powodu kompresji. Podobno
>> tez z jednego miliampera na 3.7V wyciągają dwa razy więcej mocy w watach.
>>
> W swoim czasie na makówkach binarki były 2x większe bo zawierały kod na
> x86 i PPC

Paaanie, takie numery to już były w dosowych plikach COM.

W dniu 29.09.2016 o 16:46, Tomasz Wójtowicz pisze:
/.../
>> W swoim czasie na makówkach binarki były 2x większe bo zawierały kod na
>> x86 i PPC
>
> Paaanie, takie numery to już były w dosowych plikach COM.

Więc możemy śmiało postawić tezę o narzutach wydajnościowych Androida 
związanych z zapewnieniem jego działania na rozmaitych prockach, 
graficzkach, konstrukcjach. Ponoć teraz się coś poprawiło.

Z kolei tu i tu nie da się puścić youtube na słuchawki i zablokować 
telefonu. O domyślnej aplikacji mówię.

W dniu 2016-09-29 o 23:34, Smok Eustachy pisze:
> W dniu 29.09.2016 o 16:46, Tomasz Wójtowicz pisze:
> /.../
>>> W swoim czasie na makówkach binarki były 2x większe bo zawierały kod na
>>> x86 i PPC
>>
>> Paaanie, takie numery to już były w dosowych plikach COM.
>
> Więc możemy śmiało postawić tezę o narzutach wydajnościowych Androida
> związanych z zapewnieniem jego działania na rozmaitych prockach,
> graficzkach, konstrukcjach. Ponoć teraz się coś poprawiło.

I możemy ją jeszcze śmielej obalić. Architektura ARM jest jednolita, 
niezależnie od tego, kto wykonał procesor. Nawet w x86 nie jest tak 
dobrze, bo poszczególni producenci lubią dziwaczyć.

Co do grafiki, to Android ma coś w rodzaju DirectDraw, więc aplikacja 
nie musi wiedzieć, z jaką kartą graficzną pracuje. To nie jest DOS, 
gdzie każda gra komputerowa musiała dźwigać ze sobą procedury do obsługi 
sryliona wersji Soundblasterów i innych.

On Fri, 30 Sep 2016 00:32:09 +0200, Tomasz Wójtowicz wrote:


>>>> W swoim czasie na makówkach binarki były 2x większe bo zawierały kod na
>>>> x86 i PPC
>>>
>>> Paaanie, takie numery to już były w dosowych plikach COM.
>>
>> Więc możemy śmiało postawić tezę o narzutach wydajnościowych Androida
>> związanych z zapewnieniem jego działania na rozmaitych prockach,
>> graficzkach, konstrukcjach. Ponoć teraz się coś poprawiło.
> 
> I możemy ją jeszcze śmielej obalić. Architektura ARM jest jednolita, 
> niezależnie od tego, kto wykonał procesor. Nawet w x86 nie jest tak 
> dobrze, bo poszczególni producenci lubią dziwaczyć.

A propos ARM, ten artykuł sugeruje coś innego:

http://pclab.pl/art70022-3.html

-- 
pozdrawiam
Roman Tyczka

W dniu 2016-10-01 o 20:21, Roman Tyczka pisze:
> On Fri, 30 Sep 2016 00:32:09 +0200, Tomasz Wójtowicz wrote:
>
>
>>>>> W swoim czasie na makówkach binarki były 2x większe bo zawierały kod na
>>>>> x86 i PPC
>>>>
>>>> Paaanie, takie numery to już były w dosowych plikach COM.
>>>
>>> Więc możemy śmiało postawić tezę o narzutach wydajnościowych Androida
>>> związanych z zapewnieniem jego działania na rozmaitych prockach,
>>> graficzkach, konstrukcjach. Ponoć teraz się coś poprawiło.
>>
>> I możemy ją jeszcze śmielej obalić. Architektura ARM jest jednolita,
>> niezależnie od tego, kto wykonał procesor. Nawet w x86 nie jest tak
>> dobrze, bo poszczególni producenci lubią dziwaczyć.
>
> A propos ARM, ten artykuł sugeruje coś innego:
>
> http://pclab.pl/art70022-3.html
>

To chyba go źle zrozumiałeś. Zestaw instrukcji jest zawsze ten sam, 
niezależnie kto wykonał procesor, dlatego raz skompilowana aplikacja 
pójdzie na wszystkich smartfonach.

Różnica pojawia się dopiero, gdy jeden producent oferuje smarka z 
procesorem w architekturze ARMv7 (32b), a drugi ARMv8 (64b), ale nawet 
jeśli pakiet instalacyjny przenosi obie wersje kodu, to z całą pewnością 
w trakcie instalacji na danym urządzeniu niepotrzebna wersja jest 
kasowana, bo po co ją trzymać?

W dniu 01.10.2016 o 23:23, Tomasz Wójtowicz pisze:
> W dniu 2016-10-01 o 20:21, Roman Tyczka pisze:
/.../
>
> To chyba go źle zrozumiałeś. Zestaw instrukcji jest zawsze ten sam,
> niezależnie kto wykonał procesor, dlatego raz skompilowana aplikacja
> pójdzie na wszystkich smartfonach.
>

  Podobne różnice znajdziemy w procesorach ARM – najmniejsze, takie jak 
Cortex-M0, nie mają nawet tak bogatego zestawu instrukcji jak rdzenie 
Apple, Qualcomma czy Cortex-A57.

On 2016-10-01, Tomasz Wójtowicz <spam@spam.spam.spam.com> wrote:

[...]

>> A propos ARM, ten artykuł sugeruje coś innego:
>>
>> http://pclab.pl/art70022-3.html
>>
>
> To chyba go źle zrozumiałeś. Zestaw instrukcji jest zawsze ten sam, 
> niezależnie kto wykonał procesor, dlatego raz skompilowana aplikacja 
> pójdzie na wszystkich smartfonach.

Aplikacje Androidowe miały format Dalvik, a obecnie ART i sa uruchamiane
przez wirtualne maszyny, które to dopiero wykonują instrukcje procesora.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

W dniu 08.10.2016 o 15:25, Wojciech Bancer pisze:
/../
> Aplikacje Androidowe miały format Dalvik, a obecnie ART i sa uruchamiane
> przez wirtualne maszyny, które to dopiero wykonują instrukcje procesora.
>
Co przekłada się na narzuty na pamięć i procka
Ponoć teraz są kompilowane na telefonie. Orliński się przewraca z 
wściekłości.
Swoją drogą wprowadzenie nowych binarek przeszło jakoś niezauważenie dla 
szeregowego użyszkodnika.

 Dzieki, Wojciech, za post o tresci: 
> On 2016-10-01, Tomasz Wójtowicz <spam@spam.spam.spam.com> wrote:
>
> [...]
>
>>> A propos ARM, ten artykuł sugeruje coś innego:
>>>
>>> http://pclab.pl/art70022-3.html
>>>
>>
>> To chyba go źle zrozumiałeś. Zestaw instrukcji jest zawsze ten sam, 
>> niezależnie kto wykonał procesor, dlatego raz skompilowana aplikacja 
>> pójdzie na wszystkich smartfonach.
>
> Aplikacje Androidowe miały format Dalvik, a obecnie ART i sa uruchamiane
> przez wirtualne maszyny, które to dopiero wykonują instrukcje procesora.

  Applikacje Androidowe miały i mają format APK. Dalvik to maszyna wirtualna
Javy, a ART to kompilator z .dex na kod natywny. Za bardzo nie wiesz,
o czym piszesz.


-- 
Tomasz Torcz            There exists no separation between gods and men:
xmpp: zdzichubg@chrome.pl   one blends softly casual into the other.

On 2016-10-08, Tomasz Torcz <zdzichu@irc.-spamu.nie.chce-.pl> wrote:

[...]

>>> To chyba go źle zrozumiałeś. Zestaw instrukcji jest zawsze ten sam, 
>>> niezależnie kto wykonał procesor, dlatego raz skompilowana aplikacja 
>>> pójdzie na wszystkich smartfonach.
>>
>> Aplikacje Androidowe miały format Dalvik, a obecnie ART i sa uruchamiane
>> przez wirtualne maszyny, które to dopiero wykonują instrukcje procesora.
>
> Applikacje Androidowe miały i mają format APK.

APK to jest ZIP, czyli paczka dystrybucyjna, a nie plik wykonywalny.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com