Exemple, udev avant que ça devienne part au projet systemd : http://lwn.net/Articles/193603/
( 2006, pour les gens qui veulent pas cliquer ). Et pour les gens qui veulent pas cliquer aussi, on voit GKH poser la question de "pourquoi on va supporter les trucs que les créateurs refusent de supporter plus longtemps".
Il a posé la question et la réponse a été le support de HAL jusqu'en 2010 à peu près et le retrait total des distribs qui n'a eu lieu que vers 2011. On est loin de la rupture d'API du jour au lendemain.
Des APIs exposés sous la forme de chemin dans le système de fichier, y en a des tonnes. Le changement de pilote pour les disques IDE et le renommage des noms de disques qui a suivi ( hda/sda ) est un exemple de trucs qui a du casser des scripts.
hda c'etait (et c'est toujours à ma connaissance) pour le PATA de base (nappe de 40 connecteurs) ou le PATA 60Mb/s, SDA c'est pour le scsi, le SATA et certains mode en PATA (généralement 80 et 100Mb/s - nappe 80 connecteurs). Pour se retrouver avec un changement de nom qui casse le script il faut soit changer le disque, soit trifouiller dans le bios soit carrément changer de carte mère. On va dire que c'est pas franchement de la faute du kernel sur ce coup là.
Autre exemple ? Iptables, et notamment des projets approchants comme ipset, etc. Tu mets à jour ta distro, et il te faut une version plus à jour de tel ou tel truc interne.
Il te faut une version plus à jour si tu veux utiliser les nouvelles fonctionnalités.Mais pour le reste... Quand on est passé de IPCHAINS à NetFilter Linus a tout fait pour que les scripts soient compatibles (il y avait des modifications minimes à faire) et plus fort encore, vu le tollé que la migration de 2.0 à 2.2 avait été suite à la rupture entre IPFWADM et IPCHAINS, NetFilter était aussi compatible avec IPFWADM. Donc on pouvait passer de 2.0 à 2.4 quasiment sans toucher à ses règles firewall.
Les trois exemples que tu donnes vont exactement dans le sens contraire de ce que tu veux démontrer, le maintien de l'expérience utilisateur est une priorité du noyau (et du système Linux en général) depuis des années. Et ce n'est pas par réactionnite aiguë, c'est parce que quand le systèmes bouge trop ou trop vite, les administrateurs perdent confiance et soit changent de produit, soit restent sur le produit précédent.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
On est parti
Il a posé la question et la réponse a été le support de HAL jusqu'en 2010 à peu près et le retrait total des distribs qui n'a eu lieu que vers 2011. On est loin de la rupture d'API du jour au lendemain.
hda c'etait (et c'est toujours à ma connaissance) pour le PATA de base (nappe de 40 connecteurs) ou le PATA 60Mb/s, SDA c'est pour le scsi, le SATA et certains mode en PATA (généralement 80 et 100Mb/s - nappe 80 connecteurs). Pour se retrouver avec un changement de nom qui casse le script il faut soit changer le disque, soit trifouiller dans le bios soit carrément changer de carte mère. On va dire que c'est pas franchement de la faute du kernel sur ce coup là.
Il te faut une version plus à jour si tu veux utiliser les nouvelles fonctionnalités.Mais pour le reste... Quand on est passé de IPCHAINS à NetFilter Linus a tout fait pour que les scripts soient compatibles (il y avait des modifications minimes à faire) et plus fort encore, vu le tollé que la migration de 2.0 à 2.2 avait été suite à la rupture entre IPFWADM et IPCHAINS, NetFilter était aussi compatible avec IPFWADM. Donc on pouvait passer de 2.0 à 2.4 quasiment sans toucher à ses règles firewall.
Les trois exemples que tu donnes vont exactement dans le sens contraire de ce que tu veux démontrer, le maintien de l'expérience utilisateur est une priorité du noyau (et du système Linux en général) depuis des années. Et ce n'est pas par réactionnite aiguë, c'est parce que quand le systèmes bouge trop ou trop vite, les administrateurs perdent confiance et soit changent de produit, soit restent sur le produit précédent.