Testing vs unstable, bis repetita

Edit syam : Sujet d’origine : debian-sid-kde4-ecran-sur-hdmi-pas-detecte-t45752.html

Je tiens juste a réagir a ce qu’a répondu Syam :

=> En faite, a partir du moment ou tu as le dépot sid d’activé, tu es en version instable ! les dépots testings c’est normale qu’il y en ai, en effet il n’y a pas tout dans sid, quand tu installes un programme ou qd tu fais une maj, il n’y a pas tout ds sid, il doit complété avec la testing. Tu es donc en version instable.

C’est pas obligatoire mais j’avais lu que pour avoir une debian instable ou testing, il vaut mieux partir directement de l’installation testing plutot que la stable.

Non. Je suis majoritairement en testing, avec quelques bouts soigneusement sélectionnés provenant d’unstable voire même d’experimental. J’ai l’impression que tu oublies la possibilité du “pinning” de dépôts dans /etc/apt/preferences. :wink:

Il y a effectivement deux écoles. Perso je préfère partir d’une stable, installer apt-listbugs (j’avais oublié de le préciser), le rendre plus sensible que par défaut (AptListbugs::Severities “critical,grave,serious,important”; AptListbugs::IgnoreRegexp “FTBFS”;) puis seulement upgrader les paquets qui ne sont pas buggés.

Ça a déjà été discuté en long en large et en travers sur le forum, j’ai une configuration très chiante à administrer à cause du mélange des dépôts mais je n’ai jamais de gros bug sur mon système (en fait j’ai même quasiment jamais de bug, je les tolère très mal). Au pire du pire je reprends juste des paquets dans les snapshots et j’attends que ça passe, mais ça arrive genre deux fois dans l’année, rien de bien méchant.

C’est pour ça que généralement je me contente de dire “mélange douteux testing/unstable” plutôt que de m’étaler sur les bizarreries de ma config. :mrgreen:

Ba moi je suis en sid et j’ai jamais de bug aussi. tu te fais chier pour rien avec ton mélange de testing/sid.

Je sais pas si je me fais chier pour rien, mais je vois très régulièrement sur le forum des problèmes liés à unstable que je n’ai jamais chez moi, donc je vais garder ma config hein. :stuck_out_tongue: Bref, ça résout pas ton problème tout ça. :wink:

Tu es au courant que pour une utilisation personnel il faut utiliser soit la stable soit la instable mais pas celle entre les 2 (testing) qui sert juste pour tester par exemple en machine virtuel.

En effet sur testing les failles de sécurité ne sont pas corrigé ou très tard alors que c’est le cas sur sid et stable.

Je te dis, ça a déjà été discuté en long en large et en travers. :laughing: Je suis le premier à déconseiller testing aux autres : une testing “pure” n’est pas viable. C’est bien pour ça que j’ai choisi une config entre les deux : testing pour la majorité non critique du système et unstable voire experimental pour les composants critiques. Cela dit c’est pas non plus une config que je conseille aux autres, trop chiante à gérer puisqu’il faut choisir ses pinnings très soigneusement.
Garde bien en tête que c’est une machine de développement et que, oui, je teste activement Debian et remonte mes trouvailles voire même des patchs quand je peux (enfin les patchs c’est assez rare, faut dire ce qui est). Et, non, tester 5mn en VM n’est pas suffisant pour se rendre compte des problèmes, il faut l’utiliser en permanence sans quoi tu passes à côté de trop de choses.

Tiens, puisqu’on parle de sécurité, le Javascript est bien désactivé par défaut dans ton navigateur web avec une liste blanche réduite au strict minimum, rassure moi ? :wink:

[quote=“sibe39”]Tu es au courant que pour une utilisation personnel il faut utiliser soit la stable soit la instable mais pas celle entre les 2 (testing) qui sert juste pour tester par exemple en machine virtuel.

En effet sur testing les failles de sécurité ne sont pas corrigé ou très tard alors que c’est le cas sur sid et stable.[/quote]
Ce genre de base est connu de tout ceux qui ont plus de quelques centaines de messages ici ou qui sont là depuis plus d’un an :slightly_smiling: (mais c’est bien de le rappeler pour ceux qui lisent).

La question n’est pas de conseiller ou pas, mais de savoir ce que c’est et les contraintes que ça comporte.

[quote=“sibe39”]
C’est pas obligatoire mais j’avais lu que pour avoir une debian instable ou testing, il vaut mieux partir directement de l’installation testing plutot que la stable.[/quote]
Négatif, je plussoie le fait de partir d’un stable à minima, puis passer en testing et sid par petite touche et la meilleure façon de ne pas avoir de grosse galère en route (+ aptlisbugs of course)

