Recenzja Dell Vostro 1440

Dell 1440

Źródło zdjęcia (i recenzja, co prawda trochę inny model, bez grafiki AMD, ale reszta się zgadza): http://www.laptopreviews.com/dell-vostro-1440-review-2011-12

Jakiś czas temu pisałem, że kupiłem nowego laptopa. Minęło trochę czasu, więc mogę spokojnie opisać, jak się sprawuje i jak oceniam ten sprzęt. Tym bardziej, że dość szczegółowo opisywałem to już dwóm osobom.

Słabe strony:

  • trudna wymiana podzespołów – z tego co piszą, wymiana pamięci RAM wymaga wyjęcia klawiatury, wymiana dysku rozebrania połowy laptopa. Nie ćwiczyłem tego jeszcze i raczej nie zamierzam, wada, której byłem świadomy przed zakupem, wpisuję z przyzwyczajenia. Po sprawdzeniu w manualu – nie jest tak źle, ale nie jest to jedna klapka i 4 śrubki.
  • podświetlanie ekranu – dość duży skok pomiędzy najniższym poziomem (czyli wyłączonym podświetlaniem), a pierwszą wartością. Przydałaby się wartość pomiędzy – w tej chwili często jest tak, że 0 jest trochę za słabe, a 1 trochę za mocne.
  • jakość spasowania elementów – ramka wokół ekranu ma wyczuwalny przy dotknięciu luz w dolnej części, bateria też rusza się w wyczuwalny sposób. To drugie czuć szczególnie podczas pracy z laptopem na kolanach w łóżku.
  • nie do końca doszedłem do porozumienia ze sprzętem w sprawie sterowania wentylatorem i dyskiem, szczególnie na baterii – wygląda, że chce wiedzieć lepiej, czy wentylator ma pracować, a dysk się wyłączać. Być może kwestia systemu.
  • dysk dość mocno się grzeje. Zapewne położony jest w okolicy touchpada i czuć tam ciepło. S.M.A.R.T pokazuje 46 (Min/Max 15/5663), przed modyfikacją parametrów przy pomocy hdparm było tak samo.
  • ogólnie chłodzenie nie jest mocną stroną, widziałem ponad 80 C na procesorze – wygląda na to, że 1440 lubi mieć przewiew pod spodem – tu na forum też piszą o podstawkach chłodzących dla Delli
  • stosunkowo szybko, bo po ok. kwartale wyrobiła się spacja i lekko piszczy/zgrzyta czasami (chodzi płynnie, tylko ten dźwięk – jak pasikonik). Pewnie pomogło by smarowanie. Możliwe, że kwestia pojedynczego egzemplarza. UPDATE: i chyba z czasem mu minęło, chyba, że kwestia temperatury otoczenia.
  • przycisk power w złym miejscu – spokojnie mógłby być na środku, nie w okolicach brzegu. Zdarzyło mi się kilka razy go nadusić i wyłączyć kompa przy przenoszeniu.
  • z wejść z wyszukiwarki laptop dell vostro piszcząca spacja – potwierdzam, czasem, przy niektórych naciśnięciach słychać lekkie cykanie, które w pewnym momencie było zauważalne i irytujące, ale o którym już zapomniałem – chyba się „dotarł” – i gdyby nie to zapytanie, to bym nie pamiętał.

 Mocne strony:

  • ekran – 14″, rozdzielczość 1366×786, matowy i ogólnie bardzo mi pasuje. Różnica między 15,4″ a 14″ jest jednak zauważalna i film zdecydowanie lepiej na 15,4″ włączyć.
  • czas pracy na baterii – około 3h na baterii bez problemu z włączonym wifi, YouTube, jasność ekranu 0 lub 1. Chyba niezależnie od używanej karty graficznej.
  • praktycznie wszystkie gniazda są po bokach – tylko zasilanie jest z tyłu, a czytnik kart SD i MMC z przodu.
  • niezły webcam – przynajmniej w porównaniu z tymi, z którymi miałem kontakt do tej pory, radzi sobie przy słabym oświetleniu. Nie korzystam z webcama praktycznie, więc proszę traktować tę informację z rezerwą.
  • dobre wsparcie pod Linuksem – patrz recenzja z działania Debiana na Dell Vostro 1440 (ang.) na potrzeby Linux on laptops.

