Parce que "Oh, tu te rends compte, ils allouent sur la stack! Comment osent-ils!!!", moi, ça me fait ni chaud ni froid.
Je faisait référence à ceci. Oui, on passe notre temps à alouer sur la stack, à chaque appel de fonction même.
Par contre, ça se fait très rarement avec des données en provenance directe de l'utilisateur, et la fonction utilisée pour ça ne permets pas de savoir si l'appel à échoué. Les problèmes mémoire sont assez communs comme ça, pourquoi prendre un risque aussi important? La performance de journald est-elle vraiment critique au point de ne pas pouvoir appeller malloc?
a ne remet pas l'intérêt de SystemD en cause. Il répond à des besoins où nous n'avions pas de solution simple avant.
Comme je l'ai dis, je remercie systemd, du fait qu'il m'a forcé à me pencher sur le fonctionnement du PID 1, et j'ai beaucoup appris ainsi.
Et puis, le côté configuration déclarative, franchement, je trouve l'idée super. Ce que je regrette, c'est que le projet ne semble avoir aucune limite dans le NIH, et vue la criticité de tout ça, je tique.
[^] # Re: Devuan
Posté par freem . En réponse au journal Remède au problème démarrage devuan ascii sur raspberry pi 2. Évalué à 2.
Je faisait référence à ceci. Oui, on passe notre temps à alouer sur la stack, à chaque appel de fonction même.
Par contre, ça se fait très rarement avec des données en provenance directe de l'utilisateur, et la fonction utilisée pour ça ne permets pas de savoir si l'appel à échoué. Les problèmes mémoire sont assez communs comme ça, pourquoi prendre un risque aussi important? La performance de journald est-elle vraiment critique au point de ne pas pouvoir appeller malloc?
Comme je l'ai dis, je remercie systemd, du fait qu'il m'a forcé à me pencher sur le fonctionnement du PID 1, et j'ai beaucoup appris ainsi.
Et puis, le côté configuration déclarative, franchement, je trouve l'idée super. Ce que je regrette, c'est que le projet ne semble avoir aucune limite dans le NIH, et vue la criticité de tout ça, je tique.