Ha vettél már valaha írható CD-t vagy DVD-t, esetleg memóriakártyát a fényképezőgépedbe, akkor ún. szerzői jogdíjat is fizettél, ami be van építve minden ilyen jellegű adathordozó árába. Az nem számít, hogy te esetleg csak a saját adataidat akarod kiírni egy CD-re, és sose tennél rá pl. illegálisan letöltött zenét mondjuk MP3 formátumban. Az Artisjus és barátai szerint te akkor is bűnöző vagy, és ne is tagadd: biztos csak azért veszel egy DVD-t a boltbban, hogy filmeket írhass rá, és hogy ezzel megkárosítsd a művészeket és a kiadóikat.

Számomra logikusan hangzik, hogy ha már egyszer úgyis kifizettem egy összeget bizonyos közelebbről meg nem nevezett alkotásokért, akkor jogosan írom ki saját felhasználásra kedvenc hippi (sic!) zenéimet. A magyar törvények pedig ezt a felhasználást nem is büntetik, amíg az nem szolgál jövedelemszerzést.

Mindenki boldogan töltögethetné hát az mp3-akat az Internetről, azonban a ProArt ezt másképpen látja. Az Index cikke szerint most éppen a fájlcserélő szervereket vették célba. Történt ugyanis az, hogy a ProArt feljelentést tett két fájlcserélő hub üzemeltetői ellen, mert azok szerzői jogvédelem alatt álló alkotásokat tettek elérhetővé. A ProArt precedens értékű bírói határozatot akart – megkapta. A bíróság ítélete szerint a szerzői jogdíjak megfizetése már az üres adathordozók megvásárlása által megtörtént.

A ProArt szerint azonban a szabad felhasználásba nem fér bele a megosztás. A bíróság azonban ezt másképpen látta, és szerinte a vádban ismertetett megosztás nem lépte túl a szabad felhasználás kereteit.

Ha próbáltál már valamilyen káros szenvedélyről leszokni vagy hetente 3-4 alkalommal futni, de hamar feladtad, végy példát a ProArtról. Nem hagyták ők annyiban a dolgot, és polgári perben igyekeznek számukra kedvező döntést kicsikarni egy másik bírótól.

És mielőtt bárki szegény zenészeket féltené, az Index cikke szerint, az emelkedő üres adathordozó eladásokból majdnem annyi jogdíj befolyik hozzájuk, mint az eredeti CD-k eladásából.

Csak most vettem észre, hogy a regisztráció le volt tiltva, így hiába akartatok kommenteket írni, sajnos nem jött össze. A hibát javítottam. Ha van kedvetek regisztráljatok, aztán jöhet a kritika. Ami ez utóbbinak az erejét / sebzését illeti, maradjunk az I’m too young to die szintnél.

Egy alkalommal, amikor átnéztem a junk mappát, hogy véletlenül nem került-e bele jó levél, egy furcsa levelen akadt meg a szemem. Egy norvég illető azért továbbított nekem egy spamet, mert állítólag valaki a mi tartományunkból küldte neki. Ezt ráadásul azzal a nyomatékosítással tetézte, hogy ha a jövőben nem akarok tőle ilyet kapni, akkor tegyek valamit, hogy ő ne kapjon több spamet.

A levelet megvizsgálva nem győzött meg arról, hogy valóban a mi hálózatunkból ment volna ki a kérdéses spam, ezért válaszoltam neki erre a levelére, és elmondtam neki az aggályaimat. Kiderült, hogy ő a Barracuda spamszűrő dobozt használja, aminek SpamAssassin a lelke. Történt ugyanis a, hogy az én válaszomat visszadobta a Barracuda, mondván hogy az spam. Ráadásul a fejlécben meg is indokolta, hogy miért: mert a levélben szerepelt az a megszólítás, hogy “Dear Sir” (nem tudom, hogy angol nyelven egy vadidegent ugyan hogyan szólítsak meg, ha nem így), ill. a másik fő bűne az volt a levelemnek, hogy egy olyan URL szerepelt benne, amelyik IP-címmel volt megadva.

Ezt írta a Barracuda a levél fejlécébe:

