Batchyx a écrit 1261 commentaires

Référence nécessaire.

J'ai un service que je veut démarrer lorsque j'ai une route vers une IP, et que je veux arrêter lorsque je n'ai plus cette route vers une IP. Bien entendu je suis sur un pseudo "routeur", la route est dynamique.

Il gère ça le systemd ?

Et si jamais ça arrive, systemd n’enlève pas la possibilité d'utiliser des scripts SysV.

Quel est l'intérêt de systemd alors ?

par exemple, quand l'admin dit "je veux que ce logiciel tourne sans réseau", il fait abstraction de la méthode ( à savoir les namespaces réseau )

Cette abstraction ne tiens pas la route, vu que ce n'est pas Systemd qui configure le service, c'est moi.

Si je configure le service pour qu'il se connecte à localhost vers un autre service, le mettre dans un network namespace séparé ne marchera pas, sauf configuration particulière du namespace. Pourtant j'ai bien envie qu'il n'accède pas au réseau. Et j'ai pas envie qu'il accède à tout mes services locaux en plus.

Leaky abstractions. Il aurai mieux fallu ne rien abstraire du tout, tout expliciter et tout rendre configurable. Les systèmes magiques c'est peut-être mignons pour les desktop, mais ça n'a rien à faire sur un serveur.

Tu confonds "contraintes pour qu'un système démarre" et "contraintes pour qu'un systéme tourne sans jamais aucun souci".

Je ne fais pas de différences entre les deux, moi je veux un système qui marche. Si il merde au démarrage ou après, c'est déjà un échec, parce que ce système devait marcher.

Le problème, c'est juste que beaucoup de ces contraintes posent des problèmes au niveau du démarrage. Le service buggé qui supporte pas les changement d'heure doit être lancé après un ntpdate, et aucun autre logiciel ne doit changer l'heure après que l'autre ai démarré. Pareil pour l'autre contrainte qui implique de connaître tout les cwd des processus et les fichiers qu'ils peuvent garder ouvert.

