Debian-facile

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

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

#1 20-07-2011 03:27:39

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

5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Salut à tous

Petite parenthèse. Il m'arrive des fois de penser que l'on devrait avoir sur notre forum un fil de discussion dédié uniquement aux articles ou au pages que l'on a lus et que l'on désire faire partager aux gens qui parcourt ce forum.Fin de la parenthèse.

En parcourant le Planet Libre, je suis tombé sur un article de Raphäel Hertzog qui donne 5 raisons pour lesquelles Debian unstable ne mérite pas son nom : l'article en question.

Comme il l'indique si bien dans son texte :

Ceci étant, il est possible de l’utiliser sans que votre ordinateur n’explose !


lol

Martin


"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 20-07-2011 14:30:38

tetrix
Invité

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

big_smile C'est très bien écrit

#3 20-07-2011 17:57:33

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

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Il n'écrit pas tous les jours mais c'est souvent des écrits qui méritent la lecture.

Hors ligne

#4 20-07-2011 19:18:25

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 : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Merci pour cet article.:cool:

Oui c'est vrai qu'une rubrique " J'ai lu ça et cela pourrait vous intéresser" ou " Autres articles intéressants " ou bien encore "Vu sur le net" serait peut être une bonne chose.

Dernière modification par deuchdeb (21-07-2011 10:45:39)

Hors ligne

#5 23-07-2011 12:49:02

GutsBlack
Membre
Lieu : Marseille
Distrib. : Testing (Wheezy)
Noyau : 2.6.39+35.1: amd64
(G)UI : Gnome 2.30
Inscription : 22-07-2011

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Je ne suis pas vraiment d'accord avec lui.

1. unstable contient principalement des versions stables de logiciels
Les mainteneurs ne doivent donc y envoyer que des paquets d’une qualité suffisante en vue de la publication, le reste devant prendre le chemin de experimental.


Je ne suis pas du tout d'accord. Le mainteneur crée un paquet et le dépose sur le ftp-master. Il est ensuite inspecté et validé par les ftpmasters (généralement au niveau sécurité) et le paquet rentre dans unstable. Plusieurs problèmes peuvent donc apparaître.

- Echec de compilation sur les autres architectures (auto-builder)
- Il peut y avoir des bugs (critique, grave, sérieux, important, normal et mineur)
- Il peut y avoir un problème d'installation dû à une dépendance foireuse.

Le paquet unstable ne pourra rejoindre testing qu'en remplissant certaines conditions :
- Absence de bug critique où inférieur à celui de la version testing actuelle
- Rétention en unstable d'au moins 10 jours.
- Compilation réussie sur toutes les architectures prises en charge officiellement.
- Dépendances satisfaisantes.

Quand à la branche expérimental elle porte bien son nom c'est un espace de développement pour des paquets spéciaux en vu d'une lointaine intégration à la Debian. C'est un cas particulier.


2. Elle ne crashe pas tous les jours
Il est également possible de prévenir plutôt que de guérir : apt-listbugs, en vous prévenant du problème, peut vous dissuader de mettre à jour.


Elle ne crashe pas tous les jours parce que les mainteneurs font attention mais ça ne veux pas dire qu'elle ne peux pas crasher complètement.

3. Elle est à la base d’autres distributions
Si Debian unstable était de si piètre qualité, elle ne servirait pas de base de départ pour des distributions dérivées. Logique, non ? Deux exemples basées sur sid parmi d’autres : Ubuntu et Sidux Aptosid.


Si d'autres distributions veulent prendre le risque c'est leurs problèmes. Sinon concernant Ubuntu, les paquets subissent tout de même un contrôle avant d'être lâché sur les utilisateurs.

4. Sa conception ne la rend pas moins sécurisée que stable ou testing
Les vulnérabilités importantes sont généralement rapidement corrigées dans stable et unstable. L’équipe chargée de la sécurité s’occupe de stable, tandis que la correction d’unstable revient aux mainteneurs des paquets concernés. testing récupère généralement la correction à travers la mise à jour des paquets provenant d’unstable, entraînant ainsi une latence à l’obtention des corrections.
Les problèmes de sécurités d’importance moindre peuvent n’entraîner aucune correction dans stable. Dans ce cas, les utilisateurs de testing/unstable sont mieux servis, dans la mesure où ils récupèreront la correction avec la nouvelle version du paquet, quoi qu’il arrive.


