• [^] # Re: Irrémédiable

    Posté par . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 9.

    Et ifupdown supporte quel pourcentage des fonctionnalités du système ?

    100%

    ifupdown c'est le genre de logiciel UNIX bien conçu dont Gnome devrai s'inspirer un peu. De base c'est juste un logiciel qui garde un état des interfaces entre "configuré" et "pas configuré", qui maintient une correspondance "nom de la configuration interface", et qui propose un framework pour configurer et dé-configurer une interface. De base, il supporte peu d'options. Et pour gérer ce peu d'options, ifupdown utilise, à sa compilation, un méta language de programmation (les fichiers dfn si je me souviens bien) prévu pour être modifié par les mainteneurs de la distributions. Et si les choix qu'à fait ta distribution dans ces fichiers dfn te plaisent pas dans un cas particulier (ou pas), tu à le mode manual qui ignore ce qu'à fait ta distrib, et te laisse le refaire toi-même.

    Et vu que les options gérées de base sont ridicules (du même genre que la conf réseau de ce bouzin, quoi que, ifupdown supporte au moins une passerelles par défault en statique), ifupdown va utiliser des hooks qui peuvent être des scripts ou des programmes pour supporter plus d'options. Ces hooks peuvent soit être écrits par des administrateurs géniaux, soit être installés par d'autres paquets de la distributions pour étendre/intégrer un autre logiciel à ifupdown. Ce qui fait que mon ifupdown sur mon système Debian supporte le wakeonlan, les vpn, le wifi et bien d'autres choses encore, sans que j'ai besoin d'écrire de scripts. J'ai quand même des scripts dans tout les sens pour jouer avec des politiques de routages dans tout les sens, et je peux supporter absolument tout ce qui existe si j'en ai envie.

    Bon après, c'est pas forcément la panacée non plus, il n'y a pas de moyen de savoir quel options sont disponibles (ifupdown se contente simplement de prendre toutes les "option valeur" et de les mettre dans des variables d'environnement IF_OPTION=valeur, et chaque script utilise les variables qui l'intéressent) ce qui rend par exemple la détection d'erreur de nom d'option plus compliquée ou la création d'une GUI plus difficile. Mais ces problèmes peuvent quand même être résolus par la distribution.

    Mais bon, on à quand même un logiciel intégrable, extensible à la sauce UNIX, qui n'est pas bien compliqué à comprendre, qui plaît aux admins et qui ne déplaît pas vraiment aux admins débutants. Après il n'y a pas d'interface graphique, mais ça n'empêche pas la distribution d'en faire.

    Après je ne dit pas que ça ne peut marcher qu'avec une poignée de distribs, je dit justement que ça ne marche qu'avec une poignée de distribs ACTUELLEMENT, que c’est un FAIT, et qu'aujourd'hui on a la capacité avec dbus et une norme freedesktop de changer ça pour avoir un vrai gestionnaire de réseau graphique.

    C'est un fait, mais je te dit que c'était prévisible. Pour ton abstraction de configuration de distributions différentes, tu ne peux pas à la fois :
    * Fonctionner avec toutes les distributions.
    * Avoir une API facile à utiliser.
    * Ne pas casser le système si des options configurées par ailleurs sont ignorées, écrasées ou modifiées.

    Tu ne peux pas en avoir plus de deux. Si tu à une API facile à utiliser et que tu possède assez d'options pour pas beaucoup casser le système avec des options que tu ne gère pas, tu ne pourra pas étendre ça à toutes les distributions, sinon tu va devoir rendre ton API plus compliquée.

    Là on est plutôt dans un cas ou tu à une API facile à utiliser, ou tu supporte plein de distribution et ou tu casse le système vu comment ça jongle avec les fichiers de configuration d'ifupdown, au moins.