🚀 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

 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.

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.

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