Bonjour!
 
Je voulais savoir si le noyau debian 2.6 unstable est vraiment instable ou s'il est fiable.
Est-ce qu'il serait raisonnable d'installer par exemple un Firewall IPTables et un Squid sur un serveur sous Debian 2.6 ?
 
Si vous pouviez me répondre en m'expliquant briévement au passage que je me couche moins con
 
Merci

j'ai du 2.6 avec un squid dessus en prod et aucun problème

Oki c'est déjà bon de savoir ca.
Mais en fait c'est plus le délire du stable unstable qui me préocupe.
J'ai fais des recherches et compris théoriquement la différence entre stable/unstable/testing/experimental, mais je voudrai plus particulièrement savoir à quel point le noyau 2.6 peut etre qualifié de unstable.
 
Merci de ta réponse

le 2.6 est stable, renseigne toi sur comment fonctionne debian avant d'utilsier le mot 'unstable'

heu ca n'a rien a voir:
 
tu peux etre en stable avec 2.6 (d'ailleur c'est le 2.6.8.. qui est fournit par defaut)
tu peux aussi mettre 2.6.16-18 en stable compilé a la main.
 
Mais sid en production bof bof

c'est parque j'ai du mal à comprendre ces notions que je post!
Donc le noyau 2.6 existe en version stable, ca m'enlève un soucis.
 
Et dam tu veux dire quoi par "sid en production bof bof" ?

sid ca veut dire Still In Developpement.
 
Lis le topic debian c'est tout expliqué

ok merci !

debian = une distribution = un noyau + des programmes
stable = des programmes très très testés
testing = des programmes pas mal testés
unstable = des programmes peu testés
 
Après tu peux mettre le noyau que tu veux   On considère en général (mais ca peut déclencher des polémiques donc faut éviter de le dire) qu'une debian testing est largement aussi stable voire plus stable que certaines autres distribs. C'est juste que la politique debian ne vise pas la mise à jour frénétique des versions    
 
Un bon exemple ? Observe les versions de vim sur cette page, sachant que vim 7 est sorti début mai (edit : fait pas attention au "1:" devant les numéros de versions) : http://packages.debian.org/cgi-bin [...] ywords=vim

Il y a souvent une source de confusion au niveau du cycle de vie des distributions dans Debian, pour être clair je me permet d'apporter quelques éclaircissements supplémentaires.    
 
 
De façon simple,dans Debian le développement s'articule autour de trois distributions (ou 'branches') principales :
 
   --->   la distribution stable
   --->   la distribution testing
   --->   la distribution unstable
 
 
Le cheminement des paquets (logiciels) entre ces trois distributions permettent de mieux comprendre la fonction de chacune :  
 
   1) des paquets ou des nouvelles versions de paquets existants font leur apparition
 
   2) les développeurs Debian se chargent alors de les empaqueter et les soumettre
       au projet via un dépôt prévu à cet effet (le répertoire 'incoming')
 
   3) si ces paquets remplissent les critères de qualité requis (conformes à la Charte  
       Debian), ils entrent dans unstable
 
   4) les paquets demeurent ensuite dans unstable un certain laps de temps en vue  
       de déceler de possibles bugs
 
   5) après cette 'période de quarantaine', si aucun bug critique n'a été découvert,
       les paquets sont automatiquement tranférés dans testing
 
   6) les paquets resteront ensuite dans testing jusqu'à une prochaine mise à jour  
       ou jusqu'à ce que testing soit figée
 
   7) à un moment donné, les développeurs considèrent que testing est arrivée à
       maturité ; celle-ci est alors figée, elle est dite 'frozen'
 
   8) cette phase de 'gel' correspond à un état dans lequel les paquets ne devront
       être modifiés ou mis à jour que pour corriger les derniers bugs trouvés
 
   9) quand il n'y a plus aucun bug majeur de présent, et si aucun nouveau n'est
       découvert au bout d'une période de test (il peut y avoir ainsi plusieurs cycles  
       de tests jusqu'à ce qu'il n'y ait plus de bug) alors tous les paquets de testing
       passe en stable (c'est pourquoi testing représente la future version stable)
 
 10) une fois la transition effectuée, la nouvelle version stable est alors publiée ;
       pour garantir une stabilité maximale, les paquets dans stable ne seront plus
       modifiés (sauf correctifs de sécurité) jusqu'à ce qu'une nouvelle version stable
       sorte à nouveau de la même façon que précédement, et ainsi de suite...
 
 
