przez ostatni tydzień byłem praktycznie non stop poza swoim standardowym miejscem pobytu.
niestety to oznacza, że przez ten tydzień nie czytałem wiadomości. zasadniczo samo w sobie nie jest to złe, ale oznacza,  że dnewsach czeka teraz na mnie około 2.7 tysiąca newsów. które muszę przejrzeć i na podstawie części z nich stworzyć wpisy. tak więc bójcie się. kolejny flood newsowy jest bliski.

aha. mam prośbę. jakby ktoś z was był na jakimś lotnisku (najchętniej irlandzkim) i mógł mi zanabyć “irish mist" (taka wóda 🙂 to będę mocno wdzięczny. oczywiście koszt zrefunduję.

czy macie ogólne pojęcie ile mniej więcej prądu zżera wasz komputer? a serwer?

na ile szacujecie zużycie prądu, przez takie urządzenie:

• obudowa rackowa 1u
• 3 terabajty pojemności
• 4 dyski 750 giga w środku
• złącza vga, szeregowe, równoległe, 2 usb 2.0, klawiatura/mysz ps/2
• procesor – 1ghz
• pamięć do 1 gb
• gigabit ethernet
• zdalne zarządzanie systemem

odpowiedź brzmi: 80 watów. niemalże niemożliwe. ale jednak się udało.

firma capricorn technologies zaprojektowała i teraz sprzedaje takie cuda. albo pojedynczo – jako macierze 3terabajty. albo jako całą szafkę – 42u, mającą 120 terabajtów. i zużywającą około 3.2 kilowata! tylko!.

koszt ma wynosić około $1.5 za gigabajt (wiadomość nieautoryzowana). czyli macierz 3 tera, będzie kosztowała około $4500. nie jest to tanio. ale z drugiej strony – dzięki tak niskiemu zużyciu prądu, natychmiast pojawią się oszczędności.

jak udało im się to zrobić? użyli sensownego sprzętu. jako podstawę użyli mini-itx'owego rozwiązania – via epia. małe, proste, wydajne (wystarczająco).

śliczny sprzęt. kto go będzie dystrybuował w polsce?

zasadniczo to nie news – informacja jest z 14 czerwca, ale jakoś do tej pory o tym nie wiedziałem.

wreszcie wyjdzie 2 sezon twin peaks na dvd!

jeśli nie jesteście fanami tego serialu, albo może i jesteście ale nie jesteście świadomi “jazd" jakie były z wydaniami dvd twin peaks, to powiem w skrócie – właściciele filmu zmieniali się wiele razy. w pewnym momencie doszło do jakiegoś rozjechania się praw do filmu i praw do wydawania (czy czegoś takiego). i dlatego 2 sezonu nigdy nie było na dvd. była tylko wydana daaawno wersja na tzw. “laser-disku".

teraz, wrescie, paramount pictures wyda dvd. w dodatku będzie to dvd jakieś takie bardziej “wypasione". dodatki, sceny, itd. itp.

razem z premierą “Twin Peaks: Season Two – Special Edition" ma sie pojawić “Twin Peaks: The Complete Collection" zawierający oba sezony.

eh. pozostaje czekać. i to sporo czekać. premiera w australii ma być 2 listopada. a kiedy do polski trafi?

niejaki jeremiah grossman wymyślił nowatorską metodę sprawdzania na jakich stronach był wcześniej człowiek który wszedł na naszą stronę.

idea jest prosta – tworzymy stronę z dużą ilością linków.

przy pomocy css'ów ustawiamy specjalny styl dla pseudoklasy :visited.

potem javascriptem przechodzimy przez wszystkie linki na stronie i sprawdzamy jaki mają styl!.

proste i skuteczne. po połączeniu tego z ajaxem, jakąś małą bazą danych i cookiesami – i powstaje świetna metoda przeprowadzania “wywiadu" nt. użytkowników.

oczywiście daje się to zablokować. ale z drugiej strony – ile teraz osób blokuje style czy prosty javascript?

serwis engadget przygotował spory tekst nt. otwierania zamków metodą “bump key". są schematy, wyjaśnienia, zasada działania.

jeśli temat was zainteresował poprzednio, myślę, że przeczytanie tego artykułu i jego drugiej części jest niemalże obowiązkowe.

aha. podziękowania dla tmarca za informację.

w windowsy od jakiegoś czasu wbudowane jest zabezpieczanie dysków (szyfrowanie).

w najnowszych windowsach oczywiście też.

możliwe są 2 metody szyfrowania – z użyciem “trusted platform module" – procesora który docelowo ma być na każdej płycie głównej, ale obecnie jeszcze nie jest, albo z użyciem hasła zapisanego na pendrive'ie usb.

ludzie z apc magazine przeprowadzili test. wzięli wolnego peceta (pentium 4 2ghz, 512 mega ram, dysk ata 5400 rpm, 20 giga). i zobaczyli wyniki benchmarków.

(tu disclaimer: dysk 5400, dlatego, że uznali, że główną grupą docelową będą użytkownicy laptopów. co ma sens).

bez szyfrowania dysk wykazał się prędkością do 33 mb/s, i średnim czasem dostępu na poziomie 10ms.

po zaszyfrowaniu 6.3 gigabajtowej partycji (40 minut) powtórzono test. wynik: 29mb/s i średni czas dostępu 5ms (nie wiem czemu niższy niż przy braku szyfrowania).

