Komentarze elita Usuń wszystkie komentarze

Ceny netto porównuje się gdy laptop jest narzędziem pracy i stanowi koszt uzyskania przychodu. I możesz od niego odliczyć VAT, PIT, CIT czy co tam płacisz. Jak dla mnie zakup laptopa zza oceanu jest średnio opłacalny, bo różnica w cenie będzie marginalna - gdy się go nawet przemyci bez opłat - to tyle jeśli idzie o różnicę w cenie USAPL.

Kupiłeś taniego laptopa z mobilmym osprzętem aby używać go stacjonarnie, zamiast kupić normalny monitor ze 24" fullhd albo lepiej i jakieś pudełko dostając zdecydowanie lepsze warunki stacjonarnej pracy - przy tej samej cenie - to tyle jeśli idzie o sens Twojego zakupu.

Narzekasz że Apple ma drogie macbooki - ale sam udowadniasz że nie mają tanich modeli laptopów - no nie mają np takich co chodzą 2h na 1 ładowaniu jak typowy laptop z Tesco, podzespoły montowane w tych laptopach są drogie. Zobacz choćby baterie tej pojemności to koszt 800-1000zł, cpu ulv dla air to koszt połowy Twojego laptopa - co z resztą (np ekrany hires czy ssd na pcie)? To tyle jeśli idzie o cenę Twojego laptopa, a macbooka.

A palmos bazuje na Newtonie :)

Czas wczytywania kodu 64 będzie dłuższy, bo sam kod jest dłuższy, więc przy tej samej prędkości IO pamięci flash wgranie będzie trwało dłużej.
64 nadrabia ilością rejestrów, kod przekompilowany na 64 będzie się mniej odwoływał do RAM w pętlach bo więcej zmieści danych w rejestrach, ale sam kod jest dłuższy więc podczas pracy będzie więcej czytał z RAM poza pętlami. arm64 ma więcej trybów adresowo-warunkowych co też daje pewne optymalizacje, ale nie jest to przepaść - poza tym wielkość kodu w aplikacjach to jest pikuś w porównaniu do ilości grafiki jaką aplikacja potrzebuje, a te są identyczne dla 32 i 64.
Co do grafiki i fps w grach - sorry, ale mamy GPU i w przypadku zaawansowanych efektów kompresji/dekompresji grafiki/video, czy budowy ekranu CPU się nudzi i niewiele ma wspólnego z płynnością czy efektami, bo to robi GPU, więc w grach pożytek z 64 IMO niewielki, bo w idle oba cpu są tak samo mało potrzebne. No chyba że jakieś AI w grach itd :)
Tak na prawdę w wydajności rządzi najwęższe gardło i w przypadku obecnych smartphone to jest prędkość flash - co można przyspieszyć większą ilością buforów w dysku - a to oznacza więcej RAM.

Pomijam milczeniem fakt że NAJWIĘCEJ daje praca człowieka nad kodem i jego ręczna optymalizacja - gdzie się da i jak się da - tego nie zastąpi nawet najlepsze cpu. Bo jak ktoś niedbale pisze soft to i 4GB ram i 4GHz nie pomogą. Niestety obecnie parcie na czas wydania softu powoduje że za mało czasu jest ładowanego w kod, w czym nie przeszkadza to że mamy w telefonach prawie xeony :) i programiści to olewają.
Nie mówiąc już o totalnym np olewaniu responsywności - aplikacja zamiera, interfejs nie odpowiada dopóki app nie dostanie danych z sieci, a sieć przez komórkę - no to jest nagminne. Oni nie znają wielowątkowości, nieblokujących gniazd itd? Inne zaniedbania - np w aplikacjach webowych - wczytać CAŁE jquery aby wyświetlić JEDNĄ kontrolkę - wymagającą 5-10 linii kodu natywnego więcej. Mógłbym wymieniać dalej, ale szkoda po prostu słów :)

