On est vendredi... [etait: Re: Subversion debian 3 woody]
Raphaël SurcouF Bordet a écrit : Le jeu, 01/04/2004 à 13:59 +0200, Georges Mariano a écrit : [...] j'ajoute que si on trouve des arguments/raisons qui expliquent *par l'exemple* en quoi le backport répond à un besoin utilisateur (ce qui figure tout en haut du contrat Debian), j'ai encore pas vu d'argument tangible contre (au sens mise en défaut du mécanisme même du rétro-portage). Tout ce qu'on lit c'est le discours politiquement formaté de ceux qui ont intérêt à ce qu'on reste scotché à une mise à jour binaire (i.e boîte noire) des machines... OK, à condition que le rétroportage fonctionne bien, ce qui est loin d'être vrai dans tous les cas sans rétroporté la version N+1... de la distribution. Quel intérêt aurait-on ? Si tu as envie de développer une distribution annexe basée sur debian et permettant de faire du support sur des vieux paquets, sur une vieille base que tu ne veux pas changer, libre à toi. Attends, suivre une distribution, c'est aussi profiter de tous ses avantages (cohérence, sécurité, support, etc.). Ceci justifie sans problème le choix d'une stable pour travailler, au moins, comme base de travail. Tout le monde ne travaille pas dans une PME ou pour lui ou tout le monde n'est pas étudiant. Dans les grosses boîtes, quand tu as la chance d'avoir du Linux, c'est RH. Si tu proposes autre chose, tu assumes tout seul *toutes* les responsabilités. Si encore tu peux mettre des testing sur des postes bureautiques, c'est tout à fait déconseillé sur un serveur: - Vous avez installé quoi ? - Debian GNU/Linux - C'est bien. Quelle version ? - heu... testing (s/testing/unstable) - Quoi ! Vous prenez l'entreprise pour un centre de test... allez installer une RH 7.3. C'est fini au moins comme truc... etc. Ne t'en déplaise, et comme je l'ai déjà dit ici, pour faire du prosélitisme de Debian en entreprise, le rétroportage est une nécessité tant que Debian ne saura pas faire une release annuelle. Le projet Debian subit des attaques aussi diverses que paradoxales. D'un côté, des utilisateurs de la stable qui voudraient avoir des fonctionnalités ou des versions qui n'existent que dans la distribution de développement et préfèrent les rétro-porter parce que le rythme des sorties ne leur convient pas. Ce n'est pas : « ne leur convient pas ». C'est juste une aberration. Regarde les choses en face. Je suis un fan inconditionnel de Debian mais cela ne m'empêche pas de regarder les choses en face. Debian est complètement à la rue en ce qui concerne le rythme des sorties. Et les choses empirent. La chose marrante est que tout le monde est d'accord et surtout nos chers « lideurs » successifs (cf. leur programme électoral) et rien ne change. En fait, là, je suis de mauvaise foi : cela change. Le temps augmente entre deux releases stables. D'un autre côté, d'autres aimeraient avoir toujours les dernières versions des logiciels et des sorties plus rapides. Si le processus de publication du projet Debian ne plaît pas, il existe bien d'autres distributions Linux pour faire l'affaire: pour les premiers, une RHE est bien mieux indiquée, et pour les seconds, Gentoo me parait un meilleur choix. Bien sûr : plutôt que de tenter de remédier au problème, on botte en touche. Le temps entre deux versions stable est une aberration chronique de Debian. C'est un fait reconnu. Ce n'est pas en disant d'aller voir ailleurs que cela changera quelque chose... Maintenant, si tu as des suggestions crédibles pour améliorer le processus en question, je t'en prie mais argumente ton point de vue sans te prendre pour le centre du monde (cad tes besoins ne sont pas ceux de tous) Pas d'attaque ad hominem, cela ne fait pas avancer le débat. Une solution sera de forcer un gel de testing tous les 6-9 mois. Tant pis pour les paquets qui manquent ce jour-là, ils prendront le prochain train. Le processus de développement de la debian correspond à des critères de qualité et les rares problèmes majeurs en stable proviennent t Le processus de développement Debian est extrêmement lourd et ne correspond pas spécialement à des critères de qualités particuliers. Par contre, l'orientation est clairement *vers* les *développeurs* Debian au *détriment* des utilisateurs finaux. Lis d'ailleurs à ce sujet le questionnaire pour devenir DD. Pas un mot sur l'utilisateur, rien que de la technique. Même si je conviens qu'il est important de recruter des gens qualifiés, le but in fine est tout de même d'offrir une plateforme de travail pour des utilisateurs, pas un concept de branlage de nouille intellectuel (j'exagère... mais à peine). essentiellement de l'usage de paquets non-officiels et rétro-porté, sans parler des logiciels compilés à la main (comme Linux, par exemple). Est-ce que vous avez besoin de stabilité ou des dernières fonctionnalités ? Les deux mon général. C'est un concept inhérent au LL : « release often...». Et l'un n'est pas incompatible avec l'autre. Ce n'est pas
Re: Subversion debian 3 woody
Ce qui serait peut être intéressant là dedans serait de différencier les paquets: Entre un backport de gnome2.4 et faire un backport de nmap ou de gaim, il y a quand même un sacré différence. Si on voit les paquets comme une arborescence, faire un backport d'une feuille pour avoir une version récente (gaim, nmap, lyx, kino, unrar, etc qui sont inutilisables avec les versions actuelles de la woody) me parait bien innocent: le système n'est pas modifié. Il est clair que si on désire maintenant le gnomeeting 0.98 (ne serait ce que parce qu'on est derrière une passerelle sans le NewNAT, cf fil là dessus, j'y ai appris des choses) au lieu de gnomeeting 0.12 (pas tout à fait dernier cri donc), il faut installer tout gnome2, cela ne se limite plus à un simple paquet et bouleverse l'ensemble du système. François Boisson
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
Le ven, 02/04/2004 à 08:35 +0200, Patrice KARATCHENTZEFF a écrit : Quel intérêt aurait-on ? Si tu as envie de développer une distribution annexe basée sur debian et permettant de faire du support sur des vieux paquets, sur une vieille base que tu ne veux pas changer, libre à toi. Attends, suivre une distribution, c'est aussi profiter de tous ses avantages (cohérence, sécurité, support, etc.). Ceci justifie sans problème le choix d'une stable pour travailler, au moins, comme base de travail. Suivre une distribution, dans la mesure où est dans une logique de partage, c'est aussi participer et non seulement en profiter. Tout le monde ne travaille pas dans une PME ou pour lui ou tout le monde n'est pas étudiant. Dans les grosses boîtes, quand tu as la chance d'avoir du Linux, c'est RH. Si tu proposes autre chose, tu assumes tout seul *toutes* les responsabilités. Si encore tu peux mettre des testing sur des postes bureautiques, c'est tout à fait déconseillé sur un serveur: - Vous avez installé quoi ? - Debian GNU/Linux - C'est bien. Quelle version ? - heu... testing (s/testing/unstable) - Quoi ! Vous prenez l'entreprise pour un centre de test... allez installer une RH 7.3. C'est fini au moins comme truc... Oui et tu installes un noyau Linux compilé à la main ou tu gardes les trous de sécurité connus, qui vont avec (sans parler des autres logiciels) ? Sans compter que cette version n'est plus supportée par RedHat Inc. depuis longtemps. A croire que cet argument ne sert qu'aux chefs qui ne veulent pas autre chose que ce qu'ils connaissent: RedHat. Ne t'en déplaise, et comme je l'ai déjà dit ici, pour faire du prosélitisme de Debian en entreprise, le rétroportage est une nécessité tant que Debian ne saura pas faire une release annuelle. Le problème de cette démarche est un paradoxe entier: si la distribution est considérée stable alors, pas de problèmes, même si celle qui a été installée est truffée de paquets rétro-portés des distributions dites de développement voire pire des paquets carrément non-officiels (sans parler des logiciels compilés à la main, notamment Linux lui-même). Dans ces conditions, comment encore parler de distribution stable ? Les rétro-portages peuvent tirer d'affaire mais il ne faut pas en abuser ni s'en faire un crédo... Dans un contexte d'entreprise, s'il faut que la distribution soit estampillée stable, autant prendre autre chose que debian: j'en suis un supporter inconditionnel mais c'est préférable à son discrédit en cas de problèmes (sans parler de son discrédit personnel). Le projet Debian subit des attaques aussi diverses que paradoxales. D'un côté, des utilisateurs de la stable qui voudraient avoir des fonctionnalités ou des versions qui n'existent que dans la distribution de développement et préfèrent les rétro-porter parce que le rythme des sorties ne leur convient pas. Ce n'est pas : « ne leur convient pas ». C'est juste une aberration. Regarde les choses en face. Je suis un fan inconditionnel de Debian mais cela ne m'empêche pas de regarder les choses en face. Debian est complètement à la rue en ce qui concerne le rythme des sorties. En quoi serait-ce une aberration ? On n'a pas signé un contrat avec debian. S'il s'avère qu'elle ne nous satisfait plus, on est encore libre d'en changer: pas mal de personnes ont sauté le pas pour aller vers Gentoo... Et les choses empirent. La chose marrante est que tout le monde est d'accord et surtout nos chers « lideurs » successifs (cf. leur programme électoral) et rien ne change. En fait, là, je suis de mauvaise foi : cela change. Le temps augmente entre deux releases stables. D'un autre côté, d'autres aimeraient avoir toujours les dernières versions des logiciels et des sorties plus rapides. Si le processus de publication du projet Debian ne plaît pas, il existe bien d'autres distributions Linux pour faire l'affaire: pour les premiers, une RHE est bien mieux indiquée, et pour les seconds, Gentoo me parait un meilleur choix. Bien sûr : plutôt que de tenter de remédier au problème, on botte en touche. Le temps entre deux versions stable est une aberration chronique de Debian. C'est un fait reconnu. Ce n'est pas en disant d'aller voir ailleurs que cela changera quelque chose... Et se plaindre à longueur de temps sans rien faire est-il mieux ? Je ne pense pas... Une solution sera de forcer un gel de testing tous les 6-9 mois. Tant pis pour les paquets qui manquent ce jour-là, ils prendront le prochain train. Enfin un bon argument. La question a-t-elle été déjà abordée par les développeurs et, si oui, qu'en est-il ressorti ? Le processus de développement de la debian correspond à des critères de qualité et les rares problèmes majeurs en stable proviennent t Le processus de développement Debian est extrêmement lourd et ne correspond pas spécialement à des critères de qualités particuliers. Par contre, l'orientation est
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
Raphaël SurcouF Bordet a écrit : Le ven, 02/04/2004 à 08:35 +0200, Patrice KARATCHENTZEFF a écrit : [...] Suivre une distribution, dans la mesure où est dans une logique de partage, c'est aussi participer et non seulement en profiter. L'un n'empêche pas l'autre, hein ? [...] Oui et tu installes un noyau Linux compilé à la main ou tu gardes les trous de sécurité connus, qui vont avec (sans parler des autres logiciels) ? Sans compter que cette version n'est plus supportée par RedHat Inc. depuis longtemps. A croire que cet argument ne sert qu'aux chefs qui ne veulent pas autre chose que ce qu'ils connaissent: RedHat. Bienvenue dans le monde réel... Il faut atterrir un peu... le monde réel, c'est cela. C'est dur mais il faut faire avec. Soit tu t'assois par terre avec le troupeau, soit tu avances et proposes autre chose. Debian est une solution... mais une solution qui ne bouche que certains trous. Le boulot de tous les utilisateurs et DD est quand même de boucher ces trous... Ne t'en déplaise, et comme je l'ai déjà dit ici, pour faire du prosélitisme de Debian en entreprise, le rétroportage est une nécessité tant que Debian ne saura pas faire une release annuelle. Le problème de cette démarche est un paradoxe entier: si la distribution est considérée stable alors, pas de problèmes, même si celle qui a été installée est truffée de paquets rétro-portés des distributions dites de développement voire pire des paquets carrément non-officiels (sans parler des logiciels compilés à la main, notamment Linux lui-même). Dans ces conditions, comment encore parler de distribution stable ? Non. Mais au lieu d'aller à la conclusion, va aux prémices : pourquoi est-tu *obligé* de rétroporter ? 1) pas de version « non stable » en entreprise (et pour les pauvres nouilles qui sont en RTC) 2) un temps entre deux versions stables délirant le prérequis 1) n'est pas discutable (au moins sur les serveurs). Un chef d'entreprise se sert de l'informatique pour avancer, pas pour jouer au dé le sort de son entreprise (ce qui ne l'empêche pas de sponsoriser le libre). Le 2) est de la responsabilité de Debian. Dès lors, il est facile de conclure que l'instabilité d'une version stable est de la faute de celui qui rétroporte (et d'ailleurs, ce n'est pas le vrai boulot d'un admin) alors qu'il tente avec les moyens du bord de pallier aux déficiences de Debian... C'est toujours les autres le coupable ? Les rétro-portages peuvent tirer d'affaire mais il ne faut pas en abuser ni s'en faire un crédo... Il ne s'agit pas d'en faire un crédo. C'est un concept inévitable. On peut attendre 9 ou 12 mois pour avoir une version récente de l'ensemble du système. Pas deux ans. Pour rappel : Woody, c'est GNOME 1.4. La version 2.6 va sortir. *3* versions d'écart. C'est un *gouffre* dans le monde du LL... Dans un contexte d'entreprise, s'il faut que la distribution soit estampillée stable, autant prendre autre chose que debian: j'en suis un supporter inconditionnel mais c'est préférable à son discrédit en cas de problèmes (sans parler de son discrédit personnel). Voilà tout le problème de Debian : allez voir ailleurs. Ce n'est pas en fermant les yeux sur les problèmes que l'on va les résoudre. Sinon : Debian 3.1 sorti en 2004 Debian 3.2 sorti en 2012 Debian 3.3 sorti en 2039 Debian 3.4 sorti (pas eu le temps... le soleil s'est éteint avant). Le projet Debian subit des attaques aussi diverses que paradoxales. D'un côté, des utilisateurs de la stable qui voudraient avoir des fonctionnalités ou des versions qui n'existent que dans la distribution de développement et préfèrent les rétro-porter parce que le rythme des sorties ne leur convient pas. Ce n'est pas : « ne leur convient pas ». C'est juste une aberration. Regarde les choses en face. Je suis un fan inconditionnel de Debian mais cela ne m'empêche pas de regarder les choses en face. Debian est complètement à la rue en ce qui concerne le rythme des sorties. En quoi serait-ce une aberration ? On n'a pas signé un contrat avec debian. S'il s'avère qu'elle ne nous satisfait plus, on est encore libre d'en changer: pas mal de personnes ont sauté le pas pour aller vers Gentoo... Gentoo, c'est un truc de geek pour geeks. En entreprise, les gens cherchent des trucs solides, bien pensés et fonctionnels. C'est, je te rappelle, l'objectif de Debian : fournir un OS fonctionnant sur plein de plateforme, facilement maintenable et administrable. [...] Et se plaindre à longueur de temps sans rien faire est-il mieux ? Je ne pense pas... Il y a des gens qui se plaignent *et* font avancer les choses. Une solution sera de forcer un gel de testing tous les 6-9 mois. Tant pis pour les paquets qui manquent ce jour-là, ils prendront le prochain train. Enfin un bon argument. La question a-t-elle été déjà abordée par les développeurs et, si oui, qu'en est-il ressorti ? Une grande engueulade, un échange de nom d'oiseaux, une guerre de
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
Le Fri 2/04/2004, Patrice KARATCHENTZEFF disait Pour rappel : Woody, c'est GNOME 1.4. La version 2.6 va sortir. *3* versions d'écart. C'est un *gouffre* dans le monde du LL... Je ne sais pas si gnome est un bon exemple. Par contre pour revenir à ton exemple précédent de serveur en entreprise, qui veut du stable, il faut aussi des versions toujours supportées par l'upstream. Et en woody on a un postfix 1 qui n'est plus supporté upstream... -- Erwan
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
Bonjour, On Fri, 02 Apr 2004 10:39:52 +0200 Patrice KARATCHENTZEFF [EMAIL PROTECTED] wrote: to: debian-user-french@lists.debian.org Non. Mais au lieu d'aller à la conclusion, va aux prémices : pourquoi est-tu *obligé* de rétroporter ? 1) pas de version « non stable » en entreprise (et pour les pauvres nouilles qui sont en RTC) 2) un temps entre deux versions stables délirant le prérequis 1) n'est pas discutable (au moins sur les serveurs). Un chef d'entreprise se sert de l'informatique pour avancer, pas pour jouer au dé le sort de son entreprise (ce qui ne l'empêche pas de sponsoriser le libre). Ce n'est pas forcement l'avis de tout le monde : ci-joint deux liens d'une discussion sur la ml postfix où des administrateurs justifient l'utilisation de unstable en production : http://groups.google.fr/groups?hl=frlr=ie=UTF-8oe=UTF-8selm=blvtt8%2445h%241%40FreeBSD.csie.NCTU.edu.tw http://groups.google.fr/groups?hl=frlr=ie=UTF-8oe=UTF-8selm=bm0ccv%24gc9%241%40FreeBSD.csie.NCTU.edu.tw Personellement, je n'ai pas de serveur unstable ou testing en production, mais quelques serveurs de tests en testing et je dois avouer que les problèmes sont assez limité (et doivent pouvoir être facilement amortis avec un serveur pour tester les upgrades). Evidemment, il faut pouvoir justifier l'utilisation de tel serveur. Mais dans la mesure où, pour plusieurs paquets critiques, des versions récentes [1] sont nécessaire à la réalisation du projet (pour répondre au cahier des charges), entre entrer dans le jeu sans fin des backports ou avoir un serveur en unstable en production [2], il ne me parrait pas aberrant de se poser la question... Par contre, avant de le faire, je penses qu'il faut s'assurer pendant une periode de test de plusieur mois qu'on est capable de maintenir un serveur unstable. [1] on peut citer postfix, openldap, samba 3 et plein d'autres ou l'apport de fonctionnalités est non négligeable. [2] testing n'étant pas imaginable à mon sens en produciton puisqu'il n'y a pas de mise à jour de sécurité. a+ Julien
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
On Fri, Apr 02, 2004 at 09:44:03AM +0200, Raphaël SurcouF Bordet wrote: A croire que cet argument ne sert qu'aux chefs qui ne veulent pas autre chose que ce qu'ils connaissent: RedHat. Je crois que tu voulais écrire Windows. Dans un contexte d'entreprise, s'il faut que la distribution soit estampillée stable, autant prendre autre chose que debian. Je ne suis absolument pas, mais alors pas du tout, d'acord avec ça (sinon je posterais sur une liste Gentoo ou RH ou Mandrake :-) ). Un problème a mon avis est que le mot 'stable' est vague: personellement, ça n'est pas tellement la fiabilité du système qui m'interesse (car franchement, unstable n'est pas tellement moins fiable), c'est que les numéros de versions ne changent pas tout le temps. Si un trou de sécurité est découvert, je n'ai pas besoin de réinstaller 1243 paquets. Là où je travaille (où je trolle sur duf?) on avait des RH. Ça s'installait bien. Et un jour, on a eu besoin d'installer des outils a nous. Et horreur, on a découvert qu'on avait toutes les versions de RH de 5 à 7, toutes avec des libc différentes, et impossible de partager les binaires, et impossible d'upgrader quoi que ce soit. Maintenant avec Debian, toutes les machines sont sur les mêmes versions de libs et logiciels, et c'est *cette* stabilité qui m'interesse. Maintenant on compile nos outils sur une machine, ils marchent partout. Le jour où Sarge stabilise, on upgrade une machine, on regarde ce qui casse, puis on fait toutes les machines, ça prend une journée et c'est fait. Maintenant, si on a besoin d'une version plus récente de tcpdump ou de strace, il suffit de faire un backport et tout le monde peut l'avoir également. En comparaison, mes 2 PCs à la maison, où j'utilise unstable, ne sont pratiquement jamais aux mêmes versions (c'est ma faute, je suis pas organisé). (Récement j'ai eu besoin de wget sur une machine RedHat ancestrale. Impossible bien entendu d'installer un RPM (ils ne sont même plus disponibles sur redhat.com d'ailleurs), ça s'est fini avec apt-get source wget sur une Debian et make sur une RH: on peut même backporter sur des distribs différentes :-) ). Et comme dit François, il faut faire la différence entre backporter tcpdump ou GAIM, et backporter Gnome ou KDE. j'en suis un supporter inconditionnel mais c'est préférable à son discrédit en cas de problèmes (sans parler de son discrédit personnel). Qui aime bien, chatie bien; y'a pas de mal à dire qu'il y a des problèmes quand il y a des problèmes. pas mal de personnes ont sauté le pas pour aller vers Gentoo... Gentoo en entreprise? Les derniers pilotes sont toujours les plus stables... question de débogage et d'utilisation. Sinon, tout le monde utiliserait encore un noyau 0.99pre192. Hmm, tout le monde n'utilise pas linux 2.6.4 non plus :) Y.
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
Raphaël SurcouF Bordet a écrit : [...] allez installer une RH 7.3. C'est fini au moins comme truc... Oui et tu installes un noyau Linux compilé à la main ou tu gardes les trous de sécurité connus, qui vont avec (sans parler des autres logiciels) ? Sans compter que cette version n'est plus supportée par RedHat Inc. depuis longtemps. Le support (maj securite) existait jusqu'au 31/12/2003 minuit. Pour RH9, c'est jusqu'au 30/04/2004 minuit [...] -- : __ __ __ __ __ __ [EMAIL PROTECTED] : /_// __ // __ //_// __ // / phone.: +48 32 285 5276 : / / / /_/ // /_/ / / / / /_/ // / fax: +48 32 285 5276 : /_/ /_//_/ /_/ /_/ /_//_/ mobile..: +48 602 284 546
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
Patrice KARATCHENTZEFF [EMAIL PROTECTED] writes: [...] Et pourquoi Debian ne ferait-il pas la même chose ? On démarre le premier janvier, on gèle en septembre, on release le 25 décembre et rebelotte ? Tu parles beaucoup de réalité en entreprise etc... hors en entreprise justement ce qui est important c'est d'avoir quelque chose de stable dans le sens qui ne bouge pas étant donné que chaque changement a un coût (phase de test, changement d'habitudes, formation). Bien sur il faut évoluer de temps en temps, mais le cycle souhaité est rarement en dessous de 2 ans et bien plus dans le monde industriel et dans l'administration par ex. C'est une règle d'or en informatique, on ne touche pas quelque chose qui marche ! Qui a été nuancée du fait des problèmes de sécurité uniquement. 1 an c'est bien trop court, imagine quand tu développe une grosse application, ça prend facilement 1 an. Si le jour où tu la sort le système sous-jacent a complètement changé t'es foutu... -- William - http://flibuste.net
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
William Dode a écrit : Patrice KARATCHENTZEFF [EMAIL PROTECTED] writes: [...] Et pourquoi Debian ne ferait-il pas la même chose ? On démarre le premier janvier, on gèle en septembre, on release le 25 décembre et rebelotte ? Tu parles beaucoup de réalité en entreprise etc... hors en entreprise justement ce qui est important c'est d'avoir quelque chose de stable dans le sens qui ne bouge pas étant donné que chaque changement a un coût (phase de test, changement d'habitudes, formation). Bien sur il faut évoluer de temps en temps, mais le cycle souhaité est rarement en dessous de 2 ans et bien plus dans le monde industriel et dans l'administration par ex. C'est une règle d'or en informatique, on ne touche pas quelque chose qui marche ! Qui a été nuancée du fait des problèmes de sécurité uniquement. 1 an c'est bien trop court, imagine quand tu développe une grosse application, ça prend facilement 1 an. Si le jour où tu la sort le système sous-jacent a complètement changé t'es foutu... Là je suis entièrement d'accord, 1 an c'est trop court. Et en général tant qu'on à pas besoin d'une nouvelle fonctionnalité autant rester sur ce qui marche. Par contre il y'a le soucis de certains packages... Notamment Postfix, Samba, Clamav, etc... On est bien obligé de backporter clamav si l'on veux un anti virus sur sa messagerie. Quand à KDE c'est un autre soucis, on parle là de station cliente (je n'ai pas d'interface graphique sur les serveurs), et il est vrai que pour une station cliente le développement Debian est bien long car les applis bougent bcp. Il serait intérréssant de tenir 2 ans en moyenne sur une version, enfin c mon avis... Mais pour un serveur il est vrai que ça fait court... sich
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
William Dode a écrit : Patrice KARATCHENTZEFF [EMAIL PROTECTED] writes: [...] Et pourquoi Debian ne ferait-il pas la même chose ? On démarre le premier janvier, on gèle en septembre, on release le 25 décembre et rebelotte ? Tu parles beaucoup de réalité en entreprise etc... hors en entreprise justement ce qui est important c'est d'avoir quelque chose de stable dans le sens qui ne bouge pas étant donné que chaque changement a un coût (phase de test, changement d'habitudes, formation). Bien sur il faut évoluer de temps en temps, mais le cycle souhaité est rarement en dessous de 2 ans et bien plus dans le monde industriel et dans l'administration par ex. C'est une règle d'or en informatique, on ne touche pas quelque chose qui marche ! Qui a été nuancée du fait des problèmes de sécurité uniquement. 1 an c'est bien trop court, imagine quand tu développe une grosse application, ça prend facilement 1 an. Si le jour où tu la sort le système sous-jacent a complètement changé t'es foutu... Oui, et que se passe t'il si le jour ou tu la sors le systeme sous-jacent n'est plus maintenu ou n'evoluera plus? (radiusd-cistron woody par ex.)? Lorsqu'on developpe on choisit: on est compatible avec l'existant ou on repart a zero avec les produits existant: dans ce cas on suit l'evolution. Dans cette affaire tout le monde a raison ou tord. Il y a des entreprises/metiers qui *ont* besoin de packages recents, d'autres peuvent se permettre de rester scotche avec une version d'il y a 2 ans ou plus. Reste a trouve le juste milieu pour Debian. Le delai actuel me parait tout de meme long. Au fait: qui de vous a virer son W98SE pour XP? ;-) -- : __ __ __ __ __ __ [EMAIL PROTECTED] : /_// __ // __ //_// __ // / phone.: +48 32 285 5276 : / / / /_/ // /_/ / / / / /_/ // / fax: +48 32 285 5276 : /_/ /_//_/ /_/ /_/ /_//_/ mobile..: +48 602 284 546
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
Le ven, 02/04/2004 à 11:03 +0100, Yves Rutschle a écrit : On Fri, Apr 02, 2004 at 09:44:03AM +0200, Raphaël SurcouF Bordet wrote: A croire que cet argument ne sert qu'aux chefs qui ne veulent pas autre chose que ce qu'ils connaissent: RedHat. Je crois que tu voulais écrire Windows. Non, non: quand ils te disent Linux, faut comprendre RedHat Linux. Dans un contexte d'entreprise, s'il faut que la distribution soit estampillée stable, autant prendre autre chose que debian. Je ne suis absolument pas, mais alors pas du tout, d'acord avec ça (sinon je posterais sur une liste Gentoo ou RH ou Mandrake :-) ). Un problème a mon avis est que le mot 'stable' est vague: personellement, ça n'est pas tellement la fiabilité du système qui m'interesse (car franchement, unstable n'est pas tellement moins fiable), c'est que les numéros de versions ne changent pas tout le temps. Si un trou de sécurité est découvert, je n'ai pas besoin de réinstaller 1243 paquets. Le problème est justement qu'on te demande une distribution dite stable avec un numéro de version, etc.. Essaie de proposer une debian testing/unstable dans un tel contexte, tu verras assez vite les réticences... Ensuite, je n'ai jamais dit que l'unstable était si instable que ça: elle vaut bien certaines versions pourtant considérées stables des autres distributions, voire même mieux. Quant aux correctifs de sécurité, j'apprécie tout autant la méthode de debian: corriger uniquement l'anomalie sans changer de version. Là où je travaille (où je trolle sur duf?) on avait des RH. Ça s'installait bien. Et un jour, on a eu besoin d'installer des outils a nous. Et horreur, on a découvert qu'on avait toutes les versions de RH de 5 à 7, toutes avec des libc différentes, et impossible de partager les binaires, et impossible d'upgrader quoi que ce soit. Je suis bien d'accord mais va dire d'installer une distribution Linux qui n'est pas supportée par l'éditeur propriétaire d'un logiciel (Oracle pour ne pas le citer) très utilisé par l'entreprise et la réponse sera non... [...] Et comme dit François, il faut faire la différence entre backporter tcpdump ou GAIM, et backporter Gnome ou KDE. Tout à fait d'accord: avec modération et en connaissance de cause. j'en suis un supporter inconditionnel mais c'est préférable à son discrédit en cas de problèmes (sans parler de son discrédit personnel). Qui aime bien, chatie bien; y'a pas de mal à dire qu'il y a des problèmes quand il y a des problèmes. Dire qu'il y a un problème, oui. Se plaindre à longueur de temps, c'est lassant... pas mal de personnes ont sauté le pas pour aller vers Gentoo... Gentoo en entreprise? Je devrais baliser le public concernés à chaque généralisation de ce type car dans toute cette discussion, on peut distinguer plusieurs catégories d'utilisateurs: - utilisateurs en enteprise, - utilisateurs particuliers. Et je connais des professionnels qui utilisent gentoo mais mon propos n'est pas de faire du prosélytisme de cette distribution. -- Raphaël 'SurcouF' Bordet [EMAIL PROTECTED]
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
Le ven, 02/04/2004 à 12:17 +0200, [EMAIL PROTECTED] a écrit : Evidemment, il faut pouvoir justifier l'utilisation de tel serveur. Mais dans la mesure où, pour plusieurs paquets critiques, des versions récentes [1] sont nécessaire à la réalisation du projet (pour répondre au cahier des charges), entre entrer dans le jeu sans fin des backports ou avoir un serveur en unstable en production [2], il ne me parrait pas aberrant de se poser la question... [...] [2] testing n'étant pas imaginable à mon sens en produciton puisqu'il n'y a pas de mise à jour de sécurité. Exact mais rien n'empêche de récupérer les paquets de l'unstable mis à jour si nécessaire: la priorité de telles mises à jour est généralement haute et la quarantaine n'est alors que de deux jours. -- Raphaël 'SurcouF' Bordet [EMAIL PROTECTED]
Re: On est vendredi... [etait: Re: Subversion debian 3 woody]
[EMAIL PROTECTED] a écrit : [...] Ce n'est pas forcement l'avis de tout le monde : ci-joint deux liens d'une discussion sur la ml postfix où des administrateurs justifient l'utilisation de unstable en production : Attention, tu ne m'as pas compris : ce n'est pas moi qui émet un avis, c'est celui de la DSI... En tant que technicien, il est évident qu'avoir un serveur en testing/unstable ne pose pas de problèmes majeurs (en tout cas, pas plus que de gérer un RH au quotidien). Le problème n'est pas là : si Debian propose une version stable, c'est a priori pour bosser dessus (et rassurer un DSI au passage...). Personellement, je n'ai pas de serveur unstable ou testing en production, mais quelques serveurs de tests en testing et je dois avouer que les problèmes sont assez limité (et doivent pouvoir être facilement amortis avec un serveur pour tester les upgrades). On est d'accord. Evidemment, il faut pouvoir justifier l'utilisation de tel serveur. Mais dans la mesure où, pour plusieurs paquets critiques, des versions récentes [1] sont nécessaire à la réalisation du projet (pour répondre au cahier des charges), entre entrer dans le jeu sans fin des backports ou avoir un serveur en unstable en production [2], il ne me parrait pas aberrant de se poser la question... Par contre, avant de le faire, je penses qu'il faut s'assurer pendant une periode de test de plusieur mois qu'on est capable de maintenir un serveur unstable. [1] on peut citer postfix, openldap, samba 3 et plein d'autres ou l'apport de fonctionnalités est non négligeable. [2] testing n'étant pas imaginable à mon sens en produciton puisqu'il n'y a pas de mise à jour de sécurité. disons que c'est à toi de faire la veille de sécu, c'est normal puisque ce n'est pas fait pour être mis en prod ;-) PK -- Patrice KARATCHENTZEFF STMicroelectronics Tel: 04-76-92-67-96 850, rue Jean Monnet 38926 CROLLES Cedex, Courriel: [EMAIL PROTECTED]
Re: Subversion debian 3 woody
On Wed, 31 Mar 2004 10:52:13 +0200, Raphaël SurcouF Bordet wrote: Inutile de rappeler mon opinion sur les paquets rétro-portés... oui, c'est effectivement inutile. Car ton point de vue à ceci de paradoxal que, vu que tu n'aimes pas la backport, tu n'en fais pas je présume, ce qui ne t'empêche pas d'en parler de manière négative sans vraiment en comprendre ni le fonctionnement (pur debian en fait) ni l'utilité ... j'ajoute que si on trouve des arguments/raisons qui expliquent *par l'exemple* en quoi le backport répond à un besoin utilisateur (ce qui figure tout en haut du contrat Debian), j'ai encore pas vu d'argument tangible contre (au sens mise en défaut du mécanisme même du rétro-portage). Tout ce qu'on lit c'est le discours politiquement formaté de ceux qui ont intérêt à ce qu'on reste scotché à une mise à jour binaire (i.e boîte noire) des machines... Le hasard fait que je viens de tomber sur un petit exemple bien sympathique. J'espère qu'il est suffisamment simple pour que chacun pige ce qui se passe. * tout commence lorsque je m'aperçois que je n'ai pas installé syslog-summary avec mon logcheck. * apt-get -s install syslog-summary -t stable = ok, 1 paquet v 1.11 * apt-get -s install syslog-summary -t testing = argh!! 19 paquets à mettre à installer (dont gtkglarea5 iceme python xlibmesa3) pour avoir la version 1.12 (notez au passage le saut phénoménal en version qui justifie la mise à jour d'autant de paquets) [*] * évidemment, il n'est pas nécessaire que syslog-summary dépende de python dernier cri, je vous refait pas le coups du backport qui prend 2mn pour avoir un paquet avec les dépendances correctes et qui s'installe bien sur votre machine bien stable sans prendre le moindre risque (sauf celui de casser syslog-summary, mais ça c'est normal) Subversion dépend étroitement d'Apache 2, Largement discutable pour ne pas dire foutaise, comme il a été dit ici : Subversion also offers a standalone server option using a custom protocol (not everyone wants to run Apache 2.x) C'est sur la page des features de subversion, i.e des trucs **positifs**, je traduis : c'est un bon point de ne pas dépendre d'apache2 d'ailleurs : apt-cache show subversion | grep -i apache donne rien, y'a mieux comme dépendance étroite... Bon, j'arrête là, j'ai déjà perdu assez de temps[**] à essayer de montrer qu'il est possible de sortir des affirmations à l'emporte pièce et de discuter d'un sujet avec un minimum d'argument tangibles (ce pourquoi je n'ai pas attendu demain, il ne s'agit donc pas d'un troll ;-) [*] le nombre exact de paquets à mettre à jour dépend évidemment de votre stableité actuelle, si vous êtes en sid, ça passe tout seul hein ;-) [**] oui parce qu'un message argumenté nécessite de passer du temps à consulter les rapports de bugs, faire le backport, tester les mises à jours (dans le chroot, en dehors du chroot), tester un peu le paquet obtenu... Tout ce que l'on peut s'épargner par la phrase radicale mais vide de sens : le backport c'est mal (DebianTM). Aller, note finale d'humour : je vous laisse admirer le bug (clos!!) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171043 A+
Re: Subversion debian 3 woody
Le jeu, 01/04/2004 à 13:59 +0200, Georges Mariano a écrit : On Wed, 31 Mar 2004 10:52:13 +0200, Raphaël SurcouF Bordet wrote: Inutile de rappeler mon opinion sur les paquets rétro-portés... oui, c'est effectivement inutile. Car ton point de vue à ceci de paradoxal que, vu que tu n'aimes pas la backport, tu n'en fais pas je présume, ce qui ne t'empêche pas d'en parler de manière négative sans vraiment en comprendre ni le fonctionnement (pur debian en fait) ni l'utilité ... A-t-on besoin d'essayer pour en discuter ? J'ai passé mes premières années sous Linux à gérer des RedHat. Là, tu n'avais pas d'outils comme apt et surtout une base de paquets si exhaustive et passer d'une version à une autre était un véritable sacerdoce. Cerise sur le gâteau: aucun support à attendre de la part de RedHat quant aux paquets rpm (quand on en avait) externes. j'ajoute que si on trouve des arguments/raisons qui expliquent *par l'exemple* en quoi le backport répond à un besoin utilisateur (ce qui figure tout en haut du contrat Debian), j'ai encore pas vu d'argument tangible contre (au sens mise en défaut du mécanisme même du rétro-portage). Tout ce qu'on lit c'est le discours politiquement formaté de ceux qui ont intérêt à ce qu'on reste scotché à une mise à jour binaire (i.e boîte noire) des machines... Quel intérêt aurait-on ? Si tu as envie de développer une distribution annexe basée sur debian et permettant de faire du support sur des vieux paquets, sur une vieille base que tu ne veux pas changer, libre à toi. Le projet Debian subit des attaques aussi diverses que paradoxales. D'un côté, des utilisateurs de la stable qui voudraient avoir des fonctionnalités ou des versions qui n'existent que dans la distribution de développement et préfèrent les rétro-porter parce que le rythme des sorties ne leur convient pas. D'un autre côté, d'autres aimeraient avoir toujours les dernières versions des logiciels et des sorties plus rapides. Si le processus de publication du projet Debian ne plaît pas, il existe bien d'autres distributions Linux pour faire l'affaire: pour les premiers, une RHE est bien mieux indiquée, et pour les seconds, Gentoo me parait un meilleur choix. Maintenant, si tu as des suggestions crédibles pour améliorer le processus en question, je t'en prie mais argumente ton point de vue sans te prendre pour le centre du monde (cad tes besoins ne sont pas ceux de tous) Le processus de développement de la debian correspond à des critères de qualité et les rares problèmes majeurs en stable proviennent essentiellement de l'usage de paquets non-officiels et rétro-porté, sans parler des logiciels compilés à la main (comme Linux, par exemple). Est-ce que vous avez besoin de stabilité ou des dernières fonctionnalités ? Oui, supporter le matériel parait être une bonne raison mais en quoi le dernier cri en matière de matériel est-il nécessairement un critère de ...stabilité ? En aucune façon... Le hasard fait que je viens de tomber sur un petit exemple bien sympathique. J'espère qu'il est suffisamment simple pour que chacun pige ce qui se passe. * tout commence lorsque je m'aperçois que je n'ai pas installé syslog-summary avec mon logcheck. * apt-get -s install syslog-summary -t stable = ok, 1 paquet v 1.11 * apt-get -s install syslog-summary -t testing = argh!! 19 paquets à mettre à installer (dont gtkglarea5 iceme python xlibmesa3) pour avoir la version 1.12 (notez au passage le saut phénoménal en version qui justifie la mise à jour d'autant de paquets) [*] Oui, parce que tu n'utilises pas de testing et donc les paquets dont dépend ce paquet ne sont pas ceux de la stable. Maintenant, si tu vois des objections quant à la pertinence des dépendances, libre à toi d'en faire part de façon moins polémique au responsable. Il sera toujours prêt à entendre ton avis et tu as intérêt à bien argumenter. Et de telles remarques, j'en ai déjà fait: qu'elles soient suivies ou non, l'important est de discuter avec les développeurs: ils ne sont pas inaccessibles, loin de là et ce serait mieux de cracher dans la soupe (se plaindre publiquement du projet et, à la moindre contrariété, faire tout à sa sauce au lieu de participer à ce même projet). Dans ce cas précis, tu peux toujours chercher à discuter de la pertinence d'un champ Provides: python-interpreter avec eux. * évidemment, il n'est pas nécessaire que syslog-summary dépende de python dernier cri, je vous refait pas le coups du backport qui prend 2mn pour avoir un paquet avec les dépendances correctes et qui s'installe bien sur votre machine bien stable sans prendre le moindre risque (sauf celui de casser syslog-summary, mais ça c'est normal) Rien ne t'empêche de le faire mais ne viens pas polluer le bts si jamais tu as des problèmes par la suite... Car la véritable question est bien là: comment supporter de tels paquets, pour le projet ? Impossible à faire pour les développeurs... Et surtout, ce serait bien plus de travail pour eux.
Subversion debian 3 woody
Bonjour a tous, j'ai une machine des plus stables tournant sans souci depuis plus d'un an sous woody, et là j'ai un besoin pressant d'installer un CVS-like dessus.Les personnes qui vont l'utiliser n'etant pas du tout des programmeurs,elles trouvent CVS rugueux, de plus j'ai bien envie de tester Subversion :) j'ai vu qu'il y avait des paquets pour unstable et des backports pour stable. Est ce que quelqu'un a testé ? Ne vais je pas casser ma jolie machine ? :) en fait il faut installer un paquet de trucs dont Apache 2.0.48,db4, SWIG etc... donc j'hesite... toute opinion bienvenue Jerome -- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13=9782212111941
Re: Subversion debian 3 woody
Le mer, 31/03/2004 à 10:25 +0200, jerome moliere a écrit : Bonjour a tous, j'ai une machine des plus stables tournant sans souci depuis plus d'un an sous woody, et là j'ai un besoin pressant d'installer un CVS-like dessus.Les personnes qui vont l'utiliser n'etant pas du tout des programmeurs,elles trouvent CVS rugueux, de plus j'ai bien envie de tester Subversion :) j'ai vu qu'il y avait des paquets pour unstable et des backports pour stable. Est ce que quelqu'un a testé ? Ne vais je pas casser ma jolie machine ? :) en fait il faut installer un paquet de trucs dont Apache 2.0.48,db4, SWIG etc... donc j'hesite... toute opinion bienvenue Actuellement, il y a la 1.0.0 dans testing et la 1.0.1 dans l'unstable. Inutile de rappeler mon opinion sur les paquets rétro-portés... Subversion dépend étroitement d'Apache 2, aussi l'installer sur une stable qui n'est pas prévu pour cela présente en effet des risques: tu te retrouverais non plus avec une debian stable mais avec une debian hybride qui n'aura de stable que le nom dans /etc/debian_version. -- Raphaël 'SurcouF' Bordet [EMAIL PROTECTED]
Re: Subversion debian 3 woody
Actuellement, il y a la 1.0.0 dans testing et la 1.0.1 dans l'unstable. Inutile de rappeler mon opinion sur les paquets rétro-portés... un petit condensé pour ceux yaant loupé les épisodes précédents ? :) Subversion dépend étroitement d'Apache 2, aussi l'installer sur une stable qui n'est pas prévu pour cela présente en effet des risques: tu te retrouverais non plus avec une debian stable mais avec une debian hybride qui n'aura de stable que le nom dans /etc/debian_version. c'est bien ce que je craignais je vais le coller sur une redhat mais cela m'embete un peu, cette machine n'est pas destinéeà rester up tout le temps merci Jerome -- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13=9782212111941
Re: Subversion debian 3 woody
jerome moliere [EMAIL PROTECTED] writes: Bonjour a tous, j'ai une machine des plus stables tournant sans souci depuis plus d'un an sous woody, et là j'ai un besoin pressant d'installer un CVS-like dessus.Les personnes qui vont l'utiliser n'etant pas du tout des programmeurs,elles trouvent CVS rugueux, de plus j'ai bien envie de tester Subversion :) j'ai vu qu'il y avait des paquets pour unstable et des backports pour stable. Est ce que quelqu'un a testé ? Ne vais je pas casser ma jolie machine ? :) en fait il faut installer un paquet de trucs dont Apache 2.0.48,db4, SWIG etc... donc j'hesite... Pour ma part j'ai choisi gnuarch. Un des avantages est justement qu'il n'y a *strictement* rien à installer sur le serveur. Au niveau rugosité de l'utilisation client, on peut se limiter à une utilisation centralisé (partage d'un répertoire du serveur en sftp), les commandes sont alors très simple tla missing, tla what-changed, tla update, tla commit. Les plus hardis créront leurs propres branches sans déranger les autres... Ceci dit, il n'est pas indispensable d'installer apache 2 pour subversion, il peut aussi tourner en serveur autonome. -- William - http://flibuste.net
Re: Subversion debian 3 woody
c'est bien ce que je craignais je vais le coller sur une redhat mais cela m'embete un peu, cette machine n'est pas destinéeà rester up tout le temps merci Jerome -- Non, installe un debootsrap en sage ou woody avec subversion et apache2 dessus. Ta machine reste en stable et tu as subversion en sarge ou sid dessus. Que veux tu de plus? François Boisson
