Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 02-03-2011 04:12:50

martinux_qc
Administrateur
Lieu : Montréal (Québec)
Distrib. : Sid
Noyau : Linux 4.7.0-1-amd64
(G)UI : XFCE 4.12
Inscription : 12-10-2008

À propos de Debian Testing et du projet CUT (Constantly Usable Testing

Salut

Sur le site de Raphael Hertzog (développeur Debian et co-auteur du livre "Cahier de l’Admin Debian Lenny"), on peut lire un article intéressant où il décrit, dans un premier temps, ce qu'est Debian unstable et Debian testing pour les dévelopeurs et met en garde les utilisateurs quant à l'utilisation de Testing. Puis, il s'attarde surtout à présenter le projet de « Testing Constamment Utilisable » — Constantly Usable Testing (CUT) et à identifier les défis à surmonter pour le réaliser.

On peut lire cet article ainsi que des commentaires en suivant ce lien.

Je me permet tout de même de reproduire ici l'article en entier.

Debian peut-elle proposer une distribution testing constamment utilisable ?
Posted on 28/02/2011 by Raphaël Hertzog

Testing est le dépôt où Debian prépare la prochaine version stable, et bien que cela reste sa mission première, de nombreux utilisateurs l’ont adoptée en tant que distribution courante, leurs offrant un bon compromis entre stabilité et « fraîcheur » des paquets. Il y a cependant des inconvénients à l’utiliser dans cette optique et le projet de « Testing Constamment Utilisable » — Constantly Usable Testing (CUT) — tend à les résorber. Cet article présente ce projet ainsi que les défis à surmonter pour y parvenir.

À propos de Debian unstable et Debian testing

Debian unstable est le premier dépôt dans lequel les nouvelles versions des paquets sont envoyées. Il est ainsi très fréquent que certains paquets n’y soient pas utilisables du fait de modifications dans des dépendances ou tout simplement parce que leur mise à jour n’est pas totalement terminée.

Debian testing assure a contrario la cohérence de son écosystème. La nouvelle version d’un paquet dans unstable n’est répliquée dans testing que si le paquet a été suffisamment testé (au bout de 10 jours, habituellement), s’il est exempt de nouveau bogue critique, s’il est disponible pour toutes les architectures supportées, et enfin s’il ne « casse » aucun autre paquet déjà présent dans testing. La Release Team (RT) contrôle ce processus et aide à cibler les ensembles de paquets candidats au passage de unstable vers testing.

Ces dispositions permettent également d’assurer avec une relativement bonne probabilité que les paquets qui migrent vers testing sont exempts de bugs rédhibitoires (qui empêchent le boot par exemple, ou X de démarrer). Cette caractéristique rend testing particulièrement attractive pour les utilisateurs intéressés par les dernières versions des logiciels qu’ils utilisent, débarassées toutefois des plus gros bugs les affectant. Bien que l’exposé fasse apparaître testing très séduisante, les développeurs Debian recommandent de ne pas l’utiliser dans cette optique. Pourquoi donc ?

Problèmes connus dans testing

Disparition de logiciels

La Release Team utilise ce dépôt pour préparer la prochaine version stable et, de temps à autre, en retire des paquets. Soit parce que la migration d’autres paquets de unstable vers testing le requiert, soit parce qu’ils sont affectés par des bugs critiques qui ne semblent pas être en voie de résolution. Il arrive également que des paquets soient retirés sur la demande des mainteneurs de ces derniers, dans la mesure où ils pensent que la version actuelle du paquet ne pourra être maintenue (question sécurité) pour les 2 années à venir ou plus. L’équipe Debian en charge de la sécurité émet également régulièrement de telles requêtes.

Délais de correction important pour les failles de sécurité / bugs importants

Malgré la période d’attente de 10 jours minimum dans unstable, certains bugs « très ennuyeux » ne sont découverts qu’une fois dans testing (y compris les failles de sécurité). Bien que le mainteneur puisse être très rapide à renvoyer une version corrigée dans unstable, voire à élever l’importance de la correction à « urgent » pour accélérer la migration, il arrive que cette dernière doive attendre la fin d’une migration massive de paquets en cours, ce qui peut parfois prendre des semaines.

Cette attente peut être court-circuitée en envoyant le paquet corrigé directement dans testing (via testing-proposed-updates), mais cela n’arrive que rarement hors période de gel, où la résolution d’anomalies bien définies devient la norme.

Pas toujours installable…

Testing évoluant quotidiennement, il arrive que les modifications « brisent » les dernières images d’installation disponibles (les netboot en particulier, permettant de tout récupérer par le réseau). Les paquets de l’installeur Debian sont généralement corrigés rapidement, mais ne migrent pas automatiquement vers testing car la combinaison de tous les paquets de l’installeur n’a pas forcément déjà été validée. Colin Watson résume le problème :

    Migrer le nouveau code de l’installeur vers testing prend trop de temps, et par conséquent les anomalies restent non corrigées dans testing pendant trop longtemps. [...] Le problème actuel concernant le développement de l’installeur Debian tient plus du fait que nous sommes trop lents à publier de nouvelles *versions* de ce dernier. [...] Les options qui s’offrent à vous sont soit de travailler avec la version stable (trop vieille), soit la version testing (intéressante sauf lorsque rendue inutilisable, sachant que cela prend une semaine à tout corriger), soit enfin la version instable (perpétuellement brisée).

Origine de CUT

CUT trouve ses origines dans une ancienne proposition de Joey Hess poussant l’idée qu’une version stable n’était pas le seul produit de Debian et que testing pouvait, avec « du travail », devenir un choix viable pour les utilisateurs finaux. Mais personne ne prit à son compte ce « travail » et aucun progrès ne fut fait ces 3 dernières années.

Mais Joey relança récemment la question de TCU sur la liste de diffusion de testing et Stefano Zacchiroli (le chef de projet Debian) le mit au défi de monter un atelier TCU pour DebConf10. Cet atelier fut l’un des plus attendus de la conférence (vidéo disponible ici), témoignant de l’intérêt majeur porté à ce sujet.

Un wiki dédié est maintenant disponible, ainsi qu’une page et une liste de diffusion. La suite de cet article tente de résumer les différentes options proposées et la manière dont elles entendent résoudre les problèmes identifiés.
CUT : choix du mode de fonctionnement

Parmi toutes les solutions possibles, deux approches ont été particulièrement approfondies. La première consiste à faire une image régulière de testing à des états réputés – relativement - stables. Ces images seraient alors nommées « cut ». La seconde serait de bâtir une distribution testing améliorée (« rolling »), conçue pour répondre aux attentes des utilisateurs souhaitant des mises à jour quotidiennes.
Images régulières de testing

La nécessité de telles images « instantanées » de testing recueille un large consensus, étant la seule solution garantissant la viabilité de l’installeur généré jusqu’à la prochaine image. Si l’image générée ne montre aucun problème sérieux, alors elle devient la dernière cut en date. La codification serait de type « cut-AAAA-MM » pour plus de clarté, la cut-2010-09 serait donc l’instantané de septembre 2010 par exemple.

Bien que non définitive, une approche « agressive » de la fréquence de capture des images est plébiscitée : au pire tous les 6 mois, mais une base mensuelle a également été proposée. La décision finale doit prendre en compte plusieurs aspects.

L’un de ceux-ci (et probablement le plus important) tient à la sécurité. Etant donné que l’équipe en charge de la sécurité est déjà sous l’eau, il serait difficile de proclamer que tout instantané sera supporté comme une version stable sans les faire sombrer. A l’inverse, aucun support sécurité semble de prime abord impensable, bien que l’on puisse y objecter un argument de poids : le suivi sécurité de testing est généralement meilleur que celui de la version stable (cf. le security tracker). En effet, les corrections de sécurité arrivent naturellement avec les migrations dans testing. Debian stable obtient toujours les corrections de sécurité importantes plus rapidement que testing mais, dans l’ensemble, il existe moins de failles de sécurité connues dans testing que dans la version stable à un instant donné.

Etant donné que les patches de sécurité ne sont qu’affaire de temps, une fréquence élevée de cut entraîne une obtention plus rapide des correctifs pour les utilisateurs. Mais Stefan Fritsch, qui fit parti autrefois de la Debian testing security team, a également relevé les inconvénients que cela occasionne pour les contributeurs des correctifs de sécurité :

    Les mises à jour de sécurité ne sont utiles dans testing que pendant quelques semaines, jusqu’à ce qu’une version corrigée du paquet ne migre depuis unstable. Dans la version stable, les correctifs restent appliquées pendant quelques années, ce qui motive bien plus à les réaliser.

S’il est difficile de former une équipe chargée de la sécurité dédiée, alors le travail d’application des correctifs de sécurité incombe aux mainteneurs des paquets concernés. Ceux-ci envoient généralement assez rapidement la version corrigée dans unstable, mais ne prêtent pas attention à la migration de la version vers testing — ce dont on ne peut les blâmer : testing étant initialement prévue pour préparer la prochaine version stable, il n’y a aucune urgence à ce que la correction y parvienne, tant qu’elle intervient avant le lancement de la nouvelle version stable.

CUT peut précisément aider à faire bouger les lignes sur ce point, étant donné qu’à travers elle des utilisateurs finaux seront censés utiliser au quotidien des paquets de testing, et qu’ils méritent donc des mises à jour de sécurité au même titre que ceux utilisant la version stable.

Un autre aspect à considérer quant à la détermination de la fréquence de cut est l’ensemble du travail demandé pour toute sortie de version officielle : tester les montées de version, documenter les changements et préparer les images d’installation. Il semble difficile d’accomplir ce travail tous les mois. Cette fréquence ne permet pas non plus de fournir une nouvelle révision majeure du noyau avec chaque cut (puisque ce dernier est publié tous les 2-3 mois). Or un nouveau noyau est toujours intéressant pour les utilisateurs puisqu’il vient avec son lot de nouveau matériel supporté.

En résumé, la publication d’instantanés apporte une solution au problème d’une testing pas toujours installable, et change la perception qu’ont les mainteneurs de cette dernière, de telle sorte qu’on puisse espérer qu’ils apportent plus d’attention aux mises à jour de sécurité dans testing, et donc dans les cuts. Mais cela ne résout pas la problématique des paquets qui « disparaissent ». Une autre approche est nécessaire pour adresser ce problème.
Une nouvelle distribution rolling?

Lucas Nussbaum a mis en évidence que des instantanés de Debian n’étaient pas vraiment un concept novateur :

    En quoi cela se différencierait-il des autres distributions s’imposant un cycle de publication de 6 mois, et en particulier d’Ubuntu, qui s’apparente déjà à une image instantanée de Debian (+ valeur ajoutée) ?

CUT ne devient intéressante pour Lucas que si elle est capable de fournir une distribution type rolling release (à l’instar de testing) avec un « flux constant de publications amont ». Ce serait pour lui « unique dans le monde du Logiciel Libre ». Les instantanés seraient utilisés comme point de départ pour l’installation, et le système installé pointerait vers les archives de la distribution, de telle sorte que les utilisateurs mettraient à jour aussi souvent qu’ils le désireraient. Les mises à jour de sécurité ne sont pas très importantes dans ce scénario, au contraire de l’état de la distribution.

Mais si c’est testing qui fait office de distribution rolling release, le problème des paquets qui disparaissent inopinément n’est pas résolu. C’est la raison pour laquelle l’introduction d’une nouvelle distribution nommée rolling a été proposée. Celle-ci serait similaire à testing, mais avec quelques règles propres. Les images instantanées seraient effectuées à partir de celle-ci plutôt qu’à partir de testing.

La solution basique consiste à faire une copie de testing en y ré-introduisant les paquets qui en ont été enlevés, pour les raisons préalablement mentionnées qui n’ont plus de raison d’être pour une distribution constamment mise à jour. L’exemple le plus récent étant Chromium).