A noter l'existence de 'experimental' qui contient certains paquets jugés trop dangereux pour entrer dans unstable, et l'existence de 'volatile' qui contient des versions récentes jugées stables de quelques paquets -essentiellement pour des questions de fonctionnalités (ex: scanner de virus Clamav). Du fait de leur caractère hybride et partiel, on ne peut pas désigner 'experimental' et 'volatile' comme des distributions ou branches à part entière.
 
 
Ces observations nous permettent ainsi de déduire les spécificités de chacune :
 
   ---> stable     :  extrême fiabilité, minimum de bugs, uniquement des mises à jour de sécurité des paquets
   ---> testing    :  bonne fiabilité, quelques bugs généralement mineurs, mises à jour régulières des paquets
   ---> unstable :  fiabilité réduite, nombre et gravité des bugs variable, mise à jour permanente des paquets
 
 
Enfin, pour pouvoir différencier les multiples distributions au fil du temps on utilise habituellement un numéro de version mais pour les distributions de développement il est de tradition d'employer un nom de code pour les désigner . Dans Debian, les noms de code utilisés jusqu'ici sont issus des noms des personnages de Toy Story (cette idée provient de Bruce Perens, un des anciens leaders de Debian qui travaillait à l'époque chez Pixar) :
 
   --->   la précédente distribution stable à pour nom de code 'Woody'
   --->   la distribution stable actuelle à pour nom de code 'Sarge'
   --->   la distribution testing actuelle à pour nom de code 'Etch'
   --->   la distribution unstable à pour toujours le nom de code 'Sid'
 
Ainsi, quand la distribution testing 'Etch' passera en stable, stable deviendra 'Etch'. Précisons qu'ensuite testing ne deviendra pas 'Sid' qui est un nom de code permanent pour désigner unstable (en perpétuel changement/développement) ; le prochain nom de testing sera déterminé un peu avant ou pendant la période de gel où celle-ci passera en 'frozen'.  
Pour finir j'indique qu'il existe tout de même des numéros de versions en plus des noms de code, mais ceux-ci ne sont utilisés que pour désigner les différentes distributions stable : ainsi on a Debian 'Woody' 3.0, Debian 'Sarge' 3.1 et dans le futur on aura Debian 'Etch' 3.2

 
PS : il existe oldstable apparement, la woody reçoit encore des updates de sécurité malgré l'existence de la sarge ?

Toutafé    
 

 
Franchement, tu crois pas que Etch sera la 4.0 . Je suis pas sur que les softs purement Debian aient bcp évolués d'accord, mais python 2.4, Xorg 7.0 et gcc 4.1 ca fait une belle evolution...

911> ce serait bien de mettre le post de thrak dans le premier, on saura où botter en touche

Jusqu'ici je n'ai pas entendu parler d'un numéro 4.0 pour Etch, mais on ne sait jamais qui sait ; toutefois si Etch porte le numéro de version 3.2, imagine ce qui nous attends alors pour une future version 4.0  

Quelques personnes avaient deja argumenté (je sais plus comment) pour que Sarge soit la 4.0 et non la 3.1 . A mon avis, ce coup-ci ca va etre bon  

Comment on switch entre sarge/etch/sid
 
Dans mes dépots j'ai mis les combinaisons stable, testing, updates pour main et contrib plus les sources (3*2*2=12 dépots)
 
Et il me dit "debian testing/unstable".
Suis-en sid, en Sarge, les deux ?
 
Merci

Pour la Etch 4.0 je sais pas, woody => sarge on avait juste fait 3.0 / 3.1 (remarque après 3.0 c'était un peu tôt pour passer à 4.0)
 
hdsdi : dans ton sources.list, tu peux mettre au choix : stable, testing, unstable, sarge, etch, sid (testing = testing de tout temps, etch ben le jour où elle passe stable tu bougeras plus). Et faut surtout pas mélanger ca pète tout je pense (sauf si tu tunes bien les priorités de telle et telle version derrière mais bon...)