QUOTE(demond @ Nov 5 2006, 07:14 AM)
ongeboren, pyrvo chestito prikluchvane na modernizaciata i vyvezhdane na unibg v 21-vi vek - good job
vtoro, kakvo shte pravish ottuk natatyk?
imash li planove za razvitie na ircd-ratbox-unibg i ratbox-services-unibg (za onia s koito triabva da se syobraziavash znam che niamat i nikoga ne sa imali)
ako niamash: eto edna idea, eventualnoto realizirane na kojato bi ti pomognalo da navlezesh v MT programming - koeto e vazhno, ponezhe sled 2-3 godini kogato mozhe bi triabva da zavyrshish, programist bez MT skills niama da ima golemi shansove za dobre platena rabota
az vinagi sym tvyrdial che e ircd e primitiven softuer v sravnenie s drugi vidove Internet serveri ponezhe ne izpolzva MT - no ne sym komentiral prichinite za tova; glavnata obektivna prichina e v samia design na IRC kojto, implementiran v ircd, pravi izkluchitelno trudno realiziraneto na concurrency po nachina po kojto e napraveno primerno v webserverite, zashtoto za razlika ot httpd kydeto vseki client mozhe da se obsluzhva napylno nezavisimo ot drugite, v ircd clientite sa inherently dependent (za patriotite - vrodeno zavisimi ili neshto ot sorta) poradi estestvoto na komunikaciata, sledovatelno se iziskva update na obshti strukturi - koeto ot svoja strana vodi do neobhodimost ot pochti postojanni locks za sinhronizacia => degrading overall performance
no tova che MT e pochti bezmislen za klasicheskoto ircd ne znachi che niama miasto v specifichni razshirenia na ircd - i edno takova razshirenie bi bila multi-threading anti-spam subsystem
v naj-obshti linii, ideata e spawning threads za proverka na vseki PRIVMSG (na praktika - izpolzvane na thread pool), kojto thread mozhe da pravi vsichko koeto si poiska bez da zabavia obsluzhvaneto na drugite, po-vazhni sybitia v ircd - ot prost regexp check do Bayesian filtering
edinstvenoto neshto koeto bi iziskvalo sinhronizacia e PRIVMSG pipeline - queueing & dequeueing, za koeto ima gotovi reshenia chrez izpolzvane na monitors/semaphores/condition variables
Tova, koeto ti predlagash tuk e neshto, koeto mi beshe hrumnalo kak da bude napraveno (po drug, no shoden, nachin) predi okolo 2 sedmici, suotvetno go spodelih s nyakolko dushi s koito chesto obshtuvam v irc. Ideyata mi vse pak e bazirana na reportvane na spam, otkolkoto na avtomatichen podbor kakvo e spam i kakvo ne e. I tochno tova e neshtoto, koeto me pritesnyava - tova e da se ostavi edna mashina sama da precenyava dali edno suobshtenie e spam ili ne. Idiotite ot yahoo mail tvurdyat, che imali naj-dobrite spam filtri, yet inbox-a mi tam ima poveche spam ot junk foldera. Gmail-a opredeleno imat po-dobur filtur, no ot druga strana okolo 5% ot pismata mi otivat na greshnoto myasto.. t.e. spam v inbox-a i normalni pisma v spam-a.
Shto se otnasya do trenirovki v MT programming - zapadnoto obrazovanie vklyuchva podobni neshta oshte pri purviat kurs po C++ (v moiat sluchaj), kudeto se izuchava sushto taka i STL na dosta zadulbocheno nivo. V bulgaria pod C++ razbirat class declaration-a i eventualno nyakoj i drug primer s multiple inheritance (lichno vpechatlenie, koeto sum pridobil ot hora izuchavali C++ vuv VUZ v bg prez poslednite nyakolko godini i ne angajiram nikoj s tova mi mnenie) i koeto napulno izklyuchva dori i upomenavaneto na templates.
No da se vurnem na temata. Tova, koeto mi dojde naum e mechanizm pri kojto dori i normalen potrebitel bi mogul da relay-ne poluchen spam do opredelen service, eventualno za prostota posredstvom komanda ot sorta na /quote spam source target :message. Sled tova vaprosniat service v kombinacia s ostanalite irc serveri ot mrejata bi tryabvalo da moje da proveri dostovernostta na reporta i da vzeme nyakakvo preconfigurirano reshenie. Estestveno tazi schema bi pozvolila kakto MT (makar da mi se struva malko overkill), taka i izpolzvaneto na naj-razlichni "off the shelf" algorithmi za identificirane na spam, s edinstvenata razlika, che vaprosniat service shte e tozi, kojto shte harchi cpu, a ne irc serverite, koito spored ideyata mi shte harchat poveche ram za nyakakvo FIFO ili hash ot checksums. Tova bi bilo edin vid tvoiata ideya za "borba sus spama bez irc operatori" na nov glas
samo che s povishen koeficient na polezno dejstvie i pochti nulev shans za abuse (zloupotreba).
Inache, shto se otnasya za drugi planove.. kakto veche mitaka spomena, raboti se (predimno ot nego za momenta) po port-vaneto na nyakolko funkcii ot hybserv-a v rserv-a kato kill immed i unsecure, koito kakto izliza sa life-saving za "hi-asl-omg-lol" potrebitelite na tazi mreja, koito predstavlyavat po posledni statisticheski danni 49% ot potrebitelite na mrejata (49% se spodelyat m/u friendly bots, bnc's, drones i spambots, kato ostanalite 2% sa enforcement nicknames). Kakvoto dosega sme napravili kato novovuvedenie v rserv-a e do golyama stepen merge-nato s originalniat source, daje 95% ot bugfixes i novite features v originalniat rserv za poslednite 6-7 meseca idvat ot unibg, koeto predvid ogromnoto im kolichestvoto, zabavi release-vaneto na porednata stable versia s nyakolko meseca. V TODO listata na services vlizat oshte dosta drugi neshta, koito chastichno se pripokrivat s TODO listata na originalniat proekt. Obshto vzeto v rserv-a shte sa osnovnite promeni, koito predstoiat. Ircd-to e izbrano s cel da se sledvat lesno efnetskite releases, zashtoto poddurjaneto na minimalen patchset e neshto prosto. Sus services obache iavno nyama nachin vsichko da se poddurja minimalno. Patchset-a veche e dosta obemist dori i sega, a predstoi da raste i oshte.. Dano poveche ot neshtata budat merge-nati v originalniat rserv, zashtoto v momenta v kojto segashniat developerski ekip se razpadne i nyama koj da poddurja kakto services, taka i ircd-tata, unibg neminuemo otnovo shte popadne v dupkata ot koiato v momenta ia izmukvame.
