Journal Comment je suis passé d'Ubuntu à Debian Sid

Posté par Cyprien (site web personnel) le 11 mai 2017 à 09:33. Licence CC By‑SA.

Étiquettes :

mai

2017

J'utilise Ubuntu Linux depuis 10 ans, surtout pour sa simplicité. J'ai plusieurs fois tenté de passer sur Debian, notamment pour éviter les mises à jours douloureuses tous les 6 mois, mais j'ai toujours rencontré des obstacles qui m'ont fait faire demi-tour. Voilà six mois, j'y suis arrivé avec bonheur après une autre tentative, et finalement, ca n'est pas si compliqué !
Voici un rapide guide, non exhaustif, pour ceux qui voudraient aussi se lancer et éviter quelques pièges.

Avertissements

Je suis débutant avec SID, il est donc fort probable qu'il ait des imprécisions dans ce journal
Sid est une rolling release, vous aurez donc quelques dizaines de MO à télécharger tous les jours

Choix de la version : Sid !!

Il y a 4 versions de Debian :
Stable - Testing - Unstable (Sid) - Experimental
Alors, laquelle choisir ?
Cela parait simple, la Stable est fiable mais avec de vieux logiciels, de l'autre côté, l'Expérimental possède des logiciels derniers cris mais possède plus de bugs.
Donc, on a le choix entre Unstable et Testing : Erreur ! La testing ne sert qu'à valider la prochaine Stable donc elle suit le cycle de développement. Si elle ressemble à la Unstable à la sortie d'une nouvelle version stable, elle ressemblera plus à Unstable avant la sortie d'une version stable.
Bon, c'est compliqué tout cela, choisissez donc unstable (Sid) pour votre desktop :)

Installation

Maintenant vous allez chercher une iso de SID… Mais elle n'existe pas. En fait, il faut d'abord installer une version stable et la passer ensuite en SID. C'est plus long que compliqué.
Télécharger d'abord l'ISO de la version stable. J'ai utilisé cette page. J'ai pris l'image netinst qui contient le minimum de paquets et qui télécharge, durant l'installation, les autres paquets nécessaires.
L'installation est simple et ne devrait pas vous dépayser d'Ubuntu. Pour le choix du bureau, j'utilise Gnome, mais j'ai également installé XFCE sur une plus petite config. Je n'ai rencontré aucun problème avec l'intégration de ces environnement.

Autoriser Sudo

Par défaut, vous ne pouvez pas utiliser sudo avec Debian ! Pour exécuter une commande en root, il faut lancer la commande su. Cela a été difficile pour moi de m'habituer donc j'ai suivi ce guide pour utiliser sudo avec l'utilisateur créé lors de l'installation.
Pour résumer, il suffit de lancer la commande :
adduser nom_utilisateur sudo
et ensuite redémarrer une session (ou l'ordinateur)

Passer en unstable

Vous avez maintenant une belle debian stable installée. Il faut la passer en SID (unstable) :
sudo nano /etc/apt/sources.list

ensuite, j'ai remplacé l'ensemble des lignes du fichier par :
deb http://ftp.fr.debian.org/debian/ sid main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ sid main contrib non-free

puis j'ai lancé les commandes habituelles :
sudo apt-get update
sudo apt-get dist-upgrade
Après l'installation et le redémarrage, vous êtes en possession d'une debian SID en rolling release !

Eviter les paquets qui contiennent de bugs grave

Avec une rolling release, il arrive d'avoir des paquets qui contiennent des bugs graves. Pour les éviter, il suffit d'installer le paquet apt-listbugs.
sudo apt-get install apt-listbugs
Lors des mises à jours, vous aurez alors un message vous prévenant que le paquet a été signalé comme contenant un bug. Je réponds alors toujours "p" pour "Pinning" et la mise à jour attendra une version non buggé de ce paquet. (Pour en savoir plus).

Voilà, grâce à ces quelques manipulations, j'ai une debian SID qui fonctionne parfaitement depuis 6 mois avec des logiciels à jours en permanence. Le bonheur, c'est simple comme SID :)

# Installation par mini.iso

Posté par Xanathos le 11 mai 2017 à 09:40. Évalué à 8.

L'autre solution, peut-être plus simple et plus propre pour l'installation, est de passer par la mini.iso puis de choisir d'installer la version unstable.
https://wiki.debian.org/fr/InstallFAQ#Q._Comment_installer_.2BAKs_unstable_.2BALs_.28Sid.29_.3F

C'est comme ça que j'ai fait à ma dernière installation de sid et ça s'est très bien passé !
- [^] # Re: Installation par mini.iso
  
  Posté par barmic le 11 mai 2017 à 11:11. Évalué à 9.
  Moi j'utilise une live (généralement Debian) et j'utilise debootstrap. C'est super rigolo comme façon d'installer et ça me permet :
  - d'avoir une base assez petite
  - d'utiliser un noyau à jour dès le départ, de choisir un partitionnement comme je l'entends sans être contrains par l'installeur
  - de continuer à lire mes mails et écouter de la musique pendant mon installation :)
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Installation par mini.iso
    
    Posté par ZeroHeure (site web personnel) le 11 mai 2017 à 14:41. Évalué à 4.
    
    de choisir un partitionnement comme je l'entends sans être contrains par l'installeur
    
    L'installateur ne te contraint en rien. En choisissant « Partitionnement manuel » tu fais ce que tu veux.
    
    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
    - [^] # Re: Installation par mini.iso
      
      Posté par barmic le 11 mai 2017 à 14:52. Évalué à 3.
      
      Il fut un temps ou pour faire du btrfs, il n'y avait pas de solution uniquement par l'installeur.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Installation par mini.iso
        
        Posté par ZeroHeure (site web personnel) le 11 mai 2017 à 15:09. Évalué à 3.
        
        Ce que ne sait pas faire l'installeur se contourne facilement en ouvrant un shell (depuis l'installeur). C'est d'ailleurs presque toujours comme ça que je procède.
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: Installation par mini.iso
        
        Posté par barmic le 11 mai 2017 à 15:59. Évalué à 8.
        
        He ben c'est vachement pratique de passer par debootstrap quand tu en arrive là. Tu as un émulateur de terminal et pas un TTY avec peu de colonnes, tu peux flâner sur le web pour retrouver tes notes, lire de la doc, chercher de l'aide ou pour troller sur linuxfr, etc
        
        Ça permet aussi de voir la simplicité d'une installation (c'est pas mal d'étapes, mais rien de bien compliqué).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Installation par mini.iso
        
        Posté par ZeroHeure (site web personnel) le 11 mai 2017 à 17:32. Évalué à 5.
        
        Tu as raison d'insister sur debootstrap, et j'admet volontier le côté pratique pour consulter la doc! Et puis installer à partir d'un autre système est effectivement une bonne façon de voir comment ça se fait, que ça n'a rien de magique ni de compliqué. On peut tout faire "à la main".
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# 6 bons mois

Posté par Denis Dordoigne le 11 mai 2017 à 10:09. Évalué à 10.

Je suis utilisateur de debian sid depuis plusieurs années, et les six derniers mois ne sont pas forcément représentatifs des risques encourus, il n'y a pas eu de changement majeur. Je ne conseillerais pas cette distribution pour des personnes n'ayant pas déjà de bonnes connaissances en administration linux et gestion de paquets debian, parce qu'on peut aussi facilement se retrouver avec des problèmes de dépendances de paquets à cause de renommages ou de changement d'outil (passage de ffmpeg à avconv par exemple), un système bordélique parce qu'il y a un changement majeur en cours (arrivée de systemd par exemple), ou un service qui nous est essentiel qui ne marche pas parce qu'il n'a pas encore été testé pour notre configuration (j'ai personnellement beaucoup souffert lors du passage à Xorg, et lorsque j'ai acheté une nouvelle carte graphique il y a 2 ans j'ai bien fait attention à prendre un modèle très standard en prévision de l'arrivée de wayland).