Les vulnérabilité sur la branche stable sont corrigées très rapidement et il y a une équipe pour ça, ce n'est pas le cas de unstable où on corrige d'abord les bugs (pas forcément la sécurité), même si une correction de bug peu corriger un problème de sécurité, ce n'est pas la priorité. Entre testing et unstable, il y a effectivement une latence et unstable peut se révéler plus sécurisé que testing à cause par exemple des 10 jours de rétention obligatoire. Les utilisateurs les mieux servis restent toujours ceux en stable puisque les versions de paquets ne changent pas et il ne peut pas y avoir de bugs critiques insérés, ils disposent d'une équipe qui gère les failles de sécurités et les failles trouvés sur des versions plus récentes peuvent être rétroporté sur une version plus ancienne par les mainteneurs.

5. Je l’utilise sur mon ordinateur principal
Et je ne suis pas le seul !


Ce n'est pas une donnée suffisamment fiable, chaque utilisateur peut avoir sa propre bonne ou mauvaise expérience. Et Internet est surement remplis d'utilisateur aussi ravis que mécontent d'unstable.

Pour terminer ne faisons pas comme la distribution Ubuntu, à force de vouloir aller vite on finis par se planter lamentablement smile


Si tu polishes ta caisse elle brille !

Hors ligne

#6 23-07-2011 14:16:38

Invité-5
Banni(e)

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

GutsBlack a écrit :

Je ne suis pas vraiment d'accord avec lui.


+1  wink

#7 23-07-2011 14:40:08

tetrix
Invité

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

@GutsBlack :

sur que tes arguments se tiennent, mais il faut garder à l'esprit que sid est, et restera le jouet favori des "debiangeeks", donc de ce fait elle poursuit une évolution permanente (rolling release),ceci contribuant à une certaine variation de la stabilité du système.

En fait pour une comparaison : sid c'est la voiture de sport, et comme toute chose "pointue",cela reste un peu plus fragile. Mais, HAMA cela reste  hyper stable (juste faire gaffe aux MAJ) wink

#8 23-07-2011 15:24:06

Thuban
Modérateur
Distrib. : OpenBSD
Noyau : current
(G)UI : xfce ou dwm
Inscription : 09-01-2009
Site Web

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Bon, faut quand même avouer que dans le type rolling release, elle pose beaucoup moins de problèmes qu'une arch par exemple smile

YA3HGA-H

Hors ligne

#9 24-07-2011 13:51:50

captnfab
Admin-Girafe
Lieu : /dev/random
Distrib. : Debian Stretch/Sid/Rc-Buggy
Noyau : Linux (≥ 4.3)
(G)UI : i3-wm (≥ 4.11)
Inscription : 07-07-2008
Site Web

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Hum, pour ma part, je ne suis pas vraiment d'accord avec GutsBlack (et donc avec Darien) smile


GutsBlack a écrit :

1. unstable contient principalement des versions stables de logiciels
Les mainteneurs ne doivent donc y envoyer que des paquets d’une qualité suffisante en vue de la publication, le reste devant prendre le chemin de experimental.


Je ne suis pas du tout d'accord. Le mainteneur crée un paquet et le dépose sur le ftp-master. Il est ensuite inspecté et validé par les ftpmasters (généralement au niveau sécurité) et le paquet rentre dans unstable. Plusieurs problèmes peuvent donc apparaître.

- Echec de compilation sur les autres architectures (auto-builder)
- Il peut y avoir des bugs (critique, grave, sérieux, important, normal et mineur)
- Il peut y avoir un problème d'installation dû à une dépendance foireuse.

Le paquet unstable ne pourra rejoindre testing qu'en remplissant certaines conditions :
- Absence de bug critique où inférieur à celui de la version testing actuelle
- Rétention en unstable d'au moins 10 jours.
- Compilation réussie sur toutes les architectures prises en charge officiellement.
- Dépendances satisfaisantes.


Les logiciels empaquetés pour debian sid sont des versions de logiciels assez stables dans le sens où elles correspondent à des "releases" du logiciel. C'est le paquet qui n'est pas stable, non pas le logiciel.
Après, bien sûr, il contient des bugs. C'est le cas de toutes les releases, et ces bugs ne disparaissent pas avant d'avoir été détectés puis corrigés.
Il y a encore plein de bugs dans debian stable, et même dans debian oldstable. Et ces bugs ne seront jamais corrigés, sauf s'ils induisent des problèmes de sécurité. En effet, corriger un bug sur une version stable impliquerait un changement de comportement du logiciel, et donc une instabilité (au sens discontinuité) du comportement de la distribution. En revanche, les bugs des versions testing et sid peuvent être corrigés s'ils sont reportés.

GutsBlack a écrit :

Quand à la branche expérimental elle porte bien son nom c'est un espace de développement pour des paquets spéciaux en vu d'une lointaine intégration à la Debian. C'est un cas particulier.


