> a v cem jsi to psal ty? no ja to napsal v jdk1.5, ale mel jsem si to hodit jako cviceni ve smalltalku, uz jsem dlouho v nem nic nedelal a potreboval bych refresh, je to fajn jazyk.
jinak je to malinky, snadno se mi bude delat udrzba, pokud vubec bude nekdy potreba. Je to kompletni dns bez AXFR/IXFR, DNSSEC a loadovani souboru v bind formatu (to asi jeste dodelam abych tim mohl nahradit stavajici bind instalaci). kod: 58KB (including javadoc), 1886 java asm instrukci testsuite: 65KB 2994 java asm instrukci, 125 testu test coverage 99,6% Takhle nejak si ja predstavuji kvalitni moderni program. male, otestovane, zdokumentovane, multithreaded, realtime grafy pres monitoring v jconsoli. Pokud jde o rychlost je to rychlejsi a docela prekvapive o dost nez bind/djbdns a to i na singlecore cpu Rychlosti myslim pocet microsekund wall clock nez dorazi po lokalni siti nazpet odpoved na dns dotaz mereno prumerem median. S MT bindem jsem to na niagare zatim netestoval. spotreba pameti moje 13.5 mb, djbdns ma 4.3mb > mluvit o nizky bezpecnosti ci velky chybovosti ve spojeni s kodem od > DJB se mi zda trochu troufaly. Ja jeho kod neznam, ale co jsem cetl tak tam > bylo chyb minimum, a z toho zadna security buga. Kolik chyb jsi tam objevil? v djbdns jsem nasel 2 mozna 3 chyby, zadna security. Ale ja jsem myslel celkove TCO, i kdyby byl djbdns 100% bugfree a 100% security hole free, tak porad: 1. neumi native ipv6 2. problematicka licence, problemy s distribuci patchnute verze 3. nema to testsuite 4. single threaded 5. zprasenej kod 6. pouziti neni moc user friendly 7. zadna dokumentace k kodu 8. je to C, t.j. programovani vyzaduje zvysenou pozornost vzhledem k malloc(), free(), pointerum. 9. testovani vsech codepath v C je problematicke jelikoz vyzaduje specialni tooly. Proto se to v C prakticky vubec nedela. 10. problem s konflikty nase patche vs cizi djbdns patche. proste celkove TCO spojene s patlanim patchu do djbdns bylo prilis vysoke a patche jsou potreba pac bez nich neni IPv6 a spousta jinych veci. Tak jsem se rozhodoval mezi portnuti patchu do bindu vs vlastni DNS a vlastni dns to vyhral z duvodu ze si budu moci napsat i svuj sql backend. Do bindu existuje jen jakysi postarsi sql backend, ktery je dost let unmaintained, nemoderni a jeho autor mi na maily neodpovida. Jsou sice i jine dns s SQL backendem, ale nemam informace o tom jak moc jsou bugfree, abych si je mohl dovolit dat do produkce. Naproti tomu muj shining new SQL backend ma v db trigger a kdyz ji nekdo aktualizuje, tak se o tom server hned dozvi a znovu nacte zonu a prekontroluje i serial number, zda se zvysilo. Odpadaji tak m.j. starosti se zapomenutym rndc reload. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l