Mais je suis quand même un utilisateur très satisfait de SID, je veille juste à ne pas faire de mises à jour quand je suis d'astreinte :) Remarque : j'ai longtemps tourné avec ubuntu au bureau parce que c'était ce qu'utilisaient mes collègues, et j'ai eu plein de problèmes à chaque mise à jour avec le matériel utilisant des pilotes privateurs, je perdais à chaque fois une demi-journée, ça me gonflait sévère. L'année dernière après une mise à jour foireuse de LTS ça m'a gonflé grave (j'avais naïvement cru ceux qui me disaient que mon problème était que je ne faisais pas que des mises à jour de LTS en LTS) et je suis passé en debian sid avec des pilotes libres : depuis je n'ai plus de problème, mais je dois reconnaître que par sur-précaution je ne fais pas de mises à jour au bureau que je n'ai pas d'abord testée chez moi.

Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
- [^] # Re: 6 bons mois
  
  Posté par ʭ ☯ le 11 mai 2017 à 10:23. Évalué à 5.
  
  j'ai personnellement beaucoup souffert lors du passage à Xorg
  
  Idem, je suis revenu à ~~Mandriva~~ Mageia à ce moment-là. J'imagine que ce sera du coup le passage à Wayland qui sera aussi douloureux…
  
  Effectivement, les moments où la prochaine Debian stable approche sont sans douleur, et ne ressemblent pas au reste (j'ai fait 4 ans de SID sur mon poste professionnel). C'est un peu comme le chaudron de Mageia, qui est très stable depuis un an : la nouvelle version ayant pris du retard, il évolue très peu.
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
  - [^] # Re: 6 bons mois
    
    Posté par _eLRIC le 14 mai 2017 à 09:21. Évalué à 2.
    
    Idem : depuis près de 15 ans sur SID et les rares problèmes que j'ai eus étaient au passage à Xorg, et en particulier avec les drivers Nvidia.
    
    SID est tout à fait pertinente pour du desktop du moment qu'on :
    - n'a pas de matériel "exotique" (d'un autre côté, dans ce cas, l'herbe est-elle plus verte ailleurs ?)
    - fait ses MAJ régulièrement, au moins 2x par mois, pour éviter qu'apt ne s'emmêle les pinceaux avec trop de paquets
    
    Ensuite, comme mentionné dans d'autres commentaires, ne pas hésiter à aller chercher quelques paquets dans experimental (Firefox notamment)
# apt-listbugs

Posté par nono47 le 11 mai 2017 à 10:11. Évalué à 5.

Salut,

Avant de changer les sources pour sid, il est de bon ton d'installer apt-listbugs pour ne pas installer de paquets bogués qui pourrait casser le système .
Le mode d'emploi @ debian-facile : https://debian-facile.org/doc:systeme:apt:apt-listbugs
- [^] # Re: apt-listbugs
  
  Posté par eingousef le 11 mai 2017 à 10:50. Évalué à 6.
  
  Ne pas oublier d'installer aussi reportbug, pour le cas où tu installes tes mises à jour très vite, avant que apt-listbug ait des bugs à te rapporter.
  
  *splash!*
# Pertinence de listbug

Posté par Marco le 11 mai 2017 à 10:13. Évalué à 4.

Salut,
Je peux me tromper mais j'ai l'impression que listbug te fait virtuellement passer de sid à testing. Le fait d'éviter les bugs les plus critiques c'est pas le principe de testing (seul les paquets sans bug repéré au bout de 10 jours passent à testing) ?
J'ai peut être mal saisi l'utilité de ce paquet, quelqu'un peut m'expliquer l'avantage par rapport à testing ?

Si elle ressemble à la Unstable à la sortie d'une nouvelle version stable, elle ressemblera plus à Unstable avant la sortie d'une version stable.

Avant la sortie de la stable en général la testing ressemblera fortement à une stable puisqu'il y aura eu un freeze
- [^] # Re: Pertinence de listbug
  
  Posté par chimrod (site web personnel) le 11 mai 2017 à 10:41. Évalué à 3. Dernière modification le 11 mai 2017 à 10:41.
  
  Il te permet de lister les bugs connus pour un paquet donné, et te laisse choisir l'action correspondante. Par exemple il m'arrive d'installer quand même des paquets quand je sais que les bugs annoncés ne me concerne pas (par exemple incompatibilité avec tel autre paquet que je n'ai pas installé, ou erreur sur une autre architecture que la mienne).
  
  En même temps, il peut également être installé sur testing, pour bloquer les mises à jours qui peuvent poser problème, donc c'est plutôt complémentaire à sid/testing.
- [^] # Re: Pertinence de listbug
  
  Posté par eingousef le 11 mai 2017 à 10:43. Évalué à 3.
  
  Je ne peux pas parler pour unstable mais j'utilise testing et apt-listbugs et ça me sert. Parfois un bug important apparaît dans l'un des paquets que je veux mettre à jour, dans ce cas je le garde en "hold" pendant quelques semaines, et je le met à jour quand le bug n'apparaît plus. Donc mes paquets sont bien souvent à jour par rapport à la branche, il y en a juste un ou deux qui sont en "hold" une fois de temps en temps.
  
  *splash!*
  - [^] # Re: Pertinence de listbug
    
    Posté par eingousef le 11 mai 2017 à 11:14. Évalué à 2.
    
    Lors des mises à jours, vous aurez alors un message vous prévenant que le paquet a été signalé comme contenant un bug. Je réponds alors toujours "p" pour "Pinning" et la mise à jour attendra une version non buggé de ce paquet.
    
    Ah ben j'ai lu trop vite, il en parlait dans le journal. Je ne savais pas qu'apt-get/unstable proposait de pinner comme ça, c'est une fonctionnalité bien pratique que aptitude/testing n'a pas.
    
    *splash!*
    - [^] # Re: Pertinence de listbug
      
      Posté par vv222 (site web personnel) le 12 mai 2017 à 15:45. Évalué à 2.
      
      C’est une fonctionnalité d’apt-listbugs, pas d’apt-get/aptitude.
      Et elle est présente dans les versions d’apt-listbugs proposées dans toutes les branches de Debian ;)
      - [^] # Re: Pertinence de listbug
        
        Posté par eingousef le 12 mai 2017 à 16:24. Évalué à 3.
        
        Ah ? De mémoire elle ne me proposait que [Y/n/?]
        
        *splash!*
        
        [^] # Re: Pertinence de listbug
        
        Posté par vv222 (site web personnel) le 12 mai 2017 à 17:57. Évalué à 3.
        
        Le p est très probablement caché derrière le ? ;P
        Il y a en fait bien plus d’options que de simplement accepter ou refuser la mise-à-jour de la totalité des paquets, y compris la possibilité de consulter directement les rapports de bugs complets dans ta console ou de figer seulement certains paquets.
        
        [^] # Re: Pertinence de listbug
        
        Posté par eingousef le 12 mai 2017 à 21:35. Évalué à 3.
        
        Effectivement !
        
        Êtes-vous certain(e) de vouloir installer/mettre à jour les paquets ci-dessus ? [Y/n/?/...] ? y - continuer l'installation avec APT, mais sans marquer les bogues comme étant ignorés. a - continuer l'installation avec APT en marquant tous les bogues ci-dessus comme étant ignorés. n - interrompre l'installation avec APT. <num> - demander le rapport de bogue spécifié (nécessite reportbug). #<num> - identique à <num>. b<id> - comme <num>, mais interrogeant le bogue identifié par <id>. r - afficher les listes de bogues. p <pqt..> - figer les paquets (APT doit être relancé pour activer cette option). p - figer tous les paquets ci-dessus (APT doit être relancé pour activer cette option). i <num> - marquer comme étant ignoré le bogue numéro <num>. i b<id> - marquer comme étant ignoré le bogue identifié par <id>. ? - afficher cette aide. w - afficher les listes de bogues en HTML (cette option utilise sensible-browser).
        
        *splash!*