co istotne – te testy przeprowadzili na becie visty, więc jest szansa, że przed wypuszczeniem finalnego systemu wydajność jeszcze się poprawi.

a nawet jeśli nie – spadek wydajności o 12% jest przy typowych zastosowaniach praktycznie niezauważalny. zwłaszcza, że szyfrować dyski będą chcieli raczej ludzie pracujący niż grający.

vista wygląda coraz lepiej.

nowe suny (t1000 i t2000, na procesorach niagara) jak wiadomo są energooszczędne. mniej prądu, niższe rachunki za prąd.

ale to nie wszystko. jeśli twoja serwerownia jest w regionie obsługiwanym przez firmę pacific gas & electric – dostaniesz od nich rabat! wysokośc rabatu jest ustalana każdorazowo indywidualnie, ale średnio wynosi od $700 do $1000!

oczywiście większość czytających te słowa jest w polsce, a więc poza zasięgiem działania pg&e, ale informacja jako taka jest w/g mnie mocno interesująca. czy u nas też pojawią się takie możliwości? kiedy?

na razie możecie poczytać o tym jak za wielką wodą dają zarobić na energooszczędnych serwerach.

naprawdę tak było. uważałem, że wiem co i jak i gdzie.

a potem dostałem szybką serię:

1. w inode'ach są przechowywane 3 czasy. wymień je!
   no to raczej proste – atime, ctime, mtime
2. kiedy jest modyfikowany mtime?
   no … kiedy się plik zmodyfikuje. jego zawartość znaczy się.
3. kiedy jest zmodyfikowany atime?
   przy dostępie/odczycie z pliku.
4. to kiedy dokładnie? przy open() czy dopiero przy read()?
   ekhem. atime to “access time" czyli przy open()
5. kiedy jest modyfikowany ctime?

i to zasadniczo był koniec.

poczułem się jakbym grał z tmarciem w urban reign i dostał magical combosa za 70% zdrowia.

czemu? a uważacie, że odpowiedziałem dobrze? (celowo nie podałem odpowiedzi na pytanie 5, bo to dłuższa sprawa).

pytanie 1 było proste. i odpowiedziałem prawidłowo.

pytanie numer 2. – źle. nie trzeba modyfikować zawartości. zawartość może pozostać ta sama. wystarczy, że poszedł write() do tego pliku. to nawet jest logiczne – po co kernel miałby porównywać to co było w pliku z tym co jest. ale odpowiedź jest zła.

pytanie number 3 – odpowiedź nieprecyzyjna, więc dostałem kontrę – pytanie 4.

które to pytanie zwaliłem. atime zmienia się przy faktycznym odczycie danych. syscall read().

no ale ctime to była większa porażka.

najpierw uparłem się, że ctime to “creation time". co jest bzdurą. potem sobie na szczęście przypomniałem, że to jednak change time.

no a kiedy jest aktualizowane?

stwierdziłem, że gdy aktualizowany jest inode.

i to jest nieprawda.

takie wyjaśnienie ctime'a znajdziecie wszędzie. włącznie z wikipedią (więc nie tylko ja żyję w niewiedzy, ale to marne pocieszenie).

sprawdzenie tego kiedy dokładnie zmienia się ctime zajęło mi trochę czasu. mnie i rozmówcom z dwóch kanałów ircowych (#perl i #postgresql), plus grep na źródłach kernela itd.

ctime zmienia się wtedy gdy zmienia się mtime *i dodatkowo* wtedy gdy zmieniają się inne niż *time wartości w inodzie.

kilka przykładów dla lepszego zrozumienia:

• chmod i chown pliku zmieniają inode'a, więc zmienia się ctime
• zmodyfikowanie pliku (dopisanie linijki) – zmienia mtime i zmienia wielkość pliku, więc zmienia się też ctime
• zmodyfikowanie pliku (bez zmiany wielkości) – zmienia mtime więc zmienia też ctime.

to co podałem powyżej, może zasugerować, że prawdą jest, że ctime zmienia się przy zmianie danych w inodzie. ale nie.

wystarczy otworzyć plik do odczytu, odczytać coś. atime się zmienia, a ctime nie.

czyli – nie każda modyfikacja inode'a (atime jest w inodzie) modyfikuje ctime!

co zabawne. w kernelu w wersji 2.6.11 (pewnie w starszych też, i w kilku nowszych możliwe, że też), funkcja która aktualizuje mtime ma dodatkowy argument: int ctime_too. który jest potem sprawdzany i ctime jest modyfikowane tylko gdy ctime_too jest ustawione.

ale! w całych źródłach 2.6.11 (które przeszukał infi z #postgresql) wszystkie wywołania tej funkcji (inode_update_time) mają ctime_too ustawiany na 1!.

sprawdziłem źródła do 2.6.17.9 – w nich funkcja ta zmieniła nazwę na file_update_time i “zgubiła" drugi argument.

wnioski na koniec:

1. kiedy uważasz, że wiesz już sporo na jakiś temat, pojawi się ktoś kto ci udowodni, że nie wiesz podstaw.
2. teraz ja muszę wymyśleć jakieś pytanie by go (tego od pytań o czasy) zagiąć. jakieś pomysły?