Il me semble que le délai moyen est plutot 10 jours que 15 ; c'est un détail.
Pour le reste, c'est interessant mais figure toi que j'étais déjà renseigné en la matière...
Je répète que je considère testing comme un bon choix pour un poste client. Je répète que je ne conteste pas que les paquets sid peuvent être « plutot stables ». Je répète que je conteste l'idée que pour un simple utilisateur sid est un meilleur choix que testing. Tout simplement parce que dans unstable, il peut y avoir de la casse alors que testing ne risque que très peu.
Je répète que lorsqu'on parle d'une distrib, il est censé de supposer que l'on parle de cette qui est définitive.
Richard Stallman est pour le droit au fork, ça c'est très clair.
Le conflit s'est fait avant le fork, pas après. Ensuite, il y a constation que pour certaines questions légales, des bouts de XEMacs ne peuvent être repris pour Emacs, ça s'arrête la.
Concernant les histoires d'insultes et de « mal codé », vu que les gens du camps Xemacs qui sont à l'origine du fork n'en parlent pas, j'ai l'impression qu'il s'agit plutot d'une manière de dénigrer celui que l'on voit comme adversaire plutot qu'un récit honnête.
- D'autant que si Emacs est « mal codé », je n'ai réussi en quelques années à le faire planter qu'une seule fois... Ce qui me semble plutot impressionnant pour un paquet de 20 Mo... Et sur ce paquet, des très grands noms travaillent (compétents), ce qui serait dur à croire s'il était si défectueux.
- D'autant que pour suivre assez régulièrement l'actualité de GNU, je n'ai jamais surpris Richard Stallman se laisser aller à l'insulte. Ca n'implique pas que Richard Stallman lave plus blanc que blanc, ça n'implique pas que l'on doivent être d'accord avec lui sur tout sans exceptions, mais cette critique là me parait sans fondement. Je crois plus Jamie Zawinsky qui dit que sur certains points Richard est intransigeant (et oui, c'est mais c'est pas un scoop et c'est ce qui garantit d'une certaine éthique pour la FSF).
En ce qui me concerne, si je devais utiliser un logiciel parce que « user friendly », ce ne serait pas Emacs ni XEmacs. Moi je l'utilise parce que c'est puissant, efficace, sans plantage. Il est vrai que je me demande pourquoi Emacs est le seul programme avec [M-X nimportequellefonction...]
Je précise que quand j'écrivais « c'est con mais c'est la vie », je sous-entendais « c'est con pour toi, mais t'as tort : la Debian, comme précisé, celle qui a suivi ..., ne contient pas nox ».
Je ne sous-entendais pas que c'est con qu'il n'y ait pas nox. Si tu t'interessais au sens de la discussion (et non à prouver qu'il est possible d'utiliser sid, ce que personne ne conteste d'ailleurs), tu aurais vu que je signalais que selon ma propre expérience, il n'y a pas grande différence entre emacs -nw et emacs-nox (sauf les dépendances) en terme d'utilisation de ressources.
- Je ne donne pas dans la psychologie à la petite semaine. Non seulement ton accusation de paranoia ne repose sur rien mais en plus si j'étais réellement concerné par cette pathologie, ton approche n'aiderait la chose en rien. Ta remarque est non seulement ridicule mais en plus nocive.
- Tu te sens très grand ? Quelle insistance avec ce « petit » ! Moi je n'éprouve pas le besoin de parler de ta personne avec tant d'insistance...
- Sid n'est pas la branche proposée lorsque tu te rends sur debian.org ( http://www.debian.org/distrib/(...) ). Bref, ce n'est pas la branche installée naturellement. Donc la Debian, sans précision, ce n'est pas sid. La distribution qui à suivi tout le processus de maturation ne contient pas nox. C'est con mais c'est la vie.
« Je trouve que Suse c'est bien, ne serais ce que pour avoir une alternative a RedHat mais en version Europe, vu les frictions actuelles avec les U.S.A. ;) »
C'est quoi cette connerie ? RedHat est un acteur majeur du libre, qui ne fait que du libre. On s'en tape qu'ils soient américains ou pas, c'est un autre sujet.
Le problème, c'est que tu sembles être un gros nazn.
(je suis près à prendre pas mal de moins un pour ce petit défoulement).
emacs21-nox n'existe pas dans Debian, uniquement dans une branche qui n'est pas figée comme tu l'as repeté toi-même (ce qui implique que ce choix n'est pas forcément définitif), une branche qui n'est pas celle que les gens installent naturellement quand ils installent une Debian.
Aussi, je me demande ce que tu cherches à prouver avec ton "la Debian unstable est stable" :
- elle ne l'est pas au niveau de son contenu
- elle contient des logiciels qui viennent de paraitre qui peuvent donc être instable (à moins d'être Madame Soleil, tu ne peux rien prédire - combien de fois MDK à été critiqué pour avoir mis des logiciels fraichement sortis dans leurs dernières versions ?)
- son rôle principal n'est pas d'être stable mais d'être le lieu d'arrivée de nouveaux paquets pour Debian, avec tout les tests que ça implique. Si tout marche niquel pour toi, c'est cool. Si c'est pas le cas, ce n'est pas un problème, c'est justement le but : voir ce qui merde pour avoir le moins de merdes plus loin, (dans testing, par exemple, qui sera la prochaine stable probablement).
Quand on parle d'une distrib, on parle pas des betas dont le contenu change régulièrement. On pourra tourner et retourner cela dans tout les sens, ça ne changera pas le fond.
Dire qu'il n'y pas nox dans Debian, c'est actuellement vrai. Si c'est dans sid, ça n'implique pas que ça passera un jour dans une stable (bien que ce soit probable). De la même manière, il n'y a plus nox dans RedHat, ni stable ni beta, mais s'ils l'ajoutent dans un beta ça ne permettra pas plus de dire qu'il y a nox dans une RedHat.
« Oui mais dans cette dernière version de Mandrake rien ne t'empèche de trouver le paquet officiel X qui manque et de l'installer par la suite. »
Je ne comprend pas le sens de cette phrase.
« Donc réellement la Debian testing est celle dont tu peux le plus rapprocher des autres distributions. Et la Mandrake cooker peut être comparé à la Debian sid. »
Ca c'est ton avis.
Toujours est-il que la dernière Debian, c'est woody. Quand à ton histoire de figé/pas figé, lorsque RH et MDK sortent une distrib et la gravent, c'est tout aussi figé. Ca ne bouge plus (sauf maj de sécurité, comme pour woody).
Disons que les auteurs de XEmacs sont relativement nombreux. A ce que j'en ai lu, tous ne s'en foutent pas, non loin de là. Par contre, il est clair que ça n'apparait pas comme priorité pour un bon nombre d'entre eux, ce qui bien évidemment dénote une différence d'approche par rapport à GNU Emacs. Ce qui explique aussi pourquoi certaines questions légalles sont vu comme capitales d'un coté et que d'autres s'en tapent.
La sid EST NOMMEE instable. Si ça te fait mal quelque part, n'hésite pas à demander à Debian de renommer cette branche. Voire de supprimer les deux autres, puisque c'est ça l'esprit.
« Donc dès que le 2.4.20 est modifié, ça devient un 2.4.21 ? Marcelo annonce un pre7 . Il sera suivi d'un rc qui aura aussi beaucoup de modification (principalement cleanup et bug fix). C'est à partir du premier rc qu'il n'y a normalement pas de modification (sauf imprévu). Donc dans le noyau mandrake, il manque pre5, pre6, pre7, rc . »
Un pre, ce n'est pas un 2.4.20 juste modifié, c'est une "prerelease" du 2.4.21. Donc plus proche, comme je l'ai déjà dit, du 2.4.21 tel qu'il est prévu.
Que la notation soit inexacte, personne ne dit le contraire. Ceci dit, ce n'est pas une affaire d'Etat.
Comme je l'ai déjà dit, ceux qui nécessitent ce degré de précision sauront très bien faire la différence.
Par exemple, un nox et un -nw ne sont pas réellement plus ou moins léger l'un que l'autre.
Bien sur, le nox est compilé sans support de X, mais ce que je signalais c'est que le -nw est souvent une solution très interessante, entendu que ni debian ni redhat ne fournissent un nox.
L'histoire n'est pas simple. Au départ, il y avait collaboration, puis il y'a eu un clash concernant les directions à prendre et la gestion du projet.
XEmacs à beaucoup avancé après le clash, lui donnant une avance technique sur GNU Emacs. Mais dans de nombreux fichiers d'XEmacs manquent des informations légales, et donc ne sont pas inclus dans Emacs, car le projet GNU accorde une grande importance à ces questions (ie un logiciel est libre s'il peut légalement être défendu en tant que tel).
Ensuite, Emacs à fait un grand bond avec la sortie de la 20 et la 21. Beaucoup pensent qu'Emacs à de nombreux égard à dépassé XEmacs.
Lequel choisir ? Moi je préfère naturellement celui qui est clair sous tous aspects légaux. Aussi, naturellement, j'ai tendance à préferer un paquet GNU à un équivalent non-GNU, dans la mesure où un paquet GNU répond à des exigeances particulières qui attestent d'une certaine qualité.
Donc forcement, moi je recommande GNU Emacs, qui fonctionne comme un charme :)
Posté par Anonyme .
En réponse au journal Free ?.
Évalué à 6.
Aujourd'hui samedi 29, 8h45, ça foire toujours....
wép.
En espérant qu'ils n'ont pas encore baissé les temps d'exécution car mon PHP part en vrille pour la moindre page générée de plus de x lignes apparemment :/ ........
Restera-t-il des hébergeurs gratuits et sans pub dans 5 ans ?
En connaissez-vous d'autres sans pub ? (prenant en charge PHP_4_ et MySQL evidemment) ?
« APPAREMENT ? UNE ? Tu as le sens des euphémismes. »
Quelle agressivité...
« Non, j'ai des exemples de gens qui critiquent gcc-2.96-toutcourt. »
Des gens mieux placé que RedHat (un des contributeurs majeurs à gcc) qui ont certainement répondu point par point aux arguments avancés par RedHat. Chapeau, tu me les citeras :)
(c'est vraiment un combat d'arrière garde, le 29/03/2003 !)
Il y'a beaucoup de message sur phoebe-list mais le staff de RedHat ne discute pas avec le vulgum pecum ses choix, il veut juste des signalements de bogues.
Exemple : j'ai demandé avec insistance pourquoi wmaker n'était pas prévu. Une quinzaine de personnes se sont exprimées sur le sujet, dont la plupart signalait aussi désirer wmaker (y compris des employés de boites utilisant wmaker et redhat à grande échelle). Pas une seule réponse.
La réponse, c'est un autre utilisateur qui l'a proposée. Ce n'est qu'une hypothèse : wmaker n'est plus vraiment développé et cohabite mal avec GNOME/KDE.
Mon hypothèse, c'est qu'ils doivent se tater, et que donc ils ne se risquent pas à faire une déclaration sans décision publique... Mais il est clair que ça fait pas très « communauté » comme approche.
> Si mandrake affiche 2.4.21-pre4(+partie spécifique mdk), je n'ai aucun reproche à faire. C'est une 2.4.21-pre4. Ce n'est pas un 2.4.21 + patchs mandrake.
Un 2.4.21-pre4 est un noyau de la série 2.4.21, ceux qui précède la version estimée définitive. Un 2.4.21-215 est aussi un noyau de la série 2.4.21.
Généralement les numeros de versions donnent une information permettant d'évaluer quel est l'état du système. Et un noyau 2.4.21-pre est en théorie un noyau qui est plus proche du 2.4.21 que du 2.4.20 (sinon celui qui gère les sorties, Marcello donc, fait n'importe quoi).
Ceci étant souligné, en gros je doute que tant de monde que cela soit traumatisé par l'affaire. Le renseignement approximatif (2.4.21) est acceptable, quand au détail, ceux qui sont interessés comprendront.
> mdk 9.1 : uname -r : 2.4.21-0.13mdk => c'est un 2.4.21-pre4. Ce n'est pas un 2.4.21
> mdk 9.0 : uname -r : 2.4.19-16mdk => c'est un 2.4.19. C'est un 2.4.19. Tout baigne.
>
> C'est le "0." qui fait toute la différence ? Faut le savoir alors...
Oui, le 0 fait la différence. J'ai déjà vu ce type de notations. Je pense qu'elle est suffisement singulière pour être remarquée.
Ceci dit, tu as raison, ça pourrait être mieux, il aurait été plus cohérent de faire un 2.4.21-pre4-13mdk (quoique moins lisible), mais ce n'est à mon avis en aucun cas grave.
(ex: http://www.debian.org/doc/debian-policy/ch-versions.html(...) )
> D'ailleur la page de description de la 9.1 indique 2.4.20. Heu non, il indique la
> 2.4.21-pre4. Heu non, il indique 2.4.21 qui n'existe pas encore. Si un programme > est fait pour tirer parti des spécificités de la 2.4.21, il ne marchera peut-être pas
> sur mandrake 2.4.21-0.13mdk. C'est un fait.
Non, ça c'est faux. Si Tossati fait bien son boulot, il ne va pas y avoir de nouvelles fonctionnalités ajoutées entre une pre4 et une version définitive. Logiquement l'intérêt des pre est de permettre aux gens de tester et d'ensuite corriger des bugs pour sortir une version la plus stable possible, pas pour faire des tests à tout va. Enfin, je pense :)
[^] # Re: petit explication sur debian stable/testing/unstable/experimental
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 2.
[^] # Re: Sortie de GNU Emacs 21.3
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 5.
[^] # « c'est con mais c'est la vie », précision
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à -4.
Je ne sous-entendais pas que c'est con qu'il n'y ait pas nox. Si tu t'interessais au sens de la discussion (et non à prouver qu'il est possible d'utiliser sid, ce que personne ne conteste d'ailleurs), tu aurais vu que je signalais que selon ma propre expérience, il n'y a pas grande différence entre emacs -nw et emacs-nox (sauf les dépendances) en terme d'utilisation de ressources.
[^] # Bon allez, à la niche, tout ceci n'a de loin plus pour objet les logiciels libres.
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à -3.
[^] # Re: Parfait !
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 0.
- Tu te sens très grand ? Quelle insistance avec ce « petit » ! Moi je n'éprouve pas le besoin de parler de ta personne avec tant d'insistance...
- Sid n'est pas la branche proposée lorsque tu te rends sur debian.org ( http://www.debian.org/distrib/(...) ). Bref, ce n'est pas la branche installée naturellement. Donc la Debian, sans précision, ce n'est pas sid. La distribution qui à suivi tout le processus de maturation ne contient pas nox. C'est con mais c'est la vie.
[^] # Re: SuSE annonce la disponibilité de sa solution serveur pour plateformes Itanium 2
Posté par Anonyme . En réponse à la dépêche SuSE annonce la disponibilité de sa solution serveur pour plateformes Itanium 2. Évalué à 7.
C'est quoi cette connerie ? RedHat est un acteur majeur du libre, qui ne fait que du libre. On s'en tape qu'ils soient américains ou pas, c'est un autre sujet.
[^] # Re: Parfait !
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 1.
[^] # Re: Parfait !
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 2.
(je suis près à prendre pas mal de moins un pour ce petit défoulement).
emacs21-nox n'existe pas dans Debian, uniquement dans une branche qui n'est pas figée comme tu l'as repeté toi-même (ce qui implique que ce choix n'est pas forcément définitif), une branche qui n'est pas celle que les gens installent naturellement quand ils installent une Debian.
Aussi, je me demande ce que tu cherches à prouver avec ton "la Debian unstable est stable" :
- elle ne l'est pas au niveau de son contenu
- elle contient des logiciels qui viennent de paraitre qui peuvent donc être instable (à moins d'être Madame Soleil, tu ne peux rien prédire - combien de fois MDK à été critiqué pour avoir mis des logiciels fraichement sortis dans leurs dernières versions ?)
- son rôle principal n'est pas d'être stable mais d'être le lieu d'arrivée de nouveaux paquets pour Debian, avec tout les tests que ça implique. Si tout marche niquel pour toi, c'est cool. Si c'est pas le cas, ce n'est pas un problème, c'est justement le but : voir ce qui merde pour avoir le moins de merdes plus loin, (dans testing, par exemple, qui sera la prochaine stable probablement).
[^] # Re: Parfait !
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à -2.
Dire qu'il n'y pas nox dans Debian, c'est actuellement vrai. Si c'est dans sid, ça n'implique pas que ça passera un jour dans une stable (bien que ce soit probable). De la même manière, il n'y a plus nox dans RedHat, ni stable ni beta, mais s'ils l'ajoutent dans un beta ça ne permettra pas plus de dire qu'il y a nox dans une RedHat.
[^] # Re: Parfait !
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 5.
Je ne comprend pas le sens de cette phrase.
« Donc réellement la Debian testing est celle dont tu peux le plus rapprocher des autres distributions. Et la Mandrake cooker peut être comparé à la Debian sid. »
Ca c'est ton avis.
Toujours est-il que la dernière Debian, c'est woody. Quand à ton histoire de figé/pas figé, lorsque RH et MDK sortent une distrib et la gravent, c'est tout aussi figé. Ca ne bouge plus (sauf maj de sécurité, comme pour woody).
[^] # Re: Sortie de GNU Emacs 21.3
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 2.
[^] # Re: Parfait !
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 2.
[^] # Re: Détails sur la sortie du 2.4.21
Posté par Anonyme . En réponse à la dépêche Détails sur la sortie du 2.4.21. Évalué à 1.
Un pre, ce n'est pas un 2.4.20 juste modifié, c'est une "prerelease" du 2.4.21. Donc plus proche, comme je l'ai déjà dit, du 2.4.21 tel qu'il est prévu.
Que la notation soit inexacte, personne ne dit le contraire. Ceci dit, ce n'est pas une affaire d'Etat.
Comme je l'ai déjà dit, ceux qui nécessitent ce degré de précision sauront très bien faire la différence.
[^] # Re: Interface
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 1.
Et à l'utilisation, ça donne quoi ? La coloration syntaxique est toujours aussi rapide que celle avec lucid ?
Aussi, la modeline ne semble pas être gtk.
[^] # Re: Parfait !
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 1.
Bien sur, le nox est compilé sans support de X, mais ce que je signalais c'est que le -nw est souvent une solution très interessante, entendu que ni debian ni redhat ne fournissent un nox.
# Re: Sortie de GNU Emacs 21.3
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 2.
# Re: Test du Kernel 2.5.66
Posté par Anonyme . En réponse au journal Test du Kernel 2.5.66. Évalué à 5.
en effet ! là où il faut vraiment des petits noyaux (sur des disquettes boot par exemple) rien n'empèche l'emploi d'un 2.4 :)
"ça se joue à quelques secondes près, une dizaine tout au plus. "
Mon pc boot en 13", mais je suppose que le retard serait moindre. car sinon 23s au lieux de 13 c'est quand même une vache de perte ...
[^] # Re: Interface
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 1.
C'est quoi cette blague ?
Pour ce qui est de gtk+2, à voir à quoi ça ressemblera...
[^] # Re: Parfait !
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 10.
Vraiment, cette remarque (à laquelle tu réponds) est largement exagérée !
Note: emacs-nox, c'est emacs -nw (lorsqu'ils ne sont pas proposé en deux paquets séparés)
[^] # Re: Sortie de GNU Emacs 21.3
Posté par Anonyme . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 10.
XEmacs à beaucoup avancé après le clash, lui donnant une avance technique sur GNU Emacs. Mais dans de nombreux fichiers d'XEmacs manquent des informations légales, et donc ne sont pas inclus dans Emacs, car le projet GNU accorde une grande importance à ces questions (ie un logiciel est libre s'il peut légalement être défendu en tant que tel).
Ensuite, Emacs à fait un grand bond avec la sortie de la 20 et la 21. Beaucoup pensent qu'Emacs à de nombreux égard à dépassé XEmacs.
Lequel choisir ? Moi je préfère naturellement celui qui est clair sous tous aspects légaux. Aussi, naturellement, j'ai tendance à préferer un paquet GNU à un équivalent non-GNU, dans la mesure où un paquet GNU répond à des exigeances particulières qui attestent d'une certaine qualité.
Donc forcement, moi je recommande GNU Emacs, qui fonctionne comme un charme :)
[^] # Re: Free ?
Posté par Anonyme . En réponse au journal Free ?. Évalué à 6.
wép.
En espérant qu'ils n'ont pas encore baissé les temps d'exécution car mon PHP part en vrille pour la moindre page générée de plus de x lignes apparemment :/ ........
Restera-t-il des hébergeurs gratuits et sans pub dans 5 ans ?
En connaissez-vous d'autres sans pub ? (prenant en charge PHP_4_ et MySQL evidemment) ?
Merci cher journal :-*
[^] # Re: Bon esprit...
Posté par Anonyme . En réponse à la dépêche Interview de Gaël Duval à propos de Mandrake. Évalué à 1.
Quelle agressivité...
« Non, j'ai des exemples de gens qui critiquent gcc-2.96-toutcourt. »
Des gens mieux placé que RedHat (un des contributeurs majeurs à gcc) qui ont certainement répondu point par point aux arguments avancés par RedHat. Chapeau, tu me les citeras :)
(c'est vraiment un combat d'arrière garde, le 29/03/2003 !)
[^] # Re: Bon esprit...
Posté par Anonyme . En réponse à la dépêche Interview de Gaël Duval à propos de Mandrake. Évalué à 1.
Exemple : j'ai demandé avec insistance pourquoi wmaker n'était pas prévu. Une quinzaine de personnes se sont exprimées sur le sujet, dont la plupart signalait aussi désirer wmaker (y compris des employés de boites utilisant wmaker et redhat à grande échelle). Pas une seule réponse.
La réponse, c'est un autre utilisateur qui l'a proposée. Ce n'est qu'une hypothèse : wmaker n'est plus vraiment développé et cohabite mal avec GNOME/KDE.
Mon hypothèse, c'est qu'ils doivent se tater, et que donc ils ne se risquent pas à faire une déclaration sans décision publique... Mais il est clair que ça fait pas très « communauté » comme approche.
# Re: Mandrake 9.1 et HostName
Posté par Anonyme . En réponse au journal Mandrake 9.1 et HostName. Évalué à 2.
Moi je croyais qu'une adresse mac correspond plutôt à un identifiant unique d'une carte réseau...
hardware ethernet 00:48:54:1c:60:29;
[^] # Re: Détails sur la sortie du 2.4.21
Posté par Anonyme . En réponse à la dépêche Détails sur la sortie du 2.4.21. Évalué à 1.
Un 2.4.21-pre4 est un noyau de la série 2.4.21, ceux qui précède la version estimée définitive. Un 2.4.21-215 est aussi un noyau de la série 2.4.21.
Généralement les numeros de versions donnent une information permettant d'évaluer quel est l'état du système. Et un noyau 2.4.21-pre est en théorie un noyau qui est plus proche du 2.4.21 que du 2.4.20 (sinon celui qui gère les sorties, Marcello donc, fait n'importe quoi).
Ceci étant souligné, en gros je doute que tant de monde que cela soit traumatisé par l'affaire. Le renseignement approximatif (2.4.21) est acceptable, quand au détail, ceux qui sont interessés comprendront.
> mdk 9.1 : uname -r : 2.4.21-0.13mdk => c'est un 2.4.21-pre4. Ce n'est pas un 2.4.21
> mdk 9.0 : uname -r : 2.4.19-16mdk => c'est un 2.4.19. C'est un 2.4.19. Tout baigne.
>
> C'est le "0." qui fait toute la différence ? Faut le savoir alors...
Oui, le 0 fait la différence. J'ai déjà vu ce type de notations. Je pense qu'elle est suffisement singulière pour être remarquée.
Ceci dit, tu as raison, ça pourrait être mieux, il aurait été plus cohérent de faire un 2.4.21-pre4-13mdk (quoique moins lisible), mais ce n'est à mon avis en aucun cas grave.
(ex: http://www.debian.org/doc/debian-policy/ch-versions.html(...) )
> D'ailleur la page de description de la 9.1 indique 2.4.20. Heu non, il indique la
> 2.4.21-pre4. Heu non, il indique 2.4.21 qui n'existe pas encore. Si un programme > est fait pour tirer parti des spécificités de la 2.4.21, il ne marchera peut-être pas
> sur mandrake 2.4.21-0.13mdk. C'est un fait.
Non, ça c'est faux. Si Tossati fait bien son boulot, il ne va pas y avoir de nouvelles fonctionnalités ajoutées entre une pre4 et une version définitive. Logiquement l'intérêt des pre est de permettre aux gens de tester et d'ensuite corriger des bugs pour sortir une version la plus stable possible, pas pour faire des tests à tout va. Enfin, je pense :)