Inne uwagi:

  • miękka klawiatura – pisze się jakby ciszej, ale też jakby troszeczkę wolniej (wpisywane szybko hasła często „nie wchodzą”). Specyficzne, nie jest nieprzyjemne, nie przeszkadza, jest troszkę inne po prostu. Do układu, na który narzekałem w poprzednim opisie bez problemu szybko się przyzwyczaiłem. Pracując równolegle na innym, „tradycyjnym” sprzęcie.
  • mimo „pomniejszonego” rozmiaru jeśli chodzi o przenośność daleko mu do ultrabooka 13,3″. Jest po prostu troszkę mniejszy i zauważalnie lżejszy od typowego laptopa 15,4″
  • plastik, pomijając wymienione wyżej spasowanie jest OK
  • wierzch i spód jest „gumowany” – przypominający gumę plastik o dużym tarciu zapewnia pewny uchwyt, ale materiał sprawia wrażenie podatnego na uszkodzenia. Raczej tylko wrażenie – nic się w praktyce nie dzieje.

Gdyby ktoś miał inne pytania, proszę śmiało pytać czy to w komentarzach czy w inny sposób. Będę uzupełniał, tym bardziej, że mam wrażenie, że o czymś zapomniałem.

PolicyKit w Debianie.

Wczoraj po krótkiej rozmowie na kanale IRC zostałem przekonany do przejścia na unstable pełną gębą (plus odrobinka testing…). Do tej pory korzystałem ze stable plus backporty plus testing plus unstable, gdzie ok. połowy pakietów było ze stable. Upgrade przebiegł pomyślnie i w sumie dość bezproblemowo: przestała działać karta wifi (kwestia zdjęcia blacklist odpowiednich modułów), odinstalowało fglrx (nie patrzyłem jeszcze czemu, grafika Intela działała od kopa) i… znowu system przestał pozwalać na wyłączenie, wstrzymanie i hibernację.

Piszę znowu, bo temat jest znany i stary, pamiętam odkąd używam Debiana z LXDE, że był z tym problem. Czyli chyba od Lenny’ego. Na pewno było w Squeeze. Do tej pory pomagało ubicie procesu  /usr/lib/policykit-1/polkitd, albo, trwalej, usunięcie pakietu policykit-1. Mało eleganckie, ale proste i skuteczne. Zresztą na żadnym z moich desktopów nie potrzebowałem takich wynalazków.

Problem z PolicyKit jest taki, że może i jest to fajne, ale wygląda na skomplikowane, a dokumentacja jest żenująca – wystarczy spojrzeć na opis PolicyKit na wiki Debina. No i co najgorsze, niespecjalnie są przykłady. Podobnie jest w wielu innych miejscach, a nawet jeśli coś jest, to często są to stare i nieaktualne dane. Ostatecznie pomógł ten wpis nt. PolicyKit i opis PolicyKit na wiki Arch. Po kolei, czyli najpierw wyświetlanie dostępnych w systemie akcji – polecenie pkaction. Jego wynik to u mnie:

com.ubuntu.pkexec.gparted
org.blueman.bluez.config
org.blueman.dhcp.client
org.blueman.hal.manager
org.blueman.network.setup
org.freedesktop.consolekit.system.restart
org.freedesktop.consolekit.system.restart-multiple-users
org.freedesktop.consolekit.system.stop
org.freedesktop.consolekit.system.stop-multiple-users
org.freedesktop.policykit.exec
org.freedesktop.policykit.lockdown
org.freedesktop.udisks.cancel-job-others
org.freedesktop.udisks.change
org.freedesktop.udisks.change-system-internal
org.freedesktop.udisks.drive-ata-smart-refresh
org.freedesktop.udisks.drive-ata-smart-retrieve-historical-data
org.freedesktop.udisks.drive-ata-smart-selftest
org.freedesktop.udisks.drive-detach
org.freedesktop.udisks.drive-eject
org.freedesktop.udisks.drive-set-spindown
org.freedesktop.udisks.filesystem-check
org.freedesktop.udisks.filesystem-check-system-internal
org.freedesktop.udisks.filesystem-lsof
org.freedesktop.udisks.filesystem-lsof-system-internal
org.freedesktop.udisks.filesystem-mount
org.freedesktop.udisks.filesystem-mount-system-internal
org.freedesktop.udisks.filesystem-unmount-others
org.freedesktop.udisks.inhibit-polling
org.freedesktop.udisks.linux-lvm2
org.freedesktop.udisks.linux-md
org.freedesktop.udisks.luks-lock-others
org.freedesktop.udisks.luks-unlock
org.freedesktop.upower.hibernate
org.freedesktop.upower.qos.cancel-request
org.freedesktop.upower.qos.request-latency
org.freedesktop.upower.qos.request-latency-persistent
org.freedesktop.upower.qos.set-minimum-latency
org.freedesktop.upower.suspend
org.kde.kcontrol.kcmremotewidgets.save

