Szóval pl. az udev-nek miért kellett beolvadnia a systemd-be? Korábban systemd nélkül udev-et használtam, jó volt.
Miért lenne jobb, ha külön repóban lenne? :)
Disclaimer: a lentebb említett egyik projekt nevében sem beszélek, mind a saját véleményem.
És akkor a válasz: hogy működőképes termék legyen belőle. Szépen és jól hangzik a "jól definiált, standardizált interfészeken keresztül beszélgető komponensek" móka, ha ráérsz standardizálni az interfészt (és akkor az indulásra van több, egymással elvileg interkompatibilis implementációd), de egy idege a legtöbb sikeres projekt inkább integrálja a komponenseit (akár kód, akár deployment szinten) és saját hatáskörbe veszi azokat.
Mindig ezzel példálózom, de ott van a Samba. Működik a cucc, és azóta működik (azután jöttek ki alfából!), hogy dobták a kezdeti lelkesedést, hogy majd csak össze kell drótozni egy OpenLDAP-ot, egy Kerberost, egy Bind-ot és egy ntpd, aztán lesz AD DC. Aztán amikor ott volt, hogy jó, akkor az upstream projektekben ezt és ezt kéne módosítani, szépen jött a saját LDAP szerver (ma már portolhatnák OpenLDAP-ra, meg van hozzá benne a tranzakció kezelés, de már nem foglalkoznak vele), jött a saját szerverből futó, a kódbázisba bevágott Heimdal KDC (a RedHat-osok évek óta tolják MIT KDC alá és még mindig van egy csomó funkció, ami nem működik vele, pedig a Samba vonatkozó részét már átírták, hogy egy absztrakciós rétegen keresztül dolgozzon), egy darabig szórakoztak a fájl alapú DNS-sel, utána próbálták upstreamelni a DLZ módosításaikat a Bind-ba, de nem sikerült, úgyhogy lett saját DNS szerverük (utána release-re a Bind-ba bekerültek a DLZ patcheik, úgyhogy az is működik, pár év után meg dobták a fájl backendet a Samba-ból). És ezek csak a "külső" komponensek, a kódon belül kismillió esetben volt, hogy egy feladatra kerestek valami lib-et, volt 1-2-3 lehetséges, aztán írtak inkább sajátot.
Udev gondolom ugyanez lehetett pepitában: az integráláshoz mindkét irányú kommunikációra szükség van, ráadásul az udev-et fel kellett készíteni arra, hogy kövesse azokat a tulajdonságokat, amikre a systemd-nek szüksége van (újfent: fejből a seat management-et tudnám mondani). Meg lehetett volna úgy oldani, hogy minden udev -> systemd irányú adatközlésre csinálnak egy futtatható fájlt, a vonatkozó udev rule-ok meg kapnak egy EXEC-et, visszirányban meg ad az udev valamilyen interfészt. Mit értek volna el vele? Ugyanúgy meg lenne a coupling a két komponens között, mindkét komponens pontosan egy implementációval rendelkezik (*: az integrálás után forkolták az eudev-et!), tehát lenne egy felesleges interfész (ill. kettő, mert mindkét irány játszik)...
És félre ne érts, én is szerencsésebbnek tartanám, ha szép, tiszta, egységes interfész lenne minden között is. Viszont lássuk be, minden interfész úgy működik, hogy vagy az egyik fél diktál (esetleg enged), vagy bikesheddingbe torkollik vagy ad absurdum a használhatatlanságig elabsztrahálják.
BlackY