Network-manager peut le faire sur les distributions RHEL et Fedora, donc le souci est plutôt "pourquoi ubuntu et debian ne le font pas".
( https://live.gnome.org/NetworkManager/SystemSettings , cherche 'ifcfg-rh' ).
Transformer les scripts shell en un format hybride ne me parait pas une idée terrible, ne serais que parce ça implique d'avoir le choix entre un parser ultra complexe, ou d'avoir un sous ensemble et donc ne pas être un script shell ( genre, comment tu géres des choses comme toto=$(foo) dans ta config du coté de n-m ). Si le but est d'avoir une configuration qu'on peut lire et écrire, il y a encore une fois déja un plugin ( keyfile ).
Ensuite, Network Manager ne va pas lancer X executables pour changer le réseau quand il peut directement parler au noyau, pour plus de finesse et un meilleur résultat. La façon principale de parler au kernel, c'est des ioctl ( ou écritures dans /proc/ et /sys/ ), pas des outils comme ifconfig ou ip. Les premières sont censé être stable, alors que les 2emes sont la pour les humains et n'ont pas de promesse de stabilité ( d'un point de vue de l'abi ). Les remontés d'erreurs sont assez difficile à faire quand tu n'a pas d'ABI ( ie, pas de standard des codes retours, pas de messages ou de précision sur ce qui ne va pas ).
Il est bien plus simple en C ou n'importe quoi d'autres de pas avoir à faire de parsing que d'avoir à en faire. Surtout quand les outils disent de pas le faire ( genre iwconfig à un moment ).
Ensuite, relancer tout le réseau pour juste un changement est inutile. Si je change le mtu de ma carte ethernet, pourquoi est ce que je devrait relancer network ? Et pourquoi lancer un processus quand on peut éviter ? Ça pose aussi des soucis d'atomicité, si je change juste un paramètre, et qu'il est faux, je dois annuler tout ce qui a été fait avant. Ce n'est pas une chose que les scripts font actuellement.
Enfin, il est plus sur d'appeler directement le noyau plutôt qu'un executable, car les interfaces de communication sont bien plus stricts ( exemple, il y a pas besoin de se casser la tête sur "est ce que le path est correct, est ce que j'ai pas oublié d'échapper un truc".
[^] # Re: Point de vue rétro-actif de noob.
Posté par Misc (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 0.
Network-manager peut le faire sur les distributions RHEL et Fedora, donc le souci est plutôt "pourquoi ubuntu et debian ne le font pas".
( https://live.gnome.org/NetworkManager/SystemSettings , cherche 'ifcfg-rh' ).
Transformer les scripts shell en un format hybride ne me parait pas une idée terrible, ne serais que parce ça implique d'avoir le choix entre un parser ultra complexe, ou d'avoir un sous ensemble et donc ne pas être un script shell ( genre, comment tu géres des choses comme toto=$(foo) dans ta config du coté de n-m ). Si le but est d'avoir une configuration qu'on peut lire et écrire, il y a encore une fois déja un plugin ( keyfile ).
Ensuite, Network Manager ne va pas lancer X executables pour changer le réseau quand il peut directement parler au noyau, pour plus de finesse et un meilleur résultat. La façon principale de parler au kernel, c'est des ioctl ( ou écritures dans /proc/ et /sys/ ), pas des outils comme ifconfig ou ip. Les premières sont censé être stable, alors que les 2emes sont la pour les humains et n'ont pas de promesse de stabilité ( d'un point de vue de l'abi ). Les remontés d'erreurs sont assez difficile à faire quand tu n'a pas d'ABI ( ie, pas de standard des codes retours, pas de messages ou de précision sur ce qui ne va pas ).
Il est bien plus simple en C ou n'importe quoi d'autres de pas avoir à faire de parsing que d'avoir à en faire. Surtout quand les outils disent de pas le faire ( genre iwconfig à un moment ).
Ensuite, relancer tout le réseau pour juste un changement est inutile. Si je change le mtu de ma carte ethernet, pourquoi est ce que je devrait relancer network ? Et pourquoi lancer un processus quand on peut éviter ? Ça pose aussi des soucis d'atomicité, si je change juste un paramètre, et qu'il est faux, je dois annuler tout ce qui a été fait avant. Ce n'est pas une chose que les scripts font actuellement.
Enfin, il est plus sur d'appeler directement le noyau plutôt qu'un executable, car les interfaces de communication sont bien plus stricts ( exemple, il y a pas besoin de se casser la tête sur "est ce que le path est correct, est ce que j'ai pas oublié d'échapper un truc".