Marek <f...@f...com> wrote:
> Dla mnie idiotyczne w
> Androidzie jest ciagle wyladowyanie aplikacji z pamieci jesli ida w
> tlo (nie mylic z praca w tle tylko chodzi o czas zycia aplikacji
> onCreate, onStop itd). Taka pierwotna koncepcja schedulera byl
> zwiazana z praca w ograniczonych zasobach pamieci i o ile mógl byc
> dobry w czasach G1 gdy telefony mialy 256MB RAM.
> Ale teraz nawet przy 2GB ciagle ten mechanizm jest aktywny, bo widac
> po przywolaniu aplikacji doladowuje jej stan przed puszczeniem w
> tlo. Ale jak programista idiota i nie zaimplementuje system.oncreate
> to aplikacja startuje od zera (tracac stan poprzedniej sesji) przy
> przywolaniu

Rozumiem. Wyslij swoje zgloszenie jako developera systemowego do opiekunow
Androida, zaproponuj ze przerobisz im schedulera. I zrobisz to za tyle
pieniedzy, ile beda w stanie wyciagnac z systemu, czyli z oplat
uzytkownikow.
Rozumiem tez, ze wszystkie twoje aplikacje korzystaja z oncreate. Oglos
wiec ze prowadzisz szkolenia z pisania aplikacji, bo ty, bwana kubwa, wiesz
wszystko lepiej i jestes madrzejszy od wszystkich wokol. Oswiecisz
wszystkich pozostalych programistow, oswiecisz wszystkich managerow.
Wdziecznosc spolecznosci uzytkownikow Androida bedzie twoja satysfakcja.

A teraz jeden kamyczek do ogrodka. To Ty jestes idiota. Nie znasz zalozen
schedulera. Nie pomyslales o tym, ze jak pamiec jest potrzebna, bo sie np.
laduje strona WWW z masa wodotryskow, to ta pamiec ma byc gotowa, a nie
dopiero wtedy wyszarpywana z procesow? Nie pomyslales o tym, ze wydobycie
pamieci od nieaktywnej app wymaga jej uruchomienia, powiadomienia "wiesz,
wytne twój stan, bo potrzebuje pamieci", poczekania az app sobie ten stan
zapisze, i dopiero wtedy mozna pamiec wykorzystac? A user czeka, i czeka, i
czeka... i klnie na pewnego Marka Fake.
Scheduler zwalnia pamiec "w wolnym czasie", kiedy to nikomu nie
przeszkadza i nic nie opoznia. Bo dokladnie tak ma robic, i tak jest
dobrze, wbrew twoim wyzwiskom.

do góry

On Fri, 9 Nov 2018 07:41:02 -0800 (PST), Bolko <s...@g...com>
wrote:
> co to jest magic?

man magic

--
Marek

do góry

On Fri, 9 Nov 2018 21:54:29 +0100, "J.F."
<j...@p...onet.pl> wrote:
> To jest akurat jakies androidowe (i nie tylko) uproszczenie - ze
> nazwa
> okresla typ i nie mozna tego zmienic.

Oczywiście ale chodziło mi o genezę, która jest windowsowa.

--
Marek

do góry

Użytkownik "Marek" napisał w wiadomości grup
dyskusyjnych:a...@n...neos
trada.pl...
On Fri, 9 Nov 2018 21:54:29 +0100, "J.F."
<j...@p...onet.pl> wrote:
>> To jest akurat jakies androidowe (i nie tylko) uproszczenie - ze
>> nazwa okresla typ i nie mozna tego zmienic.

>Oczywiście ale chodziło mi o genezę, która jest windowsowa.

geneza jest znacznie starsza, juz w unixach bylo "rozszerzenie" i
mowilo co to jest, choc niezobowiazujaco.
Potem bylo w CP/M, choc podejrzewam, ze oba systemy to zapozyczyly z
jeszcze starszych.

Ale ten twoj magic to jest dopiero kanal:
-nie wiesz jaki program otworzy Ci plik, zaiste swietna konstrukcja w
dobie wirusow i trojanow,

-z opisu sadząc to nie bylo przewidziane od samego poczatku, tylko
zostalo dorzezbione pozniej, i teraz moze zle rozpoznawac ..

Co prawda Windows promuje teraz ukrywanie rozszerzen, ale odkad to MS
robi cos z glowa ...

J.

do góry

