Közismert, hogy a racionális számok megszámlálhatóak. A következő algoritmussal ugyanis fel tudjuk őket mind sorolni (az egyszerűség kedvéért, most csak a 0 és 1 közöttieket, a többiek negálással és invertálással adódnak):

1. Legyen q=1.
2. Legyen p=1.
3. Ha p/q nem eleme a készítendő listának, tegyük bele.
4. Ha p=q, akkor legyen q=q+1 és folytasd a 2. lépéstől. Különben legyen p=p+1.

Így előáll egy lista, ami tartalmazza az összes racionális számot 0 és 1 között. A kérdés: hogyan lehet meghatározni ennek a listának az n-edik elemét?

Nyilvánvaló, a fenti algoritmus egyben meg is határozza a lista elemeit, de ez az algoritmus O(n) nagyságrendű. A kérdés tehát az, hogy létezik-e (létezhet-e) olyan algoritmus, ami a lista n-edik elemét ennél gyorsabban (mondjuk O(ln(n)), esetleg O(1) rendben) képes meghatározni? Ja, a "felírom a listát egy papírra és kikeresem az n-edik elemet. O(1), nyertem" típusú megoldás nem játszik...

Faites vos jeux!

Tudjátok, miért utálom az Internet Explorert?

Egyebek között, ezért. (Figyelmeztetés: a link erősen károsíthatja az ön és környezete intellektuális békéjét.)

(Kis háttér: A napokban találkoztam a következő Apache direktívával, ami arra szolgál hogy az Internet Explorer kevésbé legyen hülye:)

<IfModule mod_headers.c> Header set X-UA-Compatible "IE=edge" # `mod_headers` can't match based on the content-type, however, we only # want to send this header for HTML pages and not for the other resources <FilesMatch "\.(appcache|crx|css|eot|gif|htc|ico|jpe?g|js|m4a|m4v|manifest|mp4|oex|oga|ogg|ogv|otf|pdf|png|safariextz|svgz?|ttf|vcf|webapp|webm|webp|woff|xml|xpi)$"> Header unset X-UA-Compatible </FilesMatch> </IfModule>

Megtört szívvel jelentem, hogy kedvenc cégem, a StartVox szerverén elszaporodott a SPAM. Méghozzá nem az a vidám, baráti SPAM, amit a zen.spamhaus.org egy mozdulattal eltüntet, hanem magyar SPAM! Na de fúj. Befektetési tanácsadás? Őrületes hozamok? Fogyókúra két hét alatt?? Mindez az én szerveremen???

Nem, ez nem mehet így tovább! Valamit tenni kell, még akkor is, ha több időbe telik, mint egyesével törölni a leveleket. Szerencsére úgy láttam, hogy az összes ilyen levélben található egy meglehetősen fura SMPT fejléc mező, amit más levélben még nem láttam. Úgyhogy a szűrés nem olyan bonyolult: ha egy levélben van ilyen fejléc mező (X-Mailer-RecptId), akkor kuka.

Tanuljunk meg hát Exim4 filtert készíteni, jól, gondoltam én. Tájékozatlanok számára: az Exim4 egy MTA (Mail Transfer Agent), ismertebb nevén: e-mail szerver. Igen jól fejlett példánya az open source szoftvernek: csak a filterezésről szóló dokumentációja 25 oldal kinyomtatva, a Debian által szállított Exim4 mindenesetre tartalmaz egy minta konfigurációs file-t, ami laza 2000 sort nyom.

Összefoglalva: az Exim4 konfigurálás súlyos fekete mágia!

Szerencsére az alap Debian template tartalmaz néhány pontot, ahol bele lehet piszkálni a levélkézbesítés folyamatába, méghozzá anélkül, hogy ezt az óriás template-et kellene szerkesztenem. Némi dokumentáció- és fórumolvasgatás után sikerült kiderítenem, hogy a tartalom alapú filterezés az acl_smtp_data címre hallgató access control list-ben találhatóak. A template elején található rész: .ifndef MAIN_ACL_CHECK_DATA MAIN_ACL_CHECK_DATA = acl_check_data .endif acl_smtp_data = MAIN_ACL_CHECK_DATA

Aham. Szóval keressem azt, hogy acl_check_data. Értem én! Ez a lista a file 870. soránál kezdődött, és egyebek között található volt benne egy ilyen stanza:

# This hook allows you to hook in your own ACLs without having to # modify this file. If you do it like we suggest, you'll end up with # a small performance penalty since there is an additional file being # accessed. This doesn't happen if you leave the macro unset. .ifdef CHECK_DATA_LOCAL_ACL_FILE .include CHECK_DATA_LOCAL_ACL_FILE .endif

