Ils sont contre car MS n'est pas honnète. Les entreprises ont la mémoire longue. Genre un SP de NT 4.0 qui "transformait" java pour le rendre incompatible avec Oracle par exemple.
Donc, pour une entreprise un SP == de gros problèmes en perspéctive.
Cela n'a RIEN a voir. Le probleme c'est que des grosses modificiations signifient qu'une revalidation est necessaire, et je te parles pas de changer l'interface des APIs, mais de changements interne qui en theorie(noter le mot theorie) ne sont pas sense changer quoi que ce soit..
Le probleme etant qu'il est tres difficile de deviner que telle appli metier se base sur un comportoment qu'ils ont mesure experimentalement et qui n'a jamais ete garanti, resultat si tu le changes, boum.
Linux a une api userland qui n'a jamais été modifié, ily a juste eu des ajouts. Tout programmes compilés pour le 2.6 tournera sur n'importe quel version. Cela n'est pas le cas pour windows (enfin, cela n'est pas toujours le cas).
Bien evidemment qu'on ne change jamais l'interface des APIs voyons! Raison pour laquelle tu peux encore faire tourner des softs 16bits sur Windows. Mais je crois surtout que tu ne te rends pas compte de l'etendue du probleme. La compatibilite c'est pas aussi simple que "ne jamais changer l'interface des API", c'est aussi tous les effets de bords et le comportement interne malheureusement.
Il n'y a plus de release majeur/mineur avec Linux. C'est trop complexe/ trop long à valider. Les modifications se font progressivement par petit bout (ext3->ext4 experimental ->...). Les gros patch sont découpés en rondelles (reseirfs4). Au lieu d'avoir une grosse version avec plein de nouveautés, Linux distille ces nouveauté à chaque version.
Ils ne l'appellent plus ainsi mais ca n'y change rien, le resultat au final est le meme, quand tu changes qqe chose dans le memory manager le code est utilise par tout le monde, si ce code cause des problemes a un soft, meme si le probleme est dans le soft hein, l'enterprise ne va pas toucher ton kernel.
Et c'est ca le probleme, les entreprises ne veulent pas prendre le risque de regression, ca leur coute tres cher.
Jettes un oeil aux changelog du kernel, cherches le mot regression, chaque fois que tu trouves le mot, tu as une des raisons pour lesquelles les entrerprises detestent les changements non necessaires.
[^] # Re: Les windows fanboys errent sur ce journal !!
Posté par pasBill pasGates . En réponse à la dépêche Comparatif Vista / Linux pour les performances des jeux. Évalué à 1.
Donc, pour une entreprise un SP == de gros problèmes en perspéctive.
Cela n'a RIEN a voir. Le probleme c'est que des grosses modificiations signifient qu'une revalidation est necessaire, et je te parles pas de changer l'interface des APIs, mais de changements interne qui en theorie(noter le mot theorie) ne sont pas sense changer quoi que ce soit..
Le probleme etant qu'il est tres difficile de deviner que telle appli metier se base sur un comportoment qu'ils ont mesure experimentalement et qui n'a jamais ete garanti, resultat si tu le changes, boum.
Linux a une api userland qui n'a jamais été modifié, ily a juste eu des ajouts. Tout programmes compilés pour le 2.6 tournera sur n'importe quel version. Cela n'est pas le cas pour windows (enfin, cela n'est pas toujours le cas).
Bien evidemment qu'on ne change jamais l'interface des APIs voyons! Raison pour laquelle tu peux encore faire tourner des softs 16bits sur Windows. Mais je crois surtout que tu ne te rends pas compte de l'etendue du probleme. La compatibilite c'est pas aussi simple que "ne jamais changer l'interface des API", c'est aussi tous les effets de bords et le comportement interne malheureusement.
Il n'y a plus de release majeur/mineur avec Linux. C'est trop complexe/ trop long à valider. Les modifications se font progressivement par petit bout (ext3->ext4 experimental ->...). Les gros patch sont découpés en rondelles (reseirfs4). Au lieu d'avoir une grosse version avec plein de nouveautés, Linux distille ces nouveauté à chaque version.
Ils ne l'appellent plus ainsi mais ca n'y change rien, le resultat au final est le meme, quand tu changes qqe chose dans le memory manager le code est utilise par tout le monde, si ce code cause des problemes a un soft, meme si le probleme est dans le soft hein, l'enterprise ne va pas toucher ton kernel.
Et c'est ca le probleme, les entreprises ne veulent pas prendre le risque de regression, ca leur coute tres cher.
Jettes un oeil aux changelog du kernel, cherches le mot regression, chaque fois que tu trouves le mot, tu as une des raisons pour lesquelles les entrerprises detestent les changements non necessaires.