Linus accepte les patches qui ont pour objectifs de permettre la compilation avec un autre compilateur que gcc (clang en tête). Il n'accepte pas n'importe quel patch, mais il ne refuse pas une contribution sous-prétexte que la portabilité sur d'autres environnements l'ennui.
Quel est l’intérêt de cette remarque qui n’a rien à voir avec le sujet ?
Déjà, il me semble que le noyau Linux n'est porté que sur le noyau Linux !
Linus n’accepte pas les patches qui selon lui n’ont rien à faire dans le noyau (d’où les difficultés de kdbus par exemple), systemd n’accepte pas les patches qui n’ont rien à faire dans systemd : c’est pareil.
Et la preuve est que ces fonctionnalités (des API pour des appels système sous Linux) sont présentes dans la glibc (qui pourtant filtre ce qui est disponible sur un unique noyau), et qu’elles fonctionnent très bien et sont maintenues.
Pour information, ce n’est pas la première fois qu’un développeur demande à systemd d’implémenter des fonctions de la glibc parce que la libc qu’il utilise ne veut pas le faire.
Multiplier les implémentations d’API dans de multiples projets est très mauvais, c’est une très bonne raison de ne pas réimplémenter la roue dans systemd.
Bien sûr, ça va à l’encontre de l’histoire comme quoi systemd veut tout réimplémenter (glibc, GNU par exemple) au sein de son code, mais les incohérences n’arrêtent pas les trolls.
systemd est spécifique GNU/Linux, c’était clair dès le début.
Certains n’ont pas voulu l’entendre de cette oreille et ont décidé que c’était possible et pas un énorme boulot de gérer la compatibilité avec d’autres OS, pour décrédibiliser les développeurs systemd.
Seulement, arrivé dans la réalité, tous ces beaux parleurs jettent l’éponge les uns après les autres devant l’ampleur de la tâche, comme uselessd, prouvant par là même la compétence des dévs systemd et leur propre irresponsable incompétence.
[^] # Re: Musl / uclibc
Posté par ookaze . En réponse au journal Busybox retire le support de systemd ?. Évalué à -1. Dernière modification le 16 novembre 2015 à 15:49.
Quel est l’intérêt de cette remarque qui n’a rien à voir avec le sujet ?
Déjà, il me semble que le noyau Linux n'est porté que sur le noyau Linux !
Linus n’accepte pas les patches qui selon lui n’ont rien à faire dans le noyau (d’où les difficultés de kdbus par exemple), systemd n’accepte pas les patches qui n’ont rien à faire dans systemd : c’est pareil.
Et la preuve est que ces fonctionnalités (des API pour des appels système sous Linux) sont présentes dans la glibc (qui pourtant filtre ce qui est disponible sur un unique noyau), et qu’elles fonctionnent très bien et sont maintenues.
Pour information, ce n’est pas la première fois qu’un développeur demande à systemd d’implémenter des fonctions de la glibc parce que la libc qu’il utilise ne veut pas le faire.
Multiplier les implémentations d’API dans de multiples projets est très mauvais, c’est une très bonne raison de ne pas réimplémenter la roue dans systemd.
Bien sûr, ça va à l’encontre de l’histoire comme quoi systemd veut tout réimplémenter (glibc, GNU par exemple) au sein de son code, mais les incohérences n’arrêtent pas les trolls.
systemd est spécifique GNU/Linux, c’était clair dès le début.
Certains n’ont pas voulu l’entendre de cette oreille et ont décidé que c’était possible et pas un énorme boulot de gérer la compatibilité avec d’autres OS, pour décrédibiliser les développeurs systemd.
Seulement, arrivé dans la réalité, tous ces beaux parleurs jettent l’éponge les uns après les autres devant l’ampleur de la tâche, comme uselessd, prouvant par là même la compétence des dévs systemd et leur propre irresponsable incompétence.