Toujours dans l’optique d’une rolling release, il faudrait reconfigurer rolling pour pointer directement vers unstable lors des périodes de gel de testing. Cette dernière n’étant alors plus mise automatiquement à jour.

De par ses publications fréquentes, seul un sous-ensemble d’architectures serait supporté, ce qui n’est pas réellement un problème puisque les utilisateurs souhaitant les toutes dernières fonctionnalités tournent la plupart du temps sur des architectures i386/amd64 (voire armel pour les tablettes et produits mobiles similaires). Ce choix — si acté — permettrait même d’envisager une migration plus rapide de certains paquets vers rolling par rapport à testing, notamment ceux qui sont simplement pénalisés par le retard de certaines architectures en terme d’auto-compilation (par les buildd).

Mais si précéder testing peut être un point positif pour les utilisateurs, cela peut être également problématique sous divers aspects : tout d’abord le travail de la Release Team ne pourrait plus être réutilisé en l’état, rendant la gestion de rolling beaucoup plus compliquée. Cela introduirait ensuite une compétition entre les deux distributions, ce qui pourrait avoir comme corollaire une plus grande difficulté de publication de la version stable, si par exemple les mainteneurs ne se soucient plus que de l’arrivée de leurs paquets dans rolling.

L’idée d’une distribution type rolling release n’en reste pas moins une belle idée, mais dont les règles de gestion doivent être construites avec soin pour éviter toute perturbation du processus de publication de la version stable. Elle aurait au moins le mérite de nous débarrasser du problème marketing qui entâche testing, à savoir que son nom même suggère qu’elle n’est pas prête à être utilisée.
Conclusion