# SID

Posté par tiot (site web personnel) le 11 mai 2017 à 10:14. Évalué à 9.

J'étais sur debian sid il y a très longtemps (une bonne dizaine d'années) et j'ai été très séduit par le côté rolling release. J'étais sous Slackware et une mise à jour s'était très mal passée : plus de son etc. Bref réinstaller son système tous les X mois est assez contraignant.

Puis comme une nouvelle version de debian devait sortir ils ont gelés SID pendant plusieurs mois. Il n'y avait alors plus de montée de version. Le Firefox (qui a l'époque montait de version moins souvent qu'aujourd'hui) était dépassé sur la base SID.
De plus j'ai eu quelques mise à jour qui se sont assez mal passées.

Au final je ne pense pas que Debian SID soit une bonne solution pour avoir une distribution en rolling release. Tout simplement car ce n'est a pas son but. Parfois des paquets cassent tout et il y a le gèle pour la prochaine debian.

Je suis donc passé à une distribution rolling release (archlinux mais maintenant il y en a plus) et cela correspond beaucoup mieux à ce que je cherche : une machine à jour facile à maintenir.
- [^] # Re: SID
  
  Posté par eingousef le 11 mai 2017 à 11:09. Évalué à 3.
  
  Puis comme une nouvelle version de debian devait sortir ils ont gelés SID pendant plusieurs mois. Il n'y avait alors plus de montée de version. Le Firefox (qui a l'époque montait de version moins souvent qu'aujourd'hui) était dépassé sur la base SID.
  De plus j'ai eu quelques mise à jour qui se sont assez mal passées.
  
  Les périodes de freeze c'est assez chiant ouais. Je suis sous testing et là je sais que je vais devoir attendre plusieurs mois avant d'avoir l'alléchant mesa 17.
  
  D'autant plus que je ne met pas à jour tout mon système tout de suite à la fin du freeze, parce que je sais que la vague de paquets transférés de unstable à testing à ce moment-là peut poser pas mal de problèmes. J'attends donc entre 2 semaines et 1 mois avant de mettre à jour (c'est à dire que je passe en stable pendant 2 semaines - 1 mois :) ). Après cette période le gros des bugs qui cassent tout a été corrigé.
  
  Note que j'utilise un environnement de bureau minimaliste et que je privilégie les logiciels les plus "KISS" (les plus simples et qui dépendent le moins d'un autre logiciel particulier), ce qui réduit pas mal la probabilité de "yatouképété suite à l'upgrade".
  
  Si tu utilises un environnement complexe, style Gnome, KDE, Mate, Xfce, avec du GTK/Qt de partout, du *-kit, du *-dbus, du systemd-*, du upower, etc., je conseille d'attendre plutôt entre 1 et 2 mois.
  
  *splash!*
  - [^] # Re: SID
    
    Posté par tiot (site web personnel) le 11 mai 2017 à 11:45. Évalué à 10.
    
    Exactement… Ça montre bien que debian n'est pas faite pour avoir un système à jour.
    
    Cette distribution à d'excellentes qualités :
    - nombre de paquets phénoménale
    - système très stable
    - séparation nette entre paquets libre et non libre
    - activisme pour le logiciel libre
    
    Par contre pour avoir un système à jour avec les dernières nouveautés et une administration minimal je trouve que debian SID n'est vraiment pas adapté.
    Moi attendre 2 mois pour qu'au petit bonheur la mise à jour ne plante pas tout ça ne me plaît pas trop. Ça demande de se tenir au courant des paquets qui arrivent et de devoir gérer un système tout cassé.
    
    Alors que franchement sans faire d'activismes pour archlinux j'ai un système à jour qui est très facile à maintenir. Je n'ai quasi jamais de problème et si j'en ai un je l'ai toujours résolu très vite via le site officiel.
    
    Bref si une personne veut un système en rolling je ne conseille pas Debian.
    - [^] # Re: SID
      
      Posté par reynum (site web personnel) le 11 mai 2017 à 13:59. Évalué à 3.
      
      Par contre pour avoir un système à jour avec les dernières nouveautés et une administration minimal je trouve que debian SID n'est vraiment pas adapté.
      
      En fait eingousef parlait de Testing et non de Sid.
      Testing est un peu particulière les paquets rentrent mais peuvent aussi ressortir si ils sont bugés ce qui peut générer des grosses prises de tête (vécu :-)), alors que Sid est une rolling les paquets ne peuvent pas disparaître, par contre il peut y avoir plus d'instabilité mais pas plus que dans une arch car si bug il y a il vient le plus souvent du soft et non de son packaging.
      
      kentoc'h mervel eget bezan saotred
      - [^] # Re: SID
        
        Posté par Barikad le 11 mai 2017 à 16:52. Évalué à -2.
        
        Parler de SID comme d'une rolling est un peu rapide… C'est une version instable où les paquets sont balancés sans vérifications préalables. A part eprouver les paquets Debian, je ne vois pas l'interet de proposer ca à un utilisateur. Si on veut du rolling, il y a des distributions faites pour (Arch et derivés par exemple)
        
        [^] # Re: SID
        
        Posté par reynum (site web personnel) le 11 mai 2017 à 16:57. Évalué à 4.
        
        C'est une version instable où les paquets sont balancés sans vérifications préalables.
        
        Non ça c'est le rôle de expérimental, les paquets de unstable ont déjà eu quelques tests de fonctionnement.
        
        kentoc'h mervel eget bezan saotred
# config un peu évoluée

Posté par reynum (site web personnel) le 11 mai 2017 à 10:51. Évalué à 8.
Bon, c'est compliqué tout cela, choisissez donc unstable (Sid) pour votre desktop :)

En fait Sid est parfois sérieusement cassée ce qui peut être très gênant.
Testing est parfois amputée de certains paquet ce qui peut être très gênant aussi.
Stable ne dispose pas de logiciel ayant des fonctionnalités récentes ce qui peut être très gênant aussi aussi.

ma solution est de faire un fichier de preferences (/etc/apt/preferences)
```
Package: * 
Pin: release a=testing
Pin-Priority: 900

Package: * 
Pin: release a=stable
Pin-Priority: 890

Package: *
Pin: release a=sid
Pin-Priority: 90
```
Ici nous avons les trois distribs avec différentes priorités la plus grande à testing et la plus petite à sid, ceci permet de pouvoir choisir de quelle distrib vient le paquet et du coup pouvoir limiter les problèmes et instabilités relatives aux bugs non corrigés ou paquets comportant des erreurs.

ATTENTION ce genre de config nécessite une bonne connaissance du gestionnaire de paquets

Pour en savoir plus sur cette fonctionnalité de Debian

kentoc'h mervel eget bezan saotred
- [^] # Re: config un peu évoluée
  
  Posté par esdeem le 11 mai 2017 à 12:54. Évalué à 3.
  Effectivement, l'apt-pinnig est une solution assez pratique et qui fonctionne bien une fois les réglages effectués correctement, mais ça demande de bien lire la doc pour ne pas tomber dans les pièges des réglages fais un peu vite (genre mettre 999).
  
  Ça me permet d'avoir une testing comme base, mais d'avoir accès aisément à stable, testing, unstable et experimental.
  J'ai fais le réglages il y a quelques années et je n'ai plus touché, vu que ça faisait ce que je voulais correctement.
  
  Mon /etc/apt/preferences ressemble à ceci :
```
Package: *
Pin: release a=testing
Pin-Priority: 990

Package: *
Pin: release a=testing-proposed-updates
Pin-Priority: 900

Package: *
Pin: release a=stable
Pin-Priority: 850

Package: *
Pin: release a=stable-proposed-updates
Pin-Priority: 840

Package: *
Pin: release a=unstable
Pin-Priority: 700

Package: *
Pin: release a=experimental
Pin-Priority: 400
```
  Ensuite tu peux forcer l'installation d'une version précise en faisant un truc du genre :
