http://www.mail-archive.com/cryptography@metzdowd.com/msg07606.html
http://en.wikipedia.org/wiki/Intel_Active_Management_Technology
Zlouporaba sklopovske virtualizacije ili NGSCA modula je ništa prema ovome. Ovo je dostupno već danas, i radi kao curica, neovisno o OS-u (SOAP - dakle XML!) i direktno komunicira sa MMU/CPU/NIC sklopovljem.
Slammer 2, here I come..
Jako je zanimljivo kako zaista malo programera i programskih inženjera razumije zašto ustvari koristimo Veliko-O (Big-O) notaciju u svrhu označavanja asimptotske gornje granice funkcije. Dobar ih dio u podne i ponoć zna izrecitirati formalnu matematičku definiciju za veliko i malo O, thetu, omegu i tildu ~, kao i odokativno procijeniti vremensku složenost nekih jednostavnijih algoritama s kojima se susretnu u praksi - no pravi razlozi korištenja takve asimptotske definicije im, izgleda, ostanu vječna enigma.
Stvar je inače jako jednostavna: u računskoj teoriji složenosti postoji jedno teoremče koje slovi kao Teorem o linearnom ubrzanju (linear speedup theorem) i formalno se može iskazati ovako:
Za proizvoljan rekurzivan (odlučiv) jezik L i za svaki Turingov stroj T koji ga odlučuje, za neku realnu nenegativnu konstantu c, postoji Turingov stroj S nad istom abecedom koji odlučuje L i za kojeg vrijedi:
timeS(n) ≤ c*timeT(n) + n, ∀n∈ N
Drugim riječina, za bilo koji TS koji rješava problem rabeći f(n) resursa, postoji stroj koji rješava isti problem u c*f(n) resursa, za c>0. To je razlog zašto se linearni faktori u konačnici ignoriraju i koristimo Veliko-O notaciju definiranu preko limesa.
Postoji još i općenitiji teorem o ubrzanju (speedup theorem) koji govori samo o postojanju ubrzivog jezika i koji nije primjenjiv samo na odlučive jezika, kao što je slučaj sa teoremom o linearnom ubrzanju. Za dokazivanje teorema koji bi za proizvoljani odlučiv jezik pokazao postojanje više od linearnog ubrzanja ne bi ginula Turingova nagrada ;)
Kvadratno se ubrzanje za neke klase algoritama (Groverov algoritam pretrage) može ostvariti kvantnim računalima, poput onoga kakvog je prototipno konstruirala kompanija D-Wave. Općenito se može pokazati da bilo koji problem koji može biti riješen brute-force pretragom slučajno odabranih instanci, može kvadratno ubrzati
na koje naletih baš danas:
http://www.xml.com/ldd/chapter/book/ch04.html
Many readers may be wondering why the kernel does not have any more advanced debugging features built into it. The answer, quite simply, is that Linus does not believe in interactive debuggers. He fears that they lead to poor fixes, those which patch up symptoms rather than addressing the real cause of problems. Thus, no built-in debuggers.
http://osdir.com/ml/sysutils.autoconf.general/2004-09/msg00086.html
Please do not port software to Windows, or, by extension, assist in
porting software to non-free operating systems. While GPL licensed
software specifically permits this, DON'T DO IT AND DON'T HELP. Making
Windows more usable gives users less reason to switch to free software
and more reason to continue funnelling time, effort and money into
people and companies who take away freedom at every opportunity.
Genijalno! :)
UNIX sistemski filter jest bilo program koji čita sa standardnog ulaza i piše na standardni izlaz. Obično se ulančavaju cjevovodima u shellu (koji su pri tome, kao što je Oleg Kiselyov jednoć pokazao, pri tome monadi!), filtar se nazivno promovira u koproces u trenutku kada isti program generira filtrov ulaz i čita mu izlaz, efektivno ga utilizirajući kao subsidijalnu računsku jedinku.
Iako popularniji shellovi ne podržavaju izravno koprocese (pingvinski bash/sh/csh), neki kao ksh jesu, i to uz poprilično gadnu sintaksu. No svejedno, sa stajališta sistemskih programa, koprocesi su jako korisna koncepcija. Obično ih ostvarujemo kreiranjem po para jednosmjernih (unidirekcionalnih, half-duplex - iako POSIX.1 dozvoljava ali ne zahtijeva full-duplex) cjevovoda (pipes), koje u roditelju otvaramo za čitanje/pisanje, dok u forkanom djetetu u kojem exec*-amo koproces komplementarno za pisanje/čitanje.
U 5. labosu iz kolegija Operacijski Sustavi 1, koncept se koprocesa rabi za provjeru ispravnosti korisničkih aritmetičkih izraza, projvjeravajući njihovu validnost i krajnji rezultat transparentno preko bc(1) koprocesa. Sva rješenja dotičnog zadatka koja sam ja vidio od svojih kolega, a bome i primjeri koji su asistenti-pingvini dali na većspomenutim stranicama, imaju jedan kritičan race condition.
Naime, problem leži u standardnoj I/O buffering polisi, koja se programski dade kontrolirati (sa setvbuf(3), odnosno eksplicitnim fflush(3)-anjem nakon svakog pisanja), no to postaje malo nedohvatljivo u slučaju pretkompiliranog binarya kojeg ne možemo izmjeniti (bar ne koristeći neki platformski-nezavisan POSIX-kompatibilan način). ISO C zahtijeva sljedeće buffering karakteristike:
Ovo, međutim, ne kaže mogu li stdin/stdout biti unbuffered ili linijski bufferirani ukoliko su vezani za interkativni uređaj, kao i treba li stderr biti unbuffered ili linijski buffered. Većina implementacija (POSIX je specifikacija, ne implementacija!) po defaultu koriste sljedeće tipove:
Standardni ulaz i izlaz koprocesa evidentno nisu vezani za terminal - i tu leži problem. Oni read(2)-ovi na izlaz iz koprocesa mogu potencijalno zauvijek blokirati pozivatelja koji čita sve dok ne dobije '\n' (bez obzira čak i ako koristimo neblokirajuće čitanje u petlji - još gore, sad imamo livelock!). Pozivatelj čeka na izlaz iz koprocesa, koproces čeka na ulaz iz pozivatelja, I/O podsustav čeka da u potpunosti bufferirani izlaz iz koprocesa pređe predefinirani prag popunjenja pa da ga može flushati i poslati pozivatelju - deadlock smrdi na kilometar.
Teži način rješavanja ovog potencijalno cirkularnog čekanja jest pokretanje koprocesa pod pseudoterminalom kojeg ustvari exec*-amo i koji najposlije pokreće koproces. Pisanje drivera za vlastiti pseudoterminalni uređaj je netrivijalno (dobro ne baš toliko teško, ali u svakom slučaju previše za nekoga tko samo želi naučiti elementarne IPC koncepte, a osim toga postoje i začkoljice o tome radi li se o BSD ili SystemV...), iako dakako postoje već gotova rješenja na netu.
Drugi je, lakši i hax0rskiji način, redefinirati isatty(2) tako da uvijek vraća istinu:
_isatty(int fd) { return 1;}
cc -G moj_isatty.c -o moj_isatty.so -Kpic
i potom na Solaris kanti na pinusu (naziv studentskog stroja) dinamički linkati na tu verziju podešujući okolinu koprocesa (odmah nakon forkanja):
LD_PRELOAD=/path/to/moj_isatty.so