X-Barracuda-Spam-Report:
Code version 3.02, rules version 3.0.22920
Rule breakdown below  pts rule name              description
—- ———————- ————————————————–
0.20 FROM_NO_LOWER          From address has no lower-case characters
1.61 DEAR_SOMETHING         BODY: Contains ‘Dear (something)’
0.00 NORMAL_HTTP_TO_IP      URI: Uses a dotted-decimal IP address in URL
1.05 IP_LINK_PLUS           URI: Dotted-decimal IP address followed by CGI
0.00 ADVANCE_FEE_1          Appears to be advance fee fraud (Nigerian 419)

Némi nyomozás után aztán kiderült, hogy az az IP-címmel megadott URL az ő Barracudájának a menedzsment címe, ill. miután kitöröltem a “Dear Sir” megszólítást, simán elment a levél.

Mi ebből a tanulság? Sose utasítsuk el a spamet, mert akkor a spammer tudni fogja, hogy elkaptuk a levelét, és addig próbálkozhat, amíg a spamszűrőnkön át nem csúszik a levele. Ha pedig ez megtörtént, akkor valószínűleg az összes Barracuda spamszűrőn át fog menni a módosított spam. A másik tanulság pedig az, hogy a heurisztikus spamszűrők ideje lejárt. Ma a statisztikai elven működő szűrők érik el a legjobb hatékonyságot. Ezért a norvég barátom sem tehet jobbat, minthogy kidobja a Barracuda dobozát, és telepít egy korrekt Bayesian szűrőt.

Ismered azt a viccet, amikor 2 rendszergazda megy a sivatagban? De komolyan, 2 rendszergazda még a halál torkában sem beszélné azt a halandzsa nyelvet, amelyben olyan szavak vannak, mint TCO, ROI, stb. Azonban ezeket a misztikus rövidítéseket nem lehet elkerülni, ha a menedzsmentnek vagy akár csak a főnöködnek akarsz beadni egy új megoldást a spamszűrésre. Ebben a rövid írásban ezeket a fogalmakat szeretném egy kicsit világosabbá tenni.

A ROI (=Return on Invest) egyszerűen megtérülést jelent. Ha egy új prodzsekt milliókba kerül, joggal várja el a főnököd, hogy meggyőzd, nem az ablakon fogja kidobni ezt a halom pénzt minden haszon nélkül, hanem ellenkezőleg, milyen gyorsan térül majd meg.

A spam problém kapcsán azt kell demonstrálnod, hogy a kéretlen levelek mennyi extra költséget jelentenek nektek. Ez az Interneten található kalkulátorokkal nem is lesz nehéz, már egy átlag 5-10 fős kisvállalkozásnál is százezres kárt okoz éves szinten a spam, ha nem kezelik.

A következő lépésben azt kell megmutatnod, hogy a spamre tervezett nyílt forrású megoldás mennyire olcsó. És itt jön a képbe a másik rövidítés, a TCO (=Total Cost of Ownership), azaz a birtoklás teljes költsége. Ez azt mutatja meg, hogy minden költséget összeszámolva mennyibe kerül neked az, ha az X megoldást használjátok.

Szerencsére a nyílt forrású szoftverek ingyen vannak, bárki bérmentve letöltheti azokat. Némely profitéhesorientált cég nagyon helyesen érvel azzal, hogy az előbb említett TCO-nak csak egy részét teszi ki a szoftver beszerzésének ára. Az előbbin kívül beletartozik még pl. a szoftver frissítésének ára, az üzemeltetési költségek, az esetleges migrálás (=átállás) egyszeri költsége, a felhasználók képzése, a terméktámogatás ára, az esetleges új/extra hardver költsége vagy a felhasználónkénti licencek ára szorozva a felhasználók számával.

Nagyon helytelenül érvelsz, ha azt állítod, hogy a nyílt forrású programoknál a TCO nulla. Hidd el, ezt senki nem fogja bevenni, egyszerűen azért, mert ez így, ebben a formában nem igaz. Neked azt kell megmutatnod, hogy noha a nyílt forrású termékeknek is vannak költségeik (pl. terméktámogatás, migráció), de mindezt összeadva is egy meggyőzően olcsóbb ár jön ki, mintha ugyanarra a funkcióra egy kereskedelmi programot használnátok.