```
sudo apt install -t <version> ton_paquet
```
  Pas de soucis si tu installes depuis > testing, les mises à jour seront aisées.
  
  Mais il faut quand même faire gaffe si tu veux absolument un paquet < testing et éventuellement traiter les mises à jour à la main et bloquer les paquets individuellement.
  
  0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
# Hum...

Posté par mahikeulbody le 11 mai 2017 à 10:59. Évalué à 7.

Tout ça ne me donne guère envie de quitter Ubuntu et encore moins de l'installer chez les quelques "madame/monsieur Michu" qui me demandent de les sortir de Windows.

Mais ne me faîtes pas dire ce que je n'ai pas dit : je sais parfaitement que sans Debian, Ubuntu n'existerait pas.
- [^] # Re: Hum...
  
  Posté par Psychofox (Mastodon) le 11 mai 2017 à 15:03. Évalué à 6. Dernière modification le 11 mai 2017 à 15:06.
  
  Tu peux aussi très bien utiliser la stable et avoir une utilisation très tranquille. C'est ce que je fais.
  
  Est-ce que j'ai les toutes dernières fonctionnalités de chaque logiciel ? Souvent non. Est-ce que j'en souffre ? Pas vraiment. Pour différentes raisons :
  
  [1] C'est pas parce qu'on n'a pas la dernière version d'un logiciel qu'on est au courant de ce qu'apporte les nouvelles. Du coup on n'en ressentira pas le besoin.
  
  [2] Les dernières versions d'un logiciel n'apportent pas forcément des fonctionnalités qui nous intéressent.
  
  [3] Un certain nombre de projets upstream proposent leurs propres dépôts dans les cas où l'on veut la toute
  dernière version.
  
  [4] Il existe le repo backports permettant d'installer des versions plus récentes d'un certain nombre de paquets. Exemple à l'heure où j'écris ces lignes le kernel 4.9 est dispo pour stable.
  
  et enfin pour les plus technards d'entre nous
  
  [5] Il est toujours possible de deboostraper la testing ou la sid voire même installer une autre distribution dans un chroot et d'utiliser quelques applis plus récentes par ce biais.
  
  [6] Docker !
  
  Pour ma part dans le cadre d'une utilisation personnelle à la maison il m'est très rarement arrivé d'utiliser les backports, j'ai souvent eu quelque dépots upstream. C'est essentiellement dans le cadre professionnel que j'ai eu éventuellement recours aux options 4 à 6.
  - [^] # Re: Hum...
    
    Posté par kna le 11 mai 2017 à 17:04. Évalué à 3.
    
    [7] tu peux faire tes propres backports depuis les paquets source de testing/sid ou faire du pinning.
  - [^] # Re: Hum...
    
    Posté par Stinouff le 11 mai 2017 à 17:24. Évalué à 2.
    
    J'ajouterais :
    
    Il y a un vrai plaisir à passer à la version supérieure de Debian. D'un coup, tout le système est tout neuf, et ce ne sont pas 2-3 améliorations par-ci par-là qui causent (ou d'ailleurs, qui ne causent pas…). Non, c'est plein de nouveautés partout. :D
    - [^] # Re: Hum...
      
      Posté par groumly le 12 mai 2017 à 07:21. Évalué à 10.
      
      Vous êtes géniaux, changez rien.
      Entre l'un qui explique que c'est pas grave de pas avoir des bugs fix tant qu'on est pas au courant qu'ils on été corrigés, et l'autre qui t'explique que c'est génial de pas mettre à jour pendant 2 ans parce que tu découvres un nouveau monde à chaque fois, je me bidonne, mais d'une force.
      
      C'est comme si je venais expliquer que c'est pas grave d'avoir les chiottes au fond du jardin tant qu'on sait pas que les autres ont des chiottes moderne, et que se retenir de chier pendant 1 semaine, c'est de la balle parce que quand tu finit par poser ton colombin, ca fait un bien fou!
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Hum...
        
        Posté par reynum (site web personnel) le 12 mai 2017 à 08:16. Évalué à 2.
        
        Entre l'un qui explique que c'est pas grave de pas avoir des bugs fix tant qu'on est pas au courant qu'ils on été corrigés, et l'autre qui t'explique que c'est génial de pas mettre à jour pendant 2 ans parce que tu découvres un nouveau monde à chaque fois, je me bidonne, mais d'une force.
        
        C'est si drôle de découvrir qu'il y a des gens qui pensent différemment de soi ?
        
        C'est comme si je venais expliquer que c'est pas grave d'avoir les chiottes au fond du jardin
        
        Et alors ? si la personne est heureuse comme ça qu'est ce que ça peut vous faire ?
        On notera au passage que les toilettes à l'ancienne au fond du jardin gâche beaucoup moins d'eau potable que l'es "modernes"
        
        et que se retenir de chier pendant 1 semaine, c'est de la balle parce que quand tu finit par poser ton colombin, ca fait un bien fou!
        
        C'est sure qu'entre un ordinateur à jour et une occlusion intestinale il n'y a aucune différence. :-)
        
        kentoc'h mervel eget bezan saotred
        
        [^] # Re: Hum...
        
        Posté par Anonyme le 12 mai 2017 à 12:39. Évalué à 7.
        
        Je pensais pas qu’un jour, sur DLFP, je tomberais sur un commentaire qui défend les chiottes au fond du jardin.
        
        Je crois que j’ai passé un nouveau cap dans ma vie.
        
        [^] # Re: Hum...
        
        Posté par reynum (site web personnel) le 12 mai 2017 à 12:58. Évalué à 6.
        
        Je pensais pas qu’un jour, sur DLFP, je tomberais sur un commentaire qui défend les chiottes au fond du jardin.
        
        😂
        Si vous lisez bien je ne défend pas les chiottes de jardin, je laisse un message de tolérance, en disant que si des gens veulent continuer à faire comme ça je respecte leurs choix.
        
        kentoc'h mervel eget bezan saotred
- [^] # Re: Hum...
  
  Posté par saltimbanque (site web personnel) le 11 mai 2017 à 15:22. Évalué à 3.
  
  "tout ça" : préciser svp. Bon puisque la phrase contient messieurs dames Michu un réflexe se lance, réorienter vers Debian Stable, nommée en ce moment Jessie… distribution qui satisfaire les plus exigeants.
  
  La stabilité est magnitifique; ça me rappelle cet article de M de Icaza qui installe Mac os et se rend compte que tout marche tout seul. Ben il aurait pu essayer Debian Stable…
  
  La vieillesse des logiciels? bof. déjà y'a des backports. ensuite on peut attendre. genre avoir le desktop de y'a 1an 1/2 ou de maintenant c'est la même, alors… de plus pour celui qui veut faire mumuse des solutions se mettent en place ou existent de longue date - flatpak, snappy, appamor
- [^] # Re: Hum...
  
  Posté par Stinouff le 11 mai 2017 à 17:23. Évalué à 3.
  
  À dire vrai, je faisais comme toi, j'installais Ubuntu/Mint. Mais avec le temps, je suis passé à Debian Stable chez les gens. Et c'est tellement mieux.
  
  En fait, c'est bien simple : une fois la distribution configurée (ce qui va très vite), je suis tranquille pour plusieurs années. :)
  
  Debian Stable, c'est la vie.
- [^] # Re: Hum...
  
  Posté par reynum (site web personnel) le 12 mai 2017 à 08:19. Évalué à 3.
  
  installer chez les quelques "madame/monsieur Michu" qui me demandent de les sortir de Windows.
  
  Pour ma part depuis quelques années j'ai opté pour Linux Mint, jusqu'à maintenant tous les gens sont satisfait.
  
  kentoc'h mervel eget bezan saotred