Mais l’installation d’une sid directe et tout à fait envisageable >>>> bien penser à compléter ses sources par la suite.

Je l’ai fait pendant un petit moment et j’ai eu bien moins de problème qu’avec la SID. La stable n’ayant pas de monté de version des application elle est trop «statique» pour moi.
Donc pour quelqu’un qui ne veut pas être bloqué sur une version trop ancienne des logiciel mais qui n’est pas assez compétent pour maintenir une SID, testing n’est pas forcément un mauvais choix :12

Il y’a une autre raison c’est que les MAJ sont bien moins nombreuse sous testing que sous sid.

Je suis sous testing aussi, tout va bien merci.

Quelques éléments :
Testing et Sid possèdent en permanence un grand nombre de paquets en commun (environ 80% mais bien sur ça bouge)
Il existe un dépôt pour les mises à jour de sécurité pour testing et une équipe sécurité pour Testing, cependant Debian précise que l’arrivée des mises à jour de sécurité reste plus lente pour Testing que pour stable ou Unstable (pour cette dernière il n’y a pas d’équipe de sécurité Debian, la sécurité est amenée par la “fraicheur” des paquets)
Durant le cycle de développement de Debian la “fiabilité” de Testing et Sid évolue : testing est réputé peu fiable en période de gel (personnellement je n’ai absolument rencontré aucun problème lors du dernier gel) et l’arrivée des mises à jour en Sid est ralenti laquelle en devient assez fiable (ce que j’ai effectivement constaté lors du dernier gel).
Il est plus vrai que Testing doit être complété par Unstable que l’inverse (avec contrib et non-free : 39364 paquets Testing en ce moment contre 41239 en Sid)
La politique que je pense adopter à l’avenir est donc de placer testing en prioritaire en temps normal (c’est le cas en ce moment (seul le noyau est unstable, iceweasel experimental, gvfs et dropbox en stable) et passer le dépot unstable prioritaire en période de gel.

Ça c’est bien pour la stabilité de ta machine. Mais pour aider Debian c’est moyen, comment veux-tu remonter les bugs de la testing au moment où c’est important (le gel) si tu passes en unstable? :wink:


Par contre un truc qui me paraît évident même si je ne me suis pas étalé dessus jusqu’à présent, c’est que le navigateur web représente 99% (au moins, hein :stuck_out_tongue:) de la surface d’attaque d’un poste “bureautique”. Il est donc extrêmement important de le garder à jour, c’est là qu’experimental devient intéressant puisque ça permet d’avoir le dernier Firefox stable en un temps record (1 à 2 jours après sa sortie). Même unstable n’est pas aussi rapide, on en revient toujours au mélange douteux de dépôts avec pinnings et tout le tralala. :slightly_smiling:

Et, histoire d’enfoncer le clou, à l’intérieur du navigateur c’est le Javascript qui représente la plus grosse surface d’attaque, d’où l’intérêt de NoScript. Je suis bien certain qu’un Firefox 3 sans Javascript est beaucoup plus sûr qu’un Firefox 25 avec Javascript.

heu… ça ne serait pas plutôt l’inverse.
très fiable durant le gel et peu fiable à la sortie du gel.

heu… ça ne serait pas plutôt l’inverse.
très fiable durant le gel et peu fiable à la sortie du gel.[/quote]
Ça c’est la théorie. En pratique, la période de gel peut être sacrément rock’n’roll. Pour Wheezy j’ai constaté aucun problème mais les gels de Squeeze et Lenny ont été sportifs par moments…

debian-CUT “gelait” testing pour le rendre plus fiable

Non du moins pas comme tu le crois. testing bouge toujours (c’est la seule branche de debian à toujours bouger). Cut prendre une version de testing et indique qu’elle a était testée est qu’elle est utilisable rien de plus. CUT n’a pas fait évoluer la manière dont testing est gérée.

Testing seul, est (presque vraiment) stable et à jours, (mais j’ai des utilisations minimal (pas des gros environnement graphique avec ces milles applications).

Le rajout de sid peut-être intérresent pour trouver plus récent, mais sa le rend instable si on fait pas bien attention.

Le seul truc qui me fait peur sur testing, ces les dires sur la sécurité, quelqu’un si connait bien sur le sujet ? est-ce risqué d’utiliser une testing seul ?

Ça a déjà été discuté mille fois, mais pas grave je m’y recolle. :slightly_smiling:
Le problème de testing c’est que les paquets qui rentrent ne doivent pas avoir de nouveaux bugs pendant une semaine par rapport aux paquets unstable. Ça veut dire que si un paquet unstable a un nouveau bug, est mis à jour, un nouveau bug est trouvé, le paquet est mis à jour, un nouveau bug est trouvé etc alors le paquet testing n’évoluera jamais. Dans les cas extrêmes il peut se passer plusieurs mois avant qu’un paquet testing ne soit mis à jour, toute la question étant : est-ce que la version unstable a réussi à se stabiliser pendant une semaine ?
Donc oui, ça peut poser de graves problèmes de sécurité.

Maintenant sur une config “classique” c’est à dire une machine desktop derrière un NAT IPv4 (pas d’IPv6 hein, c’est encore une autre histoire que je ne maîtrise pas vraiment) ça n’a absolument aucune importance à moins que tu ne fasses du port-forwarding, auquel cas seul le service forwardé peut éventuellement être un problème de sécurité. En pratique, ton navigateur tout neuf a mille fois plus de risques de t’apporter des emmerdes plutôt que ton serveur SSH qui n’a pas été upgradé depuis la guerre de 14. D’où, j’insiste un peu, la nécessité de bloquer le Javascript dans le navigateur sauf sur les très rares sites de confiance.

[quote=“syam”]

Par contre un truc qui me paraît évident même si je ne me suis pas étalé dessus jusqu’à présent, c’est que le navigateur web représente 99% (au moins, hein :stuck_out_tongue:) de la surface d’attaque d’un poste “bureautique”. Il est donc extrêmement important de le garder à jour, c’est là qu’experimental devient intéressant puisque ça permet d’avoir le dernier Firefox stable en un temps record (1 à 2 jours après sa sortie). Même unstable n’est pas aussi rapide, on en revient toujours au mélange douteux de dépôts avec pinnings et tout le tralala. :slightly_smiling:

Et, histoire d’enfoncer le clou, à l’intérieur du navigateur c’est le Javascript qui représente la plus grosse surface d’attaque, d’où l’intérêt de NoScript. Je suis bien certain qu’un Firefox 3 sans Javascript est beaucoup plus sûr qu’un Firefox 25 avec Javascript.[/quote]

Salut,

Cela fait plusieurs fois que je te vois intervenir sur la dangerosité de javascript en quelque jour. Aurais-tu fais une mauvaise expérience dernièrement ?

À question indiscrète, reponse non-obligatoire !!! :wink:

[quote=“kripteks”]Testing seul, est (presque vraiment) stable et à jours, (mais j’ai des utilisations minimal (pas des gros environnement graphique avec ces milles applications).

Le rajout de sid peut-être intérresent pour trouver plus récent, mais sa le rend instable si on fait pas bien attention.

Le seul truc qui me fait peur sur testing, ces les dires sur la sécurité, quelqu’un si connait bien sur le sujet ? est-ce risqué d’utiliser une testing seul ?[/quote]

Dans la FAQ officielle de Debian on trouve ceci :

[quote]Q. : Comment est gérée la sécurité pour testing ?

R. : Si vous souhaitez un serveur sûr (et stable), vous devriez garder la distribution stable. Cependant, il existe un suivi de la sécurité pour testing : l’équipe de sécurité de Debian s’occupe des problèmes de sécurité pour testing. Elle s’assurera que les paquets corrigés intègrent testing par la méthode habituelle en migrant depuis unstable (avec un délai de quarantaine réduit), ou si cela prend trop de temps, les rendront accessibles par l’infrastructure security.debian.org. Pour l’utiliser, assurez-vous de la présence dans /etc/apt/sources.list de la ligne :

deb security.debian.org <nom_de_code>/updates main

et exécutez apt-get update && apt-get upgrade commme vous en avez l’habitude

Remarquez que cela ne garantit pas que tous les bogues de sécurité connus soient corrigés dans testing ! Certains paquets mis à jour peuvent être en attente de transition vers testing. Plus d’informations sur l’infrastructure de sécurité pour testing sont disponibles sur secure-testing-master.debian.net/.[/quote]

Et sur le wiki officiel Debian sur Debian Testing il est précisé ceci :

J’en conclu qu’il existe une équipe sécurité pour Testing qui se charge de faire arriver plus vite les mises à jour de sécurité que par le processus classique de validation, mais malgré ça elles arrivent quand même moins vite que dans stable (ou la sécurité est une exigence primordiale) ou dans Sid ou par définition les paquets sont toujours plus frais que dans Testing.