Ton exemple est foireux : tu as forcement dû recompiler ton programme en changeant d'architecture (passage de 32 à 64bits) : tu as donc explicitement demandé à cibler une nouvelle "interface" de l'OS. Il est donc de la responsabilité du programmeur de s'assurer que son programme fonctionne face à cette nouvelle interface. L'exécutable produit contient un flag qui indique qu'il a été prévu pour fonctionner sur telle architecture, à l'OS de ne pas jouer au con. C'est pas pour rien que les OS tentent de garder la compatibilité avec l'architecture 32 bits même sur un OS 64 bits : éviter que le programme casse.
Là on parle d'une modification qui engendre un comportement différent de l'OS vis-à-vis des programmes, sans modifications de ces derniers : clairement c'est une erreur de l'OS, l'OS n'a pas à savoir (et ne peut savoir) ce qui est correct dans un programme utilisateur : il doit se borner à avoir un comportement constant pour assurer la compatibilité.
Il n'y a pour moi que quelques cas où un changement est acceptable : une API deprecated depuis un certain temps qui est finalement retirée/remplacée au bout de plusieurs années, généralement à travers une version "majeure" de l'OS, ou bien un problème de sécurité qui impose de casser la compatibilité plutôt que de laisser une faille ouverte.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à 2.
Ton exemple est foireux : tu as forcement dû recompiler ton programme en changeant d'architecture (passage de 32 à 64bits) : tu as donc explicitement demandé à cibler une nouvelle "interface" de l'OS. Il est donc de la responsabilité du programmeur de s'assurer que son programme fonctionne face à cette nouvelle interface. L'exécutable produit contient un flag qui indique qu'il a été prévu pour fonctionner sur telle architecture, à l'OS de ne pas jouer au con. C'est pas pour rien que les OS tentent de garder la compatibilité avec l'architecture 32 bits même sur un OS 64 bits : éviter que le programme casse.
Là on parle d'une modification qui engendre un comportement différent de l'OS vis-à-vis des programmes, sans modifications de ces derniers : clairement c'est une erreur de l'OS, l'OS n'a pas à savoir (et ne peut savoir) ce qui est correct dans un programme utilisateur : il doit se borner à avoir un comportement constant pour assurer la compatibilité.
Il n'y a pour moi que quelques cas où un changement est acceptable : une API deprecated depuis un certain temps qui est finalement retirée/remplacée au bout de plusieurs années, généralement à travers une version "majeure" de l'OS, ou bien un problème de sécurité qui impose de casser la compatibilité plutôt que de laisser une faille ouverte.