The backends are a single executable application containing the following DBus Objects
Objets qui doivent gérer les utilisateurs et groupes, la résolution de nom, la configuration des interfaces réseaux, les montages NFS, la synchronisation NTP, la configuration du démarrage des services, la configuration de samba, la gestion du temps…
Enfin bref, n'importe quel programmeur sérieux ne mettrai JAMAIS toutes ces fonctionnalités là dans UN SEUL programme. Et quand même, on touche à la configuration du système là, on peut facilement péter le boot avec ces choses là. Ce n'est vraiment pas quelque chose à prendre à la légère.
Il y a pas si longtemps, j'expliquai déjà pourquoi on voudrai pas refaire des utilitaires ifconfig/route qui utiliserai les nouvelles API du noyau, puisque ces nouvelles API ont des fonctionnalités supplémentaires qui n'ont pas d'équivalents en ioctl, et que la question de savoir si il faut écraser, ignorer ou bidouiller les fonctionnalités supplémentaires était loin d'être évidente.
Mais là, quand je vois les paramètres réseaux qui doivent pouvoir être changés pour une carte ethernet via cette interface D-Bus, c'est à se tirer une balle :
Integer32 Whether the interface is enabled
Integer32 Whether the interface is enabled automatically at boot time
Integer32 Method to obtain the IP address (Static IP, DHCP)
String IP address
String Network mask
String Network base address
String Broadcast address
Même ifconfig à plus de fonctionnalités que ça. Parce que là, IPv6, on oublie, ça n'existe pas. Ajouter une gateway par défaut en statique ? C'est quoi une gateway ? Passer des paramètres à DHCP ? Mais pourquoi faire ?!?.
Et je vous parle pas des autres types d'interfaces (genre Wi-Fi) ni du comportement du code pour modifier la configuration (dans les distribs que je connais en tout cas), parce que là, c'est tout simplement dangereux. Parce que par exemple, sous Debian, s'il voit des options qu'il ne connaît pas, il les écrases et remet des options par défaut, et cela, dans un fichier ou c'est explicitement indiqué qu'aucune application n'a le droit de modifier automatiquement. Et ce n'est que la partie "configuration des interfaces réseaux". (parce que, juste comme ça, il y a aussi un autre logiciel pour gérer la configuration réseau. Il manque un peu de fonctionnalités, mais il en supporte nettement plus et il couvre plus de cas d'utilisation. C'est un petit logiciel peu connu qui s'appelle NetworkManager. Ça couvre pas la moitié des fonctionnalités dont j'ai besoin chez moi, mais c'est largement suffisant pour bien d'autres utilisateurs. D'ailleurs je crois même que c'est intégré dans Gnome).
Et si on veut revenir à la gestion des fuseaux horaires, je ne vois pas pourquoi un utilisateur devrai forcement utiliser le fuseau horaire du système. Surtout en 2012.
Franchement, Une abstraction dans ce cas la, c'est non. Surtout dans un cas pareil, ou on est typiquement dans le cas ou chaque pourcentage d'utilisateurs à besoin d'une fonctionnalité particulière de sa distribution. Soit cette abstraction supporte toutes les fonctionnalités des distributions supportées et les programmes qui utilisent ces abstractions sont des monstres quasiment spécifiques à là distribution (ce qui est un peu le contraire du principe d'une abstraction), Soit elle sera inutile pour une partie des utilisateurs, et écrasera ou ignorera des options de configuration, alors que ces options étaient peut-être là pour une raison.
Au final, c'est soit dangereux, soit inutile. Vouloir faire des abstraction pareilles sur des méthodes de configurations alors que ça fait partie des raisons pour laquelle il y a différentes distributions, c'est vraiment idiot, et l'échec est prévisible. C'est à la distribution de faire l'intégration, pas à upstream.
[^] # Re: Irrémédiable
Posté par Batchyx . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 10.
Oui c'est du poulet :
Objets qui doivent gérer les utilisateurs et groupes, la résolution de nom, la configuration des interfaces réseaux, les montages NFS, la synchronisation NTP, la configuration du démarrage des services, la configuration de samba, la gestion du temps…
Enfin bref, n'importe quel programmeur sérieux ne mettrai JAMAIS toutes ces fonctionnalités là dans UN SEUL programme. Et quand même, on touche à la configuration du système là, on peut facilement péter le boot avec ces choses là. Ce n'est vraiment pas quelque chose à prendre à la légère.
Il y a pas si longtemps, j'expliquai déjà pourquoi on voudrai pas refaire des utilitaires ifconfig/route qui utiliserai les nouvelles API du noyau, puisque ces nouvelles API ont des fonctionnalités supplémentaires qui n'ont pas d'équivalents en ioctl, et que la question de savoir si il faut écraser, ignorer ou bidouiller les fonctionnalités supplémentaires était loin d'être évidente.
Mais là, quand je vois les paramètres réseaux qui doivent pouvoir être changés pour une carte ethernet via cette interface D-Bus, c'est à se tirer une balle :
Même ifconfig à plus de fonctionnalités que ça. Parce que là, IPv6, on oublie, ça n'existe pas. Ajouter une gateway par défaut en statique ? C'est quoi une gateway ? Passer des paramètres à DHCP ? Mais pourquoi faire ?!?.
Et je vous parle pas des autres types d'interfaces (genre Wi-Fi) ni du comportement du code pour modifier la configuration (dans les distribs que je connais en tout cas), parce que là, c'est tout simplement dangereux. Parce que par exemple, sous Debian, s'il voit des options qu'il ne connaît pas, il les écrases et remet des options par défaut, et cela, dans un fichier ou c'est explicitement indiqué qu'aucune application n'a le droit de modifier automatiquement. Et ce n'est que la partie "configuration des interfaces réseaux". (parce que, juste comme ça, il y a aussi un autre logiciel pour gérer la configuration réseau. Il manque un peu de fonctionnalités, mais il en supporte nettement plus et il couvre plus de cas d'utilisation. C'est un petit logiciel peu connu qui s'appelle NetworkManager. Ça couvre pas la moitié des fonctionnalités dont j'ai besoin chez moi, mais c'est largement suffisant pour bien d'autres utilisateurs. D'ailleurs je crois même que c'est intégré dans Gnome).
Et si on veut revenir à la gestion des fuseaux horaires, je ne vois pas pourquoi un utilisateur devrai forcement utiliser le fuseau horaire du système. Surtout en 2012.
Franchement, Une abstraction dans ce cas la, c'est non. Surtout dans un cas pareil, ou on est typiquement dans le cas ou chaque pourcentage d'utilisateurs à besoin d'une fonctionnalité particulière de sa distribution. Soit cette abstraction supporte toutes les fonctionnalités des distributions supportées et les programmes qui utilisent ces abstractions sont des monstres quasiment spécifiques à là distribution (ce qui est un peu le contraire du principe d'une abstraction), Soit elle sera inutile pour une partie des utilisateurs, et écrasera ou ignorera des options de configuration, alors que ces options étaient peut-être là pour une raison.
Au final, c'est soit dangereux, soit inutile. Vouloir faire des abstraction pareilles sur des méthodes de configurations alors que ça fait partie des raisons pour laquelle il y a différentes distributions, c'est vraiment idiot, et l'échec est prévisible. C'est à la distribution de faire l'intégration, pas à upstream.