W dniu 2018-11-14 o 11:10, J.F. pisze:
> Co prawda Windows promuje teraz ukrywanie rozszerzen, ale odkad to MS
> robi cos z glowa ...

Z drugiej strony Windows pokazuje ikonkę przy pliku, z której
jednoznacznie wynika, jakim programem będzie otwarty plik.

--
Liwiusz

do góry

W dniu 2018-11-11 o 10:38, Piotr Karocki pisze:

> Scheduler zwalnia pamiec "w wolnym czasie", kiedy to nikomu nie
> przeszkadza i nic nie opoznia. Bo dokladnie tak ma robic, i tak jest
> dobrze, wbrew twoim wyzwiskom.
>

Łatwiej żyć jak się to wie. :-)
Nawet nie wiedziałem, że taki proces zachodzi.

Łatwiej by mi było żyć gdym wiedział dlaczego aplikacje nie mogą
zmieniać ustawień zegara w Androidzie bez kart SIM.
Mam np. tablet bez SIM. Zegar się rozjeżdża.
W telefonach tego problemu nie ma.
W PC też następuje synchronizacja z ntp.

Podejrzewam jakieś względy bezpieczeństwa, ale dlaczego tylko w
Androidzie bez SIM?

Robert

do góry

On 11 Nov 2018 09:38:21 GMT, Piotr Karocki <p...@i...org> wrote:
> A teraz jeden kamyczek do ogrodka.

[ ciach lamerskie tłumaczenie czemu gorzej jest lepiej]

Gdzie jest dobrze? To jest dobrze, że jak zostawię na moment
przeglądarkę w tle na urządzeniu z 2GB ram a za chwilę wywołam ja na
front to ładuje wszystko od nowa (bo została wywalona z ram)  w
sytuacji gdy system raportuje 1GB wolnego? To jest dobrze?? To, że
nie mogę wpisać nowego url, bo stary się musi załadować i do tego
momentu
aplikacja jest praktycznie nieresponsywna? 2GB ram to mało by
zostawićna chwilę w ram aplikację?? Serio? Takie samo zachowanie na
innym
urządzeniu, innego producenta, więc jest to problem systemowy a nie
osobniczy. To też nie jest problem jednej aplikacji, bo wszystkie
przeglądarki na Androidzie zachowują się identycznie.

Ten mechanizm schedulera może i był dobry  w  czasach gdy ramu było
256MB i faktycznie trzeba by było robić szpagat. Aktualnie są nawet
urządzenia z 8GB RAM, po ma wyszarpywać przy 8GB RAM?? Czy widziałeś
gdzieś takie idiotyczne zachowanie w schedulerze
desktopa (z połową tej pamięci)?

Inne systemy jakoś przy 2GB ramu nie muszą "wyszarpywać" pamięci ani
deaktywować aplikacji. Ale Android dzielnie, niczym socjalizm
dzielnie rozwiązuje problemy nieistniejące w innych systemach bo
jakiś debil
uznał, że trzeba stworzyć scheduler działający na innych zasadach bo
"środowisko o ograniczonych zasobach" (mało ram, słaba bateria,słaby
CPU itp). Zapamiętać radzę to zdanie w cytacie bo to jest clue całości
problemu.  "Środowisko o ograniczonych zasobach" to było tylko,
uwaga, w momencie określania zarysu architektury Androida i może w
pierwszyc generacjach urządzeń mogło to być przydatne. Jak trzeba być
ograniczonym, by nie uwzględnić, że za technologiczny moment
urządzenia mobilne przekroczą wydajność i zasoby  AKTUALNYCH wtedy
desktopów, a owe "zalety" schedulera staną się wadą?
Weźmy scheduler w kernelu Linuxa, on nic nie musi wyszarpywać, bo
uwaga (developerzy Androida skupić się) ma... paging. Ale oczywiście
nie można było tego wykorzystać w Androidzie bo a) aplikacje Androida
nie są  procesem z pkt widzenia schedulera kernela (w uproszczeniu)
b) działa  mit "środowisko o ograniczonych zasobach". Nie może mieć
swapa na flashu, bo flash się wytrze, za wolny i  inne tego typu
nieaktualne
współcześnie bzdury, o których nie wie byle paparazzi ze swoim
Canonem 1D, którego karta flash przewala gigabajty dziennie i jakoś
co miesiąc karty nie wymienia. Można? Można, ale nie w Androidzie.
Po xuj wywalać aplikację z ram jak ma się GIGABAJTY (oprócz niej)
wolnego ramu? A moment faktycznie. Przecież to java. Żeby uruchomić
przysłowiowy "Hello word" musi wstać cały sandbox JVM potrzebujący min
256MB ram per proces. Skoro mamy "środowisko o ograniczonych zasobach"
to ja się pytam czemu akurat uznano, że jvm będzie akurat świetnym
wyborem na ekosystem dla Androida?   ROTFL!

