Pour débuter, reste en stable, et au cas par cas, si tu as besoin d’une fonctionalité pas encore implantée en stable, passe par les backports.
Une exception tout de même: si tu as du matériel très récent, tu seras peux étre obligé de passer en testing pour pouvoir l’utiliser.
Dans les bacckport, je conseille généralement de prendre le kernel , ça résout pas mal de problèmes (le kernel de la stable est assez ancien)
[quote=“vv222”][quote=“runedon”][quote=“vv222”]
Mais je ne me sens pas de taille pour l’instant, peut être quand j’aurais tout compris de ma stable ![/quote]
Si tu veux entraîner ta curiosité sans prendre le risque de casser ton système en faisant tes mises-à-jour avant de prendre ton café du matin, ricardo a donné la solution un peu plus haut 
[/quote][/quote]
Oui , une machine de test et une stable !
Ouais enfin quand ton PC ne boot plus parce qu’il y a eu un bug dans [mono]update-grub[/mono] (non signalé par [mono]apt-listbugs[/mono] sinon c’est trop facile) et qu’en plus tu ne retrouves aucun LiveCD/USB, tu tires quand même un peu la tronche. 
C’est ça aussi, les joies de testing et d’unstable.
Heureusement que j’ai plusieurs machines… 
[quote=“piratebab”]Pour débuter, reste en stable, et au cas par cas, si tu as besoin d’une fonctionalité pas encore implantée en stable, passe par les backports.
Une exception tout de même: si tu as du matériel très récent, tu seras peux étre obligé de passer en testing pour pouvoir l’utiliser.
Dans les bacckport, je conseille généralement de prendre le kernel , ça résout pas mal de problèmes (le kernel de la stable est assez ancien)[/quote]
je pense comme toi, c’est la solution que je compte adopter !
Pas forcément : j’imagine que tu connais le principe du double-boot ?
C’est parfaitement applicable dans ce cas.
Dans tous les cas, ton choix (stable + backports) est à mon avis le plus adapté pour découvrir Debian à ton rythme.
Est-ce que, actuellement, ils permettraient de faire tourner par exemple Flightgear ?
Pour être dans la situation dual-boot, j’ai quelques souci avec une testing qui refuse de démarrer : grub se charge, le système commence à se lance, puis plus rien : bloquer.
Personnellement, j’ai fait l’installation dans cet ordre : testing puis stable. Pourquoi ? Justement à cause de “grub”. Ainsi le dernier “grub” installé est celui de la stable qui est toujours disponible et le boot sur la testing se fait quand on veut : par défaut le système est toujours opérationnel.
Evidemment, quand plus rien ne va, il faut rebooter sur ce qui a servi à l’installation et utiliser le mode “rescue”.
Est-ce que, actuellement, ils permettraient de faire tourner par exemple Flightgear ?[/quote]
Je viens d’essayer avec le pilote libre radeon (+ le microprogramme proprio firmware-linux-nonfree), ça marche du tonnerre !
Par contre je suis en Sid, je n’ai pas de Wheezy sous la main pour tester.
OK, merci bien à toi de ce boulot qui n’est pass rien ! Je ne pensais pas que l’on fût déjà rendu là. Reste à savoir pour Nvidia, mais enfin j’imagine que c’est voisin ou que cela va l’être.
Ah bah si, sur le coup ce n’est rien !
Ça m’a pris trois commandes et cinq minutes :
[code]# apt-get install flightgear
$ fgfs
apt-get autoremove flightgear[/code]
[quote]- pour un poste client utilisateur averti: testing
- pour un poste client utilisateurs très averti ou téméraire: SID[/quote]
Je vais revenir sur ce que j’ai déjà dis maintes fois : pour moi la Testing et la Unstable (= Sid) sont des branches qui servent au développement de Debian. Si on ne compte pas contribuer au développement de la prochaine version de Debian, il est inutile d’utiliser ces branches.
Un utilisateur averti / très averti saura comment installer la toute dernière version d’un logiciel sur une Debian Stable sans que ça plante.
Il n’y a absolument aucune raison valable d’utiliser une Testing ou une Unstable sur une machine qui n’est pas destinée à faire du développement pour la prochaine version de Debian. La Testing correspond plus ou moins à une version Beta de Debian et la Unstable à une version Alpha.
Il existe tout un tas de solutions propres pour garder un système en Stable tout en ayant des paquets plus à jours : rétroportages (= backports en anglais), patche des sources, réempaquetage des binaires, chroot, machines virtuelles,…
Utiliser Testing ou Unstable montre précisément qu’on n’est pas au niveau pour savoir porter des versions récentes de logiciels sur une Stable.
Comprenez-moi bien : je ne dis pas cela avec mépris ou méchanceté. Ce que je dis c’est qu’utiliser une autre branche que la Stable c’est mal comprendre comment fonctionne Debian et c’est faire une utilisation erronée des branches. Les branches Testing et Unstable ne sont là que pour ceux qui contribuent au développement de la prochaine version, rien d’autre. Elles sont par définition bugguées et pleines de failles de sécurité. Sinon ça serait une Stable !
Si on veut une Debian Sid qui ne plante pas, ça s’appelle Ubuntu, ou quelque chose d’approchant.
J’étais un inconditionnel du double boot Windows + Linux depuis longtemps
Voir la conversation ici , d’un triple boot que j’ai tenté !
https://www.debian-fr.org/mon-idee-sur-mon-portable-t46686.html
j’avais tenté ce triple boot le temps de faire ma conversion vers Debian ,
Mais j’ai abandonné cette méthode car j’avais des problèmes d’affichages et des erreurs system
sans arrêt sur Ubuntu et Debian , je me suis donc dit , je vais changer ma méthode !
garder un ordinateur Windows pour peu de chose ! , et passer , progressivement le reste en Debian
Donc je vais partir a terme sur Un Windows seul,et 2 ordinateurs , en Debian un portable et un fixe !
Cela va peut être demander un peu de temps, car ce n’est pas une question de moyen, (Mais de santé )
ceci dit merci pour tes conseils !
[quote=“Cluxter”][quote]- pour un poste client utilisateur averti: testing
- pour un poste client utilisateurs très averti ou téméraire: SID[/quote]
Je vais revenir sur ce que j’ai déjà dis maintes fois : pour moi la Testing et la Unstable (= Sid) sont des branches qui servent au développement de Debian. Si on ne compte pas contribuer au développement de la prochaine version de Debian, il est inutile d’utiliser ces branches.
Un utilisateur averti / très averti saura comment installer la toute dernière version d’un logiciel sur une Debian Stable sans que ça plante.
Il n’y a absolument aucune raison valable d’utiliser une Testing ou une Unstable sur une machine qui n’est pas destinée à faire du développement pour la prochaine version de Debian. La Testing correspond plus ou moins à une version Beta de Debian et la Unstable à une version Alpha.
Il existe tout un tas de solutions propres pour garder un système en Stable tout en ayant des paquets plus à jours : rétroportages (= backports en anglais), patche des sources, réempaquetage des binaires, chroot, machines virtuelles,…
Utiliser Testing ou Unstable montre précisément qu’on n’est pas au niveau pour savoir porter des versions récentes de logiciels sur une Stable.
Comprenez-moi bien : je ne dis pas cela avec mépris ou méchanceté. Ce que je dis c’est qu’utiliser une autre branche que la Stable c’est mal comprendre comment fonctionne Debian et c’est faire une utilisation erronée des branches. Les branches Testing et Unstable ne sont là que pour ceux qui contribuent au développement de la prochaine version, rien d’autre. Elles sont par définition bugguées et pleines de failles de sécurité. Sinon ça serait une Stable !
Si on veut une Debian Sid qui ne plante pas, ça s’appelle Ubuntu, ou quelque chose d’approchant.[/quote]
Très Bien expliqué !
Tupeux aussi virtualiser un windows dans ta debian. Ca évite d’avoir 2 machines physiques. Si windows c’est pour leu avec un max d’effets, ce n’est évidement pas la bonne solution.
j’ai déjà utilisé virtualbox sous Ubuntu !
Je n’avais pas pensé a cette solution sous Debian
Il va falloir que je me documente ?
Ce serait intéressant d’être en stable avec une Testing ou unstable
virtualisée !
C’est faisable aussi.
Perso je suis plus KVM/QEMU
[quote=“piratebab”]C’est faisable aussi.
Perso je suis plus KVM/QEMU[/quote]
Oui pourquoi pas !
Quand même ! Et alors, si je comprends bien, on est en train de revenir à une période comparable à celle d’y a dix ans, où personne sous Linux ne se souciait des drivers graphiques propriétaires, ceux de l’OS suffisant amplement et peut-être leur étant parfois supérieurs… Une révolution !
Quand même ! Et alors, si je comprends bien, on est en train de revenir à une période comparable à celle d’y a dix ans, où personne sous Linux ne se souciait des drivers graphiques propriétaires, ceux de l’OS suffisant amplement et peut-être leur étant parfois supérieurs… Une révolution ![/quote]
Effectivement c’est ce qui est en train de se passer pour AMD, car ils développent à la fois des pilotes graphiques propriétaires et libres. Les pilotes libres sont développés depuis 2 ans et demi par une équipe très restreinte mais qui abat un boulot incroyable. Ils en sont à un point où maintenant ils arrivent à sortir les pilotes libres et à les intégrer dans le noyau avant la sortie des cartes graphiques sur le marché ! 
Concernant Intel ils ont toujours sortis uniquement des pilotes libres et ils font un travail remarquable sur tous leurs pilotes sous Linux, au point que les pilotes de leurs cartes graphiques et cartes-mères sont intégrés dans le noyau 9 mois avant la sortie du matériel sur le marché 
Enfin, Nvidia est une fois de plus montrée du doigt… Comme ils ne sortent que des pilotes propriétaires, les pilotes libres que la communauté réécrits en faisant de la rétro-ingénierie ont forcément toujours du retard sur les pilotes propriétaires. Ce que fait la communauté est impressionnant, ils ont un énorme mérite.
Donc en résumé Intel est la référence sur laquelle tous les fabricants devraient prendre modèle.
AMD est en train d’améliorer ses pilotes libres qui devraient à terme surpasser les pilotes propriétaires (leur approche prudente est intelligente techniquement et financièrement).
Et Nvidia… : youtube.com/watch?v=19jUboon5gI 
C’est vrai que je suis passé en Nvidia parce que pour Solaris il fallait du Nvidia, mais après tout, maintenant… Et alors plus de module-assistant, plus de nvidia-kernel-dkms et autres glx ! C’était la messe, pourtant…