> on peut lire le source de ce pilote et en comprendre assez sur le
> fonctionnement du hardware pour écrire un pilote
Je pense que tu ne perçois pas tout le problème (d'où tes commentaires sur le reste).
Il ne s'agit pas seulement d'écrire un pilote, mais aussi de le maintenir. Soit, entre autres :
- Corriger les bugs rapidement
- Apporter de nouvelles fonctionnalités non prévues dans le pilote initial (supporter le suspend-to-ram, par exemple)
- Pouvoir facilement refactorer un sous-système (type gestion des périphériques blocs, des périphériques réseau, enlever un verrou global, changer de stack wifi, ...) sans être bloqués par ce qu'on ne sait pas quoi faire d'un pilote intouchable.
- Continuer de maintenir le pilote malgré le turn over des développeurs (et même lorsque le constructeur préférerai qu'on encourage l'achat de nouveau matériel)
Si on prends en compte ces contraintes supplémentaires (en plus de l'écriture d'un driver initial, one shot, fut-il libre), on peut affirmer qu'en effet :
- Même lorsqu'un pilote libre est intégré dans le noyau vanilla, si seule Red Hat (au hasard) dispose des docs, cette compagnie sera plus à même de servir ses clients (corriger les bugs, etc) que ne le sera SuSE (au hasard encore).
- Lorsque le constructeur souhaite pousser l'adoption d'une nouvelle génération de matériel, il est peu probable qu'il accepte de continuer à livrer les docs sous NDA pour le vieux matériel. Dès lors, on il ne nous reste qu'à croiser les doigts pour que le développeur (ou la compagnie) disposant de cette doc ne disparaisse pas.
- Et n'oublions pas que, effectivement, les distributions commerciales de Linux négocient leur bénédiction pour le support des serveurs (IBM, HP, Sun, ou Dell on généralement besoin que leurs serveurs soient "officiellements" supportés par RHEL et SuSE, mais ces dernières n'exigent pas que le matériel soit documenté de façon ouverte).
Pour finir, je continue d'être surpris par la tolérance envers les NDA dans la communauté du libre. Lorsque Greg Kroah-Hartman a lancé son Linux Driver Project en annonçant qu'il fournissait un cadre blindé pour les constructeurs souhaitant une diffusion restreinte des docs par NDA, et que c'était encouragé, j'ai sauté au plafond !
Prenez le temps de comparer avec ce qu'on (les personnes sensibles au libre) dit et pense des format ouverts et libres, des protocoles standards, ... ; à savoir : que la disponibilité d'une implémentation de référence (fut-elle libre, comme pour le .doc dans abiword, netbios dans samba, ...) ne suffit pas à rendre le format/protocole libre : il faut au moins la doc soit publiquement disponible (et c'est une condition nécessaire mais non suffisante).
Pourquoi ne pas exiger des constructeurs de matériel ce qui nous parait aller de soi pour les concepteurs de protocoles et formats de fichiers ? Theo n'a pas tort, ça fait très double standard.
# et la maintenance du pilote ? (doubles standards)
Posté par herodiade . En réponse au journal The Linux developers are selfish dickheads. Évalué à 10.
> fonctionnement du hardware pour écrire un pilote
Je pense que tu ne perçois pas tout le problème (d'où tes commentaires sur le reste).
Il ne s'agit pas seulement d'écrire un pilote, mais aussi de le maintenir. Soit, entre autres :
- Corriger les bugs rapidement
- Apporter de nouvelles fonctionnalités non prévues dans le pilote initial (supporter le suspend-to-ram, par exemple)
- Pouvoir facilement refactorer un sous-système (type gestion des périphériques blocs, des périphériques réseau, enlever un verrou global, changer de stack wifi, ...) sans être bloqués par ce qu'on ne sait pas quoi faire d'un pilote intouchable.
- Continuer de maintenir le pilote malgré le turn over des développeurs (et même lorsque le constructeur préférerai qu'on encourage l'achat de nouveau matériel)
Si on prends en compte ces contraintes supplémentaires (en plus de l'écriture d'un driver initial, one shot, fut-il libre), on peut affirmer qu'en effet :
- Même lorsqu'un pilote libre est intégré dans le noyau vanilla, si seule Red Hat (au hasard) dispose des docs, cette compagnie sera plus à même de servir ses clients (corriger les bugs, etc) que ne le sera SuSE (au hasard encore).
- Lorsque le constructeur souhaite pousser l'adoption d'une nouvelle génération de matériel, il est peu probable qu'il accepte de continuer à livrer les docs sous NDA pour le vieux matériel. Dès lors, on il ne nous reste qu'à croiser les doigts pour que le développeur (ou la compagnie) disposant de cette doc ne disparaisse pas.
- Et n'oublions pas que, effectivement, les distributions commerciales de Linux négocient leur bénédiction pour le support des serveurs (IBM, HP, Sun, ou Dell on généralement besoin que leurs serveurs soient "officiellements" supportés par RHEL et SuSE, mais ces dernières n'exigent pas que le matériel soit documenté de façon ouverte).
Pour finir, je continue d'être surpris par la tolérance envers les NDA dans la communauté du libre. Lorsque Greg Kroah-Hartman a lancé son Linux Driver Project en annonçant qu'il fournissait un cadre blindé pour les constructeurs souhaitant une diffusion restreinte des docs par NDA, et que c'était encouragé, j'ai sauté au plafond !
Prenez le temps de comparer avec ce qu'on (les personnes sensibles au libre) dit et pense des format ouverts et libres, des protocoles standards, ... ; à savoir : que la disponibilité d'une implémentation de référence (fut-elle libre, comme pour le .doc dans abiword, netbios dans samba, ...) ne suffit pas à rendre le format/protocole libre : il faut au moins la doc soit publiquement disponible (et c'est une condition nécessaire mais non suffisante).
Pourquoi ne pas exiger des constructeurs de matériel ce qui nous parait aller de soi pour les concepteurs de protocoles et formats de fichiers ? Theo n'a pas tort, ça fait très double standard.