Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.
Sinon, je pourrait aussi dire "bah je flash coreboot et je boote direct sur un kernel qui lance un shell en 2 secondes" comme sur la demo ici ( https://www.youtube.com/watch?v=IKBtQYNrsBU ) et conclure "tout est bloated, il suffit juste que tout le monde tourne sur exactement mon pc et mon setup".
Il y a bien sur sans doute toujours moyen de faire plus spécialisé et qui prends le moins possible de place ( genre coder en dur les ip partout, voir pousser directement ça sur la stack du kernel ), mais l'exercise me parait futile.
Ensuite, je reconnait que le script network fait beaucoup plus que networkd. Par exemple, il gére l'isdn [~1.4M pour le rpm), le ppp (380k pour le soft), le dhcpv6, le bonding via teamd ( 250k ) ou ipx. Donc c'est pas vraiment à feature égal.
Mais sachant que je doute que l'isdn, le ppp ou ipx dans l'initrd soit vraiment présent dans la majorité des cas, je vois pas l’intérêt de prendre ça en compte. Et malgré le fait que ça soit fait de manière ad-hoc, comprendre "à l'arrache", en ne copiant pas ce qui ne doit pas être copié sans avoir vraiment de vision haut niveau de ce qui est requis, le script network marche sans la majorité des dépendances. Alors que bash et awk sont requis.
J'ai non plus pas compté les 400k de iputils, car je part du principe que même si c'est pas requis pour que networkd fonctionne, dans le cas d'une machine de rescue, on peut en avoir besoin. mais si le but est juste de comparer la taille sans prendre en compte le rescue (ce qui me semble tricher un peu, car je pense qu'on a besoin des outils), on peut retirer ça et mettre networkd, et voila.
Et en compilant systemd sans selinux, on retire les 400k de la libpcre, et les 140k de la libselinux, et j'imagine qu'avec kdbus, on peut sans doute retirer les 430k de dbus-daemon.
Je suis pas sur pour la libdbus car systemd a sa propre lib pour le support de dbus et de kdbus, et je suis pas assez courageux pour faire un make install sur ma bécane de prod, ni assez motivé pour faire une vm pour vérifier l'hypothèse.
Donc oui, dans le cas d'un initrd avec systemd/udev/etc, mettre networkd à la place du script network permet d'avoir un solution plus économe à mon sens. Mais tu peux sans doute faire mieux en sacrifiant des features qui te paraisse superflu (sans discuter du fait qu'elles le soit ou pas pour d'autres, et je reconnais bien volontiers que pas grand monde n'a besoin des vlans dans l'initrd par exemple)
C'est comme démarrer directement erlang depuis xen directement. C'est custom made, c'est rapide, ça permet d'avoir des choses qu'on arrive pas à avoir autrement mais voila, la majorité des gens vont pas utiliser ça.
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 4.
Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.
Sinon, je pourrait aussi dire "bah je flash coreboot et je boote direct sur un kernel qui lance un shell en 2 secondes" comme sur la demo ici ( https://www.youtube.com/watch?v=IKBtQYNrsBU ) et conclure "tout est bloated, il suffit juste que tout le monde tourne sur exactement mon pc et mon setup".
Il y a bien sur sans doute toujours moyen de faire plus spécialisé et qui prends le moins possible de place ( genre coder en dur les ip partout, voir pousser directement ça sur la stack du kernel ), mais l'exercise me parait futile.
Ensuite, je reconnait que le script network fait beaucoup plus que networkd. Par exemple, il gére l'isdn [~1.4M pour le rpm), le ppp (380k pour le soft), le dhcpv6, le bonding via teamd ( 250k ) ou ipx. Donc c'est pas vraiment à feature égal.
Mais sachant que je doute que l'isdn, le ppp ou ipx dans l'initrd soit vraiment présent dans la majorité des cas, je vois pas l’intérêt de prendre ça en compte. Et malgré le fait que ça soit fait de manière ad-hoc, comprendre "à l'arrache", en ne copiant pas ce qui ne doit pas être copié sans avoir vraiment de vision haut niveau de ce qui est requis, le script network marche sans la majorité des dépendances. Alors que bash et awk sont requis.
J'ai non plus pas compté les 400k de iputils, car je part du principe que même si c'est pas requis pour que networkd fonctionne, dans le cas d'une machine de rescue, on peut en avoir besoin. mais si le but est juste de comparer la taille sans prendre en compte le rescue (ce qui me semble tricher un peu, car je pense qu'on a besoin des outils), on peut retirer ça et mettre networkd, et voila.
Et en compilant systemd sans selinux, on retire les 400k de la libpcre, et les 140k de la libselinux, et j'imagine qu'avec kdbus, on peut sans doute retirer les 430k de dbus-daemon.
Je suis pas sur pour la libdbus car systemd a sa propre lib pour le support de dbus et de kdbus, et je suis pas assez courageux pour faire un make install sur ma bécane de prod, ni assez motivé pour faire une vm pour vérifier l'hypothèse.
Donc oui, dans le cas d'un initrd avec systemd/udev/etc, mettre networkd à la place du script network permet d'avoir un solution plus économe à mon sens. Mais tu peux sans doute faire mieux en sacrifiant des features qui te paraisse superflu (sans discuter du fait qu'elles le soit ou pas pour d'autres, et je reconnais bien volontiers que pas grand monde n'a besoin des vlans dans l'initrd par exemple)
C'est comme démarrer directement erlang depuis xen directement. C'est custom made, c'est rapide, ça permet d'avoir des choses qu'on arrive pas à avoir autrement mais voila, la majorité des gens vont pas utiliser ça.