Jak widać uprawnienia odpowiedzialne za suspend i hibernację są w jednej grupie (czy też raczej gałęzi drzewa), a restartowanie i zatrzymywanie systemu – w innej. Ostatecznie utworzyłem plik /etc/polkit-1/localauthority/50-local.d/10-my-power-policy.pkla o zawartości:

[Let rozie shutdown]
Identity=unix-user:rozie
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*
ResultActive=yes

Jak widać z wildcardem, bo – jak wspomniałem – niespecjalnie zależy mi na ograniczaniu samego siebie. Ale można podać konkretne uprawnienia, po średniku. Podobnie, można przyznać uprawnienia grupie użytkowników, a nie tylko pojedynczemu. Wówczas linia odpowiedzialna za przyznanie uprawnień dla usera rozie i dodatkowo grupy będzie miała postać:

Identity=unix-user:rozie;unix-group:jakaśgrupa

Na wiki Debiana jest pokazany screenshot policykit-gnome, ale jakoś nie udało mi się na to natknąć, choć pakiet mam zainstalowany. Może Gnome only i dlatego na LXDE nie działa?

UPDATE: Skoro już o naprawianiu błędów po upgrade do unstable, to jeszcze jedna ważna rzecz, którą „zepsuł” upgrade – po odłączeniu zasilania dysk co chwilę zatrzymuje się i rozpędza. Czyli co kilkadziesiąt sekund spin down i spin up. Tradycyjne miejsca (hdparm, apmd itp.) okazały się niewinne, rozwiązaniem okazało się odinstalowanie upower dostarczającego upowerd, który wygląda na słabo konfigurowalny. dodanie wpisu w /etc/hdparm.conf:

/dev/sda {
        apm = 254
        apm_battery = 254
}


UPDATE2: We wpisie o policykit był błąd: nie ResultAny=yes a ResultActive=yes (poprawione we wpisie). Po jakimś czasie zauważyłem, że nie działa, ale zwaliłem winę na lxpolkit, który w międzyczasie pojawił się w systemie (uroki unstable). Po bliższym przyjrzeniu – j.w. Nie żebym wnikał, czym to się dokładnie różni.



Jak zrobić backup bloga?

Na wstępie wyjaśnienie, skąd ten wpis. Na forum Blox co jakiś czas pojawiają się osoby, które straciłydorobek paru lat życia. Znaczy takie, których blog – z różnych przyczyn – przestał być dostępny. I zniknęły cenne wpisy (pół biedy, bo to ludzie czasem mają zapisane lokalnie) oraz jeszcze cenniejsze komentarze. Widziałem narzekania na administrację Blox, gorzkie żale, próby wyciągania treści z cache Google itp. hardcore, na dodatek nie zawsze skuteczny. Wszystko niepotrzebnie, bo ww. opisanym tragediom[1] można w prosty sposób zapobiec robiąc backup bloga. Oczywiście problem nie dotyczy tylko Blox, tak samo może zdarzyć się na innych platformach.

Trzeba uświadomić sobie dwie rzeczy. Po pierwsze, blog, a dokładnie jego zawartość jest treścią tworzoną samodzielnie, przez długi okres czasu, trudno odtwarzalną. Szczególnie, jeśli uwzględnimy komentarze. Po drugie, żaden serwis, a już na pewno nie darmowy, nie daje specjalnych gwarancji na to, że dane nie znikną. Jasne, zwykle nie znikają. Co więcej, jeśli nawet znikną, to zwykle administracja serwisu ma backup, który może przywrócić. Jednak awarie i błędy ludzkie (samodzielne skasowanie notatki lub bloga) się zdarzały, zdarzają i będą zdarzać.

