Ça ne me gène pas que D-Bus soit utilisé sur la session de madame michu. Un processus qui plante tout le bureau quand il merde, il y en a suffisamment, alors un de plus ou un de moins …
Mais sur un système de boot, non, quoi. Déjà la libdbus est extrêmement chiante à intégrer dans un programme, surtout si tu n'a pas une mainloop des années 90. Et encore faut t'il en avoir un, de programme qui tourne.
Ensuite, ne faire qu'une API qui parle à travers des sockets, c'est franchement lourdingue. Une socket, ça à plein de cas d'erreurs différents qui sont chiants à gérer pour faire des choses simples : une socket peut se fermer en plein millieu à n'importe quel moment, peut rester sans réponse indéfiniment, ou peut recevoir de la merde.
À coté, quand je fait un service monservice reload, Je demande rien à personne. Le fork peut merder, l'exec aussi et j'ai peut-être un sigchld à ignorer, et hop c'est fini. Un système de boot pourra choisir de lancer le service directement à partir de /sbin/service ou alors pourra charger son D-Bus lourdingue et planter lamentablement avec fallback sur la première solution en cas de problème). Si j'ai envie d'une information supplémentaire sur l'opération, je peux regarder le code de retour. C'est vrai que c'est très limité, et c'est sans doute la première chose que je changerai si on me demandait de faire une API systemd-like.
Et voilà comment une API qui existe presque déjà est plus simple, plus fiable, plus portable et plus facilement implémentable (et donc remplaçable) que n'importe quel machin avec du D-Bus dedans: Si tu veux causer au système de boot, tu lance un programme avec des arguments spécifiés. Va trouver un système de boot qui ne puisse pas implémenter ça !
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Batchyx . En réponse au journal udev forké. Évalué à 3.
Une alternative à D-Bus ? Pourquoi pas … aucune ?
Ça ne me gène pas que D-Bus soit utilisé sur la session de madame michu. Un processus qui plante tout le bureau quand il merde, il y en a suffisamment, alors un de plus ou un de moins …
Mais sur un système de boot, non, quoi. Déjà la libdbus est extrêmement chiante à intégrer dans un programme, surtout si tu n'a pas une mainloop des années 90. Et encore faut t'il en avoir un, de programme qui tourne.
Ensuite, ne faire qu'une API qui parle à travers des sockets, c'est franchement lourdingue. Une socket, ça à plein de cas d'erreurs différents qui sont chiants à gérer pour faire des choses simples : une socket peut se fermer en plein millieu à n'importe quel moment, peut rester sans réponse indéfiniment, ou peut recevoir de la merde.
À coté, quand je fait un
service monservice reload, Je demande rien à personne. Le fork peut merder, l'exec aussi et j'ai peut-être un sigchld à ignorer, et hop c'est fini. Un système de boot pourra choisir de lancer le service directement à partir de /sbin/service ou alors pourra charger son D-Bus lourdingue et planter lamentablement avec fallback sur la première solution en cas de problème). Si j'ai envie d'une information supplémentaire sur l'opération, je peux regarder le code de retour. C'est vrai que c'est très limité, et c'est sans doute la première chose que je changerai si on me demandait de faire une API systemd-like.Et voilà comment une API qui existe presque déjà est plus simple, plus fiable, plus portable et plus facilement implémentable (et donc remplaçable) que n'importe quel machin avec du D-Bus dedans: Si tu veux causer au système de boot, tu lance un programme avec des arguments spécifiés. Va trouver un système de boot qui ne puisse pas implémenter ça !