To vypadá jako spousta práce, ale taky hezké výsledky. Díky za článek a vhled.
Dalo by se nějak zhodnotit, jak se projekt programuje? Kde jsou nástrahy? Kolik kódu je jak starého např. pomocí https://github.com/erikbern/git-of-theseus
A určitě otravná, ale zajímavá otázka - pomohl by v takovém projektu Rust? (Nemyslím to nijak ideologicky, nejde mi tu o nějakou hypotetickou lepší bezpečnost, ale spíš efektivitu vývoje.)
> Dalo by se nějak zhodnotit, jak se projekt programuje?
Přesně nevím, na co se ptáte. Programuje se jako každý větší starý komplexní vícevláknový program. Něco se programuje dobře něco špatně a něco je vyloženě peklo. Moderní nástroje to trochu ulehčují (ASAN, TSAN, UBSAN, různé statické analyzátory kódu).
> Kde jsou nástrahy?
Vícevláknové programování (synchronizace data a memory reclamation) je složité, ale většina chyb, kterou dnes máme je buď nějaká edge condition ve state machine DNS, nebo případně různé amplifikace, kdy na jeden příchozí packet se resolver snaží až moc a vygeneruje jich příliš odchozích kvůli různým přesměrováním, CNAME apod.
> Kolik kódu je jak starého např. pomocí https://github.com/erikbern/git-of-theseus
Tak ostatně tohle si asi můžete pustit nad repozitářem i sám. Jenom upozorním, že dřívější vývojový model byl nad CVS, pak už nad gitem, ale ve starém modelu, takže co se týče autorů kódu, tak je to relevantní až cca od března 2018.
> Ad Rust
Tím jsem se již nejednou zabývali, nějaké poznámky jsou tady: https://gitlab.isc.org/isc-projects/bind9/-/wikis/A-few-thoughts-on-Rust-in-BIND, ale v zásadě bychom museli jít modelem "všechno nebo nic", a vzhledem k tomu, že většina chyb, které v kódu jsou nejsou "memory-safety", tak ten přínos použití Rustu je diskutabilní.
Tady jsem ještě uložil ty grafy z git-of-theseus:
https://gitlab.isc.org/isc-projects/bind9/-/wikis/Git-Of-Theseus
Jak jsem již říkal, tak authors tam nedávám, protože to jednak nedává smysl, a jednak nemáme úplně přesně poznačené commity s automatickým refaktoringem, které také významně zkreslují výsledky.