Même si tout reste à faire pour que CUT se concrétise, le démarrage est encourageant : Joerg Jaspert (responsable FTP) a d’ores et déjà déclaré que le nouveau serveur d’archives pourrait supporter une nouvelle distribution, et une proposition est à l’étude. Le projet pourrait commencer rapidement : un plan d’implémentation existe déjà pour le volet « instantané »; l’aspect rolling pourra toujours être introduit par la suite, une fois prêt. L’une et l’autre approche sont complémentaires et apportent chacune des éléments utiles à des populations différentes d’utilisateurs.

La proposition dans son ensemble est séduisante : contrer « l’obsolescence » des versions stables Debian par des publications intermédiaires. Quiconque souhaitant une version actuelle pour le support de matériels récents commencerait par l’installation d’une image instantanée, dont il suivrait les cuts ultérieures jusqu’à la publication finale. Les utilisateurs cherchant toujours les dernières versions de paquets utiliseraient quant à eux le système de rolling après avoir installé un instantané.

Du point de vue utilisateur, on peut apercevoir une proximité avec l’alternance de versions normales et de versions à long support d’Ubuntu. Mais le processus serait considérablement différent du point de vue développement, d’autant plus que les contraintes imposées par une distribution constamment opérationnelle sont plus fortes : tout changement à grande échelle doit être introduit progressivement de manière à ce qu’il soit transparent pour l’utilisateur.

    Cet article est une traduction de Can Debian offer a Constantly Usable Testing distribution? contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.