Ça veut dire regarder absolument tout les logiciels qui tournent (même l'init) et savoir ce qu'ils font tous. S'il font tous ce que je demande, c'est cool. S'ils ne font pas ce que je demande, il va falloir que je les patche, et je préfère patcher du shell script plutôt que de patcher du C.

Et le syndrome de systemd qui consiste à uniquement regarder ce qu'on besoin 80% des personnes et a envoyer chier les autres ne simplifie vraiment pas le problème. Pour systemd, ils ont du regarder les besoins de la plupart des services et ils vont se dire qu'ils ne vont gérer que ces contraintes là, les autres pouvant aller se faire foutre. Pareil pour system-networkd: ils ont du rencontrer un admin qui leur à demandé une certaine liste de fonctionnalité et ils n'ont pas du se dire que peut-être un jour d'autres personnes auront d'autres besoins. On se retrouve avec des logiciels qui sont utiles que pour une certaines majorité de personnes qui viennent ensuite expliquer aux autres comment ils n'ont pas besoin des fonctionnalités qu'ils avaient avant.

systemd te fait abstraction de beaucoup de concepts

Il ne fait d'abstraction sur rien du tout: Ce n'est pas lui qui configure et gère les services, il ne fait que les lancer et les arrêter. Satisfaire les besoins et les dépendances d'un service restera à ta charge. Toutes les dépendances ne peuvent pas s'exprimer dans un unit systemd, certaines peuvent être particulièrement poilues comme "ce point de montage doit être démontable à n'importe quel moment", ou "ce logiciel ne supporte pas les changements d'heures".

Et si tu ne lit pas la documentation sur tout ton système et que tu ne regarde pas ce que fait chaque programme, tu peux toujours t'accrocher.

"Leaky abstractions" comme dirait l'autre.

Parce que systemd, tu sais pas ce qu'il fait, mais moi, Apache2, une fois que je lance le serveur, je n'ai aucune idée de ce qu'il fait dans mon dos, et au vu de la taille de la doc, y'a de quoi faire.

Je ne te confierai jamais l'administration d'une machine. Encore moins la conception d'un Linux embarqué.

Je demande pas non plus que tu puisse expliquer chaque instruction assembleur utilisée, mais dire que tu n'a aucune idée de ce que ton serveur HTTP fait (hors failles de sécurités), des requêtes qu'il accepte et des modifications qu'il peut faire à ton système, alors tu a juste construit un serveur qui est tombé en marche.

dans le cadre d'un système de démarrage cela fait sens.

Si systemd n'était qu'un système de démarrage, ça aurai un sens. Sauf que c'est pas le cas.

Le principe avec les unit files de systemd

C'est bien beau les principes, mais il faudrai regarder les faits en face: Toutes les distributions ne sont pas identiques, certaines vont vouloir privilégier la sécurité, d'autres vont vouloir privilégier la simplicité, la légèretée, le fait d'avoir un / read only ou qui supporte un nombre limité d'écriture, ou d'avoir des invariants folkloriques à respecter …

Tu va pas me faire croire que toutes les cas d'usages d'un démon se résolvent par un seul fichier d'unit unique. Si toutes les distributions passent à systemd, je te garanti qu'elles n'utiliseront pas les mêmes units. Si c'est le cas actuellement, c'est juste que toutes les distributions ne sont pas passées à systemd (heureusement).

L'apprenti systemv:
- Cherche sur le net (c'est pas faute de tenter de lui convaincre de lire la doc …)
- Tombe sur un mec qui lui apprend l'existence de rc.local. Ou de faire un script en partant d'un autre ou d'un skeleton, en remplacant NAME par le nom du programme.
- Le stagiaire choisi d'éditer rc.local, ça à l'air plus simple. Suffit juste d'entrer les commandes qu'il fait en console pour lancer le programme.
- Fini. C'est super moche, mais osef, si ça marche au premier boot, ça marche sur les suivants.

L'apprenti Systemd:
- Cherche sur le net plutôt que de lire la doc. De toute façon, la doc de systemd est en anglais, il y comprend rien. Malgré qu'on arrête pas de lui répéter que l'anglais dans l'informatique c'est obligatoire.
- Tombe sur un tutoriel écrit par un neuneu comme lui, et va recopier l'unit sans trop réfléchir, sur un service qui n'a peut-être pas les mêmes dépendances et qui nécessite pas la même chose pour démarrer.
- Si ça marche au premier boot, tant mieux. Pas dit que ça marche aux suivants. Si ça marche pas au premier boot, j'espère qu'il aura le réflexe de lire les logs, plutôt que d'utiliser la solution windowsienne qui consiste à essayer plein de trucs jusqu'à que ça marche.

Dans tout les cas, il fera de la merde. Faire un unit ou un script shell, c'est à laisser à des professionnels.

Vu autrement, tu demandes à un projet qui a 4 ans et qui va vite entre autre grâce à l'utilisation de choses faites ailleurs d'être aussi mature qu'un projet qui a mis 20 ans avant de se dire que le code standard ça serait bien.

Oui: un code moderne n'a pas à faire les mêmes erreurs qu'un code ancien.

Tu as 16 ans d'avance (ou pendant 16 ans tu as "oublié" de critiquer Linux à ce sujet).

Personnellement, je n'ai pas attaqué Linux il y a 16 ans, mais d'autres s'en sont chargés à ma place.

Encore une attaque qui sort du chapeau contre ce projet et seulement celui-ci.

Oui, parce qu'il y a bien que Lennart pour dire que la portabilité ça sert à rien, que la philosophie Unix est un échec, et d'autres types de conneries.

Après, à toi de convaincre de l'utilité pour le besoin aujourd'hui de systemd, sans pourrir les time to market.

Ah, ça y est, on en est là: Il faut absolument du time to market, y compris en pondant du code dégueulasse architécturé comme les téléphonistes le faisait même pas il y a 20 ans ?

Dans ce cas la, c'est plus simple alors, il suffit de prendre toutes les critiques que l'on peut faire à du code écrit par des entreprises plongées dans ce genre de foutaises et l'appliquer à systemd, ça sera plus simple.

Comme j'aurai pas besoin d'expliquer pourquoi un hippie comme Linus Torvalds viens dire que plus on porte vers d'autres architectures, plus on trouve de bugs qui affectaient les autres.

Je ne doute pas que le code d'Avahi soit complexe, la question est plutôt de savoir si celait pouvait l'être moins.

Le fait de réimplementer 5 fois des listes chaînées, des tableau dynamiques, de faire du gros copier-coller, d'avoir des mégafonctions ou de faire des API D-Bus imbitables (wrappées dans des bibliothèques que ceux qui viennent de l'API de l'implémentation d'Apple ne comprennent pas pourquoi elles sont aussi compliquées à utiliser), n'a absolument rien à voir avec les problèmes de portabilités entre les OS.

Sérieusement quoi, c'est un programme réseau qui envoie et reçoit des datagrammes multicast. l'API des sockets est définie par des RFC respectées sur quasiment tout les systèmes. Et, comme d'habitude dans un programme réseau, la partie qui les utilisent ne représente qu'une toute petite partie du code. Et il existe plusieurs bibliothèques portables qui permettent d'abstraire tout ça.

Toi pas comprendre. Linux compilera avec LLVM/Clang parce que Linux s'approchera du standard C99, pas l'inverse. Ça fait depuis longtemps que Linux n'accepte plus aussi facilement du nouveau code qui dépend d'extensions de GCC autres que celles qui sont wrappées dans des macros spécifiques au noyau qui permettent leur désactivation en un seul endroit.

Enfin bref, un projet de 1991 qui donne des leçons de portabilité à un projet qui date de 2010, ça fait toujours plaisir.

Avec le même travail systemd compilera avec LLVM/CLang.

Est ce que les mainteneurs de Systemd en ont simplement envie ?

Tu as déjà essayé de compiler Linux avec autre chose que GCC?

Des gens y travaillent, et ça va finir par compiler avec LLVM/Clang. Les extensions de GCC comme les VLAIS sont en train d'être remplacées par du C99 valide.

Par exemple, ça utilise largement des fonctionnalités de gcc pour nettoyer les variables automatiquement ( via l'attribut cleanup ) pour éviter les fuites de mémoires.

Ça présage bien de la qualité du machin. Moi j'ai pas besoin d'extensions à GCC pour faire la même chose: Ça s'appelle C++, c'est portable et ça existe depuis 1998, avec une mise à jour bien sympathique en 2011.

Mais bon, comme dirait l'autre, on peut programmer en fortran dans n'importe quel langage.

Techniquement, le grand père n'est pas impliqué: Si le père d'un zombie meurt , il sera rattaché directement au machin centralisé qu'est le PID 1, qui l'achèvera.

Mais ta conclusion reste parfaitement correcte.

C’est clairement indiqué que c’est pour les configurations simples.

ifupdown aussi c'est prévu pour les configurations simples, tout en étant extensible à l'infini avec des scripts. Et vu que ça laisse dhclient-script gérer DHCP, et bien ça juste marche. Et qu'on vienne pas me dire qu'ifupdown n'est pas documenté.

Non, t'a pas suivi: Systemd est bloat, system-networkd est non-maintenable.

Ah et j'ai regardé system-networkd, et je suis tombé sur le code qui gère la reception d'un lease DHCP: C'est un véritable retour en arrière par rapport à ce qui existe déjà: les seules options que ça supporte c'est d'avoir une adresse, un netmask, une gateway (alors qu'il peut y en avoir plusieurs), un hostname et des serveurs DNS (ouf ça en gère plusieurs).

Fin bref, au revoir les domaines, les suffixes par défaut, les routes statiques, et toutes les fonctionnalités de DHCP sorties après les années 2000. Même dhclient-script gère plus d'options que ça.

Et on veut mettre ça sur un serveur ?!?

On va prendre par exemple bind9. Dans le script de bind9, le script fait :
- l'ajout de localhost dans /etc/resolv.conf de façon conditionnel

Sans utiliser resolvconf ? Oh le bon vieux script que voila.

• le chargement d'un module ( capabilities )

Qui n'existe pas. On sent le script maintenu.

• la creation de /var/run/named

Ça par contre tu ne peux pas y couper. Si tu veux créer ce répertoire lors de l'installation du paquet, et bien ça marchera pas, point.

• vérifie que le réseau est configuré avant de lancer bind

Avec ifconfig en plus, quelle plaie. Personne n'a du retoucher ce script depuis des lustres.

On peut voir dbus. Il fait :
- création du repertoire pour le pid

Ça tu peux pas y couper.

• vérification si /proc est monté

Qui sert à rien, vu que ce script dépend de remote_fs, qui lui dépend plus ou moins directement de mountall.

• génere un fichier /etc/machine-id si absent

Fichier qui, si je me souviens bien, est également généré lors du postinst.

Enfin bref, les scripts d'init sont écrits par des abrutis, pourtant tu les comprend rapidement.

Ok, un autre script au hasard, celui de saslauthd. 400 lignes.

La logique de lancement d'un processus dans systemd: une fonction de 614 lignes, dont la longueur des lignes va jusqu'à 142 caractères. Et qui bien entendu appelle d'autres fonctions écrites dans le même style. J'ai besoin d'élaborer ?

Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.

La seule formation qu'un admin à besoin pour comprendre ça, c'est savoir lire du shell. De toute façon il faudra forcement qu'il en écrive un jour.

Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.

Comme systemd, quoi. Sauf que là c'est lisible.

Désolé, mais j'ai pas réussi à trouver de différences fondamentales entre le code d'Avahi et le peu de code de systemd que j'ai lu.

J'espère pour toi, pour être cohérant avec ce que tu dis, que tu es sous GNU Hurd et pas cette saloperie de bloat

Linux, bloat ? Va falloir me le démontrer ça. T'a un noyau avec moins de ligne de code compilées avec à peu près autant de fonctionnalités à proposer ?

et code non-maintenable

Quasiment toutes les fonctionnalités sont optionnelles, avec des API bien séparées entre les composants, et des modules chargeables délégués à l'espace utilisateur, comme beaucoup d'autres fonctionnalités d'ailleurs. Et la qualité du code est incomparable avec systemd ou la plupart des autres logiciels que tu utilise.

Argument sans fondement.

quel projet upstream pour systemd? Linux? (vu que systemd est pid 1…)

Gnome, X et bien d'autres. Faut sortir de ta grotte un peu.

Et t'es allé voir le code de systemd pour voir s'il était bloated ?
Je parie que non.

Non, j'ai déjà lu en long en large et en travers celui d'Avahi, et ça me suffit pour ma santé mentale. De ce que tu m'en décris, celui de systemd est similaire. Comme c'est surprenant.

Le jour ou je serait obligé d'utiliser systemd sur un système embarqué que je doit maîtriser entièrement, t'inquiète pas que je te le lirait le code source.

systemd, c'est un cœur simple, et une soixantaine d'utilitaires.

Comme Avahi ? Un bon gros cœur qui fait tout avec une API imbitable et des clients qui l'utilisent ?

Et si on regarde le code source, et qu'on regarde les fichiers sources les plus gros, aucune fonction ne dépasse les 40 lignes.

Facile de ne pas dépasser les 40 lignes quand on respecte pas les 80 caractères.

Non, vraiment, le code a l'air bon et bien compartimenté.

Avahi aussi est à peu près bien compartimenté aussi. Tellement bien compartimenté que chaque compartiment réimplémente sa liste chaînée et son tableau dynamique. Non mais sérieusement quel code de «¶ŋøߢ !

La documentation pour écrire un unit-file systemd est on ne peut plus simple. C'est même plus simple que d'écrire des scripts (ce qui était le but), et ça fonctionne sur des distributions différentes.

Moi je ne te parle pas d'écrire, je te parle de lire et de savoir exactement ce qui se passe lorsque ton système boote et quel impact peut avoir chaque dysfonctionnement. Il se passe quoi avec systemd si /etc/fstab est foutu ?

systemd est bien mieux documenté que ne l'était SysV.

le démon sysvinit est assez bien documenté moi je trouve. Les scripts shells le sont moins, mais quand le code source est lisible et bien plus petit que la documentation, je trouve pas ça franchement utile de documenter.

Par contre, on a pas à se taper des scripts à la con qui répètent de la logique entre eux (bloat).

Ce bloat peut se résoudre sans l'aide de systemd. Certaines distributions l'on déjà fait. Mais si on regarde bien, la plupart des scripts d'init font plus que lancer et tuer des démons.

Clair que les scripts bash qui se baladent et non facilement maitrisable sur qui fait quoi, c'est très maintenable.

Je sais pas de quel système tu parle (Android ?), mais chez moi les scripts d'init sont tous dans /etc/init.d, avec de la conf dans /etc/default. Chaque script d'init s'occupe d'une seule chose et s'exécute dans un ordre bien précis.

À te lire on dirait que bash est un objet quantique et que c'est le script d'init de cron qui configure le réseau.

Et si tu trouve que le code de systemd est plus maintenable que des scripts shells, et bien je veux bien te regarder.

tu parles bien des systèmes d'init avant systemd, on est d'accord?

Non, je te parle des 30000 lignes de code de systemd, là ou tout mon init.d (avec une bonne tétrachiée de démons et de conf, plus que sur un desktop normal) n'en fait que 10000, /etc/init.d/rc compris. Et bash reste bien plus lisible et plus compact que du C.

Sauf que la, c'est plus que l'init.

Pourquoi le code de systemd est plus gros que ce qui sert à démarrer absolument tout les démons et les fonctionnalités noyaux qui me servent sur mon système, qui tiens plus d'un hybride serveur-desktop que d'un serveur ou un desktop habituel ?

Si seul l'init t'interresse, la doc est moins bordélique (c'est pas du bash qui plante car tu n'es pas sur la bonne distro et que tu as pas pensé à la petite subtilité de la distro) et petite.

Genre il y a des distros sur lequel le language bash n'est pas le même ? Tu crois vraiment à ce que tu dit ?

Et moi je préfère lire un script de 3 pages que de lire 30 pages de doc.

Tes exemples ensuite n'ont rien à voir : Mac OS X est simple pour l'utilisateur, ça ne dit pas que ce qu'il y a dessous est simple.

C'est toi qui n'a rien compris: on me dit que pour que Linux soit utilisable, il doit être complexe. La réponse est non. Merci.

Et tu donnes d'ailleurs un très bon exemple : pour le moment, la charge de travail est pour le mainteneur de distro et les utilisateurs

La charge de travail de quoi ? De l'écriture du script d'init ? Désolé mais elle reviens à l'auteur upstream du démon qui doit fournir un script LSB (sous Linux). Libre aux distributions de patcher ce script si elles veulent améliorer les choses.

Moi, j'en ai marre qu'on dise qu'avant c'était trop génial, que c'était simple et que ça faisait tout ce qu'on attend d'un OS moderne.

Peut-être parce que c'était le cas ? Après si tu préfère les systèmes centralisés interdépendants qui gèrent 90% des services de la machine "parce que c'est plus simple" qu'un système ou on sépare les choses bien comme il faut dans des couches et/ou des processus séparés, je ne vois pas ce que tu fout sur Internet ou sur un système Unix (malgré ses origines téléphonistes chez AT&T).

Et ce n'est pas parce que systemd est à la mode chez les mainteneurs que ça le sera pour l'éternité. Les mainteneurs ne font généralement que suivre les projets upstreams: si Gnome veux du policykit, du consolekit et du systemd, alors les mainteneurs vont avoir tendance à intégrer policykit, consolekit et systemd plutôt que réimplémenter Gnome.

Dans ce cas là, c'est toute la fonctionnalité "imprimer sur une imprimante réseau" qui est inutile pour toi. Le fait qu'il y ai de la découverte via mDNS, via du cups en broadcast ou via de la découverte maison spécifique à une imprimante n'est qu'un dommage collatéral.

Est ce que je peux utiliser system-networkd sans utiliser systemd en PID 1 ?

Si oui, alors il s'agit d'un processus autonome qui peut être étudié séparément comme n'importe quel autre processus, et donc il n'y a pas besoin de chercher à comprendre comment systemd marche. Il suffit juste de regarder les interactions que ce démon à avec le monde extérieur, qui doivent se résumer à une socket rtnetlink, à forker un client dhcp et ptet à servir une API et/ou lancer des (séries de) scripts lancés lors d'événements. Un peu comme Network Manager dans le cas filaire, quoi (sans la socket vers udev, qui sert pas à grand chose dans le cas filaire). Et dans ce cas la, je vois pas pourquoi il y a systemd dans le nom.

Si non, alors il y a potentiellement des interactions cachées dont l'utilité ne saute pas au yeux pour un outil de configuration réseau et qui n'aident pas à la compréhension. Ça veut dire que si un jour ça marche pas, il va falloir que je comprenne comment systemd est censé marcher pour savoir comment system-netlinkd est censé marcher. Le fait que ça soit un processus séparé n'est qu'un détail d'implémentation, ça aurai pu être dans le PID 1 que ça aurai pas changé grand chose.

Mais vous en avez pas marre de cracher sur systemd, avec l'argument le plus pourri qui soit: "je n'y comprend rien !". Si tu n'y comprend rien, passe ton chemin ou documente-toi, mais ne vas pas dire que c'est nul parce que tu ne comprend pas.

En terme logiciel on appelle ça du bloat et du code non-maintenable. Et oui, c'est une critique parfaitement valide: si un logiciel qui est censé fournir une fonctionnalité simple se retrouve à être un monstre de complexité incompréhensible par un non-spécialiste parce qu'il fourni une masse de fonctionnalité en un bloc qui ne sont pas utiles pour tout le monde, alors oui il y a un problème.

Parce que avant, n'importe quel développeur pouvait se lire la doc d'inittab et les scripts d'init de son système (ou du système des autres) et comprendre immédiatement ce que est censé faire son système quand il boote. Il pouvait aussi lire le code du processus PID 1 qui n'est pas très gros. Certes ça ne lui servait pas à grand chose parce que ça faisait exactement ce qui était écrit dans la doc et ce qui pourrai être dans l'imagination du développeur si c'était lui qui devait le programmer.

Là on se retrouve à lire une quantité incroyable de documentation, et même en l'ayant lue, on peut encore en apprendre en lisant son code source gigantesque. C'est clairement pas idéal.

Pour faire de Linux un système enfin utilisable par tout le monde, il s'est complexifié.

C'est l'une des plus grosse foutaise que j'en ai marre d'entendre: l'utilisabilité d'un système n'a rien à voir avec sa complexité. Suffit de voir Windows et Mac OSX: il y en a un qui est plutôt complexe et l'autre qui est plutôt utilisable. Ou alors l'iphone qui était quasiment mono-tache. On peut remonter loin dans l'histoire de l'informatique, et ça restera le cas. Ceux qui disent le contraire ne savent juste pas modulariser du code ou n'ont juste pas envie.

Et si vous n'êtes pas content, faites du réseau en RS232 […]

T'est gentil mais j'utilise une configuration réseau bien plus avancée que ce que networkd peut actuellement fournir, et le tout uniquement avec ifupdown et /etc/network/interfaces sous Debian. Et ça c'est pour une machine filaire. Sur un portable, il me faut aussi un équivalent à guessnet, ce que le sois disant utilisable systemd-networkd ne fourni pas.

C'est absolument horripilant quanf tu es au boulot, qu'il y a des utilisateurs mac autour avec leur bonjour et que tu te retrouves avec plein d'imprimantes inutile et que tu ne peux pas forcement utilise.

Mauvais administrateurs, changer administrateurs. Si l'imprimante n'est pas utilisable out of the box, faut pas l'annoncer via mDNS.

C'est encore plus genant quand le systeme d'impression est centralise et que tu doives utilise une queue d'impression avec un login bien particulier.

Dans ce cas là, tu n'a pas besoin d'un démon cups local. Tu pointe juste ton client cups vers ton serveur central et puis c'est tout. C'est bien plus simple que de gérer un démon cups local qui rebalance sur un distant.

Tout le monde met le nom conseille par les IT et du coup tu sais jamais si l'imprimante que tu as utilise c'est celle que tu as configure toi.

Gné ?

Tres tres chiant! Il existe deux solutions: virer ce truc inutile qu'est avahi […]

Tu sais, tu peux aussi désactiver l'utilisation d'mDNS dans la conf de cups. Mais si tu n'a pas du tout besoin d'avahi, tu peux aussi le virer, pas comme Systemd.

Je vois pas en quoi c'est choquant, beaucoup d'imprimantes réseaux s'annoncent via mDNS, et c'est pratique comme fonctionnalité à utiliser. Si tu a une autre implémentation d'mDNS, tu peux la proposer à cups.

Et puis bon, cups ne dépend pas du démon Avahi, mais uniquement de ses bibliothèques mal foutues et pas très utiles qui servent juste à masquer une API D-Bus absolument horrible.