Elaboratores administratoris systematis systemd de minuendis dependentiis a bibliotheca libsystemd disputant, quae non solum cum componentibus systemd sed etiam cum multis applicationibus externis coniungitur. Exempli gratia, in Fedora, plus quam 150 fasciculi in libsystemd ut dependentia nituntur. Auctor disputationis credit additionem bibliothecarum tertiarum partium ad libsystemd, quae a creatoribus systemd non reguntur, superficiem impetus significanter augere si bibliotheca tertia partis compromittitur, ut cum bibliotheca liblzma accidit.
Praeter liblzma et glibc, libsystemd etiam bibliothecas libzstd, liblz4, et libgcrypt onerare solet, et securitatem harum bibliothecarum conservare magni momenti est. Libsystemd aditum ad duodecim API principales praebet (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path, et sd-resolve). Hoc condicionem creat ubi applicatioβexempli gratia, quae libsystemd utitur tantum ad sd_notify vocandum ad systemd de mutatione status certiorem faciendum vel sd_journal ad data in acta scribendaβcum omnibus aliis bibliothecis et tractatoribus API connectitur. Solutio proposita est libsystemd in plures bibliothecas separatas dividere quae pro specificis API responsabiles sunt, permittens ut dependentiae tertiae partis tantum ubi opus est onerentur.
Fabricatores systemd putant divisionem horum tractatorum impracticum esse, cum tractatores in libsystemd praesentes inter se conexi sint. Divisio eorum magnum laborem requireret et vel ad iacturam efficientiae vel ad necessitatem duplicationis codicis duceret. Ad vestigium memoriae reducendum, libsystemd nuper mutationem adoptavit ut bibliothecas liblzma, libzstd, et liblz4 dynamicΔ oneraret utens dlopen() cum earum functiones vere necessariae sunt. Similis mutatio pro libgcrypt in proxima versione implementabitur.
Haec solutio reprehensa est quia, loco nexus expliciti et visibilis, bibliothecae tertiae partis nunc implicite onerabuntur, diagnostica complicata cum nexus inter invocationes API libsystemd et functiones ex bibliothecis externis obscurus sit. Mutatio ad onerandum per dlopen() ipsa architecturam non mutat; tantummodo componentes externos a curatoribus et usoribus celat.
Lenart Poettering vehementer adversatus est ideae dividendi libsystemd in plures bibliothecas, cum talis motus communicationem codicis intra systemd magnopere complicaret et omnes tractatores internos publicos reddere vel separatim eos in singulas bibliothecas statice compilare requireret. Prius difficultates in conservanda stabilitate API et spatiis nominum crearet, dum posterius magnitudinem propter duplicationem codicis augeret.
Lenart credit optimam rationem esse bibliothecas externas tantum cum necesse est onerare, ut in proxima versione implementatum est. Problema complicationis processus acquirendi notitias de bibliothecis dynamicis oneratis proponitur ut solvatur addendo campos additionales fasciculis ELF cum informatione de talibus dependentiis dynamicis, quae a debugatoribus tractari et in exitu utilitatis readelf ostendi possunt.
De coniunctione magni numeri applicationum cum libsystemd, Lenart commendavit ut fabricatores applicationum vitarent onerationem libsystemd pro una functione, sed implementarent tractatorem protocolli in gradu applicationis. Exempli gratia, implementatio sd_notify() satis facilis est et perfici potest paucis lineis codicis cum sockets UNIX (AF_UNIX) utuntur. Similis implementatio separata sd_notify pro OpenSSH ab anno 2017 praesto est et nuper in ramum portabilem OpenSSH 9.8 accepta est, cuius emissio media aestate exspectatur.
Source: opennet.ru
