A fenti három székkel volt alkalmam találkozni az elmúlt néhány évben. Az egyértelmű nyertes közülük (mind funkciók száma, mind kényelem szempontjából) a Kinnarps 5000-es sorozatból az 5284M, de lássuk sorban a versenyzőket.
IKEA Markus: Őt szerettem a legkevésbé. Előny a fejtámla és a puha karfa. Hátránya, hogy a karfa fix, az ülés mélysége nem állítható, a csillagról lecsúszik az ember lába, túl meredeken emelkedik. A fix karfa miatt nem lehet túl közel ülni az asztalhoz, vagy a magasságával kell játszani. Kollégák közül páran inkább leszedték a karfát.
IKEA Volmar: A csillagról nem csúszik le a láb, viszonylag alacsony az emelkedési szöge. Az ülés mélysége állítható, de nem túl nagy a játéktér. A karfák egymástól való távolsága nem állítható kézzel, imbuszkulcs kell hozzá. A karfa anyaga kemény műanyag és elég vékony is (legalábbis a Kinnarpshoz viszonyítva). A karfa magassága kézzel állítható, és előre-hátra is tolható, így nem a karfa szabja meg, hogy milyen közel ülj az asztalhoz.
Kinnarps 5284M: Kényelmes, zselés karfa (puha, nem kemény műanyag), amelyek egymástól való távolsága kézzel állítható (imbuszkulcs nélkül). Szélességük jóval nagyobb, mint a Volmaré, és vízszintesen is állítható a szöge, ami külön plusz. A csillag teljesen lapos, van rajta csúszásgátló is. Látszik, hogy direkt arra találták ki, hogy azon pihentesse az ember a lábát.
Epub fájlok helyett PDF-ekkel is egész jól használható a Sony PRS-650, csak az oldalméretet, margót és betűméretet kell jól beállítani.
Alapadatok a Sony PRS-650 6 colos kijelzőjéhez:
Pár megjegyzés:
Akad néhány hátrány is:
Igaz, hogy már több, mint egy éve megjelent a 7-es Java, de még mindig nem késő megismerkedni az újdonságaival. Egész konkrétan az új íves és hajlított építőelemekre gondolok.
Céges gépen:
Thunderbird-ben, céges gépen:
Otthoni gépen, szintén Thunderbird-ben:
Így a leveleket csak az otthoni Thunderbird törli a szerverről, valamint az öt nap miatt a hosszú hétvégéken érkező levelek is meglesznek a céges gépen arra az esetre, ha esetleg kellene valami régebbi dolog munkaidőben.
A céges gépről küldött levelek pedig az otthoni postafiókba is megérkeznek, csak át kell őket pakolni az Elküldött elemek mappába. Túl sokat nem írok, úgyhogy ezt általában kézzel csinálom, bár biztos lehet rá automatikus szabályt is létrehozni.
Néhány triviális és kevésbé triviális dolog, amibe bele szoktak kötni a bírálók, vagy csak úgy simán hasznos – nem csak diplomaterv írásakor. Nem feltétlenül ebben a sorrendben.
Néhány önéletrajzos gondolat, leginkább szoftverfejlesztői pozíciókra kihegyezve, de nagy része más állásokra is igaz lehet:
Az, hogy túl zöld. Mondhatni sötétzöld. De ne legyünk ilyen durvák, nézzük a tényeket, spekulációkat.
Az SPCR fórumára bevágott WD Support által írt levelek és SMART adatok szerint a WD GP winyók 8 másodperc inaktivitás után parkolják a fejet. A másfél éve létező SCPR fórum után az elmúlt egy évben valamikor felkerült a hivatalos Western Digital tudástárba is egy bejegyzés a problémáról (The S.M.A.R.T Attribute 193 Load/Unload counter keeps increasing on a SATA 2 hard drive).
A funkció előnye, hogy kevesebb áramot fogyaszt a merevlemez, ellenben növekszik a SMART Load_Cycle_Count (LCC) számláló értéke. A winyó adatlapja szerint ezekből a parkolásokból legalább 300 ezret ki kellene bírnia. Ha azonban pechesek vagyunk, és mondjuk pont 10 másodpercenként nyúlunk a lemezhez (vagy megteszi egy programunk 10 másodpercenként), akkor ezt a 300 ezres számot viszonylag hamar elérhetjük (kb. 35 nap folyamatos üzem esetén).
Persze ez nem jelenti azt, hogy a 300 001-edik parkolás már biztosan nem fog sikerülni, és utána a winyón tárolt adatok sosem lesznek elérhetőek, de akkor is idegesítő. Főleg, ha a parkolás hangját is halljuk. A fentebb említett fórumon egyébként van néhány felhasználó, akiknek több milliónál jár ez a számláló és a winyó hibátlanul működik.
De nézzük, hogy miért nem túl fair a helyzet:
Saját tapasztalat: Egy éves WD10EADS, 70 ezer körüli Load_Cycle_Count érték, tökéletes működés.
Frissítés, 2011. augusztus 12.:
A témáról a Prohardver is cikkezett nemrég. Ők is a WD egyik support oldalára hivatkoznak (Answer ID 5357), ami szerint lehet használni a wdidle3.exe-t Caviar Green lemezekkel. Pontosan idézve a support oldalt: „Set Idle3 to max time (effectively turns off load/unload power saving feature thus will use more power) per below link.”
A „below link”-et követve eljutunk az RE2GP Idle Mode Update Utility oldalára, ahonnan letölthető a wdidle3.exe egy figyelmeztetés mellett, mely szerint csak a WD1000FYPS-01ZKB0, WD7500AYPS-01ZKB0, WD7501AYPS-01ZKB0 modellekkel használható. Nem Raid Edition Green Power merevlemez nincs a listában. Az első lapon (Answer ID 5357) viszont Raid Edition merevlemez egyáltalán nincs említve.
Az anomáliáról kérdeztem a hivatalos supportot is, szerintük nem támogatott a WD10EADS, és a többi nem Raid Edition lemezek használata wdidle3.exe-vel: „Unfortunately this software was made for a specific model of internal drives and the Caviar Green GP drive is not one of them. It was made for RE3 drives.” (Igen, RE3-at írtak a levélben.) A support oldalt persze azóta sem tették egyértelművé, hiába kértem.
További adalék, hogy az eredeti, NGOHQ-n megjelent cikket a Western Digital PR is kommentálta, de a kommentben nyoma sincs tiltakozásnak, hogy a wdidle3.exe használata Caviar Green lemezekkel nem támogatott.
Ezek után nem könnyű eldönteni, hogy merjük-e a használni a wdidle3.exe-t, esetlegesen kockáztatva a garanciát, vagy inkább hagyjuk szépen növekedni az LCC-t.
Lentebb egy biztonsági mentést készítő szkript Sony PRS-650-hez. Amit tud: automatikus mount/umount, könyvtárlétrehozás dátum alapján, md5sum az elkészült mentésről, a database/media/audio/ alatti tartalmak kihagyása.
#!/bin/bash ### Sony PRS-650 backup script by palacsint, 2011. 07. 14. ### http://palacsint.hu/ INPUT_DIR=/mnt/prs650_internal BACKUP_BASE_DIR=/backup/sony-prs-650 mkdir --parents $BACKUP_BASE_DIR || exit -1 BACKUP_DIR=$BACKUP_BASE_DIR/sony-prs-650-$(date +%Y-%m-%d) echo "Backup directory: $BACKUP_DIR" if [ -d $BACKUP_DIR ]; then echo "Backup directory already exists, skip backup" exit -1 fi echo "Free space on backup drive: $(df -h $BACKUP_BASE_DIR | tail -1 | awk '{print $4}')" MOUNTED=false if mountpoint -q $INPUT_DIR; then echo "Input directory $INPUT_DIR already mounted" MOUNTED=true else mount $INPUT_DIR || exit -1 fi mkdir --parents $BACKUP_DIR || exit -1 rsync --whole-file --recursive --filter='exclude, database/media/audio/**' $INPUT_DIR/ $BACKUP_DIR find $INPUT_DIR | sed "s:$INPUT_DIR::" | sed 's:/::' > $BACKUP_DIR/file-list cfv -q -C -t md5 -rr -p $BACKUP_DIR || exit -1 echo "Backup size: $(du -sh $BACKUP_DIR | awk '{print $1}')" if [ "x$MOUNTED" = "xfalse" ]; then umount $INPUT_DIR sync fi echo "Backup OK"
Adott a következő könyvtár, amely napi mentéseket tartalmaz negyedévenként külön szülőkönyvtárban:
... backup-2011q1/backup-2011-03-31 backup-2011q1/backup-2011-04-01 backup-2011q2/backup-2011-04-02 ...
Az egyes napi mentések nem túl nagyok, de azért jó lenne egy idő után hatékonyan tömöríteni őket. Tart és gzipet vagy bzip2-t használva nem nyerünk sokat, a jelen esetben néhány száz megás, minimálisan eltérő napi mentések tömörített mérete csak 10-20 százalékkal kisebb, mint a könyvtárak tömörítetlen mérete.
A tar fájl a benne lévő fájlokat elérési útjuk szerinti ábécé sorrendben tárolja. Így a mindegyik napi mentésben előforduló azonos fájlok egymástól távol kerülnek a tar fájlban. A távolság miatt a gzip/bzip2 nem ismeri fel az ismétlődő mintákat, ezért nem tömörít hatékonyan. (Aki otthon van a témában, nyugodtan javítson ki, pontosítson kommentben.)
Gyors megoldás, ha gzip/bzip2 helyett 7-Zip-et használunk. Sajnos a gzip/bzip2 párost semmilyen paraméterrel nem sikerült rávennem, hogy maguktól felismerjék ezeket az ismétlődéseket, de a tar tartalmának megfelelő sorrendezésével segíthetünk a dolgon.
Erre két javasolt megoldás a credentiality blogon található. Az MD5 hash alapján történő sorrendezés megtalálható az előbbi linken, a fájlnév alapú sorrendezésre pedig egy példamegoldás a következő:
$ cat ~/bin/tar2 #!/bin/bash export GZIP=-9 find "$1" -type f | awk '{split($0, pathElements, "/"); print pathElements[length(pathElements)] "\t" $0 }' | sort | cut -f 2- | tar czvf "$1.tar.gz" -T -
Sajnos a tar tartalmának megfelelő sorrendezése nem segít az ismétlődő, de túl nagy fájlok tömörítésén, ezen ismétlődéseket a gzip/bzip2 továbbra sem fogja felismerni. A 7-Zip használata erre is megoldást jelent.
Az Effective Java című könyvben is szerepel, hogy nem ajánlott nullt visszaadni, inkább részesítsük előnyben az üres tömböket és az üres kollekciókat, ha tömb vagy kollekció a visszatérési érték típusa. Lentebb arra látható egy példa, hogy JAXB használatakor hogyan kell annotálni az osztályunkat, hogy az unmarshall után a JAXB ne hagyjon maga után nullokat a kollekciók értékeként.
import java.util.LinkedList; import java.util.List; import javax.xml.bind.annotation.XmlAccessType; import javax.xml.bind.annotation.XmlAccessorType; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlElementWrapper; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement @XmlAccessorType(XmlAccessType.NONE) public class Data { @XmlElementWrapper(name = "list") @XmlElement(name = "list-element") private final List<String> list = new LinkedList<String>(); public Data() { } public List<String> getList() { return new LinkedList<String>(list); } public void setList(final List<String> list) { if (list == null) { throw new IllegalArgumentException("list cannot be null"); } this.list.clear(); this.list.addAll(list); } }
Érdemes megjegyezni, hogy ha a getter metódusra kerülne a @XmlElement annotáció, akkor a metódus által visszaadott listába kerülnének a JAXB által felvett elemek, emiatt a getterben nem lehetne másolatot visszaadni a belső listáról.
Legutóbbi hozzászólások
8 év 47 hét
9 év 36 hét
9 év 40 hét
10 év 6 hét
11 év 8 hét
11 év 13 hét
11 év 13 hét
11 év 14 hét
11 év 24 hét
11 év 47 hét