Moi j'ai envie de faire des logiciels qui savent aussi bien tourner en tant que démon, que tourner en tant qu'utilisateur simple voulant avoir le service temporairement.
L'exemple le plus simple, c'est bien le serveur HTTP avec PHP : à la fois utile en tant que service mais aussi pour l'utilisateur simple qui veut utiliser une interface web sur le port 1430.
Et pour faire ces logiciels, je pouvais utiliser n'importe quoi : shell, python, C, C++, Java... et avec la librairie de mon choix, qui pouvait faire des grosses abstractions bien plaisante. Je pouvais utiliser ce que je voulais dans mon logiciel : si je fait du shell, je peux utiliser wget, nc -l, ou n'importe quoi avec mes sockets. Et dans les autres languages, je pouvais utiliser la librairie que je voulais, qui en général avait le bon goût d'être portable, et pas seulement entre des systèmes posix.
La, ce système de socket activation pète absolument tout, et l'API est complètement centré sur le C. En shell il faudra que j'm'implémente la bidouille des variables d'environnement pour récupérer le fd du socket (qui risque de péter à chaque nouvelle version de systemd), Avec python je pourrai peut être m'en sortir en bidouillant pour appeller les fonctions C qui vont bien, mais par exemple, en Java je peux mourrir. Déjà quand on voit la vieillesse générale des JVM qui sont installées, même si un support systemd appairait (ce qui serai déjà un miracle) dans une nouvelle version (ce qui serai un autre miracle), je risquerai jamais de pouvoir l'utiliser. Et ça c'est lorsque c'est moi qui code le machin. Parce que si c'est un logiciel Java dont j'ai pas le source, qui à été prévu pour être portable mais utilisé principalement sous windows, le support systemd je pourrai me le mettre ou je pense.
J'ai parlé de Java parce qu'il fait pas mal dans l'esprit "la portabilité, envers et contre tout", mais ce n'est pas le seul. Rien que des bibliothèques C++ de gestion de socket propres et portables ne seront pas utilisables en l'état.
Et bidouiller chaque bibliothèque pour ajouter le support de systemd... Comme tout développeur, y a des parties ou j'ai envie de faire le meilleur code qui soit, et d'autres ou j'ai simplement envie que ça marche avec le moins d'effort. Pas sûr que beaucoup de monde fasse l'effort de rajouter pas mal de code en plus pour une fonctionnalité qui va être chiante à tester.
Et ça va surtout faire chier ceux qui voulait une librairie 100% POSIX qui marche partout, parce que au final ils n'auront plus une librairie 100% POSIX qui marche partout. Tout ça parce que Linux n'est même plus foutu de supporter correctement POSIX au démarrage.
La portabilité, c'est aussi pouvoir exécuter des logiciels prévus pour être portables, même s'ils ont été principalement développé sur des systèmes complètement étrangers.
[^] # Re: Modestie...
Posté par Batchyx . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10.
Parce que tu n'est pas programmeur.
Moi j'ai envie de faire des logiciels qui savent aussi bien tourner en tant que démon, que tourner en tant qu'utilisateur simple voulant avoir le service temporairement.
L'exemple le plus simple, c'est bien le serveur HTTP avec PHP : à la fois utile en tant que service mais aussi pour l'utilisateur simple qui veut utiliser une interface web sur le port 1430.
Et pour faire ces logiciels, je pouvais utiliser n'importe quoi : shell, python, C, C++, Java... et avec la librairie de mon choix, qui pouvait faire des grosses abstractions bien plaisante. Je pouvais utiliser ce que je voulais dans mon logiciel : si je fait du shell, je peux utiliser wget, nc -l, ou n'importe quoi avec mes sockets. Et dans les autres languages, je pouvais utiliser la librairie que je voulais, qui en général avait le bon goût d'être portable, et pas seulement entre des systèmes posix.
La, ce système de socket activation pète absolument tout, et l'API est complètement centré sur le C. En shell il faudra que j'm'implémente la bidouille des variables d'environnement pour récupérer le fd du socket (qui risque de péter à chaque nouvelle version de systemd), Avec python je pourrai peut être m'en sortir en bidouillant pour appeller les fonctions C qui vont bien, mais par exemple, en Java je peux mourrir. Déjà quand on voit la vieillesse générale des JVM qui sont installées, même si un support systemd appairait (ce qui serai déjà un miracle) dans une nouvelle version (ce qui serai un autre miracle), je risquerai jamais de pouvoir l'utiliser. Et ça c'est lorsque c'est moi qui code le machin. Parce que si c'est un logiciel Java dont j'ai pas le source, qui à été prévu pour être portable mais utilisé principalement sous windows, le support systemd je pourrai me le mettre ou je pense.
J'ai parlé de Java parce qu'il fait pas mal dans l'esprit "la portabilité, envers et contre tout", mais ce n'est pas le seul. Rien que des bibliothèques C++ de gestion de socket propres et portables ne seront pas utilisables en l'état.
Et bidouiller chaque bibliothèque pour ajouter le support de systemd... Comme tout développeur, y a des parties ou j'ai envie de faire le meilleur code qui soit, et d'autres ou j'ai simplement envie que ça marche avec le moins d'effort. Pas sûr que beaucoup de monde fasse l'effort de rajouter pas mal de code en plus pour une fonctionnalité qui va être chiante à tester.
Et ça va surtout faire chier ceux qui voulait une librairie 100% POSIX qui marche partout, parce que au final ils n'auront plus une librairie 100% POSIX qui marche partout. Tout ça parce que Linux n'est même plus foutu de supporter correctement POSIX au démarrage.
La portabilité, c'est aussi pouvoir exécuter des logiciels prévus pour être portables, même s'ils ont été principalement développé sur des systèmes complètement étrangers.