Jedyny sens użycia arm64 w tym modelu to przyszłościowa rezygnacja z hybrydowości i przejście na 64 w pełni przez cały ekosystem ios - wspierane modele tylko 64 i tylko takie w ofercie, aplikacje w appstore tylko 64, wywalenie z ios wszystkich pozostałości i emulacji 32bit itd.
Ten model będzie miał nadal wsparcie. Po za tym nie da nic do wydajności, w tym co robią smartphone nie ma zastosowania. Za to w tabletach i owszem, tam ma to sens.

Konkurencja ma Linuxy, a tam 64-bit to obecnie mainstream. Więc mają łatwiej niż z ios. Optymalizacja pod ios7 to głównie ekran, a samo 64 niewiele da przy tej ilości ramu.

@Steve Drops

To akurat nie problem, potrzeba tylko odpowiedniej masy ;)

iMail faktycznie, mam problemy z poprawną synchronizacją zmian z innego klienta poczty, Jak usunę wiadomość np z iphone lub z firmowego thunderbirda to imail tych zmian nie widzi. Zmiany iphonethunderbird są widoczne i live. Na dobrą sprawę pomaga tylko przebudowa skrzynki po stronie klienta.

W porównaniu do zysku z reklamy? :) Skromny mandat.

A czym się ten patent różni od dial on demand dostępnego w prawie każdym routerze z adsl?

A od kiedy design nie jest sztuką?

Tylko że ładowanie smartphone nie jest problemem, nawet co noc włączyć do ładowarki, a w trybie oszczędnym (np bez wifi) aby wytrzymał weekendowy wyjazd - to jest OK. Tak smartclocka (o fajna nazwa :) mógłbym ładować max raz na 2 tyg, a w trybie oszczędnym 3 tyg - to jest IMO totalne minimum dla zegarka. Co więcej powinien mieć on zwykłą bateryjkę jak w klasycznym elektronicznym zegarku i nawet po totalnym rozładowaniu umierałyby funkcje smart, ale zegarek nadal powinien pokazywać czas i datę - i tu widzę czas pracy jakieś klasyczne kilka lat.

@arstechnica

Jak?

No i w sumie słusznie - jeśli chodzi o samo pobieranie paczki. Jeśli ktoś nie zamierza instalować aktualizacji, to 1GB zajętego zbędnie miejsca jest bezsensu.

Taki styl renderowania - można by ukierunkować na hiperreality - Autor ma dzięki temu swój 'image' i oryginalność.
Z drugiej strony jak ktoś widział sampla w miejscu publicznym to wie że nieraz strach się go dotknąć, bo nie wiadomo czym ocieka.

sancruz3: popieram w rozciągłości. NIC tak nie daje kopa w soft jak odpowiednia optymalizacja kodu. Dorzucanie core jest czasami potrzebne, ale z doświadczenia wiem że korzystne zmiany w sofcie dają dużo więcej. Sam w moich systemach to widzę, że lepiej coś napisać, pomyśleć jak cpu to robi, zapisać jakieś rzeczy w cache/ram, skrócić pętle itd i system potrafi być 2-3X szybszy niż przed zmianami (na tym samym hw) niż po dorzucenia 2-3x więcej rdzeni/ram whatever.
Niestety parcie jest na sprzedaż hardu więc lepiej "psuć" soft aby źle chodził na starym hw aby ludzie kupili nowy.

Na pewno sporo kasy władowano w bezpieczeństwo danych na różnych cloudach. Ale jak to mówią "umiesz liczyć? licz na siebie" i ja bym tego NIGDY nie traktował jako jedyną kopie.
Doświadczenia pokazały już że na gmailu ginęły wiadomości, dostawcy bankrutowali itd. Sytuacji można mnożyć.
Prywatna chmurka ma tą zaletę że panujesz nad wszystkim. Jak to umiesz zrobić z głową - to osiągniesz dobre bezpieczeństwo danych. Naturalnym jest w przetwarzaniu danych że:
- WSZYSTKO trzymamy na 2 nośnikach - co najmniej,
- nie powinny to być synchroniczne nośniki (raid to nie backup!) - błąd logiczny wolumenu macierzy czy zwykła pomyłka i można sobie wywalić wszystko w kosmos,
- dobrze jakby jeden z ww nośników był offline - podpinany np co dzień, tydzień w zalezności od wymagań i przechowywany bez prądu,
- dobrze byłoby ten nośnik offline przechowywać w innej lokalizacji (biuro/dom/u babci ;)
- jeśli oba są naraz online - to pkt 4 jest wymagany!
- traktujemy backup PRIORYTETOWO, nie ma rzeczy które traktujemy - a tego nie zgrywam - nośniki są obecnie tak śmiesznie tanie że więcej czasu zmarnujemy na to co backupować, a co nie niż wydamy na dysk
- i najważniejsze - archiwum TEŻ backupujemy, archiwum to taki sam cenny zbiór danych, najczęściej wywalany z laptopa/komputera aby tam nam nie zaśmiecał dysku, ale nie pozostawiajmy go w 1 kopii.
- model pracy każdego jest inny więc każdy powinien sobie wypracować workflow tak, aby dane możliwie zawsze były w 2 kopiach.