Ez lefordítva a magyar nyelvre: ha a lokális makrók között (amik egy külön file-ban vannak) definiálok egy CHECK_DATA_LOCAL_ACL_FILE nevű makrót, akkor azt az Exim4 szépen felveszi a többi filter közé! Nosza, ezt írtam az exim4.conf.localmacros mélyére: # @UPi: Local spam filters CHECK_DATA_LOCAL_ACL_FILE = /etc/exim4/local_check_data

(Általában config file-okban @UPi-val szoktam jelölni a saját változtatásaimat, és az ahhoz kapcsolódó kommenteket. Így látom, hogy hol barmoltam bele a rendszerbe.) Ezután már csak a konkrét filter hiányzik ügye, ami elvégzi a tényleges szűrést.

# @UPi: deny from Hungarian spam gang deny condition = ${if def:h_X-Mailer-RecptId: {yes}{no}} delay = 45s message = DIAF

Mit is jelentenek ezek? A deny annyit fejez ki, hogy ha ez a szűrő érvényesül, akkor szépen visszautasítjuk a levélkét. A condition rész az Exim4 agyament nyelvén azt fejezi ki, hogy ha létezik az a bizonyos fejléc mező, akkor teljesüljön csak a filter. (Ha a condition nem teljesül, akkor a rendszer szépen megy a következő filterre.) A delay bónusz szopatás: 45 másodpercig várunk a válasszal, ezzel is feltartjuk az ő kis SPAM rendszerüket. Az üzenet pedig az én személyes jókívánságom, csak nekik.

Hát ennyit az Exim4 szűrésről. Még azt érdemes megemlítenem, hogy hogyan érdemes egy új szűrőt tesztelni! Erre a következő parancs a legalkalmasabb, az Exim4 kismillió opciója közül: exim4 -bh 46.102.245.88 A 46.102.245.88 egy szabadon választott külső IP cím; az Exim4 a teszt folyamán úgy fog tenni, mintha erről a címről csatlakoztam volna hozzá. Ezek után SMTP protokoll szerint lehet parancsokat beírni, erről egy jól használható példa van a Wikipedia SMTP-ről szóló oldalán. Közben az Exim4 pedig szorgosan írja, hogy éppen melyik filtereket futtatja, és azokat hogyan értelmezte közben.

Itt a vége, fuss el véle, búcsúzik a műsorvezető.

Kedvenc-utált platformom, a HTML5 kezd olyan képességeket felmutatni, amelyek alkalmassá teszik mindenféle érdekes dologra a szokásos blog, social media és levelezőprogram funkciókon felül.

A legújabb ilyen képesség, amivel játszani kezdtem, a getUserMedia névre hallgató API-szörny. Ennek a segítségével dzsuvaszkriptből képessé válik az ember arra, hogy a helyi gép webcameráját és mikrofonját hozzákösse egy (szintén a HTML5-ben definiált) <audio> illetve <video> elemhez. Ehhez természetesen a felhasználó tudta és beleegyezése szükséges, amit a böngésző hivatott kikönyörögni.

Mire jó az, hogy a webcamerát hozzá lehet kötni egy <video> elemhez?

• A felhasználó tudja a weboldalt tükörnek használni borotválkozáshoz.
• A <video> elem tartalmát be lehet másolni egy <canvas> elembe, és ott mindenféle érdekes dolgot csinálni vele.

Mi az a mindenféle érdekes dolog? Például, feltölteni a tartalmát a szerverre egy képfile formájában. (Ez az, amit megcsináltam az ApocalypseKÖZÖS engine-re, ki lehet próbálni a feltöltő oldalon.) Ezen kívül mindenféle vicces trükköt lehet csinálni, például egy egyszerű trükkel (green screen) kicserélni a hátteret valami tréfás dologra. Vagy ki tudja.

Íme az első próbálkozásom:

(Üzenet az agynak: a lámpával a webcamba világítani vicces.)

Kis bevezető: szerintem az elmúlt évtizedben a linux elvesztette a "csak kockáknak" matricáját.

A 90-es évek végén léptem be a linuxozók közébe. Kezdetben csak nagygépeken, később a saját otthoni PC-men is. Az első grafikus környezet, amivel találkoztam, az fvwm volt. Lehetett benne mindenféle csoda dolgot beállítani, és a beállítás módja egy szöveges konfigurációs file szerkesztése volt. Viszont képes volt olyan dolgokra, mint pl "az összes netscape ablak ugyanazon a képernyőn nyíljon meg", amire a mai, modern grafikus felületek egyike sem (se a windows, se os X, senyő nem állítható be ennyire precízen).