Przed takimi sytuacjami można w prosty sposób się zabezpieczyć robiąc samemu backup swojego bloga. Szansa, że nastąpi awaria krytyczna awaria w dwóch różnych miejscach, jest pomijalna. Tak naprawdę samo jednorazowe skopiowanie to jedno polecenie, jeśli chcemy zautomatyzować, warto skorzystać z prostego skryptu. Wybrałem wariant najprostszy, z użyciem programu wget, dostępnego w każdej dystrybucji Linuksa[2], który powinien działać na każdej platformie blogowej (udostępniającej wszystkie wpisy bez logowania), a tworzy backup, który można bezpośrednio wgrać na dowolny serwer WWW i treść będzie od razu dostępna i wyglądająca praktycznie identycznie, jak na blogu. Oczywiście po takim przywróceniu działać będzie tylko odczyt, bez możliwości dodawania komentarzy itp. Co prawda średnio da się z tego automatycznie przywrócić w pełnej formie czy przenieść na inny silnik blogowy, ale najważniejsza rzecz, czyli treść, jest zachowana.

Backupowane są strony z wpisami (i oczywiście komentarzami), hostowane lokalnie zdjęcia i skrypty JS. W przypadku Blox także te strony statyczne, do których jest „przejście” przy pomocy linków. Nie są bacupowane strony, do których nie ma przejścia, linkowane strony, materiały umieszczone na zdalnym hostingu (np. muzyka umieszczona na soundcloud). Najlepiej i najprościej uruchomić i samemu sprawdzić, co się pobrało. Przy zmianie szablonu i linkowań może rzecz jasna dojść do zmiany zawartości nowych backupów.

Koniec tego przydługiego, ale koniecznego moim zdaniem wstępu. Prawda jest taka, że najsłabszym ogniwem jest człowiek i jeśli nie uruchomi się automatycznego backupu, to w najpotrzebniejszym momencie danych nie będzie. A samo się nie włączy. Czyli klasyczne ludzie dzielą się na tych, którzy robią backupy i tych, którzy będą je robić.

Do rzeczy. Aby zrobić automatyczny backup bloga korzystam z polecenia:

wget -q -m -p -E -k http://rozie.blox.pl

Opcje (krótko): q – brak wyświetlania wyjścia, m – mirror, p – ignorowanie poziomu rekursji, E – konwersja plików do HTML niezależnie od rozszerzenia, k – konwersja linków na lokalne. Bardziej szczegółowy opis każdej opcji w pomocy programu.

Cały skrypt dla Linuksa, który można dodać do crona, żeby raz na jakiś czas się uruchamiał – poniżej. Wersja moja, trzeba sobie dostosować. Łatwo daje się przerobić na backupowanie kilku blogów.

Mam nadzieję, że będzie parę tragedii mniej. Chętnie usłyszę uwagi do tego sposobu i propozycje poprawy. Jakby ktoś chciał popełnić dokładny opis dla Windows, to zapewne ludziom się to bardziej przyda.

Przydatne linki (stąd wiem, że działa także dla Blogspot i WordPress, a także podpatrzyłem kilka opcji):

Automatyzacja backupu bloga Blogspot

Automatyzacja backupu bloga WordPress

[1] Tak, nabijam się. Zawartość bloga, konta na FB czy µbloga nie jest dla mnie tak ważna. Ale wiem, że niektórzy podchodzą do tego inaczej.

[2] Jest też wersja wget dla Windows, kiedyś używałem i działała. Oczywiście cały skrypt wymaga przepisania na platformę Windows, co nie jest trudne. Przydadzą się zapewne gzip dla Widnows oraz tar dla Windows, chyba, że od razu skorzysta się z jakiegoś natywnego archiwizera plików typu rar, zip itp.

UPDATE Przy okazji zrobieniu backupu starego bloga (zamknięcie Joggera) wyszła pewna wada – przynajmniej w przypadku Joggera braku http:// na początku URLi całość się nieprzyjemnie pętli i puchnie. Pewnie da się to obejść nie robiąc -m, tylko limitując poziom rekursji. Ja wolałem poprawić URLe. Wadliwe wpisy można prosto namierzyć po wielkości katalogów.