Distribution : Dunc-tank: comment aider à la publication de Etch en décembre
Posté par Raphaël Hertzog (page perso, ). Modéré le 19 septembre 2006.
Alors, si vous faites partie des fervents supporters de cette distribution, et que vous aimeriez bien que le projet respecte la date de publication prévue, à savoir le 4 décembre 2006, n'hésitez pas à soutenir cette initiative.
![[en]](../images/en.png)
Dunc-tank (1092 hits)-
Annonce officielle (246 hits)
-
Participer et faire une donation (203 hits)
![[fr]](../images/fr.png)
Point de vue de Raphael Hertzog (1577 hits)-
Note du Debian Project Leader (203 hits)
> Lire la dépêche (68 commentaires, moyenne: 3).
Vous avez demandé le commentaire #756054.
Run by 
Cette page a été générée par Templeet en 0.092s (dont 0.0081 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
pas logique
sur le site de Raphael Hertzog :
Et que le débat s’ouvre!
Les commentaires sont fermés.
ceci dit l'idée ne me parrait pas terrible d'un point de vue perso. Compliqué a gérer, peut-être du coup manque de motivation de ceux qui ne seront pas payés ... jalousie interne au projet, enfin tout ce que l'argent peut apporter de mauvais. Il peut y avoir des avantages mais pour moi, etch sortira quand ca sera prêt et un point c'est tout !
[^]Re: pas logique
Tout à fait d'accord, je ne comprends pas toujours cette pression qui s'exerce sur l'équipe debian pour la sortie de la nouvelle version de la distribution. S'il s'agissait d'une distrib déstinée aux utilisateurs de bureau, là je comprendrai bien, on veut les dernières nouveautés que proposent nos logiciels favoris, mais la branche stable ne s'adresse pas à cette catégorie là.
Si etch ne sort pas à temps, c'est que ce n'est tout simplement pas prêt. C'est pour proposé un meilleur "produit" que l'équipe de debian n'effectue pas la sortie, pas parce qu'ils prennent plaisir à agir ainsi... Si c'est le prix qu'il faut payer pour avoir un système qui tourne bien, un peu de patience ne fait pas de mal.
Puis pour ceux qui râlent, c'est qu'ils n'ont à priori pas besoin de la version stable, ils n'ont qu'à passer en sid puis voilà. Moi ça me convient parfaitement...
[^]Re: pas logique
Il n'y a pas que dans le monde de la bureautique que les choses évoluent rapidement. Dans le monde des serveurs, le matériel évolue également et nécessite parfois des softs récents, notamment au niveau du noyau. Bien entendu, il est toujours possible de debootstraper une Sarge puis recompiler un noyau récent, mais adieux les mises à jours de sécurité. Je parle ici d'un contexte professionnel, pas d'une utilisation perso. Les derniers mois avant la sortie de Sarge ont été assez délicats, il était quasiment impossible d'installer Woody sur un serveur neuf, et le problème commence à se poser avec le noyau 2.6.8 de Sarge, par exemple avec les cartes RAID SATA. Sid n'est absolument pas une solution dans ce contexte.
Je pense que toute initiative visant à aider le projet Debian à tenir sa roadmap et à raccourcir le temps entre 2 releases est la bienvenue.
[^]Re: pas logique
Je suis 100% d'accord. D'ailleurs, je tourne de plus en plus sous noyau 2.6.16 en sarge.
Heureusement, il y a les backports. Une chose qui manque à la stable est justement une meilheure visibilité de ces backports. Nous n'utilisons ici que les backports pour le noyau (matériels récents), openoffice, firefox et thunderbird. De manière très ponctuel, et pour quelques serveurs, d'autres paquets comme le serveur ssh...
Il y a des installeurs sarge avec des noyaux plus récent (2.6.15) mais comme rien n'est officiel, il faut faire confiance...
Bref, un backports un peu plus officiel mais ayant les recommendations du backport actuel (à utiliser avec précauin et parcimonie...) avec des images aussi plus récentes pour les cas difficiles serait les bienvenues. Une bonne partie du travail est à mon avis déjà réalisées. C'est "juste" un problème de "com".
[^]Re: pas logique
> S'il s'agissait d'une distrib déstinée aux utilisateurs de bureau, là je
> comprendrai bien, on veut les dernières nouveautés que proposent
> nos logiciels favoris, mais la branche stable ne s'adresse pas à cette
> catégorie là.
Ah bon !
Ben chez moi, tout le monde est sur stable. Il n'est pas question de mettre du testing et de l'unstable sur les postes de bureautique. Sur quelques serveurs, en nombre très limité, pourquoi pas.
Je ne vais pas faire le tour des postes de bureautique pour expliquer aux gens tous les quatre matins que tout a changé.
Bon, pour une machine perso, c'est autre chose...
[^]Re: pas logique
Rien n'oblige de faire une mise à jour tous les 3, 4 jours.
Si mes souvenirs sont bons, openoffice.org n'était pas disponible sur woody, ce qui rendait l'usage de sarge plus ou moins obligatoire (mis à part usage de backports) pour ceux qui en avaient besoin.
En gros ce que je veux dire, c'est que la stabilité qu'offre la version stable de debian ne s'adresse qu'à un public à mon avis restreint. J'utilise sid depuis quelques années déjà, et n'ai eu affaire qu'à une petite dizaines d'ennuis lors de mises à jour, mais la machine restait tout à fait utilisable. Si on installe donc une sid qui ne présente pas de problèmes particuliers, c'est plus que confortable pour de la bureautique (par exemple).
Pour ce qui est de l'évolution des serveurs, je n'ai pas une expérience personnelle sur le sujet donc j'en resterai à des suppositions, mais je pense que pour un grand pourcentage d'entre eux, on ne fait pas de mise à jour (mis à part des patches de sécurité) tous les 3 mois, que ce soit hardware ou software. Puis si le hardware doit être remplacé pour une raison X ou Y, rien n'empêche de prendre un noyau directement sur kernel.org afin que le matériel soit supporté. Si après une mise à jour logicielle s'impose afin que le tout tourne convenablement, j'ai tendance à croire qu'il s'agit là de cas très particuliers et qu'ils ne représentent pas à eux tous seuls la majorité.
[^]Re: pas logique
et bien si justement, les mises à jours de sécurité sont fréquentes, y compris sur la stable. Et surtout, on n'attend sur stable que des mises à jour de sécurité.
Le problème de Sid, ce n'est pas sa stabilité en terme de fonctionnement (plantage,...) mais la stabilité du contenu. A chaque MAJ de Sid, il y a des choses qui changent, des montées de version de soft avec parfois des effets de bords,...
Tout ceci est tout à fait gérable pour un poste perso, mais pas sur un serveur ou sur un ensemble de poste de travail.
[^]Re: pas logique
On est tous d'accord, sur la fin, la woody commençait a être viellle. Ce n'est pas encore le cas de woody.
Pour ce qui est de la stable, je suis en totale opposition. Combien de machines gères-tu ? Sur quel type de réseau ? Pour ma part, je suis sur du réseau à accès gigabits en frontal sur le net, mes machines sont toujours à jours, au minimum deux à trois fois par semaines ! Idem pour les serveurs, par exemple, la dernière mise à jour concerne gzip donc là, tu as tout ton parc à mettre à jours... (merci clusterssh)
Par ailleurs, j'utilise cfengine pour autoconfigurer les postes. J'ai donc tout intérêt a avoir un parc homogène d'un point de vue logiciel. Si j'installai un poste pour ne plus y toucher après, je ne serais pas sur à 99% que mes routines cfengine ne fassent pas le bazard ici ou là.
Ta technique ne me parait valable que pour des petits parcs qui ne sont pas en frontal sur le net avec des grosses liaisons.
[^]Re: pas logique
la dernière mise à jour concerne gzip donc là, tu as tout ton parc à mettre à jours... (merci clusterssh)
Essaie cron-apt :)
Claws Mail - it bites!
[^]Re: pas logique
Je l'ai sur toutes mes machines ! Je gagne donc un temps fou avec cela.
cron-apt télécharge mais n'installe pas chez moi. Par contre, je suis devant un terminal pour voir comment se passe les mises à jour. Surtout que sur les serveurs, il y a parfois des choses à reprendre, heureusement très rarement. Et puis, c'est pas vraiment un problème, avec clusterssh, je fais 25 machines d'un coup. Le jour ou j'aurais 400 machines, je reverrais ma manière de faire.
[^]Re: pas logique
J'ai même testé pkgsync sur un poste. C'est radical d'efficacité !
Le problème est que ca ne marche pas toujours... Dans mon boulot actuel, nous sommes sur plusieurs bâtiments. Il est donc pour moi hors de question de faire le tour des postes de travail le matin en arrivant.
[^]Re: pas logique
Même son de cloche qu'au dessus : tu n'as peut-être pas l'intérêt d'une machine de bureau sous sarge, mais d'autres l'ont. Exemple tout bête : machine perso derrière une connection à 500 ko/s avec quelques services (apache et dns en libre accès, postfix, ftp et ssh filtrés sur l'IP ; comme tout le monde n'a pas les moyens ni l'envie d'avoir une machine dédiée comme passerelle (et encore mieux une troisième comme DMZ), elle est en stable malgré qu'elle soit aussi utilisée comme machine de bureau.
Pour ma machine perso, j'ai jamais voulu passer à sid, je suis resté en testing. Et je ne suis pas uptodate, je ne mets à jour que chaque mois.
Encryption is not magic pixie dust to sprinkle on things to make them more secure.
[^]Re: pas logique
:)
C'est exactement ce que j'entend par serveur et non machine de bureau. L'utilisateur moyen, voulant pouvoir lire ses mails, surfer sur le net puis faire usage d'une suite bureautique, ne connais d'apache que les tribus, dns pour lui c'est du chinois, ssh et postfix n'en parlont même pas.
Certains diront, "lui, il ne travaille pas sous linux alors", mais les tendances montrent que de plus en plus de personnes se retrouvent à faire la transition windows-linux, pas forcément par choix personnel (je pense à toutes les administrations/organisations qui décident de passer sous linux).
Il me semble possible pour un administrateur de trouver un état de sid qui lui convient, faire une install sur une machine puis après (par quelque moyen que ce soit, image ou autre), distribuer le tout sur son réseau.
Ceci dit tout ceci n'est qu'une supposition, je le rappelle, puisqu'à la question :
je réponds, 1.5, mon pc puis un portable archaïque sur lequel je fais des tests une fois tous les 6 mois (d'où le 0.5). Rien qui ne permette une expérimentation très concluente, surtout que la "solution" ci-dessus ne s'applique à priori facilement que sur un réseau comportant des machines plus ou moins semblables (encore que...).
[^]Re: pas logique
Justement, sur un parc conséquent, de plus en plus de personnes n'y connaissent rien en administration système, et cela est normal. A chacun son boulot.
Je ne comprends pas pourquoi tu cherches a avoir un état de sid qui te convienne pour le distribuer sur un parc. Ton truc ne sera jamais maintenable dans la durée. C'est justement ça : une stable. Une stable est juste une sid sans bogue à un instant donné qui est ensuite suivis.
Pour avoir des machines qui ont eu la slink, puis la patate, puis la woody, maintenant la sarge et qui risque de finir leur vie sur etch, la période de transition d'une version à l'autre n'est pas toujours triviale, même si debian est pour cela exemplaire. Cela ne marche pas à tous les coups et ça prends du temps.
Ensuite, l'idéal est effectivement d'avoir un parc homogène comme cela tu essayes sur une machine et tu propages. Malheureusement, je n'ai pas de parc homogène, les seuls que je connaisse qui ont des parcs très homogènes sont ceux qui gèrent des salles de cours pour les étudiants. Dans ces cas là, oui, c'est plus facile. Même au niveau des secrétariats d'administration, c'est assez hétéroclite, surtout en ce moment où avec le même nom, deux machines ayant six mois d'écarts sont très différents (je pense notament au DELL Optiplex GX620).
Enfin pour finir sur l'utilisateur qui n'y connais pas grand chose, que tu lui mettes gnome 2.14 ou gnome 2.16, il s'en fiche un peu. S'il ne connait que la version 2.14, cela lui conviendra tout à fait (en plus, elle est pas si mal cette version). J'ai même eu des personnes qui ne voulaient pas openoffice2 car ils ne voulaient pas changer leur habitudes et la version 1 leur allaient.
J'ai par ailleurs vu des développeurs qui en ont marre que leur code ne compile plus tous les mois à cause d'une bibliothèque qui change sans cesse et qui, après avoir été "bleeding edge" quelques temps, me demande une stable bien stable (qui surtout ne bouge plus).
Bref, faut presque se battre pour avoir le droit d'installer juste les mises à jour de sécurité ;-)
[^]Re: pas logique
Bon, je reformule, tu auras peut-être moins de mal à suivre : même sans parler d'un parc de plusieurs machines comme l'a fait Sytoka Modon au-dessus, il y a une raison toute simple pour préférer utiliser une Debian stable sur un poste de travail unique : une machine que l'on administre pour son utilisateur, et qu'on a pas envie de mettre à jour tous les jours, ou même tous les mois. Surtout si la machine est reliée à internet, avec les problèmes de sécurité que ça peut poser, et si en guise de compensation on en profite tourner quelques services.
Merci de ne pas me rabattre les oreilles en répétant une fois de plus que cette machine est un serveur, puisque ce n'est pas le cas. C'est une machine de bureau, qui n'existerait pas si son utilisateur n'avait pas besoin d'une machine de bureau. Et elle est en Debian stable. Et ça serait cool si etch sortait à la fin de l'année, enfin, pas avec un an de retard quoi, histoire que l'utilisateur profite d'une mise à jour générale de son système.
Encryption is not magic pixie dust to sprinkle on things to make them more secure.
[^]Re: pas logique
Je sens que je t'ai offensé, j'en suis désolé ce n'était pas le but. Cependant je maintiens que l'ordinateur dont tu me parles, selon moi, est un serveur. Il propose des services (du type serveur web, serveur ftp, très probablement serveur mail, etc.) donc en ce sens il est un serveur. Après, il est également client puisque ces services ne sont utilisés que par un utilisateur connecté sur cette même machine.
extrait de wikipedia
Je ne fais donc pas référence à serveur dans le sens grosse machine qui à elle seule remplit une salle...
Donc en ce sens on est d'accord, tu as besoin des garanties que propose la version stable, c'est normal et non contraire à ce que je dis. Ceci dit, une machine pûrement client, peut avoir besoin (remarquez besoin est un bien grand mot) de dernières nouveautés que l'on ne trouve que dans testing/sid.
Je pense que si mon jugement est éventuellement faussé, c'est du au fait de ma courte expérience de Debian, puisque les seules stables que j'ai connu sont woody puis sarge. Et avec woody, il y avait en effet un problème d'ancienneté qui n'était pas négligeable à l'époque.
[^]Re: pas logique
En fait de nous deux, c'est moi qui te dois des excuses pour la sécheresse de mon message précédent, qui était largement disproportionnée.
Pour en revenir à cette fameuse machine et au risque de me répéter, je ne la considère pas comme un serveur tout simplement parce que ce n'est pas sa première fonction. Si son propriétaire n'avait pas l'utilité d'une machine de bureau, elle n'existerait pas. Mais à partir du moment où elle est connectée 24/7 à Internet, j'ai pris la liberté d'y faire tourner quelques services. Selon moi, ça n'en fait pas un serveur pour autant.
Plus important, ce n'est pas la présence de ces services qui sont la première motivation de la laisser en stable : je ne mets pas en testing une machine connectée 24/7, même avec un firewall. En deuxième, ça réduit les besoins de maintenance, ce qui est tout à fait à mon goût. Et enfin, ces fameux services interdisent de toutes façons autre chose que la branche stable.
Encryption is not magic pixie dust to sprinkle on things to make them more secure.
[^]Re: pas logique
Désolé, c'était une erreur, les commentaires sont désormais ouverts.
En ce qui concerne etch, oui elle sortira quand elle sera prête dans tous les cas. Le challenge est donc qu'elle soit prête dans les délais que l'on souhaite respecter!
[^]Re: pas logique
Cependant, du moins en ce qui me concerne, je ne suis pas convaincu (après lecture rapide, je n'ai pas fait de recherche approfondie).
Certes j'apprécie grandement la distribution et le travail de tous les développeurs, mais ceci dit ça me semble une donnation trop ciblée (du point de vue des récepteurs du don) et pour une cause qui n'est pas justifiée.
Donc oui pour une donation, mais au projet Debian en tant que tout.
[^]Re: pas logique
question de néophite : L'attrait de l'argent ne risque-t-il pas de faire de Debian une machine a fric? Dans le sens ou les intérêts financiers peuvent être plus fort que la stabilité de la version.
En gros, s'ils doivent sortir la future version pour le 4 décembre (et qu'ils ne seront payé que si elle sort le 4 décembre) qu'est-ce qui empeche les "release manager" de sortir leur version même si celle-ci n'est pas complètement finalisée et ce uniquement dans le but de toucher leur argent?
Est-ce que au final on ne risque pas d'avoir une déviance monétaire à la Microsoft (dans une moindre mesure bien évidemment) ?
[+] [^]Re: pas logique
question de néophite : L'attrait de l'argent ne risque-t-il pas de faire de Debian une machine a fric? Dans le sens ou les intérêts financiers peuvent être plus fort que la stabilité de la version.
En gros, s'ils doivent sortir la future version pour le 4 décembre (et qu'ils ne seront payé que si elle sort le 4 décembre) qu'est-ce qui empeche les "release manager" de sortir leur version même si celle-ci n'est pas complètement finalisée et ce uniquement dans le but de toucher leur argent?
Est-ce que au final on ne risque pas d'avoir une déviance monétaire à la Microsoft (dans une moindre mesure bien évidemment) ?