La branche epérimentale contient souvent les paquets et bibliothèques dont tous les paquets en dépendant n'ont pas encore été mis à jour. Les paquets ne sont pas forcément instables, mais ils peuvent provoquer des problème de cohérence au niveau des dépendances. Une utilisation au compte-goutte ne pose en général aucun problème (exemple, avec iceweasel et ses dépendances).

GutsBlack a écrit :

2. Elle ne crashe pas tous les jours
Il est également possible de prévenir plutôt que de guérir : apt-listbugs, en vous prévenant du problème, peut vous dissuader de mettre à jour.


Elle ne crashe pas tous les jours parce que les mainteneurs font attention mais ça ne veux pas dire qu'elle ne peux pas crasher complètement.


Il y a effectivement des problèmes graves de temps en temps. Le dernier en date était le passage de udev à l'utilisation du /run, qui a été fait de manière un peu trop anticipée. Un autre type de problème possible sont les paquets de grub2 un peu buggués, qui peuvent empêcher le démarrage. Je n'ai du voir qu'un seul paquet de ce type depuis le passage à grub2.
Tous ces problèmes sont certes embêtant, mais peuvent être réparés, à condition d'avoir un peu de connaissances en la matière. Ça doit faire 6-7 ans que je suis sous Debian sid, et je n'ai commencé à utilisé Linux qu'il y a 7-8 ans. Conclusion: 1 an d'expérience suffit à s'en tirer. wink

GutsBlack a écrit :

3. Elle est à la base d’autres distributions
Si Debian unstable était de si piètre qualité, elle ne servirait pas de base de départ pour des distributions dérivées. Logique, non ? Deux exemples basées sur sid parmi d’autres : Ubuntu et Sidux Aptosid.


Si d'autres distributions veulent prendre le risque c'est leurs problèmes. Sinon concernant Ubuntu, les paquets subissent tout de même un contrôle avant d'être lâché sur les utilisateurs.