Emlékszem még tisztán arra, hogy mennyit kellett hákolni annak idején olyan alapvető dolgokhoz, mint pl "egyáltalán elinduljon a grafikus felület". Ezeknek ma már vége. Az új linux telepítő, mint egy gondos dadus a kissé fogyatékos gyerekkel, szépen mindent detektál, beállít, és utána megdicsér téged hogy milyen ügyesen telepítetted a linuxodat. Valahogy elveszett belőle a küzdés és a vadászat élménye, pontosabban olyan ez a vadászat, mintha a nyúl fogná magát, szépen odajön hozzád, agyonlövi és megnyúzza önmagát, és aztán megfőzi neked a paprikást is, te meg csak nézel.

Szóval történt pedig az, hogy vettem 2 éve egy Trust slimline rajztáblát. Hiba volt, még a windows-os drivere is elég szar volt, a linuxos pedig nem létező. Hogy mennyire szar a windows-os drivere? Például nem lehetett beállítani a minimális nyomási erősséget, ami azt jelentette, hogy az a programok nehezen tudtak különbséget tenni aközött, hogy te most valahova csak átrakod a tollat, vagy egy nagyon-nagyon vékony vonalat akarsz oda rajzolni. Gyász. Még szerencse, hogy van a Ctrl+Z.

Pár hete nagyjából-egészében átálltam linuxos üzemre, és pár napja elhatároztam, hogy kéne megint rajzolni. Bedugom a tabletet. A linux szépen érzékeli, mint egy egeret, mínusz a nyomásérzékenység. Namármostan az én rajzmódszerem olyan, hogy ha nincs változtatható vonalvastagság, akkor egyszerűen nem tudok vázlatozni. Némi nyomozás után kiderült, hogy volt egy wizardpen nevű (azóta elárvult) projekt, ami az aiptek-alapú (vagyis az összes szar-olcsó) tablethez volt hivatott drivert alkotni. Meg is találtam a csomagot, beállítom a forrást (hoppá! command line!): kiderül, hogy csak ubuntu 10.04-hez csináltak letölthető binárist.

Második probálkozás: letöltöm, és kézzel installálom a 11.04-es binárist. Eredmény: most már egérként sem kezeli a rendszer a tabletet. Nézem a /var/log/Xorg.log-ban, hogy mi van: a régi bináris nem kompatibilis, és ezért nem töltötte be a driver-t. Kettőből semmi.

Harmadik próbálkozás: szedjük le a 11.04-es forrását, fordítsuk le belőle a csomagot, aztán lássuk mi van. Nyerés van. Ez volt a helyes megoldás.

Szóval, a következőket kell tenni (arra az esetre, ha valaki utánam akarja csinálni a dolgokat):

    sudo aptitude install dpkg-dev debhelper autotools-dev xautomation xserver-xorg-dev libsysfs-dev xutils-dev
    cd /tmp
    wget http://ppa.launchpad.net/doctormo/xorg-wizardpen/ubuntu/pool/main/x/xserver-xorg-input-wizardpen/xserver-xorg-input-wizardpen_0.8.1-0ubuntu3.dsc
    wget http://ppa.launchpad.net/doctormo/xorg-wizardpen/ubuntu/pool/main/x/xserver-xorg-input-wizardpen/xserver-xorg-input-wizardpen_0.8.1-0ubuntu3.tar.gz
    dpkg-source -x xserver-xorg-input-wizardpen_0.8.1-0ubuntu3.dsc
    cd xserver-xorg-input-wizardpen-0.8.1/
    dpkg-buildpackage -rfakeroot -b
    dpkg –install ../xserver-xorg-input-wizardpen_0.8.1-0ubuntu3_i386.deb

Amik itt történnek azok a következők:

1. Először is telepítem a fordításhoz szükséges csomagokat.
2. Leszedem a launchpad-ról a wizardpen csomag forrását (.dsc és .tar.gz)
3. Kitömörítem és lefordítom a csomagot.
4. Az így keletkező bináris csomagot telepítem.

Utána még szerkeszteni kell a /usr/share/X11/xorg.conf.d/70-wizardpen.conf file-t, a helyes tartalom a következő:

Section "InputClass"
   Identifier "wizardpen"
   MatchIsTablet "on"
   MatchDevicePath "/dev/input/event*"
   MatchVendor "UC-LOGIC|KYE Systems|Ace Cad|WALTOP|Waltop"
   Driver "wizardpen"
   Option "TopX" "0"
   Option "TopY" "0"
   Option "BottomX" "20000"
   Option "BottomY" "12500"
EndSection
Section "InputClass"
   Identifier "wizardpen ignore mouse dev"
   MatchIsTablet "on"
   MatchDevicePath "/dev/input/mouse*"
   MatchVendor "UC-LOGIC|KYE Systems|Ace Cad|WALTOP|Waltop"
   Driver ""
   Option "TopX" "0"
   Option "TopY" "0"
   Option "BottomX" "20000"
   Option "BottomY" "12500"
EndSection

Hurrá, megvolt a vadászat, és a rajztáblám is működik. Valaki főzze már meg a paprikást...