# Aptosid

Posté par Goffi (site web personnel, Mastodon) le 11 mai 2017 à 12:18. Évalué à 3.

J'ai utilisé pendant un moment Aptosid qui est surtout intéressante à l'installation (installation de SID directement), et également pour son forum qui permet d'anticiper/trouver de l'aide pour les problèmes après des mises à jour : http://aptosid.com/index.php?name=PNphpBB2&file=viewforum&f=3&sid=e8fcdae185d9730c83d52ad50f9d5fcf

Ça vaut le coup d'y jeter un œil.

Là ça fait un peu plus d'un an que je me suis mis à Arch, c'est une distro qui a bonne réputation et c'est mérité elle est vraiment chouette, et j'ai très peu voire pas d'ennuis avec (et son wiki est excellent). Ça peut être utile de coupler à un système de containeurs (lxc, Docker ou autre) pour certains cas, notamment quand on veut des versions précises de logiciels ou une distro particulière.
# Pourquoi ?

Posté par lockidor le 11 mai 2017 à 12:52. Évalué à 5.

Pourquoi, si des gens veulent une rolling-release, ne prennent-ils pas une distribution dédiée à ce modèle de mises à jour, comme OpenSuse Tumbleweed ou à la limite Arch ou Void au lieu d'essayer de forcer Debian dans un rôle qui n'est pas le sien ?
- [^] # Re: Pourquoi ?
  
  Posté par Anonyme le 11 mai 2017 à 13:40. Évalué à 2.
  
  Parce que ça marche bien et que j’ai tous les outils et packages que je connais.
  - [^] # Re: Pourquoi ?
    
    Posté par saltimbanque (site web personnel) le 11 mai 2017 à 15:47. Évalué à 3.
    
    "à la limite Arch" : en dépit des avertissements quant à Debian Sid, cette rolling release est en réalité assez sereine. Aucune comparaison avec Arch. En des années d'usage il se peut que vous ne rencontriez pas le moindre crash de session graphique. Pas la même avec Arch. Je n'ai pas testé Tumbleweed c'est vrai que c'est une bonne quesiton. Mais à mon avis ça rentre plutôt dans la catégorie "fedora rawhide" où ce genre de trucs sport extrême
    - [^] # Re: Pourquoi ?
      
      Posté par Nibel le 11 mai 2017 à 16:52. Évalué à 5. Dernière modification le 11 mai 2017 à 16:53.
      
      J'ai personnellement vécu l'expérience inverse : dès qu'il y a de gros changements Sid a toujours fini par me lâcher et m'a fait bien souffrir.
      
      Alors qu'en 8 ans sous Arch, les seuls problèmes rencontrés durant une MAJ étaient du au fait que je n'étais pas aller lire le fil d'actualité pour migrer proprement. Entièrement de ma faute.
      
      Comme quoi, ça dépend des gens… Pour ma part, je n'ai pas connu de RR aussi solide que celle de Arch actuellement.
      
      La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
      - [^] # Re: Pourquoi ?
        
        Posté par saltimbanque (site web personnel) le 11 mai 2017 à 22:28. Évalué à 3.
        
        ah heureux de l'apprendre! (enfin pour Arch, triste que Sid t'ait fait défaut). Oui c'est logique qu'en fonction du hardware & de l'environnement on ait des cas différents.
        
        Cela dit je postais le truc honnêtement donc je fus surpris. Je ne sais pas si un site permettrait de faire des moyennes… bah oui c'est con mais du coup pour conseiller quelqu'un, dans le meilleur des cas on se retrouve à se fier à ses expériences & connaissances…
      - [^] # Re: Pourquoi ?
        
        Posté par Psychofox (Mastodon) le 11 mai 2017 à 22:35. Évalué à 3.
        
        J'ai eu la même chose. La fois où ils avaient déplacés les binaire de /bin à /usr/bin (ou le contraire je ne sais plus).
        
        Mais bon pour moi c'est justement pas admissible dans une optique pc de bureau d'avoir un système en rolling release mais qui peut potentiellement être cassé par pacman -syu parce que t'as pas suivi l'actualité dans les mailings lists. Soit tu t'assures que tout se passe automatiquement, soit tu t'assures que l'outil d'upgrade ait une fonction "drapeau noir" pour avertir l'utilisateur que s'il ne fait pas çi et ça son système va être cassé.
        
        [^] # Re: Pourquoi ?
        
        Posté par Nibel le 12 mai 2017 à 00:39. Évalué à 3. Dernière modification le 12 mai 2017 à 00:39.
        
        ah heureux de l'apprendre! (enfin pour Arch, triste que Sid t'ait fait défaut). Oui c'est logique qu'en fonction du hardware & de l'environnement on ait des cas différents.
        Cela dit je postais le truc honnêtement donc je fus surpris. Je ne sais pas si un site permettrait de faire des moyennes… bah oui c'est con mais du coup pour conseiller quelqu'un, dans le meilleur des cas on se retrouve à se fier à ses expériences & connaissances…
        
        Ouaip, l'environnement et le hardware y sont pour beaucoup. Sans doute plus l'environnement pour ma part, ayant même du Arch sur mes serveurs à la maison (oui oui, vous avez bien lu), l'un depuis 5 ans et l'autre depuis 3 ans, jamais cassé et des uptimes de plusieurs mois régulièrement (je n'ai pas d'onduleur et quand y a une coupure de courant, tout ramasse…) avec un pacman -Syu manuel par hebdomadaire, la maintenance s'arrête là.
        
        Après c'est vrai que dans la théorie, Arch devrait casser plus souvent que Sid mais mon expérience me montre que c'est l'inverse qui s'est produit dans mon cas (et j'irai même jusqu'à vous avouer que Tumbleweed a cassé une semaine après une instal' fraîche, sans jamais avoir compris pourquoi, c'est dire la logique…).
        
        Maintenant, pour conseiller l'un ou l'autre, je serai bien embêté, parce que je ne saurai pas être réellement objectif tant mon coeur bat pour Arch. Le seul véritable argument objectif et factuel que j'ai c'est sa documentation formidable, très fournie, la quasi-totalité des problèmes courants sont résolvables en sachant parcourir la doc et c'est très agréable. Mais le mieux pour se faire un avis, c'est encore d'essayer :).
        
        J'ai eu la même chose. La fois où ils avaient déplacés les binaire de /bin à /usr/bin (ou le contraire je ne sais plus).
        Mais bon pour moi c'est justement pas admissible dans une optique pc de bureau d'avoir un système en rolling release mais qui peut potentiellement être cassé par pacman -syu parce que t'as pas suivi l'actualité dans les mailings lists. Soit tu t'assures que tout se passe automatiquement, soit tu t'assures que l'outil d'upgrade ait une fonction "drapeau noir" pour avertir l'utilisateur que s'il ne fait pas çi et ça son système va être cassé.
        
        Je peux comprendre que ça puisse être rédhibitoire pour certains. Etant sous OpenBox avec un petit conky configuré aux petits onions, j'ai le flux RSS des dernières news
        affiché dans un coin de mon bureau et il me suffit d'y jeter un coup d'oeil avant d'initier mon pacman -Syu pour m'assurer que tout va bien se passer. Pour ceux qui n'ont pas envie de ça, aller une fois par semaine sur https://www.archlinux.org/ pour check ne me paraît pas insurmontable mais oui, ça demande un peu plus de temps. De manière générale, une RR demande de toute manière plus de temps en terme de maintenance qu'une distro classique, c'est le prix à payer pour profiter des dernières technologies avant tout le monde.
        
        Concernant le drapeau noir, c'est pas toujours vrai pour toutes les MAJ demandant une intervention manuelle, mais pour le déplacement de /bin vers /usr/bin, la MAJ était impossible sans suivre la procédure de la ML, on tombait sur cette erreur :
        
        erreur: la validation de la transaction a échoué (conflit de fichiers) filesystem: /bin est déjà présent dans le système de fichiers filesystem: /sbin est déjà présent dans le système de fichiers filesystem: /usr/sbin est déjà présent dans le système de fichiers Des erreurs se sont produites, aucun paquet n'a été mis à jour.
        
        Après oui, faut pas s'amuser à balancer du --force quand la MAJ veut pas passer dans ce genre de cas…
        
        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
        
        [^] # Re: Pourquoi ?
        
        Posté par Renault (site web personnel) le 12 mai 2017 à 10:08. Évalué à 6.
        
        Ouaip, l'environnement et le hardware y sont pour beaucoup. Sans doute plus l'environnement pour ma part, ayant même du Arch sur mes serveurs à la maison (oui oui, vous avez bien lu), l'un depuis 5 ans et l'autre depuis 3 ans, jamais cassé et des uptimes de plusieurs mois régulièrement (je n'ai pas d'onduleur et quand y a une coupure de courant, tout ramasse…) avec un pacman -Syu manuel par hebdomadaire, la maintenance s'arrête là.
        
        Et pour l'application des mises à jour du noyau, couches basses (glibc par exemple), tu fais comment avec un uptime de plusieurs mois ? EN terme de sécurité ce n'est pas terrible.
        
        [^] # Re: Pourquoi ?
        
        Posté par Nibel le 12 mai 2017 à 12:37. Évalué à 1.
        
        C'est effectivement pas le top en terme de sécurité mais en général je reboot tous les 3/4 mois si c'est pas le courant qui m'y oblige.
        
        Après il faut savoir que l'un est un petit serveur HTTP me permettant de mettre rapidement des solutions en ligne, vu que j'ai un upload assez merdique, c'est plus un support de transition.
        
        L'autre est un petit serveur de jeux privé et seules des personnes de confiance y ont accès, iptable est en deny all et je mets en liste blanche les personnes autorisées une par une, je pense que c'est suffisant.
        
        Après effectivement, pour des serveurs de production de plus grosse envergure et avec plus de trafic, ce serait sans doute inconscient de faire ce que je fais. Mais pour ma ridicule infrastructure, ça me semble suffisant.
        
        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
        
        [^] # Re: Pourquoi ?
        
        Posté par Renault (site web personnel) le 12 mai 2017 à 12:54. Évalué à 4.
        
        Après, est-ce que l'usage d'une distribution type CentOS ne conviendrait pas plus ? Cela limiterait les désagréments sans être chiant pour un tel usage.
        
        Sans oublier que vu l'usage de tes serveurs, je ne vois pas le soucis de faire le redémarrage de manière journalière ou après chaque mise à jour.
        
        [^] # Re: Pourquoi ?
        
        Posté par Nibel le 12 mai 2017 à 13:14. Évalué à 1.
        
        Si sans doute. De manière générale, à peu près n'importe quelle distro serait mieux que Arch pour mon usage. Mais je n'ai jamais pris le temps de le faire.
        
        Pour le serveur HTTP je pourrai effectivement le reboot régulièrement sans problème mais le serveur de jeux a toujours un peu de trafic (même si ce n'est qu'une ou deux personnes, un reboot régulier n'est jamais agréable en pleine partie, même si ce n'est qu'une fois par jour). Confort de jeu avant tout.
        
        Mais pour mes VPS, les deux sont sous Debian Stable.
        
        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
        
        [^] # Re: Pourquoi ?
        
        Posté par Anonyme le 12 mai 2017 à 12:41. Évalué à 3.
        
        C’est d’ailleurs dommage qu’en 2017, à l’heure des VM et containers partout, on trouve encore des gens pour se vanter d’avoir un uptime élevé.
      - [^] # Re: Pourquoi ?
        
        Posté par Anonyme le 12 mai 2017 à 12:35. Évalué à 3.
        
        Y a quand même pas mal de trucs pas cool sous Arch.
        
        Les trucs les plus marquants dont je me souviens :
        
        pas d’installateur ;
        
        changement de kernel in-place (« merde, ma clef USB fonctionne pas, faut que j’reboot ») ;
        
        il faut vérifier sur archlinux.org avant chaque upgrade pour être sûr qu’il n’y ait pas tout un tas de chose à faire avant (ça donne un peu l’impression que les dev n’ont rien à foutre des scripts de {pre,post}-{install,remove}) ;
        
        il y a quand même un certain nombre de paquets qui ne sont pas dans les dépôts officiels (et non, AUR n’est pas un dépôt) ;
        
        de mémoire (mais j’ai peut-être loupé la news l’annonçant) les paquets ne sont toujours pas signés ;
        
        [^] # Re: Pourquoi ?
        
        Posté par Nibel le 12 mai 2017 à 12:58. Évalué à 2. Dernière modification le 12 mai 2017 à 13:01.
        
        pas d’installateur ;
        
        Evidemment, Arch est une distribution minimaliste, elle n'a pas vocation a fournir un installateur, c'est dans sa philosophie même. On est en droit de pas aimer mais c'est personnellement aussi pour ça que j'aime Arch. Autrement, il existe toujours le projet Arch-Anywhere qui permet de configurer Arch facilement pour les débutants / ceux qui ont la flemme. Je ne l'ai jamais essayé, n'en ayant pas l'utilité mais j'ai lu beaucoup de bien dessus.
        
        changement de kernel in-place (« merde, ma clef USB fonctionne pas, faut que j’reboot ») ;
        
        C'était vrai il y a plusieurs années, maintenant seuls les modules DKMS sont déchargés, la clé USB fonctionnera toujours :)
        
        il faut vérifier sur archlinux.org avant chaque upgrade pour être sûr qu’il n’y ait pas tout un tas de chose à faire avant (ça donne un peu l’impression que les dev n’ont rien à foutre des scripts de {pre,post}-{install,remove}) ;
        
        Il faut bien savoir qu'il faut quelqu'un pour les écrire les scripts, tu peux te proposer si tu le souhaites, je suis certain que tu seras accueilli à bras ouverts, on manque de monde.
        
        il y a quand même un certain nombre de paquets qui ne sont pas dans les dépôts officiels (et non, AUR n’est pas un dépôt) ;
        
        15259 paquets dans les repos officiels de Arch.
        
        AUR est bien un dépôt (Arch User Repository ça veut bien dire ce que ça veut dire). Certes non-officiel mais s'en priver, c'est se priver d'une grosse partie de l'intérêt de Arch. C'est tout de même 43139 paquets supplémentaires.
        
        103434 paquets dans les repos officiels de Debian Sid.
        
        Avec AUR, on peut dire que globalement il y a moitié moins de paquets sous Arch que sous Debian Sid. A titre personnel je n'ai jamais manqué d'un paquet mais c'est possible que pour certaines choses plus spécifiques, ça manque. Encore une fois, les mainteneurs volontaires sont les bienvenus.
        
        de mémoire (mais j’ai peut-être loupé la news l’annonçant) les paquets ne sont toujours pas signés ;
        
        Ils sont signés depuis plusieurs années déjà, il me semble que ça date de 2012 (déjà 5 ans…) avec la sortie de pacman 4.0.
        
        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
        
        [^] # Re: Pourquoi ?
        
        Posté par barmic le 12 mai 2017 à 18:28. Évalué à 7. Dernière modification le 12 mai 2017 à 18:29.
        
        AUR est bien un dépôt (Arch User Repository ça veut bien dire ce que ça veut dire). Certes non-officiel mais s'en priver, c'est se priver d'une grosse partie de l'intérêt de Arch. C'est tout de même 43139 paquets supplémentaires.
        
        Je ne connais pas, mais j'ai souvent lu des gens expliquer qu'il ne fallait pas se plaindre d'avoir des problèmes s'ils utilisent AUR ou que les paquets sont à l'abandon.
        
        103 434 paquets dans les repos officiels de Debian Sid.
        
        Ce sont des paquets que l'on sait à jour et qui respectent toutes les règles de qualité Debian (il y a une liste de paquets en souffrance, mais justement pour les retirer si personne ne s'en occupe (pour info il y en a environ 1 100 actuellement https://www.debian.org/devel/wnpp/index.fr.html)).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Pourquoi ?
        
        Posté par Nibel le 14 mai 2017 à 13:37. Évalué à 2.
        
        Je ne connais pas, mais j'ai souvent lu des gens expliquer qu'il ne fallait pas se plaindre d'avoir des problèmes s'ils utilisent AUR ou que les paquets sont à l'abandon.
        
        Ce n'est pas tout à fait vrai. En effet, tout ce qui est sur AUR n'a pas été testé officiellement, cependant il est possible à tout un chacun de faire des alertes sur un paquet (s'il se retrouve périmé ou non-fonctionnel), d'envoyer un PKGBUILD valide ou de commenter le dit paquet. Il suffit de se rendre sur la page listant les paquets d'AUR et de choisir le paquet concerné. On peut se plaindre mais il faut le faire de manière à ce que ça puisse profiter à tout le monde.
        
        De manière générale, les paquets fonctionnent et sont régulièrement mis à jour. Les "ratés" sont assez rares et souvent corrigés rapidement (et corrigeables par soi-même si l'on se débrouille un petit peu).
        
        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
        
        [^] # Re: Pourquoi ?
        
        Posté par Nibel le 14 mai 2017 à 15:44. Évalué à 1. Dernière modification le 14 mai 2017 à 15:44.
        
        Double post à supprimer svp
        
        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
        
        [^] # Re: Pourquoi ?
        
        Posté par Okki (site web personnel, Mastodon) le 13 mai 2017 à 00:56. Évalué à 5.
        
        Sous Debian, il me semble que le nombre de paquets est complètement faussé par le fait qu'ils séparent tout (fichiers de développement, symboles de débogage, documentation…). Sous Arch, en général il n'y a qu'un paquet, qui prend peut être un peu plus d'espace disque, mais où l'on s'emmerde moins à chercher quoi installer. Je rajouterai donc ça dans les avantages :p
        
        [^] # Re: Pourquoi ?
        
        Posté par lockidor le 15 mai 2017 à 02:13. Évalué à 3.
        
        Plus les méta-paquets, plus toutes les libs de langages qui sont souvent majoritairement délégués au gestionnaire idoine dans les autres distros (python/pip, perl/cpan, haskell/cabal, ruby/gem, etc.).
# Iso de testing et sudo à l'installation

Posté par Frédéric Péters (site web personnel) le 11 mai 2017 à 12:55. Évalué à 7.

Maintenant vous allez chercher une iso de SID… Mais elle n'existe pas. En fait, il faut d'abord installer une version stable et la passer ensuite en SID. C'est plus long que compliqué.

Il y a aussi des images iso produites pour testing, ce qui permet de diminuer le delta à mettre à jour, elles se trouvent ici : http://cdimage.debian.org/cdimage/weekly-builds/ , quand c'est le cas, il y a aussi sur cette page un petit mot annonçant les problèmes connus.

Autoriser Sudo

Pour avoir sudo configuré dès l'installation, il suffit de ne pas renseigner de mot de passe pour l'utilisateur root.
# imprécisions et mauvais conseils

Posté par Adrien le 11 mai 2017 à 14:52. Évalué à 4.

Perso je ne suis pas d'accord avec le point de vue : SID est une version faite pour casser, la recommander pour un desktop n'est pas forcément génial, sauf si on peut se permettre de casser (et donc réparer) son PC assez souvent. Typiquement lorsque la nouvelle version stable sera sortie, on pourra en rediscuter ;)
Ensuite testing ne suis pas le développement de la version stable mais bien celle de sid. En effet, un paquet passe automatiquement de sid vers testing au bout de quelques jours (15 il me semble, à vérifier) s'il n'y a pas de bug bloquant. Tous les 2 ans testing est gelée, les bugs principaux corrigés, et ça fournit la nouvelle version stable.
Certes, tous les 2 ans le freeze fera que pendant 6 mois il n'y aura plus de mises à jour… mais rien n'empêche de mettre ponctuellement un paquet à jour depuis sid ou experimental !

La distribution testing est donc SID avec 15 jours de retard et surtout sans les bugs critiques. Elle me semble tout à fait adaptée à une utilisation de bureau, pour un utilisateur qui n'a pas beaucoup de temps à consacrer à la maintenance de son PC. D'autant que désormais la sécurité est désormais gérée pour testing.

Autre choix : utiliser la version stable avec les dépôts backports, qui permettent d'avoir des logiciels plus à jour : libreoffice 5.2.6, linux-image-4.9 par exemple.
- [^] # Re: imprécisions et mauvais conseils
  
  Posté par eingousef le 11 mai 2017 à 15:28. Évalué à 3.
  
  Certes, tous les 2 ans le freeze fera que pendant 6 mois il n'y aura plus de mises à jour… mais rien n'empêche de mettre ponctuellement un paquet à jour depuis sid ou experimental !
  
  Ça en ce qui me concerne ça dépend des paquets. J'ai aucun problème à prendre un paquet "utilisateur final" dans unstable ou experimental, comme mutt, isync, iceweasel, kakoune, et la plupart des jeux, autant j'évite de piocher dans unstable et experimental pour des trucs plus critiques comme mesa, Xorg, linux-image, acpi, openrc, et la plupart des libs. Je préfère avoir des libs obsolètes pendant 6 mois tous les deux ans que de prendre le risque d'en avoir une qui me pète tous les logiciels qui en dépendent.
  
  Autre choix : utiliser la version stable avec les dépôts backports, qui permettent d'avoir des logiciels plus à jour : libreoffice 5.2.6, linux-image-4.9 par exemple.
  
  C'est quoi le pourcentage des logiciels de testing/stable présent dans backports ? Parce que si on veut que stable soit utilisable sur un desktop il faudrait rétroporter pratiquement toute la section games/ ainsi que la plupart des logiciels de communication (messagerie instantanée, vidéostreaming, etc.).
  
  *splash!*
  - [^] # Re: imprécisions et mauvais conseils
    
    Posté par Adrien le 11 mai 2017 à 15:35. Évalué à 3.
    
    C'est quoi le pourcentage des logiciels de testing/stable présent dans backports ?
    
    Difficile à dire, ça dépend beaucoup des packageurs. Certains backportent volontier les nouvelles version, d'autres non. Hormis les jeux que je ne connais pas trop, je dirais que souvent les paquets importants sont backportés, par ex. lorsqu'une nouvelle version apporte des changements significatifs et qu'il y a une forte demande utilisateur
- [^] # Re: imprécisions et mauvais conseils
  
  Posté par kna le 11 mai 2017 à 17:07. Évalué à 3.
  
  La distribution testing est donc SID avec 15 jours de retard et surtout sans les bugs critiques. Elle me semble tout à fait adaptée à une utilisation de bureau
  
  Le problème avec testing, c'est que si c'est toi qui remonte le bug, il sera d'abord corrigé dans sid, et il te faudra attendre 15 jours pour que la correction descende dans testing.
  - [^] # Re: imprécisions et mauvais conseils
    
    Posté par kantien le 11 mai 2017 à 17:23. Évalué à 4.
    
    D'où le pinning en ayant les dépôts de Sid dans le sources.list, avec priorité pour Testing, et on vise explicitement Sid avec l'option -t sid pour le paquet en question dès qu'il est dispo : pas besoin d'attendre qu'il arrive dans testing.
    
    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
  - [^] # Re: imprécisions et mauvais conseils
    
    Posté par Adrien le 12 mai 2017 à 09:59. Évalué à 3.
    
    Il me semble que suivant que le passage sid -> testing peut-être plus rapide suivant le degré de criticité du bug.
    
    Mais il ne me semble pas déraisonnable de devoir attendre 15 jours, histoire de voir si la correction ne casse pas tout. Pour les utilisateurs expérimentés, il est toujours possible d'installer un paquet de sid :
    
    apt install -t sid MON_BEAU_PAQUET
# SID

Posté par H2L29 (site web personnel) le 11 mai 2017 à 16:57. Évalué à 5.
- [^] # Re: SID
  
  Posté par H2L29 (site web personnel) le 12 mai 2017 à 18:20. Évalué à 1.
  
  http://ftp.fr.debian.org/debian/dists/README
  This directory, dists, is the canonical way to access the distributions.
  Each distribution can be accessed by name or state from here.
  
  oldstable, or wheezy - the released Debian 7.11
  stable, or jessie - the released Debian 8.8
  oldoldstable-proposed-updates - possible updates to Debian 6.0
  oldstable-proposed-updates - possible updates to Debian 7
  stable-proposed-updates - possible updates to Debian 8
  squeeze-updates - important updates to Debian 6.0
  wheezy-updates - important updates to Debian 7
  jessie-updates - important updates to Debian 8
  testing, or stretch - the development version of the next release
  unstable, or sid - untested candidate packages for future releases
  experimental, or rc-buggy - experimental packages to be used on top of unstable
  
  ça fait un peu plus que 4 :)
  - [^] # Re: SID
    
    Posté par Marotte ⛧ le 12 mai 2017 à 20:01. Évalué à 5.
    
    Experimental n’est pas une version de Debian. Les dépôts pour les "proposed-updates" sont liés à la version correspondante (il y a ausi les dépôts backports). Comme experimental, ces dépôts seuls ne permettent pas d’utiliser Debian.
    
    Cela dit, effectivement, oldstable peut être considérée comme une version de Debian.
    
    Donc, en tout, quatre. Le compte est bon ;)
# Version

Posté par Marotte ⛧ le 11 mai 2017 à 19:03. Évalué à 4.

Il y a 4 versions de Debian :
Stable - Testing - Unstable (Sid) - Experimental

Attention, "experimental" n’est pas une version à proprement parler. Certains packages vont directement dans Sid et d’autres ne quittent jamais "experimental"…

https://wiki.debian.org/fr/DebianExperimental
# Canonical bashing

Posté par saltimbanque (site web personnel) le 11 mai 2017 à 22:34. Évalué à 3.
bon maintenant qu'il y a eu des commentaires intéressant & constructifs on peut commencer
- quels désastres technologiques canonical a t'il produit pour te chasser?
  son abandon de mir? ou de tant d'autres choses?
  ou juste les upgrade semestriels comme tu le cite? mais dans ce cas sont ils si mauvais? car après tout une dist-upgrade
  ça peut être 3 min de taf
- es tu un parmi une foule innombrable d'utilisateurs ubuntu qui vont quiter ce navire pitoyable en train de couler dans le cloud?
  [ j'en fais pas trop là j'espère ]
- [^] # Re: Canonical bashing
  
  Posté par Cyprien (site web personnel) le 12 mai 2017 à 16:39. Évalué à 2.
  
  Non, ce ne sont pas les dernières nouvelles sur Canonical qui m'ont chassés puisque j'étais parti avant :)
  Les mises à jours tous les 6 mois en ont été la raison principale.
  Je ne critique pas Ubuntu, qui m'ont vraiment facilité les choses.
