On ne peut pas avoir le beurre et l'argent du l'argent :-)
> Du coup, l'utilisateur "personnel" (i.e. à la maison)
Lequel ?
Madame Michu ?
Pour un utilisateur, c'est toujours du boulot que de suivre les évolutions d'un projet dynamique. Ce n'est pas spécifique à Linux.
Madame Michu ne doit pas utiliser kernel.org, mais une distribution avec du support.
> un 2.6-quelquechose et ce quelque chose varie d'une distribution à l'autre.
Ce n'est pas un problème Linux. C'est le libre, c'est le choix des distributions.
Par exemple RHEL 5 (et ses clones) utilise un 2.6.18 (et sur toute la durée de vie de RHEL 5, c-à-d au moins 7 ans). Libre à toute distribution d'utiliser aussi le 2.6.18. Mais (et ce n'est pas un reproche) elles préfèrent prendre la dernière version lorsqu'une distribution est en gestation (exactement comme le fait Red Hat).
Il y a de bonnes raisons à ça et ce n'est pas que pour la frime. C'est aussi pour avoir le support de la communauté des développeurs Linux lors de la gestation de la distribution (les développeurs ont le nez dans la dernière version, pas dans les vieilles versions).
Il n'y a pas de solution unique au désagrément du modèle de développement de Linux. S'il y a une solution uniquement, c'est d'avoir les drivers en libre et upstream.
Mais voyons aussi ce qu'a apporté l'évolution rapide de Linux et qui répond à ton soucis. Aujourd'hui Linux marche "les doigts dans le nez". A l'époque de Linux 2.0, 2.2 et même le 2.4 (sauf peut-être les dernières versions de 2.4) beaucoup d'utilisateurs devaient recompiler le noyau, faire un checkout d'un CVS pour avoir un driver pour leur carte télé, etc...
Ce que je veux dire, c'est que remettre en cause la rapidité de développement de Linux (c-à-d aussi son modèle de développement), c'est aussi reppousser le moment où on a la solutions qui va bien (pour une carte télé qui marche "les doigts dans le nez", etc).
Aujourd'hui très peu recompile leur noyau, c'est aussi grace au modèle de développement de Linux. Certe, de façon indirect.
> De même, l'utilisateur "professionnel" (i.e. en entreprise et/ou développeur pour Linux) ne bénéficie plus de cette pérennité connue avec les noyaux <= 2.4 et le diagnostic est d'autant plus difficile.
Le professionnel veut une garantie de service (c'est-à-dire du support). Donc il prend (ou devrait prendre) une distribution professionelle (ou un clone de distribution professionnel s'il ne veut pas de support mais seulement la stabilité de l'api) et ne pas se poser de question et ne pas demander l'impossible à Linux (le Linux upstream). Linux ne peut pas évoluer vite (ce qui est hypra important sinon Linux est dépassé par les autres et ne répond pas aux attentes) et être figé.
Kernel.org n'a pas pour cible Madame Michu ni les professionnels.
> d'un certain nombre de logiciels/technos à côté (genre udev, dbus...).
Ces technos étaient en développement intensif. Ça devrait se calmer.
Notons que le libre est ouvert. Donc les technos en pleine gestation sont disponibles (ça a les inconvéniants de ses qualités).
> Bref, hors développeurs du noyau lui-même, il n'y a pas que des avantages.
Il faut penser à l'offre de GNU/Linux globalement. kernel.org n'est "que" le développement.
Si tu veux du stable (api), tu trouves.
Si tu veux du "chaud", tu trouves aussi.
Comme l'a faire remarquer le GeneralZod (c'était toi ?), beaucoup utilisent Fedora (c'est "chaud", c'est pour le développement, c'est pour la veille technologique, etc) ET RHEL ou ses clones (c'est "froid", ça ne bouge pas, c'est sans intérêt pour la veille technologique, etc). Il faut deux distributions (ou plus de façon plus générale) car il y a des objectifs d'utilisation incompatibles.
Linux (de kernel.org) ne peut pas répondre aux utilisateurs type Fedora et aux utilisateurs type RHEL (ou Debian stable ou Mandriva CS etc). C'est impossible.
[^] # Re: Et l'avenir ?
Posté par IsNotGood . En réponse à la dépêche Sortie du noyau Linux 2.6.23. Évalué à 3.
> Du coup, l'utilisateur "personnel" (i.e. à la maison)
Lequel ?
Madame Michu ?
Pour un utilisateur, c'est toujours du boulot que de suivre les évolutions d'un projet dynamique. Ce n'est pas spécifique à Linux.
Madame Michu ne doit pas utiliser kernel.org, mais une distribution avec du support.
> un 2.6-quelquechose et ce quelque chose varie d'une distribution à l'autre.
Ce n'est pas un problème Linux. C'est le libre, c'est le choix des distributions.
Par exemple RHEL 5 (et ses clones) utilise un 2.6.18 (et sur toute la durée de vie de RHEL 5, c-à-d au moins 7 ans). Libre à toute distribution d'utiliser aussi le 2.6.18. Mais (et ce n'est pas un reproche) elles préfèrent prendre la dernière version lorsqu'une distribution est en gestation (exactement comme le fait Red Hat).
Il y a de bonnes raisons à ça et ce n'est pas que pour la frime. C'est aussi pour avoir le support de la communauté des développeurs Linux lors de la gestation de la distribution (les développeurs ont le nez dans la dernière version, pas dans les vieilles versions).
Il n'y a pas de solution unique au désagrément du modèle de développement de Linux. S'il y a une solution uniquement, c'est d'avoir les drivers en libre et upstream.
Mais voyons aussi ce qu'a apporté l'évolution rapide de Linux et qui répond à ton soucis. Aujourd'hui Linux marche "les doigts dans le nez". A l'époque de Linux 2.0, 2.2 et même le 2.4 (sauf peut-être les dernières versions de 2.4) beaucoup d'utilisateurs devaient recompiler le noyau, faire un checkout d'un CVS pour avoir un driver pour leur carte télé, etc...
Ce que je veux dire, c'est que remettre en cause la rapidité de développement de Linux (c-à-d aussi son modèle de développement), c'est aussi reppousser le moment où on a la solutions qui va bien (pour une carte télé qui marche "les doigts dans le nez", etc).
Aujourd'hui très peu recompile leur noyau, c'est aussi grace au modèle de développement de Linux. Certe, de façon indirect.
> De même, l'utilisateur "professionnel" (i.e. en entreprise et/ou développeur pour Linux) ne bénéficie plus de cette pérennité connue avec les noyaux <= 2.4 et le diagnostic est d'autant plus difficile.
Le professionnel veut une garantie de service (c'est-à-dire du support). Donc il prend (ou devrait prendre) une distribution professionelle (ou un clone de distribution professionnel s'il ne veut pas de support mais seulement la stabilité de l'api) et ne pas se poser de question et ne pas demander l'impossible à Linux (le Linux upstream). Linux ne peut pas évoluer vite (ce qui est hypra important sinon Linux est dépassé par les autres et ne répond pas aux attentes) et être figé.
Kernel.org n'a pas pour cible Madame Michu ni les professionnels.
> d'un certain nombre de logiciels/technos à côté (genre udev, dbus...).
Ces technos étaient en développement intensif. Ça devrait se calmer.
Notons que le libre est ouvert. Donc les technos en pleine gestation sont disponibles (ça a les inconvéniants de ses qualités).
> Bref, hors développeurs du noyau lui-même, il n'y a pas que des avantages.
Il faut penser à l'offre de GNU/Linux globalement. kernel.org n'est "que" le développement.
Si tu veux du stable (api), tu trouves.
Si tu veux du "chaud", tu trouves aussi.
Comme l'a faire remarquer le GeneralZod (c'était toi ?), beaucoup utilisent Fedora (c'est "chaud", c'est pour le développement, c'est pour la veille technologique, etc) ET RHEL ou ses clones (c'est "froid", ça ne bouge pas, c'est sans intérêt pour la veille technologique, etc). Il faut deux distributions (ou plus de façon plus générale) car il y a des objectifs d'utilisation incompatibles.
Linux (de kernel.org) ne peut pas répondre aux utilisateurs type Fedora et aux utilisateurs type RHEL (ou Debian stable ou Mandriva CS etc). C'est impossible.