Oui, Ubuntu subut un "freeze" de 6 mois, pendant lequel elle doit vérifier les 29000 paquets de debian sid (oui, ceci est un argument par l'absurde), sachant qu'elle ne se refuse pas d'accepter des paquets entrant dans sid pendant le freeze (cf. gnome 3)

GutsBlack a écrit :

4. Sa conception ne la rend pas moins sécurisée que stable ou testing
Les vulnérabilités importantes sont généralement rapidement corrigées dans stable et unstable. L’équipe chargée de la sécurité s’occupe de stable, tandis que la correction d’unstable revient aux mainteneurs des paquets concernés. testing récupère généralement la correction à travers la mise à jour des paquets provenant d’unstable, entraînant ainsi une latence à l’obtention des corrections.
Les problèmes de sécurités d’importance moindre peuvent n’entraîner aucune correction dans stable. Dans ce cas, les utilisateurs de testing/unstable sont mieux servis, dans la mesure où ils récupèreront la correction avec la nouvelle version du paquet, quoi qu’il arrive.


Les vulnérabilité sur la branche stable sont corrigées très rapidement et il y a une équipe pour ça, ce n'est pas le cas de unstable où on corrige d'abord les bugs (pas forcément la sécurité), même si une correction de bug peu corriger un problème de sécurité, ce n'est pas la priorité. Entre testing et unstable, il y a effectivement une latence et unstable peut se révéler plus sécurisé que testing à cause par exemple des 10 jours de rétention obligatoire. Les utilisateurs les mieux servis restent toujours ceux en stable puisque les versions de paquets ne changent pas et il ne peut pas y avoir de bugs critiques insérés, ils disposent d'une équipe qui gère les failles de sécurités et les failles trouvés sur des versions plus récentes peuvent être rétroporté sur une version plus ancienne par les mainteneurs.


Là encore, je rejoins plutôt Raphäel Hertzog. Dans unstable, lorsqu'une faille de sécurité est détectée, les développeurs (mainstream) du logiciel la corrigent immédiatement, et le paquet est ensuite mis à jour par les mainteneurs. En général, les failles de sécurité sont plutôt détectées dans stable, et quand on veut la corriger dans unstable, on se rend compte que la faille n'existe plus et a déjà été corrigée.
Les paquets d'unstable contiennent certes des failles de sécurité, mais en générale, elles sont inconnues smile

GutsBlack a écrit :

5. Je l’utilise sur mon ordinateur principal
Et je ne suis pas le seul !


Ce n'est pas une donnée suffisamment fiable, chaque utilisateur peut avoir sa propre bonne ou mauvaise expérience. Et Internet est surement remplis d'utilisateur aussi ravis que mécontent d'unstable.


Je suis allé à la mini debconf à paris l'an passé. Moins de 10% des présents utilisaient stable sur leur machine personnelle. Tous les autres avaient une sid ou une testing.
Donc visiblement, les "experts" trouvent la sid assez utilisable wink

GutsBlack a écrit :

Pour terminer ne faisons pas comme la distribution Ubuntu, à force de vouloir aller vite on finis par se planter lamentablement smile


À mon avis, Ubuntu gagnerait à devenir une rolling release, et ce qui l'en empêche est sans-doute la nécessité d'une certaine longévité des versions des logiciels pour les entreprises. Un projet se faisant souvent sur plus de 4 ans.

Je ne m'étendrai pas sur la stabilité d'ubuntu, la plupart des reproches que je lui fais sont plus d'ordre philosophique. « Barbouiller un logiciel de rustine pour que ça semble marchotter la plupart des cas sur les configurations les plus répendues. » ça n'a jamais été appelé de la correction de bug ou du développement propre. Et « faire des cliquodrômes en python », ça ne doit pas être confondu avec « faire des logiciels stables ». Cela dit, cette critique est loin de ne concerner qu'ubuntu, Network-Manager et Wicd étant conseillés par de nombreux débianistes.

Pour finir, Raphaël Hertzog est développeur Debian depuis 1998, et il connaît plutôt bien son sujet smile

Hop.


captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.

Hors ligne

#10 24-07-2011 14:14:53

GutsBlack
Membre
Lieu : Marseille
Distrib. : Testing (Wheezy)
Noyau : 2.6.39+35.1: amd64
(G)UI : Gnome 2.30
Inscription : 22-07-2011

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

captnfab a écrit :

Les logiciels empaquetés pour debian sid sont des versions de logiciels assez stables dans le sens où elles correspondent à des "releases" du logiciel. C'est le paquet qui n'est pas stable, non pas le logiciel.


Oui et non, la version du logiciel indique une version "stable" par les développeurs, il reste néanmoins une grosse phase de debug auprès d'autres devs pas forcément impliqué dans le logiciel ainsi que par les utilisateurs avancés.

Avoir une distribution purement stable est impossible c'est sur mais stable reste moins problématique que unstable, les bugs sont rarement bloquant, mais ça peux arriver personne n'est parfait smile

captnfab a écrit :

La branche epérimentale contient souvent les paquets et bibliothèques dont tous les paquets en dépendant n'ont pas encore été mis à jour. Les paquets ne sont pas forcément instables, mais ils peuvent provoquer des problème de cohérence au niveau des dépendances.


Normalement non, ce n'est pas ça vocation mais ça peut arriver parfois pendant les période de freeze.

captnfab a écrit :

Il y a effectivement des problèmes graves de temps en temps. Le dernier en date était le passage de udev à l'utilisation du /run, qui a été fait de manière un peu trop anticipée. Un autre type de problème possible sont les paquets de grub2 un peu buggués, qui peuvent empêcher le démarrage. Je n'ai du voir qu'un seul paquet de ce type depuis le passage à grub2.
Tous ces problèmes sont certes embêtant, mais peuvent être réparés, à condition d'avoir un peu de connaissances en la matière.


Je suis d'accord mais c'est pour ça que l'article me pose un problème. Les gens qui ont de l'expérience n'ont pas besoin de l'article pour être sur SID et ceux qui se posent encore des questions n'ont à mon avis pas assez d'armes pour résister à un bug bloquant, surtout si la partie graphique ne démarre plus.

captnfab a écrit :

Conclusion: 1 an d'expérience suffit à s'en tirer. wink


Ca dépend des gens ! tongue

captnfab a écrit :

Là encore, je rejoins plutôt Raphäel Hertzog. Dans unstable, lorsqu'une faille de sécurité est détectée, les développeurs (mainstream) du logiciel la corrige immédiatement, et le paquet est ensuite mis à jour par les mainteneurs. En général, les failles de sécurité sont plutôt détectées dans stable, et quand on veut la corriger dans unstable, on se rend compte que la faille n'existe plus et a déjà été corrigée.
Les paquets d'unstable contiennent certes des failles de sécurité, mais en générale, elles sont inconnues smile


Je ne suis pas vraiment d'accord parce que les corrections sur unstable se font en fonction d'un "état du bug" et il ressort que les bugs critique, grave, bloquant rapporté par les utilisateurs ne sont pas forcément lié à la sécurité. Mais bon il faudrait faire vraiment un audit pour en savoir plus.

captnfab a écrit :

Je suis allé à la mini debconf à paris l'an passé. Moins de 10% des présents utilisaient stable sur leur machine personnelle. Tous les autres avaient une sid ou une testing.
Donc visiblement, les "experts" trouvent la sid assez utilisable wink


Oui les experts et les utilisateur avancées qui d'ailleurs ne liront pas l'article qui ne les concernent pas vraiment wink

captnfab a écrit :

À mon avis, Ubuntu gagnerait à devenir une rolling release, et ce qui l'en empêche est sans-doute la nécessité d'une certaine longévité des versions des logiciels pour les entreprises. Un projet se faisant souvent sur plus de 4 ans.


Le projet n'a surtout aucune direction claire. Pour Ubuntu le mieux serais de garder LTS pour les entreprises, une Ubuntu qui évolue chaque année et une rolling-release.

captnfab a écrit :

Je ne m'étendrai pas sur la stabilité d'ubuntu, la plupart des reproches que je lui fais sont plus d'ordre philosophique. « Barbouiller un logiciel de rustine pour que ça semble marchotter la plupart des cas sur les configurations les plus répendues. » ça n'a jamais été appelé de la correction de bug ou du développement propre. Et « faire des cliquodrômes en python », ça ne doit pas être confondu avec « faire des logiciels stables ».


Je suis à 100% d'accord. Mais bon c'est la méthode des entreprises aux logiciels propriétaires, faire en sorte que ça marche vite même si structurellement c'est pas bon. On s'en fiche on regarde sur le moment pas sur la durée.

captnfab a écrit :

Cela dit, cette critique est loin de ne concerner qu'ubuntu, Network-Manager et Wicd étant conseillés par de nombreux débianistes.
Hop.


Debian a mis pas mal de temps avant de proposer network-manager par défaut. Et maintenant c'est un logiciel qui marche bien, je n'ai jamais eu aucun problème avec lui depuis son intégration. Pour wicd je ne l'ai jamais utilisé.


Si tu polishes ta caisse elle brille !

Hors ligne

#11 24-07-2011 18:03:56

Invité-5
Banni(e)

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Malgré ma vive admiration pour Monsieur Raphäel Hertzog, je dois dire que ma petite contestation vient du fait "des surprises/surgissement assez graves sous Sid par moment sans entrer dans les détails" On peut s'en sortir mais c'est énervant. Pour une fois que nous pouvons (entre nous) "discuter/mettre en cause" un article venant d'une grande autorité dans le monde de Debian, pourquoi pas. On apprend tous les jours. Chacun ses risques et périls. Quelqu'un(une) a appelé cette branche unstable et elle doit être considéré comme telle. Si vous n'êtes pas d'accord avec moi, vous avez le droit. cool

Amicalement.

#12 24-07-2011 18:18:09

captnfab
Admin-Girafe
Lieu : /dev/random
Distrib. : Debian Stretch/Sid/Rc-Buggy
Noyau : Linux (≥ 4.3)
(G)UI : i3-wm (≥ 4.11)
Inscription : 07-07-2008
Site Web

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

La unstable a été baptisée comme telle par opposition à stable, pas par volonté de rendre la branche instable big_smile
Les paquets de stable ont quasiment tous été, un jour, dans unstable, et ils étaient déjà "stables" à l'époque smile

captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.

Hors ligne

#13 24-07-2011 18:29:48

Invité-5
Banni(e)

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

(Les paquets de stable ont quasiment tous été, un jour, dans unstable, et ils étaient déjà "stables" à l'époque)
D'accord, mais c'est "l'ensemble"qui compte et c'est assez énervant pour moi d'être tout le temps sur "qui vive" avec Sid.
Il est possible que tu as parfaitement raison. C'est ne que mon avis personnel wink

#14 24-07-2011 20:06:51

GutsBlack
Membre
Lieu : Marseille
Distrib. : Testing (Wheezy)
Noyau : 2.6.39+35.1: amd64
(G)UI : Gnome 2.30
Inscription : 22-07-2011

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Darien a écrit :

c'est assez énervant pour moi d'être tout le temps sur "qui vive" avec Sid.


Quand j'avais du temps j'étais sur Sid, maintenant sur Testing, j'ai moins de temps à consacrer à la mise à jour de mon système ainsi qu'au traitement des bugs smile


Si tu polishes ta caisse elle brille !

Hors ligne

#15 24-07-2011 22:48:21

tetrix
Invité

Re : 5 raisons pour lesquelles Debian unstable ne mérite pas son nom

En passant, vous connaissez aptosid ?

Pied de page des forums