# Linux Mint Debian Edition (LMDE)?

Posté par pizaninja le 11 mai 2017 à 23:37. Évalué à 3.

Sauf erreur de ma part, LMDE est basé sur Debian testing. C'est un très bon moyen d'avoir un environnement convivial prêt à l'emploi (iso basés sur desktop Mate ou Cinnamon) ET une Debian.

J'ai toujours eu du mal avec Ubuntu/Canonical pour des raisons d'ordre "philosophique". Ce que j'en retiens : Ça ressemble à une distribution au dessus de Debian qui n'apporte aucune valeur ajoutée, si ce n'est un "enfermement" vers leur produit maison. Ceci dit, ce n'est que mon point de vue, je ne cherche pas à convaincre sur ce point.

Donc, retour d'XP: ça fait 4 ou 5 ans que j'utilise LMDE, et j'en suis toujours autant satisfait.
- [^] # Re: Linux Mint Debian Edition (LMDE)?
  
  Posté par xcomcmdr le 12 mai 2017 à 10:17. Évalué à 8.
  
  J'ai toujours eu du mal avec Ubuntu/Canonical pour des raisons d'ordre "philosophique". Ce que j'en retiens : Ça ressemble à une distribution au dessus de Debian qui n'apporte aucune valeur ajoutée, si ce n'est un "enfermement" vers leur produit maison
  
  Perso je connais vraiment Ubuntu et non pas uniquement les rumeurs des haters autour, et ça apporte (ou a apporté) :
  - Un installeur bien plus conviviale
  - Des pilotes propriétaires (souvent et pendant longtemps le seul moyen de faire fonctionner un matériel) installées en un click
  - Une intégration de thèmes graphiques, polices de caractères, outils tierces, etc… dans un tout cohérent (installez et c'est prêt !)
  - Une documentation, notamment française, très bien fournie
  - Des forums où l'entraide est de mise et massivement utilisés
  - Des facilités d'ajouts de logiciels plus récents et dépôts tierces via les PPA.
  - J'en oublie.
  
  Faut pas oublier que ceux qui ont formé Ubuntu étaient d'anciens développeurs Debian, et savaient très bien ce qu'il y avait à améliorer.
  
  Aussi, tout ça c'est du logiciel libre, donc l'enfermement il est uniquement dans la tête.
  
  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: Linux Mint Debian Edition (LMDE)?
    
    Posté par pizaninja le 13 mai 2017 à 08:37. Évalué à -5. Dernière modification le 13 mai 2017 à 08:39.
    donc l'enfermement il est uniquement dans la tête.
    
    C'est possible.
    Note juste que certains de tes arguments sont justement ce qui fait que je n'aime pas Ubuntu
    Un installeur bien plus conviviale
    Ok. C'est pour ça que j'apprecie LMDE
    Des pilotes propriétaires (souvent et pendant longtemps le seul moyen de faire fonctionner un matériel) installées en un click
    C'est pas possible sous Debian ???
    Par ailleurs, ça n'aide pas à inciter les développement libre de drivers…
    Une intégration de thèmes graphiques, polices de caractères, outils tierces, etc… dans un tout cohérent (installez et c'est prêt !)
    LMDE ?
    Une documentation, notamment française, très bien fournie
    Je préfère l'anglais natif. Ça m'évite d'avoir à mixer français et anglais car si t'attends que le monde autour de toi soit en français, tu t'isoles.
    Des forums où l'entraide est de mise et massivement utilisés
    Quand je vois le niveau technique de certains contributeurs, je suis dépité. Ça se résoud souvent à des clic-clics souris à la windaube sans finalement savoir ce qu'il se passe derrière. Ce qui fait que ça aide les users Ubuntu, mais pas les autres users Linux (Debian compris).
    Des facilités d'ajouts de logiciels plus récents et dépôts tierces via les PPA.
    Oui, ça rend le packaging incohérent et limité à Ubuntu. Tant pis pour Debian.
    
    Donc je comprends tes arguments, mais nous n'apprécions pas les mêmes goûts et couleurs. 😉
- [^] # Re: Linux Mint Debian Edition (LMDE)?
  
  Posté par Yakulu le 12 mai 2017 à 11:32. Évalué à 5.
  
  Sauf erreur de ma part, LMDE est basé sur Debian testing.
  
  Elle l'était mais depuis la LMDE2, c'est une base Debian Stable Jessie.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.