La première partie de l'article intéressera beaucoup ceux qui seraient tentés d'utiliser Testing au quotidien. L'auteur y va d'une mise en garde importante où il mentionne que les développeurs Debian recommandent de ne pas l’utiliser même si elle semble représenter un bon compris entre relative stabilité et paquets récents. Puis, il va d'une descriptions des problèmes connus dans Testing. Donc, à moins d'aimer mettre les mains dans le cambouis, il vaut mieux y réfléchir avant de sauter à pieds joints sur Testing.

Article et lire et à relire donc s'y nécessaire.


"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.

Hors ligne

#2 02-03-2011 10:05:39

dbkblk
Membre
Distrib. : Debian Wheezy 64bits
Noyau : 3.2
(G)UI : Gnome 3.2
Inscription : 24-10-2010

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

Le passage sur CUT est aussi très intéressant, car il parle d'une sorte de "Ubuntu" avec la stabilité et l'organisation de Debian. C'est une bonne chose pour le support matériel, bien que tout ça soit déjà bien avec testing.

M. Gandhi: "C'est une erreur de croire nécessairement faux ce qu'on ne comprend pas."
C'est quoi ce bordel ?

Hors ligne

#3 05-04-2012 21:16:50

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

voilà, j'en avais un peu marre des mises a jour quotidiennes de ma sid , je suis passé en testing "stable"
et je gère désormais mes paquets avec wajig
l'install en gnome3 c'est déroulé sans aucun incident . cool

amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#4 09-06-2012 15:12:10

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

nouveau snapshot disponible

il ne s'agit toutefois pas d'une release mais d'un nightly build

procedure de mise à jour

par précaution j'ai d'abord désactivé mes extensions gnome-shell
puis modifié mon sources.list pour pointer vers le nouveau snapshot

cat /etc/apt/sources.list
# deb http://snapshot.debian.org/archive/debian/20120229T213309Z wheezy main contrib non-free
# deb-src http://snapshot.debian.org/archive/debian/20120229T213309Z wheezy main contrib non-free

deb http://snapshot.debian.org/archive/debian/20120403T034232Z wheezy main contrib non-free

deb http://security.debian.org/ wheezy/updates main contrib non-free
# deb-src http://security.debian.org/ wheezy/updates main contrib non-free


j'ai lancer ensuite

wajig update


suivi de

wajig upgrade


380 paquets mis à jour
puis de

wajig dist-upgrade


encore 120 paquets mis à jour

tout est passé comme une lettre à la poste
et j'ai enfin réactivé mes extensions

à noter cependant que gnome-shell est toujours en version 3.2 (ce qui n'est pas plus mal) cool

Dernière modification par misaine (09-06-2012 15:16:23)


amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#5 10-06-2012 12:41:09

deuchdeb
Moderato ma non troppo
Lieu : Pays de Cocagne
Distrib. : Jessie 8 + backports
Noyau : linux-image-3.16
(G)UI : KDE4.14 - Mate
Inscription : 13-01-2010

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

Salut,

Tu la trouves ou l'image de Mai 2012?

Ici , je ne trouve rien de plus récent  que Mars 2012: http://cut.debian.net/

Hors ligne

#6 10-06-2012 15:17:38

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

comme je l'ai souligné dans nightly build wink

amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#7 12-06-2012 10:00:59

arkim13012
Membre
Lieu : Montpellier
Distrib. : Wheezy
Noyau : 3.2.0-2-amd64
(G)UI : Gnome 3.4
Inscription : 22-06-2010

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

misaine a écrit :

comme je l'ai souligné dans nightly build wink


Bonjour,

Je suis très intéressé par ce projet CUT et je souhaitais avoir un complément d'information.
Lorsqu’un nouveau snapshot est distribué, il faut mettre à jour via l'iso ou peut-on le faire via apt-get?

Edit: en te relisant, je crois que tu édites ton sources.list une fois par mois (ou est-ce plus souvent) pour pointer vers la nouvelle version  ?

Dernière modification par arkim13012 (12-06-2012 10:03:20)

Hors ligne

#8 12-06-2012 17:46:00

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

je ne l'ai installé que depuis mars 2012 et jusque là il n'y avait pas eu de nouveau snapshot .mais là , ça bouge tout les jours et j'espère qu'une nouvelle release va sortir;
pour la suite je pense mettre à jour qu'en utilisant les releases.
comme je l'ai indiqué , je mets à jour avec wajig et non pas apt-get ou aptitude , mais ça ne doit pas faire de différence.

amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#9 12-06-2012 19:16:28

arkim13012
Membre
Lieu : Montpellier
Distrib. : Wheezy
Noyau : 3.2.0-2-amd64
(G)UI : Gnome 3.4
Inscription : 22-06-2010

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

Merci pour tes éclaircissements, je trouve cela tout de même contraignant et vais rester sur ma Wheezy en attendant une vraie rolling en testing.

Hors ligne

#10 12-06-2012 19:50:12

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

contraignant ? chacun son point de vue: 1 maj tous les mois voir tous les 2 mois pour avoir une testing qui ne casse pas , c'est beaucoup moins difficile que maintenir une "vrai" testing . non !?
cool

amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#11 12-06-2012 21:55:28

phreg
Membre
Distrib. : Antix MX-15
Noyau : 4.3-0-liquorix-686
(G)UI : Xfce 4.12
Inscription : 02-04-2011

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

misaine a écrit :

contraignant ? chacun son point de vue: 1 maj tous les mois voir tous les 2 mois pour avoir une testing qui ne casse pas , c'est beaucoup moins difficile que maintenir une "vrai" testing . non !?
cool


Avec 1 mise à jour tous les 1 ou 2 mois, ce n'est plus du tout "testing" à mon avis. De toute manière pour moi testing n'a jamais été ma partition de boot par défaut, juste loisir et découverte. Alors pourquoi ne pas s’amuser avec du vrai testing ou experimental quitte à tout planter ? Tout ça bien sûr en gardant une version fiable (pas forcément la stable) pour booter tous les jours.

Dernière modification par phreg (12-06-2012 21:56:42)

Hors ligne

#12 13-06-2012 06:24:45

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

tu as raison, mon but n'est pas de tester mais d'utiliser quelque chose de fiable et récent tous les jours.
et c'est bien de but de ce projet.
[hs] mais j'aime bien aussi m'amuser sur les innovations de mon environnement favori (gnome)  et pour ça je me tourne vers d'autres distributions faites pour ça. j'ai en multiboot fedora, frugalware et arch cool

au début de gnome 3 j'avais une sid/experimental mais c'était déjà en retard par rapport aux autres. [/hs]

Dernière modification par misaine (13-06-2012 06:41:31)


amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#13 14-06-2012 21:59:54

arkim
Membre
Lieu : Montpellier, France.
Distrib. : Wheezy
Noyau : 3.0 amd64
(G)UI : Gnome 3.0.2
Inscription : 04-12-2011

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

Pour ma part, je trouve Debian Wheezy trés fiable et stable. Par exemple, j'ai testé Fedora 16 durant plusieurs mois et malgré des qualités indéniables: yum, aspect graphique... J'ai eu de nombreux bugs et problèmes pourtant c'est une version stable.
Debian est aussi beaucoup plus rapide et véloce ♥

Dernière modification par arkim (14-06-2012 22:01:22)

Hors ligne

#14 14-06-2012 22:18:14

phreg
Membre
Distrib. : Antix MX-15
Noyau : 4.3-0-liquorix-686
(G)UI : Xfce 4.12
Inscription : 02-04-2011

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

arkim a écrit :

je trouve Debian Wheezy trés fiable et stable. ... Debian est aussi beaucoup plus rapide et véloce ♥


Wheezy + Xfce : encore rien vu de mieux (dans les grandes distros) pour le compromis stabilité, vélocité, simplicité.

Hors ligne

#15 14-06-2012 23:14:48

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

fiable...stable...rapide...véloce...le sens de ces mots est très subjectif.
seul le sens stable du point de vue debian veut dire quelque chose.
et dans ce sens wheezy n'est pas stable .

amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#16 15-06-2012 00:09:15

arkim13012
Membre
Lieu : Montpellier
Distrib. : Wheezy
Noyau : 3.2.0-2-amd64
(G)UI : Gnome 3.4
Inscription : 22-06-2010

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

misaine a écrit :

fiable...stable...rapide...véloce...le sens de ces mots est très subjectif.
seul le sens stable du point de vue debian veut dire quelque chose.
et dans ce sens wheezy n'est pas stable .


Je me base sur une expérience concrète avec un matériel identique, les mêmes utilisateurs et la même utilisation, le même bureau, Gnome shell.
Prenons le temps de boot, Debian est plus rapide de 30 secondes facilement .
Je n'ai pas utilisé de benchmarks officiels mais je t'assure que Wheezy est plus rapide que Fedora 16 et moins buggé.
Quant à la stabilité de Wheezy elle est a relativiser par rapport à Debian Squeeze certes mais par rapport à d'autres distributions, Wheezy est très stable j'insiste.

Dernière modification par arkim13012 (15-06-2012 00:10:25)

Hors ligne

#17 15-06-2012 07:31:15

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

je les ai sur mon multiboot : fedora 17 met 5s de plus au boot  et n'est pas plus buggé.
dans whezzy les paquets ont des m.a.j. fréquentes donc n'est pas stable (au sens debian) , j'insiste wink

Dernière modification par misaine (15-06-2012 07:37:37)


amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#18 15-06-2012 09:52:41

arkim13012
Membre
Lieu : Montpellier
Distrib. : Wheezy
Noyau : 3.2.0-2-amd64
(G)UI : Gnome 3.4
Inscription : 22-06-2010

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

misaine a écrit :

je les ai sur mon multiboot : fedora 17 met 5s de plus au boot  et n'est pas plus buggé.
dans whezzy les paquets ont des m.a.j. fréquentes donc n'est pas stable (au sens debian) , j'insiste wink


Donc Fedora 16 était une testing de Fedora 17.
En tout cas je te rejoins sur les m.a.J de Testing donc effectivement pas stable selon le projet Debian
On a tous les deux raisons en fin de compte, surtout moi wink

Hors ligne

#19 16-06-2012 08:27:48

phreg
Membre
Distrib. : Antix MX-15
Noyau : 4.3-0-liquorix-686
(G)UI : Xfce 4.12
Inscription : 02-04-2011

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

seul le sens stable du point de vue debian veut dire quelque chose.
et dans ce sens wheezy n'est pas stable


On est d'accord.
En pratique j'ai tendance à préférer la stabilité de la version Debian officiellement "unstable" à pas mal d'autres distributions officiellement stable.
Certaines sont souvent pendant 1 ou 2 mois encore bien buggées.

Hors ligne

#20 17-06-2012 09:28:22

arkim13012
Membre
Lieu : Montpellier
Distrib. : Wheezy
Noyau : 3.2.0-2-amd64
(G)UI : Gnome 3.4
Inscription : 22-06-2010

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

phreg a écrit :

seul le sens stable du point de vue debian veut dire quelque chose.
et dans ce sens wheezy n'est pas stable


On est d'accord.
En pratique j'ai tendance à préférer la stabilité de la version Debian officiellement "unstable" à pas mal d'autres distributions officiellement stable.
Certaines sont souvent pendant 1 ou 2 mois encore bien buggées.


+1

Hors ligne

#21 12-07-2012 17:46:27

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

ça y est ! les releases sont sorties .ce sont des snapshots testés et particulièrement stables qui offrent les logiciels de la future wheezy.
y a bon ! mangez-en cool
http://lists.alioth.debian.org/pipermai … 00335.html

Dernière modification par misaine (12-07-2012 17:56:30)


amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

#22 12-07-2012 20:53:39

deuchdeb
Moderato ma non troppo
Lieu : Pays de Cocagne
Distrib. : Jessie 8 + backports
Noyau : linux-image-3.16
(G)UI : KDE4.14 - Mate
Inscription : 13-01-2010

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

J'ai voulu installé debian CUT. J'ai pris une nigthly build récente et j'ai commencé l'installation. L'installateur n'a pas pris en compte le clavier français, je ne suis pas allé plus loin.

J'ai installé alors une testing classique. Peut on remplacer le sources.list testing par un sources.list CUT du jours (de la nuit d'aujourd'hui) ?

Je dirais que oui mais j'aimerais une confirmation.

Hors ligne

#23 12-07-2012 21:20:08

misaine
Membre
Lieu : sables d'olonne
Distrib. : Antergos (Archlinux)
Noyau : 4.3.3
(G)UI : gnome-shell 3.18.2
Inscription : 29-07-2007

Re : À propos de Debian Testing et du projet CUT (Constantly Usable Testing

je n'ai jamais essayé mais certains paquets de testing peuvent être plus récents

amd phenom 7650 , 4 Go DDR2 ,GeForce N210

Hors ligne

Pied de page des forums