Ha kiszámoltad a TCO-t mind az open source, mind a (jelenleg is használt) kereskedelmi termék esetében, akkor számítsd ki a korábban említett megtérülési mutatót az alábbi képlettel, amely azt adja meg, mennyi idő alatt térül meg az a bizonyos korábban említett “halom pénz“:

ROI = (nyereség – befektetett pénz) / befektetett pénz

Minél nagyobb ez a szám, annál jobb. Az is kiderül még, hogy nagyobb az esély a sikerre, ha már a kezdetektől nyílt forrású megoldást vezetsz be, mert ebben az esetben elmarad a migráció költsége. Sok sikert a meggyőzéshez!

Egy felhasználó figyelmeztetett arra, hogy nem eléggé következetes a több helyen is levő clapf oldalak tartalma.

Ezért úgy döntöttem, hogy az elsődleges site marad a saját gépemen, minden fejlesztői változatot itt fogok publikálni, míg a magyar nyelvű site, ill. a sourceforge gépein levő oldalakon csak a stabil, végleges verziókat teszem közzé. A novellforge-ról meg valószínűleg törölni fogom a projektet.

Készítettem egy Arch Linux alapú ISO image-et (175 MB, MD5: 42438497787ddf486568955a9f4b1624), amely minden csomagot egy helyen tartalmaz, ami a clapf spamszűrő futtatásához szükséges. A telepítés rendkívül egyszerű, egy felhasználóbarát menü vezet rajta végig. És ha ez még nem elég, van hozzá egy leírás is.
Az operációs rendszer telepítése után csak egy shell scriptet kell lefuttatni, és készen is vagy*!

*: A token adatbázist ezután még el kell készíteni.

A játék 4-5 éves kortól játszható, és jó ha legalább 5-6 gyerek összejön. Helyezzünk el a gyerekek számánál eggyel kevesebb széket körben. Egy valaki középre áll, a többiek elfoglalják a székeket. Ezután a középen álló gyerek elkiáltja magát, hogy földrengés, erre mindenki feláll, és (a középen állóval együtt) egy másik széket keres, ahova leülhet. Aki nem tud leülni, az mondja a következő körben, hogy földrengéééés.

Nem lennék meglepve, ha te is utálnád az image spamet, az olyan szemetet, amikor a levél maga valamilyen semleges szöveget tartalmaz, és a csatolt kép tartalmazza magát a reklámot, stb.

Postfix alatt az inline képeket tartalmazó (összes) levél még SMTP szinten eldobható az alábbi regexp-pel, amit a /etc/postfix/body_checks fájlba tehetsz:

/src\s*\=(3D){0,}\s*["']?cid:/ REJECT

Ez a szabály nincs hatással a csatolt képeket tartalmazó üzenetekre, vagy amelyeknél a képre HTML hivatkozással (<img src=”….” >) történik utalás.

Már egy jó ideje annak – kb. a 4.0.6 verziótól kezdve – hogy a PHP a register_globals változót alapértelmezésben kikapcsolt (off) állapotban javasolja biztonsági ill. teljesítmény megfontolások alapján.

Az alábbiakban egy röpke példa, hogy miről is beszélek. Vegyük pl. az alábbi kódot:

...

if($login == ... && $password == ....)

$x = 1;

if($x == 1){

// sikeres autentikacio    ... }

else {

die("autentikacio nem sikerult");

}

Ebben az esetben a támadónak nincs arra szüksége, hogy kitaláljon egy érvényes login nevet és jelszót, az is elég, ha az x=1 paramérert is átadja a scriptnek inputként, és már át is lépte az autentikációt.

Még mindig sok olyan php kódoló van, akik úgy írják meg a php script-jeiket, hogy bekapcsolt (on) állapotot feltételeznek. Ha pedig kellően sok CGI változóval dolgozik a script, akkor bizony szép munka azt átírni, pl. $x helyett $_GET['x']. Ebben az esetben az alábbi rövid kódrészlet segít, ha a script elejére teszed:

while(list($k, $v) = each($_GET)) $$k = $v;

POST metódusnál teljesen hasonlóan a $_POST nevű globális tömb használható.

Telepítettem egy galéria alkalmazást, amellyel megnézheted a mostanában készített képeimet (mentségemre legyen, nem mindet én követtem el). Keresd a jobb felső rész körül.