nexis: traktujesz raid1 jako backup? gratuluję. Chmura personalna na 1 dysku jest ok, na drugim zrobiłbym backup - offline - raid1 w tym rozwiązaniu? NO WAY.
Przypomnisz sobie moje słowa jak coś przez przypadek skasujesz, albo jak Ci tego duo skroją z domu z kompletem dysków :)

Własna chmura ma zalety, ale i obowiązki. Musimy ją sami backupować, jest droga w zakupie i utrzymaniu, ale ma rewelacyjną pojemność.
Gorzej ze wsparciem aplikacyjnym dla mało typowych chmur.
Ja kibicuję owncloud - ma otwarte API i w ogóle jest opensource i można ją postawić sobie gdzieś :). Niestety muzyki z iphone nie zesyncuje :(
Przydałby się odpowiednik icloud pozwalający na syncowanie backupu iphone, muzyki, wideo itd na własny serwer w obrębie własnych zasobów.

Czyli ściema i show :)

@nemesis

Zdjęcia straciłeś przez brak backupu, a nie z winy Seagate. Dyski WD też padają - to TYLKO żelastwo.
Sam używam różnych dysków i obie firmy obecnie mają wg mnie bardzo dobrą niezawodność, rzekłbym przepisową - ale backupy robię :)
NAS wykorzystam na backupy oczywiście :)

@jenson

Realy? A 64-bit cpu w Apple to literki?

@KvM

Ale tu piszesz o ograniczeniach implementacji danej architektury. Wiadomo, że szyna adresowa jaką wyprowadzono z cpu ma ograniczenia jakieś tam - co ma wpływ na np cenę i trudności z jego wykonaniem. Niestety 4GB jest ograniczeniem 32bit _architektury_ nie implementacji. To że virtualne adresowanie umożliwia zaadresowanie więcej (przez rejestry segmentowe jak np w x86) to inna para kaloszy. Pewnie szłoby zrobić CPU 32bitowe z 64bit rejestrem PC i zabrać ograniczenia.
Przy czym ograniczeniem obecnych smartphone w brew pozorom nie jest wydajność CPU, ale ograniczenia RAM, swapienie się na flash, wymagania wielozadoniowości itd. Kombinowanie na sztucznie z pae to dobre na chwilę. Krok w stronę 64-bit OK. Czy coś to da dla ip5s? nie. Nie bo pamięci mało :(

W przypadku androida, który jest oparty na linuxie - który ma wiele architektur 64 bitowych już wdrożony (wraz z modelem kernela hybrydowego) transformacja jest dużo prostsza. Zysk ze zmiany architektury np x86->amd64 (np w przypadku c2d zmiana linuxa) nie objawia się rewolucyjnym wzrostem prędkości. Samo dołożenie RAM - tak.

Więc przeleciałeś 15-sto stronicowy wątek po łebkach i wyciągnąłeś swój argument o naszym niezrozumieniu świata :) No cóż. Ten argument nie wymaga dalszych wyjaśnień i prób podważań. Nawet nie zaryzykuję ;)

Przeszkadza mi pewnie to że nadużywa się słowa innowacje do czegoś co w moim mniemaniu nie jest innowacją.
Bawi mnie za to argumentacja opierająca się na moim niezrozumieniu świata ;)