Ale tu nie tylko problem z schedulerem Androida. Kolejny problem to
sprawa wakelocków. Ile to krwi (czyt. baterii) napsuło użytkownikom.
Czy to nieznamienne, że googole zwraca 18 milionów wyników dla hasła
"android app battery draining"?  Już nie będę się wyżywać wskazując
personalnie idiotę, który wakelocki wymyślił (swoją drogą była ostra
dyskusja na kernel-list jak chciano wakelocki wprowadzić, było wiele
głosów przeciw). Na pierwszy rzut oka (pozornie) pomysł wygląda
rozsądnie. Ponieważ Android to system robiący wiele rzeczy w tle w
sieci (ale domyślnie
aplikacje w tle chodzić nie mogą, taki kurde żarcik twórców) nagłe
przechodzenie w sleep może generować problemy, np. przerywanie
transmisji, zrywanie sesji itp. Zgoda, niech aplikacja ma możliwość
wstrzymania sleep aż skończy.  Mądre założenie ale tylko dla mądrych
programistów a nie dla debili! Którzy nie dość, że wakelocka nie
zdejmują gdy trzeba to jeszcze ustawiają wakeup alarm. Czemu np.
aplikacja do oglądania zdjęć zrobiła 20 alarmów wake na godzinę
praktycznie uniemożliwiając sleep i tym drenując baterię? Oczywiście
mogą  tez to być celowe działania, aplikacje muszą wyświetlać reklamy,
śledzić użytkowników. Świetnie ale dla przeciwwagi użytkownik nie ma
możliwości zrobienia "overdirve" sleep (jak jest w najnowszym to
chętnie się o tym dowiem).
Dlaczego nie mogę np. w tablecie zrobić twardy sleep BEZWARUNKOWY (mam
to gdzieś, że jakaś aplikacja próbuje coś wysłać) ponieważ odkładam
tablet na półkę i dopiero za 10h będę go ponownie używał a nie chcę
robić off bo wstaje za długo? Jakoś w laptopach/desktopach twórcy
systemu i aplikacji nie mają z tym problemu, że robiąc sleep system
jest fizycznie zatrzymywany do wybudzenia przez hardware lub usera
INTENCJONALNIE. Ale w Androidzie się nie da.

--
Marek

do góry

On Wed, 14 Nov 2018 11:10:11 +0100, "J.F."
<j...@p...onet.pl> wrote:
> geneza jest znacznie starsza, juz w unixach bylo "rozszerzenie" i

Ono było infirmacyjnie dla człowieka a nie dla softu. Ale po co
kopiować idiotyczne założenia?



> dobie wirusow i trojanow,

Jakie wirusy masz na normalnych systemach.... błagam.

--
Marek

do góry

Użytkownik "Marek" napisał w wiadomości grup
dyskusyjnych:a...@n...neos
trada.pl...
>On Wed, 14 Nov 2018 11:10:11 +0100, "J.F."
<j...@p...onet.pl> wrote:
> geneza jest znacznie starsza, juz w unixach bylo "rozszerzenie" i

>Ono było infirmacyjnie dla człowieka a nie dla softu. Ale po co
kopiować idiotyczne założenia?

>> dobie wirusow i trojanow,

>Jakie wirusy masz na normalnych systemach.... błagam.

Pierwszy wirus byl na unixie :-)

J.

do góry

W dniu 2018-11-14 o 15:26, Marek pisze:
> On Wed, 14 Nov 2018 11:10:11 +0100, "J.F."
> <j...@p...onet.pl> wrote:
>> geneza jest znacznie starsza, juz w unixach bylo "rozszerzenie" i
>
> Ono było infirmacyjnie dla człowieka a nie dla softu. Ale po co kopiować
> idiotyczne założenia?

txt, bat i pewnie wiele innych - nie było żadnej informacji dla softu
wewnątrz pliku.

>> dobie wirusow i trojanow,
>
> Jakie wirusy masz na normalnych systemach.... błagam.

Na każdym systemie są wirusy.

--
Liwiusz

do góry