Debian 9 : Stretch déploie ses tentacules

102
18
juin
2017
Debian

Debian GNU/Linux 9, nom de code Stretch (en référence à la pieuvre violette de Toy Story 3) est sortie le 17 juin 2017.

Stretch, la pieuvre mauve (par Emoji One via Wikipédia)

Alors que la version 8 intégrait systemd, cette version intègre pour sa part quelques autres nouveautés technologiques de taille comme Wayland (cela concernera surtout les utilisateurs du bureau GNOME), Flatpak ou encore le pilote noyau unifié AMDGPU pour les puces graphiques AMD les plus récentes…

Les choses sont également plus claires maintenant que Firefox et Thunderbird sont présents dans les dépôts sous leurs noms officiels, grâce notamment aux efforts de Sylvestre Ledru (compte Twitter). So long Iceweasel et Icedove !

Sommaire

Considérations générales

Stretch est disponible sur dix architectures matérielles différentes : AMD64, ARM64, ARMel, ARMhf, i386, MIPS, MIPS64el, MIPSel, PowerPC64el et s390x.

Elle repose sur le compilateur GCC 6 exclusivement (voir l’annonce sur la liste de diffusion). LLVM/Clang/LLDB est proposé par défaut en version 3.8 (et embarque aussi la version 3.9).

Il est à noter que la version pour i386 nécessite un processeur prenant en charge l’option de compilation i686, et que Stretch ne sera pas disponible sur PowerPC.

Des statistiques sur le nombre de paquets (environ 54 000 paquets produits à partir de 25 000 paquets source), de fichiers source, leur taille, le nombre de lignes de code et la répartition par langage de programmation sont disponibles (parmi plein d’autres statistiques du projet Debian), ainsi que la production reproductible de paquets (94 % des paquets pour stretch/amd64).

L’installation peut se faire en 75 langues (et le site Debian est disponible en 37 langues).

Cette version est dédiée à Ian Murdock, le fondateur du projet Debian, mort en décembre 2015.

Installateur

En grande partie grâce au travail de Cyril Brulebois (comptes Twitter et Mastodon, #DebianInstaller), l’installateur a été revu :

Nouveautés logicielles

Nouvelles versions de logiciels :

Nouveauté de taille : Flatpak débarque, en version 0.8 : à vous les applications dans leur dernière version sans risque d’altérer la stabilité de votre Debian Stable ! Autrement dit : vous n’aurez plus à choisir entre nouveauté et stabilité.

Parmi les nouveautés en termes de logiciel, Stretch embarque notamment :

  • la première version du « Debian Pure Blend » Astro (une solution pour des groupes aux besoins particuliers, ici l’astronomie). Il rejoint ceux sur la chimie, les jeux, l’éducation, les SIG, pour les enfants, le médical, le multimédia ou la science) ;
  • le logiciel de mathématiques Sagemath de sagemath.org ;
  • la forge logicielle GitLab ;
  • la possibilité d’installer les paquets MELPA (Emacs Lisp) par apt (comme Flycheck, Projectile, Evil et Helm) ;
  • la pile LIO SCSI, avec les modules FC, FCoE, iSCSI, iSER, tcm_loop, etc.

Côté serveur :

  • MariaDB 10.1 devient la version par défaut de MySQL (il s’agissait précédemment d’Oracle MySQL) et des méta‐paquets ont été ajoutés pour faciliter les changements futurs ;
  • nginx 1.6 → 1.10 ;
  • OpenJDK 1.7 → 1.8 ;
  • OpenSSH 6.7 → 7.4 (les vieux algorithmes de chiffrement et le protocole SSH 1 sont maintenant désactivés par défaut dans OpenSSH) ;
  • PHP passe de la version 5.6 à la version 7.0 et l’empaquetage a été retravaillé pour faciliter l’installation de multiples versions en parallèle ;
  • OpenSSL (1.0.1t → 1.1.0e) (les chiffrements 3DES et RC4 ne sont plus disponibles, ce qui casse de vieux outils, tels que la prise en charge de TLS sous Windows XP) ;
  • Perl (5.20.2 → 5.24.1) (certains modules retirés du cœur sont livrés via des paquets séparés).

Pour les nouvelles installations, une nouvelle méthode de nommage des interfaces réseau sera utilisée (du type ens0 ou enp1s1 (Ethernet) ou wlp3s0 (sans fil) au lieu de eth0 ou eth1).

Retrait de logiciels :

  • OwnCloud, jugé trop difficile à maintenir ;
  • VirtualBox, du fait qu’Oracle refuse de partager les vulnérabilités à travers le CVE, cela rend difficile la gestion de la sécurité des paquets dans la branche stable ;
  • les interfaces réseau ne sont plus nommées de la même manière. Pour les nouvelles installations, les informations matérielles et l’adresse MAC sont utilisées pour le nommage et la numérotation ; les installations existantes ne sont pas touchées ;
  • le paquet net-tools est déclaré obsolète au profit de iproute2 (apt install net-tools pour récupérer ifconfig et ses copains) ;
  • le montage de /usr doit se faire au niveau de l’initramfs. Pas de souci avec les noyaux fournis par Debian ;
  • /bin et /sbin fusionnés dans /usr/bin et /usr/sbin à l’installation du paquet usrmerge (par défaut lors de l’installation). ça a été repoussé.

Améliorations d’apt :

  • téléchargement via utilisateur apt (ce n’est plus root) ;
  • information intéressante pour les administrateurs de miroirs : l’apt de Stretch peut utiliser des enregistrements DNS (SRV) pour localiser une ressource HTTP (back‐end) ;
  • nouveau miroir au nom « ultra simple à retenir » : deb.debian.org ;
  • interface en ligne de commande stabilisée (plus d’avertissement lors d’un tube — pipe —, par exemple) ;
  • disparition des serveurs FTP pour les paquets.

Nouveaux paquets de débogage :

Les paquets contenant les symboles de débogages étaient auparavant de la forme paquet-dbg, ceux‐ci se nomment maintenant paquet-dbgsym, sont générés automatiquement et se trouvent dans un nouveau dépôt et non plus dans le dépôt principal. Ces modifications permettront aux dépôts miroirs de ne plus avoir à récupérer ces paquets qui étaient utilisés par peu de gens, permettant ainsi d’économiser bande passante et espace disque.

Stretch avait été légèrement retardé pour faire place au noyau Linux 4.10 : en effet, ce noyau devait être une version à support étendu (long‐term support ou LTS), version que les développeurs en amont (upstream) s’engagent à maintenir plus longtemps. Ceci facilite en retour le travail de l’équipe noyau de Debian, lire ce journal pour plus d’explications. La version finalement choisie par le responsable des LTS Greg Kroah‐Hartman est la 4.9, l’équipe noyau de Debian l’a donc aussi choisie pour être le noyau de Stretch.

Debian 9

Debian 9

Après un vote public (ouvert à tous), c’est le thème graphique nommé softWaves qui a été choisi pour Stretch. Il a été réalisé par Juliette Taka‐Belin, créatrice du thème de la version précédente de Debian.

Futur

La version testing se nomme désormais Buster (le chien dans les films d’animation Toy Story).

  • # Mise à jour d'URL

    Posté par (page perso) . Évalué à 3 (+3/-1).

    Merci à tous pour l'article. Une petite édition serait la bienvenue, mon compte Twitter est (du moins pour l'instant) celui où toutes les infos relatives à l'installateur sont publiées : cf. @CyrilBrulebois & #DebianInstaller.

    Debian Consultant @ DEBAMAX

  • # KDE 5.8 !

    Posté par . Évalué à 5 (+4/-0).

    Sacré bond en avant ! Ça fait plaisir de voir Plasma dans Debian, qui sait Debian pourrait potentiellement remplacer ma Kubuntu ?

    • [^] # LXQt aussi !

      Posté par . Évalué à 3 (+3/-0).

      En plus de KDE 5, on a enfin LXQt pour du desktop sur des machines nomades. :)

  • # Ouais...

    Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 18/06/17 à 18:38.

    …land !!!

    Et ça c'est cool :)

    À part ça, si quelqu'un a une astuce sous GNOME Wayland pour que le pavé numérique reste activé au démarrage, je suis preneur. C'est censé être réglé upstream, mais ça ne l'est pas dans mes Debian…

    • [^] # Re: Ouais...

      Posté par (page perso) . Évalué à 3 (+3/-2).

      C'est vraiment une mauvaise idée d'utiliser wayland pour l'instant, encore plus avec Gnome 3.22.

      Le support est loin d'être complet et certaines fonctions de base de GTK ne sont pas implémentées: gtk_window_present() par exemple.

      • [^] # Re: Ouais...

        Posté par (page perso) . Évalué à 5 (+5/-2).

        C'est vraiment une mauvaise idée d'utiliser wayland pour l'instant

        Je ne suis pas de ton avis.
        Même s'il manque des choses, j'utilise Wayland depuis un an au quotidien sous GNOME sans avoir de soucis particuliers.

        • [^] # Re: Ouais...

          Posté par (page perso) . Évalué à 7 (+5/-0).

          Si pour toi une fonctionnalité de base à savoir afficher une fenêtre à l'écran n'est pas un problème… Clic sur une notification de geary ou autre, sous Wayland, il ne se passe rien, sous Xorg, la fenêtre devient la fenêtre active.

          • [^] # Re: Ouais...

            Posté par (page perso) . Évalué à 5 (+7/-4).

            La fonctionnalité que tu cites ne sert pas à tout le monde (typiquement, je clique rarement sur les notifications, je la lis et c'est tout).

            De plus cela reste une fonctionnalité de confort, elle n'est pas indispensable à un usage du bureau. GNOME reste utilisable dans ces conditions.

            À chacun de mettre le curseur suivant ses besoins et attentes, il y a des personnes qui ne peuvent pas utiliser Wayland encore (notamment ceux qui ont besoin d'outils d'accessibilité) mais de là à dire qu'il faut le déconseiller à tout le monde me semble aberrant. Comme je le dis, je l'utilise sans soucis depuis longtemps, et je ne suis pas le seul.

            Et il est bien que plein de gens testent Wayland par ailleurs, pour avoir des retours et l'améliorer plus vite.

            • [^] # Re: Ouais...

              Posté par . Évalué à 4 (+2/-0).

              De plus cela reste une fonctionnalité de confort

              Heu, non ?
              C'est le comportement de base sur tout les autres OS desktop/mobile …
              Cela n’empêche peut-être pas d'utiliser Wayland, mais ça reste une regression forte à mes yeux.

              • [^] # Re: Ouais...

                Posté par (page perso) . Évalué à 3 (+2/-1).

                Cela n’empêche peut-être pas d'utiliser Wayland, mais ça reste une regression forte à mes yeux.

                C'est bien ce que je dis, ce n'est pas avec cette seule régression que tu déconseille tout le monde d'utiliser Wayland.
                Je n'ai pas dis que ce n'était pas gênant, voire pénible pour certains, juste que de déconseiller Wayland sur cette seule régression était exagéré.

      • [^] # Re: Ouais...

        Posté par . Évalué à 3 (+2/-0).

        Ça marche très bien depuis plus d'un an.

      • [^] # Re: Ouais...

        Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 19/06/17 à 12:10.

        Ça marche très bien chez mon père en stable et chez moi en Unstable, si ce n'est la mémorisation de l'état du pavé numérique.
        Bon, nos besoins sont simples : un seul écran, pas de tablette wacom etc.

  • # libreoffice avec wayland ?

    Posté par . Évalué à 2 (+0/-0).

    LibreOffice 4.3 → 5.2 (parmi les nouveautés, citons le port vers GTK3 et Wayland) ;

    Jamais entendu parlé d'une prise en charge native de Libreoffice avec Wayland. Vous êtes surs?

  • # Vivement la suivante

    Posté par (page perso) . Évalué à -10 (+7/-35).

    Vivement debian 10, dans 2-3 ans, qu’on puisse enfin publier des logiciels écrits en C++17 ou en Python 3.6.

    C’est toujours un plaisir d’être coincé dans le passé à cause de cette distro.

    • [^] # Re: Vivement la suivante

      Posté par (page perso) . Évalué à 10 (+13/-0).

      Ben, be l'utilise pas…

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Vivement la suivante

        Posté par (page perso) . Évalué à 3 (+6/-4).

        Je l’utilise pas. Je veux juste que les gens qui veulent utiliser mes logiciels puissent les utiliser.

        Donc je dois me conformer à ce que les gens utilisent, malheureusement. Et le plus petit dénominateur c’est Debian stable.

        • [^] # Re: Vivement la suivante

          Posté par . Évalué à 9 (+7/-1).

          Et le plus petit dénominateur c’est Debian stable.

          Il y a des RHEL toujours maintenues largement plus vielle.

          Mais C++17 à changer d'ABI ? Je pensais que ces langages sans runtime avait justement pas ce genre de problème (modulo la disponibilité des bibliothèques dynamiques que tu utilise).

          Après on le dit à chaque fois Debian Stable est fait pour les serveurs. C'est prévu pour être véritablement stable au détriment des mises à jour (hors sécurité). Un serveur est géré par admin qui lui saura sans difficulté installer une application dans un environnement précis.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Vivement la suivante

            Posté par . Évalué à 4 (+3/-0).

            Je suppose qu’il utilise des fonctionnalités de la bibliothèque standard C++17 qui ne sont donc pas disponibles (le standard C++17 n’est même pas finalisé…). Il pourrait cela dit compiler son application en liant la libstdc++ en statique (-static-libstdc++ si mes souvenirs sont bons) si c’est juste ça le soucis, et ça marcherait vraisemblablement.

            Cela dit : les gens qui veulent une version « stable » ne veulent probablement pas d’une application compilée avec un support expérimental (il y a une grosse contradiction là-dessus).

            Sinon, si, l’ABI change grosso merdo à chaque release majeure de GCC (donc entre la 4 et la 5, la 5 et la 6, etc.). C’est cela dit surtout au niveau de la libstdc++ que cela joue, pas du langage lui-même.

            Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

            • [^] # Re: Vivement la suivante

              Posté par (page perso) . Évalué à 2 (+4/-3).

              Non, le but c’est que ça puisse etre compilé sous debian, pas de fournir un binaire qui pourrait se lancer sous debian.

              Cela dit : les gens qui veulent une version « stable » ne veulent probablement pas d’une application compilée avec un support expérimental (il y a une grosse contradiction là-dessus).

              Je pense qu’il y a des gens qui veulent un OS stable (dans le sens « j’ai plus besoin d’y toucher quand je mets à jour, rien ne va casser/bouger, je suis tranquille »), tout en ayant la possibilité d’installer quelques rares logiciels « à jour » manuellement. Sinon le repository « backport » n’existerait pas.

              le standard C++17 n’est même pas finalisé…

              En effet. Et je n’ai pas dit « je veux release mon truc aujourd’hui », mais « j’aurais bien aimé avoir la possibilité de release un truc utilisant C++17 avant 2-3 ans ». D’ici là C++17 sera bien finalisé.

              • [^] # Re: Vivement la suivante

                Posté par (page perso) . Évalué à 9 (+10/-3).

                En effet. Et je n’ai pas dit « je veux release mon truc aujourd’hui », mais « j’aurais bien aimé avoir la possibilité de release un truc utilisant C++17 avant 2-3 ans ». D’ici là C++17 sera bien finalisé.

                Es-tu conscient que ce que tu dis, si on le reformule de manière plus directe, c'est "je veux qu le truc qui sort maintenant supporte un truc qui n'a pas encore été défini"?
                IPoT?

                Personne n'est capable de faire ça, sauf à parier sur l'idée que C++17 beta sera le même que C++ release, ce qui est dans tous les cas dangereux.

                Si tu as besoin d'une truc "hype", tu ne peux compiler par défaut que sur du "hype", normal.
                Mais rien ne t’empêche de :
                - Compiler sur ta machine hype et livrer les .deb pour les non hypes
                - Arrêter de te la péter "j'ai absolument besoin de C++17", et faire du C++ compatible avec le non hype.

                Pour l’anecdote, je maintien un fork d'un projet que je compile pour des vieux macOS que certains utilisent encore, et mes patchs pour faire du C++03 (à la place de C++11, non supporté par les libs par défaut et embarquer en statique est assez galère sous macOS ou je n'ai pas trouvé) ont été refusé, alors que ça change rien (c'est de la typo, et parfois même les conversions auto ralentissent plus qu'autre chose, rien de "killer-feature"), et l'argument est juste "non mais C++11 c'est assez vieux arrête de me faire chier nous on est hype".
                Alors, perso je trollerai en te demandant en quoi ton super-logiciel a absolument besoin de C++17 qui va "enlarge your productivity".

                • [^] # Re: Vivement la suivante

                  Posté par (page perso) . Évalué à -2 (+3/-6).

                  Es-tu conscient que ce que tu dis, si on le reformule de manière plus directe, c'est "je veux qu le truc qui sort maintenant supporte un truc qui n'a pas encore été défini"?
                  IPoT?
                  Personne n'est capable de faire ça, sauf à parier sur l'idée que C++17 beta sera le même que C++ release, ce qui est dans tous les cas dangereux.

                  Le problème c’est pas que ça soit pas disponible maintenant. C’est que les versions de debian sortent tous les 1000 ans, du coup on reste sur ces versions pendant 1000 ans. cf mon autre réponse où je parle de fedora, etc.

                  C’est aussi une question de malchance. Si le freeze avait eu lieu, disons, 8 ou 9 mois plus tard, et bien peut-etre que gcc 7 aurait été dedans, et donc on aurait pu l’avoir à disposition 2 ou 3 ans plus tot.

                  • Arrêter de te la péter "j'ai absolument besoin de C++17", et faire du C++ compatible avec le non hype.

                  lol ;)

                  C’est juste qu’on n’a pas la meme notions de ce qui est « à jour » ou non. Je suppose que tu ne voudrais pas coder en C++98 avec un gcc qui a 20 ans (enfin, peut-etre que si, mais c’est juste pour la démo), parce que c’est vieux et qu’il te manque des trucs. Ben moi pareil, sauf que c’est pas au bout de 20 ans que ça me gène, c’est au bout de 2. Alors oui, techniquement je peux toujours coder avec des hyper vieux langages qui existaient avant que je sois né, mais bof.

                  Alors, perso je trollerai en te demandant en quoi ton super-logiciel a absolument besoin de C++17 qui va "enlarge your productivity".

                  Ils n’en ont pas besoin. Ils n’ont même pas besoin d’être en C++ tout court. Ils n’ont même pas besoin d’exister. C’est juste que je préfère. Parce que ça me passionne, m’intéresse et me fait plaisir.

                  (t’arrives quand même à deviner des intentions un peu comme tu veux, dans les messages des autres. « Te la péter », « ton super-logiciel »)

                  • [^] # Re: Vivement la suivante

                    Posté par . Évalué à 2 (+1/-1).

                    Saut que au final tu es de très mauvaise foi car on parle de 2ans entre chaque release debian et pas 1000ans.

                    • [^] # Re: Vivement la suivante

                      Posté par (page perso) . Évalué à 2 (+4/-3).

                      https://en.wikipedia.org/wiki/Hyperbole

                      J’ai supposé qu’en mettant un nombre irréaliste (ici 1000 ans), ça semblerait évident que c’est pas vraiment le nombre d’années entre deux release debian, et que c’était juste une éxagération pour dire « super longtemps ».

                      Mais désolé, tu as raison, ouais, c’est SEULEMENT 2 ans. Ouf.

                      • [^] # Re: Vivement la suivante

                        Posté par . Évalué à 5 (+3/-0). Dernière modification le 20/06/17 à 12:01.

                        Mais 2 ans c'est pas énorme au final.

                        J'ajouterai que ton problème n'a rien de spécifique à debian et s'efforcer à toujours utiliser ce qui est le plus bleeding edge possible, c'est un peu une forme d'asociabilité. Tu fermes la porte à la plupart des gens qui utilisent du BSD, et même la plupart des distros.

                        Si on check le nombre de distros packageant gcc > 7 dans leur dernière release on se rend compte qu'il n'y a pas beaucoup de candidates et encore moins de distributions "majeures": en gros Fedora, Arch et Gentoo. C'est peu.

                  • [^] # Re: Vivement la suivante

                    Posté par . Évalué à 4 (+4/-2).

                    C’est juste que je préfère. Parce que ça me passionne, m’intéresse et me fait plaisir.

                    Ben te plains pas alors

                    splash!

                  • [^] # Re: Vivement la suivante

                    Posté par (page perso) . Évalué à 8 (+9/-3). Dernière modification le 20/06/17 à 14:40.

                    Je suppose que tu ne voudrais pas coder en C++98 avec un gcc qui a 20 ans

                    Tu es dans la mauvaise foi la plus complète, alors soyons clair, tu as 2 options :
                    - Tu as rien à foutre des autres, dans ce cas tu as rien à foutre que Debian a GCC 1000 ou 1001,
                    - Les autres t’intéresse, tu dois gérer l'historique, qui en gros est de 5-7 ans (ce qui n'est pas énorme au passage) suivant les pas de chance, avec du CentOS, du Mac, du Ubuntu en plus de Debian. Debian n'est pas le pire en fait, c'est le cadet de tes soucis (perso j'avais toujours des utilisateurs en Ubuntu 12.04 jusqu'au mois dernier). Et tu as le choix, entre filer les binaires que tu as compilé toi-même sur du moderne avec un backport possible sur veille distro ou utiliser du C++ de plus de 5 ans (ce qui n'est pas bien méchant) pour que tout le monde puisse compiler sans se prendre la tête

                    Dans les 2 cas, il n'y a aucune raison à ta complainte sur Debian, qui est la que pour te complaire.

                    (t’arrives quand même à deviner des intentions un peu comme tu veux, dans les messages des autres. « Te la péter », « ton super-logiciel »)

                    Disons qu'avec des arguments type "C’est juste que je préfère", c'est la seule conclusion qu'on peut avoir, c'est tout. Niveau d'argumentation sur ton besoin que les autres devrait assouvir : 0.

                    • [^] # Re: Vivement la suivante

                      Posté par (page perso) . Évalué à 1 (+0/-0).

                      • Les autres t’intéresse, tu dois gérer l'historique, qui en gros est de 5-7 ans (ce qui n'est pas énorme au passage)

                      Les autres m’intéressent, mais 5-7 ans c’est énorme pour moi.

              • [^] # Re: Vivement la suivante

                Posté par . Évalué à 7 (+6/-0).

                Je pense qu’il y a des gens qui veulent un OS stable (dans le sens « j’ai plus besoin d’y toucher quand je mets à jour, rien ne va casser/bouger, je suis tranquille »), tout en ayant la possibilité d’installer quelques rares logiciels « à jour » manuellement. Sinon le repository « backport » n’existerait pas.

                En effet. Et rien ne t’interdit d’installer gcc 7 sur ta debian. Mais je comprends que les mainteneurs ne fassent pas d’effort en ce sens : ce n’est pas ce que fait le public visé, ce n’est pas ce que souhaitent la plupart des utilisateurs.

                Si ton logiciel devient :
                - important d’être mis à jour régulièrement, aussi bien en terme de technos que de sécurité
                - indispensable au quotidien des utilisateurs
                - avec une bonne réputation de qualité sur les mises à jour, notamment en terme de non-régression

                Alors tu pourras discuter avec les mainteneurs debian pour une exception. Le seul logiciel que je connais dans ce cas est firefox (pour les définitions d’anti-virus et similaires, pour qui c’est aussi le cas, il y a un canal dédié). Pour les autres, il y a les backports si ton logiciel peut supporter d’être compilé sur un environnement d’il y a x ans où x < 3. S’il ne peut pas, il te reste d’autres canaux de distribution (par exemple : fournir un .deb sur ton propre repository).

                Il y a je pense suffisamment de solutions alternatives pour que tes critiques sur le choix de stabilité fait par debian ne soient guère entendues.

                Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: Vivement la suivante

          Posté par (page perso) . Évalué à 4 (+2/-0).

          Je l’utilise pas. Je veux juste que les gens qui veulent utiliser mes logiciels puissent les utiliser.

          Ça dépend du contexte dans lequel tu développes tes logiciels, mais tu pourrais peut-être adopter une approche comme font la plupart des modules GNOME:
          - sortir une nouvelle version à intervalle régulière.
          - ne pas hésiter à utiliser les dernières technologies et versions des bibliothèques, sans garder la compatibilité avec les anciennes versions (donc pas de #if/#else suivant la version d'une bibliothèque, par exemple).
          - pour une certaine version d'une certaine distrib, prendre la dernière version du logiciel qui est compatible.

          Donc ceux qui sont en Debian stable pourraient installer la version N-1 ou N-2 de tes logiciels. Tout comme Debian stable a actuellement GNOME 3.22 alors que GNOME 3.24 est déjà sorti en amont.

          « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

          • [^] # Re: Vivement la suivante

            Posté par (page perso) . Évalué à 2 (+4/-3).

            Ouais, mais bof, après tu te retrouves avec des bugs du type:

            • Tel machin ne fonctionne pas…
            • Euh, chez moi ça marche, t’utilises quelle version ?
            • Euh, la dernière. Attends, je regarde. C’est la version 0.0.0.0.4, sur debian stable.
            • Ah, ouais, c’est sorti y’a 3 ans et demie, y’a eu 16 versions depuis, et backporter tous les bugfixes dans toutes les anciennes versions c’est trop de boulot.

            Je m’imagine très bien tomber dans une telle situation : https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/

            • [^] # Re: Vivement la suivante

              Posté par (page perso) . Évalué à 10 (+7/-0).

              Donc tu veux fournir à des utilisateurs qui privilégie une distrib avec des paquets stables (sinon ils n'utilisent pas Debian stable) un truc qui bouge tout le temps et dépend de la dernière version des bibliothèque. J'ai l'impression que tu as un problème de cible.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Vivement la suivante

                Posté par (page perso) . Évalué à -8 (+3/-12). Dernière modification le 19/06/17 à 19:56.

                Ça dépend si une release tous les ans c’est « qui bouge tout le temps » pour toi, alors ouais.

                Et c’est surtout que j’ai eu des utilisateurs debian qui sont venus demander pourquoi ça marchait pas. Du coup j’ai dû faire une image docker debian pour tester le machin, trouver pourquoi ça marchait pas spécifiquement sur debian, et maintenant j’essaye de m’assurer que ça fonctionne sur debian, parce que je suis sympa.

                Et puis « des utilisateurs qui privilégie une distrib avec des paquets stables (sinon ils n'utilisent pas Debian stable) », laisse moi rire. Je parie qu’il y a un très très grand nombre d’utilisateurs de debian qui le sont uniquement parce que « c’est la distribution pour les serveurs, et moi j’ai un serveur, donc c’est ce qu’il me faut, non ? » et qui se retrouvent à installer des backports à tour de bras.

                Mais bon, je vais peut-être envoyer chier tous les utilisateurs debian qui viendront demander comment utiliser mes logiciels, vu que c’est ça que je suis censé faire si je comprends bien ce qu’on me raconte ici. Parce que ce que je retiens de cette discussion c’est un peu « non mais on en veut pas de ton truc ». C’est triste.

                • [^] # Re: Vivement la suivante

                  Posté par (page perso) . Évalué à 6 (+4/-1).

                  Ben, c'est toi qui vient cracher sur Debian à la base du thread. Il ne faut pas s'étonner d'avoir des retour négatifs après.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Vivement la suivante

                    Posté par (page perso) . Évalué à -8 (+3/-12).

                    Oui, et c’est très bien, ça confirme ce que je pensais.

                    Je vais pouvoir utiliser tranquillement des trucs à jour la conscience tranquille.

                    Je suis passé de « oui mais les pauvres utilisateurs ?? Je peux pas les abandonner :(( » à « Barf, vu qu’apparemment ils s’en foutent, c’est bon ».

                    Je vous remercie donc.

                    • [^] # Re: Vivement la suivante

                      Posté par . Évalué à 3 (+1/-0).

                      Ben voilà tout le monde est content.

                    • [^] # Re: Vivement la suivante

                      Posté par . Évalué à 2 (+1/-0).

                      Tu pourrais en discuter avec les mainteneurs Debian et leur dire que ton logiciel n'est pas maintenu à long terme et qu'ils ne devraient pas le distribuer. Proposer juste des versions exécutables directement sur ton site par exemple (pour python je suppose que ça nécessite un emballage particulier…).

                      Parce que le principe de Debian c'est qu'ils ont une version stable maintenue longtemps, avec des logiciels qui n'ont pas subi d'ajouts de fonctionnalités depuis un moment, dans le but d'améliorer leur stabilité. C'est en contradiction avec l'objectif "je ne veux pas rétro-porter mes corrections de bugs sur les anciennes versions". Soit tu maintiens certaines versions de ton logiciel à long terme, soit ce n'est pas compatible avec Debian stable (je ne sais pas s'ils peuvent maintenir le logiciel dans les versions de test / instable seulement).

                      D'ailleurs c'est même dangereux que dans la Debian stable il traîne une telle version d'un de tes logiciels, il faudrait le voir avec eux.

                      • [^] # Re: Vivement la suivante

                        Posté par (page perso) . Évalué à 2 (+1/-0).

                        Ils backportent apparemment sur la version 4.0 (la version packagée) certains correctifs que je fais sur master.

                        Je sais pas comment ils sélectionnent quels patchs sont importants et lesquels ne le sont pas (j’ai vu qu’ils en ont pris un qui parlait d’un “null pointer dereference etc”), et je n’ai pas vraiment de retour de la part du packager, ni aucun dialogue (c’est quelqu’un d’autre qui m’a informé que c’était packagé dans debian).

                        À mon avis c’est pas une bonne idée (ils passent vraiment en revu tous mes commits pour décider lesquels sont dignes de la version stable, lesquels sont importants et lesquels ne le sont pas ?!), mais bon, c’est pas vraiment mon problème.

                        • [^] # Re: Vivement la suivante

                          Posté par (page perso) . Évalué à 3 (+1/-0).

                          On parle de biboumi ?

                          Si c’est le cas alors le paquet n’est même pas dans stable et « ils », c’est surtout Jonas Smedegaard.

                          Les packagers prennent souvent contact avec l’upstream, si ça n’est pas le cas ici, est-ce que toi tu les as contacté ? Sinon, alors tu es au mauvais endroit, c’est vers lui/eux que tu dois te retourner.

                          • [^] # Re: Vivement la suivante

                            Posté par (page perso) . Évalué à 2 (+1/-0).

                            Oui, on parle de biboumi, et oui effectivement il n’est pas dans stable (mais il reste quand meme en version 4.x, je ne sais pas trop pourquoi du coup, vu que la version 5.0 est sortie et est vachement mieux).

                            Et non, il ne m’a pas contacté, alors qu’il a patché certains trucs qui auraient pu m’intéresser, par exemple

                            https://anonscm.debian.org/cgit/pkg-voip/biboumi.git/commit/debian?id=111e446d1d57ccc47b35f7c6fbf8bd5575d5a0a1

                            https://anonscm.debian.org/cgit/pkg-voip/biboumi.git/commit/debian?id=176a1fcdf53f54c92fbc57f49f610bb7c91ec8f4

                            Je regrette un peu ce manque de communication (j’aurais bien aimé un petit « au fait, pourquoi tu n’as pas appliqué cette modification à ta dernière release, parce qu’elle rencontre aussi ce problème, pas juste la branche master ? »), mais ce n’est pas dramatique, et ce n’est pas le sujet de ce thread. Le travail fait par le packager est correct, et je n’ai pas non-plus pris la peine de le contacter pour lui dire que j’aimerais plus de communication, donc je suis pas vraiment en position pour lui raler dessus.

                            • [^] # Re: Vivement la suivante

                              Posté par (page perso) . Évalué à 3 (+2/-1). Dernière modification le 20/06/17 à 14:25.

                              (mais il reste quand meme en version 4.x, je ne sais pas trop pourquoi du coup, vu que la version 5.0 est sortie et est vachement mieux)

                              Peut-être que le mainteneur n’a pas eu le temps de s’en occuper, y a qu’en prenant contact avec lui que tu sauras.

                              alors qu’il a patché certains trucs qui auraient pu m’intéresser, par exemple

                              Concernant le second patch : « Add some bugfix patches cherry-picked upstream. », donc c’est qq chose qui est déjà présent chez toi.

                              Au final, j’ai quand même l’impression que tu en fais des tas, mais que non seulement tu es de mauvaise fois mais en plus tu ne fais rien de concret pour résoudre ces « problèmes »

                              • [^] # Re: Vivement la suivante

                                Posté par (page perso) . Évalué à 2 (+2/-1).

                                Concernant le second patch : « Add some bugfix patches cherry-picked upstream. », donc c’est qq chose qui est déjà présent chez toi.

                                Oui, cherry-picked de ma branch master, pour etre appliquée à la release 4.0 (la dernière à l’époque). Je ne l’avais pas fait moi-meme parce que je ne savais pas que le problème se trouvait aussi dans la 4.0. C’est de ça dont je parle dans mon « j’aurais bien aimé un petit “au fait, pourquoi tu n’as pas appliqué cette modification à ta dernière release, parce qu’elle rencontre aussi ce problème, pas juste la branche master” »

                                Au final, j’ai quand même l’impression que tu en fais des tas, mais que non seulement tu es de mauvaise fois mais en plus tu ne fais rien de concret pour résoudre ces « problèmes »

                                J’ai dit que c’était « un peu dommage » mais que c’était pas grave. Et t’en conclues « tu en fais des tas ».

                                Non, j’en fais pas des tas, je m’en fous. Qu’il le package comme il veut. Mon souci à la base c’était juste que je voulais que biboumi soit compilable sous debian stable, sans devoir m’interdire d’utiliser des technos que j’aime pendant les 3 prochaines années. C’est tout.

                                Et je suis pas de mauvaise foi, c’est un fait : y’aura pas de gcc 7 dans debian stable avant la prochaine release. Après par contre j’ai de nouvelles solutions qui s’offrent à moi : dire aux gens d’utiliser les backports, ou ne plus me soucier de debian et continuer à faire ce que je veux quand je veux vu qu’apparemment mon logiciel n’est pas adapté à Debian stable (si j’ai mal compris ce thread, tu peux m’aider).

                                • [^] # Re: Vivement la suivante

                                  Posté par . Évalué à 8 (+6/-1).

                                  Non, j’en fais pas des tas, je m’en fous.

                                  Une petite trentaine de commentaires… Ça doit être violent quand tu t'intéresse à quelque chose :)

                                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                            • [^] # Re: Vivement la suivante

                              Posté par . Évalué à 2 (+0/-0).

                              Oui, on parle de biboumi, et oui effectivement il n’est pas dans stable (mais il reste quand meme en version 4.x, je ne sais pas trop pourquoi du coup, vu que la version 5.0 est sortie et est vachement mieux).

                              Ces derniers mois, l'objectif de debian était de corriger les problèmes pour sortir debian 9 justement.
                              Ça implique que sid était gelé et que les mainteneurs ne mettaient à jour les paquets que pour corriger des problèmes connus.
                              Donc, forcément un paquet qui n'est pas destiné à être inclus dans la stable en préparation ne va recevoir beaucoup d'attentions.

                • [^] # Re: Vivement la suivante

                  Posté par . Évalué à 9 (+7/-0).

                  Salut,
                  depuis le début de la discussion, je me pose la question de pourquoi c++17 ?

                  En développement, il y a plusieurs façon de voir les choses : avancer tout le temps et si tu as un bug sur une ancienne version répondre prend la nouvelle !
                  Cette philosophie (courante en LL par manque de temps sur certains projet) ne me convient pas. Parce que oui, certains bug n’existe plus, mais d’autre sont apparus, et il n’y a jamais de version sans bug (même si je ne suis pas sûr que ça existe).
                  On peut aussi : maintenir des versions stables. Sur lesquelles on reporte les bug fix si nécessaires jusqu’à la sortie d’une nouvelle stable. Ça oblige à faire 2 versions, ce n’est pas la cata non plus.

                  J’ai vu que tu t’agaces ensuite, demande toi si tes utilisateurs tu veux les garder ou non. En fonction de ça, tu t’adapte. Soit tu fais du support debian, et donc, tu utilises des techno en accord (c++14) soit tu ne supportes pas, tes utilisateurs n’ont cas aller débuguer arch/Linux ;-)

                  On ne fait pas de LL pour nuire à sa santé, donc pose toi honnêtement la question de ce que tu veux faire. Fais tu le logiciel avant tout pour toi ou pour tes utilisateurs ? Peux-tu te contraindre au c++14 ou serait-se trop complexe ?

                  Avec ces réponses, tu trouveras ce qu’il faut faire.

                  • [^] # Re: Vivement la suivante

                    Posté par (page perso) . Évalué à 2 (+1/-0).

                    On peut aussi : maintenir des versions stables. Sur lesquelles on reporte les bug fix si nécessaires jusqu’à la sortie d’une nouvelle stable. Ça oblige à faire 2 versions, ce n’est pas la cata non plus.

                    Ça ne fonctionne que si on release moins vite que les versions stables de debian (si par exemple je sors 3 versions en 1 an, ben la version 1, packagée dans debian, ne sera plus prise en charge par mes backports, quand je vais sortir la 3).

                    soit tu ne supportes pas, tes utilisateurs n’ont cas aller débuguer arch/Linux ;-)

                    Oui, débuguer archlinux, ou trouver des workaround pour les bugs connus (mais non-corrigés) dans debian. Chacun choisit les bugs qu’il veut rencontrer, et perso j’aurais préféré que les deux types de personnes puissent quand meme utiliser mes logiciels. Mais bon tant pis.

                    depuis le début de la discussion, je me pose la question de pourquoi c++17 ?

                    Parce que c’est amusant, et ça m’évite de recoder std::optional<>

                    • [^] # Re: Vivement la suivante

                      Posté par . Évalué à 2 (+1/-1).

                      Ça ne fonctionne que si on release moins vite que les versions stables de debian (si par exemple je sors 3 versions en 1 an, ben la version 1, packagée dans debian, ne sera plus prise en charge par mes backports, quand je vais sortir la 3).

                      Non, regarde les versions du kernel ou de firefox, on ne maintient pas la version n-1 et n, firefox maintient une version pendant 18mois, soit 5-6 versions standard.

                      De plus tu as répondu au dessus qu’il y a un mainteneur qui suit ton travail et backport les bugfix sur la version debian. Ça a toujours été comme ça, si tes utilisateurs ont un bug sur debian tu les renvoies sur le bug tracker debian. Si le mainteneur pense que le bug vient de chez toi et non des adaptations qu’ils a réalisées, il te fera un bug report.

                      depuis le début de la discussion, je me pose la question de pourquoi c++17 ?

                      Parce que c’est amusant, et ça m’évite de recoder std::optional<>

                      Donc avec « c’est amusant » j’en déduis que tu codes pour toi, alors fait fi de tes utilisateurs. Sinon, ne peux-tu pas utiliser boost::optional ? et attendre patienment que le standard c++17 soit finalisé voir même réellement utilisable en production ?

                      • [^] # Re: Vivement la suivante

                        Posté par (page perso) . Évalué à 4 (+3/-0).

                        Ah oui, tu parles de maintenir seulement une version LTS, et la toute dernière release, mais pas entre. Ok.

                        Donc avec « c’est amusant » j’en déduis que tu codes pour toi, alors fait fi de tes utilisateurs.

                        Principalement pour moi, oui. Mais comme y’a des utilisateurs debian que ça intéresse, j’aurais bien aimé pouvoir leur dire « oui, et mon logiciel qui m’amuse, il peut aussi vous servir ». Maintenant je dois choisir entre les deux : m’amuser à 100%, ou pouvoir fournir quelque chose aux utilisateurs de debian (parce qu’avoir des utilisateurs aussi ça me fait plaisir). C’est ça qui me rend triste.

                        et attendre patienment que le standard c++17 soit finalisé voir même réellement utilisable en production ?

                        Oui, mais ça sera le cas bien avant la sortie de la prochaine debian.

              • [^] # Re: Vivement la suivante

                Posté par . Évalué à 4 (+2/-0).

                Donc tu veux fournir à des utilisateurs qui privilégie une distrib avec des paquets stables (sinon ils n'utilisent pas Debian stable) un truc qui bouge tout le temps et dépend de la dernière version des bibliothèque. J'ai l'impression que tu as un problème de cible.

                J'ai l'impression que tu n'interagis pas beaucoup avec des utilisateurs, car souvent ce sont les utilisateurs eux-mêmes qui ont un problème de cible. Pour ma part, il n'est pas rare de voir des utilisateurs de Debian stable (voire une version encore plus ancienne, ou bien une vieille CentOS) vouloir utiliser la dernière version de certains logiciels et se plaindre que ça bugue (dernier exemple en date : un utilisateur de Debian avec Python 2.7.3—ça doit être Debian 7—manque de bol, un bug corrigé dans Python 2.7.4 empêche le logiciel de tourner).

                C'est particulièrement courant, bien sûr, en entreprise, où c'est un département séparé qui choisit les versions des systèmes installés…

    • [^] # Re: Vivement la suivante

      Posté par . Évalué à 2 (+4/-3).

      C’est toujours un plaisir d’être coincé dans le passé à cause de cette distro.

      Tu n'as jamais entendu parler de debian testing ?

      • [^] # Re: Vivement la suivante

        Posté par (page perso) . Évalué à 5 (+6/-2).

        Oui, (et c’est pas mieux en testing actuellement, ni meme en unstable, https://packages.debian.org/sid/gcc).

        Mais le problème c’est pas ce que moi j’utilise, c’est ce que les gens utilisent. Et je veux (si possible) que mes logiciels puissent fonctionner sur ce que les gens utilisent, et malheureusement debian stable en fait partie. Je pourrais dire « oui, ben faut utiliser debian unstable pour pouvoir utiliser mon logiciel », mais j’aime pas trop l’idée (meme si parfois j’hésite), et je suis sur que je recevrais plein de bug report de gens mécontents.

        • [^] # Re: Vivement la suivante

          Posté par (page perso) . Évalué à 5 (+2/-0).

          Pourquoi ne pas faire une version AppImage de ton logiciel ?

          • [^] # Re: Vivement la suivante

            Posté par (page perso) . Évalué à 1 (+1/-1).

            • [^] # Re: Vivement la suivante

              Posté par . Évalué à 2 (+0/-0).

              De toute façon tu fais du logiciel libre non ? Si tu fournis les sources tout le monde peut compiler et installer ton appli.

              • [^] # Re: Vivement la suivante

                Posté par (page perso) . Évalué à 3 (+2/-0).

                Oui mais pour compiler sous debian, faudra installer gcc 7 depuis les backports et autres emmerdes.

                Alors oui, techniquement on peut tout faire, suffit juste d’y passer du temps. On peut même recoder tous les trucs qui nécessitent du C++11 pour que ça compile sous debian wheezie ou j’sais plus quel vieux machin. Le souci c’est le travail que ça demande.

                • [^] # Re: Vivement la suivante

                  Posté par (page perso) . Évalué à 0 (+0/-2).

                  depuis les backports et autres emmerdes.

                  C’est quand la dernière fois que tu as utilisé Debian ?

                  • [^] # Re: Vivement la suivante

                    Posté par (page perso) . Évalué à 2 (+1/-0).

                    Je suis dessus au boulot, par contrainte.

                    Et c’est quoi la solution pour installer gcc 7, autre que les backports ?

                    Ou alors tu fais référence à mon « et autres emmerdes », parce que tu considères que c’est simple ?

                    • [^] # Re: Vivement la suivante

                      Posté par . Évalué à 2 (+0/-0).

                      Honnêtement, qu'est-ce qui est compliqué à utiliser un package des backports ?

                      • [^] # Re: Vivement la suivante

                        Posté par (page perso) . Évalué à -1 (+2/-4).

                        Moi je n’aime pas. Mais si les gens qui utilisent debian n’ont pas de souci avec l’installation de GCC depuis les backports (et d’après ce topic, ils n’en ont pas), alors c’est peut-etre la solution que je vais retenir, oui.

                        • [^] # Re: Vivement la suivante

                          Posté par (page perso) . Évalué à 2 (+2/-2).

                          Moi je n’aime pas

                          Quel argumentaire…

                          • [^] # Re: Vivement la suivante

                            Posté par (page perso) . Évalué à -2 (+2/-5).

                            J’ai pas vraiment besoin d’argumenter, je cherche pas à convaincre. Et c’est une question de gout. Lors de mes utilisations précédentes, le fait de devoir configurer les backports et d’installer des paquets depuis ces dépots m’a parru plus agaçant que de les avoir directement.

                            Si d’autres gens aiment, tant mieux, je vais pouvoir me servir de « t’as qu’à utiliser les backports » sans souci.

                    • [^] # Re: Vivement la suivante

                      Posté par (page perso) . Évalué à 1 (+0/-1).

                      c’est quoi la solution pour installer gcc 7, autre que les backports ?

                      Sur n'importe quel Linux, sans avoir besoin des droits d'admin:

                      wget …
                      tar -xzf …
                      ./configure --prefix=…
                      make
                      make install

                      (et après tu recompiles tout ce dont dépend ton application :-)

                      • [^] # Re: Vivement la suivante

                        Posté par . Évalué à 2 (+0/-0).

                        Heu, ouais… sauf que gcc est dépendant de la version disponible de la glibc (et de la libstdc++ pour g++) : je ne suis pas sûr que ça marche aussi facilement que ça, sauf si on parle de versions très proches.

                        En C++, mon expérience est qu'il vaut largement mieux utiliser les backports fournis par la distribution, que ce soit sous Debian, CentOS ou RHEL, sous peine de s'arracher les cheveux.

                      • [^] # Re: Vivement la suivante

                        Posté par (page perso) . Évalué à 2 (+0/-0).

                        Sur n'importe quel Linux, sans avoir besoin des droits d'admin:

                        error: dependency not found.

                • [^] # Re: Vivement la suivante

                  Posté par . Évalué à 2 (+0/-0).

                  Les gens qui utilisent debian stable sont conscients de ça, donc je serais tenté de dire que ce n'est pas vraiment ton problème.

                  On ne peut pas dire qu'utiliser les backports soient une grosse emmerde c'est relativement simple d'autant plus si la seule contrainte est la version de gcc.

        • [^] # Re: Vivement la suivante

          Posté par (page perso) . Évalué à 6 (+5/-0).

          Debian unstable a toujours été à jour pour gcc. Ce n'est juste pas forcément la dernière version qui est installée par défaut. https://tracker.debian.org/pkg/gcc-7.

          Si les "gens" utilisent Debian stable, c'est qu'ils accordent de l'importance à ce côté "stable". Sinon, ils seraient sous unstable ou Arch. Debian ne force pas les "gens" à utiliser stable.

    • [^] # Re: Vivement la suivante

      Posté par (page perso) . Évalué à 6 (+5/-0).

      Il est écrit dans la dépêche que cette nouvelle mouture intégrait Flatpack…

      Cela n'est il pas sensé répondre à ta problématique ?

      • [^] # Re: Vivement la suivante

        Posté par (page perso) . Évalué à 6 (+5/-0).

        « Flatpak is the next-generation technology for building and installing desktop applications. »

        Je fais pas de « Desktop applications ». Je développe un serveur XMPP (un component, en fait : https://biboumi.louiz.org). Je suis pas sûr que ce soit le meilleur outil pour packager ce genre de logiciel. Idem pour AppImage.

        • [^] # Re: Vivement la suivante

          Posté par (page perso) . Évalué à 2 (+0/-0).

          Faut utiliser Snap alors

        • [^] # Re: Vivement la suivante

          Posté par . Évalué à 1 (+1/-0).

          Pour c++17 n'est il pas possible de linker statiquement toute les lib utilisées notamment la libc++ (avec un petit -static-libstdc++) ? Ok ça a l'inconvénient de ne plus avoir les maj de sécurité de la libstdc++ et toutes celles utilisé … peut être pas idéal.
          Et effectivement flatpak n'a pas été pensé pour les serveurs, dommage.
          Il reste snap ou docker et peut être appimage mais faut demander à l'utilisateur de l'installer.
          Donc effectivement pas de solution parfaite, snap/docker est peut être la moins pire mais pas directement clé en main pour les utilisateurs (je sais pas trop j'ai jamais vraiment utilisé).
          Sinon faut tout recoder en Go qui n'as pas de dépendance ni même à la libc (je plaisante hein). Sérieusement, je compati : c'est vrai que le vieux GCC de debian c'est vraiment pas pratique. Mais il arrive et je crois avoir lu que debian allait faire des efforts sur ce point (mais je retrouve pas où).

          • [^] # Re: Vivement la suivante

            Posté par (page perso) . Évalué à 5 (+5/-1).

            Pour c++17 n'est il pas possible de linker statiquement toute les lib utilisées notamment la libc++ (avec un petit -static-libstdc++) ? Ok ça a l'inconvénient de ne plus avoir les maj de sécurité de la libstdc++ et toutes celles utilisé … peut être pas idéal.

            Je ne fournis pas de paquet binaires (à part un .deb et .rpm qui sont juste l’output de mes tests d’integration, pour vérifier que ça build correctement et que j’ai pas merdé mes “Makefiles”. Ce n’est pas censé etre utilisé par l’utilisateur final non-dev).

            Alors oui, j’ai bien une image docker qui utilise alpine https://hub.docker.com/r/louiz/biboumi/ mais dans l’idée c’était plus pour faire plaisir aux fans de dockers, qui aiment bien utiliser ça et qui trouvent que c’est pratique. Idéalement je voudrais pas avoir à répondre « t’as qu’à utiliser docker » quand on me demande comment installer biboumi sous debian.

    • [^] # Re: Vivement la suivante

      Posté par (page perso) . Évalué à 10 (+19/-0). Dernière modification le 20/06/17 à 07:12.

      Vivement debian 10, dans 2-3 ans, qu’on puisse enfin publier des logiciels écrits en C++17 ou en Python 3.6.

      Pour la version longue de "ben, ne l'utilise pas", je voudrais faire remarquer quelques dates:

      Donc, la communauté Debian a décidé d'arrêter les intégrations de nouveaux développements / fonctionnalités en janvier. La communauté a dès lors demandé à tous ses membres et utilisateurs de tester les versions packagées dans le freeze des logiciels qu'ils utilisent afin de remonter tous les bugs possible. Après 6 mois de tests, la communauté Debian a enfin décidé que les paquets disponible durant le gel ont suffisamment été testé pour sortir une version officielle en juin 2017.

      Durant cette période de gel, il aurait été impossible d'intégrer Python 3.6.0, puisque Python est un langage fournissant énormément de paquets dépendants et car il venait juste de sortir officiellement de la communauté Python.

      Pour c++17, comment dire… Le dernier brouillon n'était même pas à disposition….

      C’est toujours un plaisir d’être coincé dans le passé à cause de cette distro.

      Pour en remettre une couche, non ce n'est pas "cette distro" qui te bloque, mais "cette communauté de membres et d'utilisateurs qui ont pris la peine pendant 2 ans d'empaqueter des centaines de logiciels et de les tester pendant 6 mois avant de décider qu'une nouvelle version de leur distribution pouvait être distribué".

      Maintenant, il n'y a pas de honte d'avertir tes utilisateurs que tu ne leur fournis aucun support et que s'ils souhaitent utiliser ton logiciel, il faut avoir une installation identique à la tienne. Ça ne change rien au fait que ton application sera toujours open-source/libre et appréciée, mais ça a le mérite de mettre directement les choses au claire avec tes utilisateurs: il n'y a pas de support et le logiciel utilise des technologies très récente (moins de 3 mois d'existence quand même).

      Il n'y a pas de honte non plus à poser des questions du style "Savez-vous pourquoi la communauté Debian n'intègre pas le support de c++ 17 ?" au lieu de rager et de critiquer directement le travail effectué par des centaines de membres et utilisateurs…

      • [^] # Re: Vivement la suivante

        Posté par . Évalué à -2 (+3/-7).

        Ce que j'en retire :

        Utilisez Arch.

        Arch c'est le bien. :p

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Vivement la suivante

          Posté par . Évalué à -5 (+0/-7).

          Le sens de l'humour se perd sur DLFP. Triste.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Vivement la suivante

            Posté par (page perso) . Évalué à -3 (+1/-5).

            Ce n'est pas parce qu'une réponse est à côté de la plaque et peu pertinente qu'il s'agit d'humour…

            C'est bien parce qu'une réponse est à côté de la plaque et peu pertinente qu'elle se prend, à la fin, une note négative …

            Bisous, coeur avec les doigts !

      • [^] # Re: Vivement la suivante

        Posté par (page perso) . Évalué à 1 (+3/-3).

        Le problème c’est pas que je peux pas utiliser python 3.6 ou gcc 7 dès aujourd’hui. Le problème c’est que, comme c’est debian stable, et que c’est figé jusqu’à la prochaine version, je ne pourrai pas utiliser ces versions de logiciels avant 2-3 ans.

        Le problème c’est pas que, en juin 2017, y’ait pas python 3.6 dans les dépots. Mon problème c’est qu’ils n’y seront pas avant très très très longtemps. Parce que oui, meme dans fedora (distro que j’utilise) y’a pas gcc 7, et c’est pas dramatique, parce que je sais que bientot ça sera corrigé.

        Il n'y a pas de honte non plus à poser des questions du style "Savez-vous pourquoi la communauté Debian n'intègre pas le support de c++ 17 ?" au lieu de rager et de critiquer directement le travail effectué par des centaines de membres et utilisateurs…

        Non mais je connais ces raisons. Ça ne m’empèche pas de « rager et de critiquer », parce que je les aime pas.

        • [^] # Re: Vivement la suivante

          Posté par (page perso) . Évalué à 3 (+4/-2).

          Tu connais visiblement pas les backports ….
          En passant, ce n'est plus un truc de bidouilleurs, c'est supporté nativement par Debian: https://backports.debian.org/

          Donc il est tout à fait possible que d'ici 5/6 mois tu ais également accès à gcc 7 ou python 3.6 via les backports… mais bon, à lire ce fil, j'ai l'impression que ton unique objectif est de râler sans aucun volonté constructive…

          Je trouve d'ailleurs ta logique, vu le soft que tu développes, particulièrement foireuse….
          Es tu au courant que les gens qui font du hosting sérieux vont généralement préférer déployer du Debian stable pour des raisons évidentes: avoir un système stable, robuste, qui ne changera pas d'un point de vue fonctionnel entre deux mises à jour, qui ne te cassera pas tes fichiers de configuration entre deux mises à jour, etc…
          Pour un mec qui développe un serveur, je te trouve un peu déconnecté de la réalité du monde de l'hébergement et de la fourniture de service …

          Si pour toi, il est plus important d'avoir accès à un langage dont le draft n'a pas encore été publié plutôt qu'avoir un système qui te donne toutes les chances d'avoir un taux de disponibilité excellent, peu d'interruption de service, un suivi de sécurité sans modification du fonctionnel, alors je pense que tu devrais plutôt te mettre à coder des applis desktop ….

          • [^] # Re: Vivement la suivante

            Posté par (page perso) . Évalué à 1 (+3/-3).

            Et je n’ai pas de problème avec les gens qui font du hosting sérieux et qui veulent continuer à utiliser la version 4.0 du serveur. J’oblige personne à upgrade. Mais je sais que y’a des gens qui sont intéressés par les nouvelles fonctionnalités.

            Donc il est tout à fait possible que d'ici 5/6 mois tu ais également accès à gcc 7 ou python 3.6 via les backports… mais bon, à lire ce fil, j'ai l'impression que ton unique objectif est de râler sans aucun volonté constructive…

            C’est faux. J’ai toujours considéré qu’utiliser les backports était chiant. Mais si j’apprends qu’en fait 99% des utilisateurs de debian stable n’ont pas de souci avec le fait d’installer gcc depuis les backports, parce qu’en fait les backports c’est pas chiant (et que y’a donc que moi qui suis nul), alors ça peut etre la solution que je vais retenir : rajouter « pour installer sous debian, utilisez GCC 7 depuis les backports » dans les instructions d’installation. C’est peut-etre un meilleur compromis que de leur dire « non c’est pas supporté, @+ ».

            • [^] # Re: Vivement la suivante

              Posté par (page perso) . Évalué à 2 (+1/-0).

              J’ai toujours considéré qu’utiliser les backports était chiant.
              Avant, les backports étaient effectivement chiant: il fallait bidouiller les préférences apt pour donner la priorité à la source backport et tout le toutim.

              Maintenant, c'est juste rajouter 1 ligne dans le /etc/apt/sources.list puis installer ton paquet à coup de:

              apt-get install -t stretch-backports gcc

              (voir : https://backports.debian.org/Instructions/ )

              Et terminé. Donc oui, c'est plus aussi chiant que ça a pu l'être à une époque et je pense que, de ce coup, c'est tout à fait envisageable de dire à tes utilisateurs d'utiliser les backports pour compiler ton soft.

              Après, peut être aurais tu tout intérêt à faire un travail de packaging (quand le gcc kivabien et le python kivabien sortiront) toi même car beaucoup d'admin ne sont pas toujours motivé pour:

              • Packager eux-même un soft qu'ils veulent utiliser.
              • Installer un binaire à la mano, compilé depuis une autre bécane.
              • Installer gcc sur un serveur de prod.

              Si tu veux aider l'adoption de ton soft, je pense que tu as tout intérêt à le packager pour qu'il soit simple à déployer.

    • [^] # Re: Vivement la suivante

      Posté par . Évalué à 2 (+2/-3).

      Joli troll ;)

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Vivement la suivante

        Posté par . Évalué à 3 (+3/-3).

        Pour celui qui n'a pas compris : quelqu'un qui vient poser un problème aussi vieux sans apporter d'arguments nouveau et qui alimente le débat stérile c'est la définition d'un troll. D'autres exemples possibles :

        • la même chose qu'ici mais pour RHEL
        • expliquer qu'Arch n'est pas stable quand on en parle
        • affirmer que Slackware est désuet
        • s'offusquer du graveleux du projet weboob
        • mettre une nimage à la fin de ses journaux

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Vivement la suivante

          Posté par . Évalué à 0 (+2/-4).

          Si pour toi un débat est « stérile », tu as le droit de ne pas participer et d'aller voir ailleurs. Je ne crois pas que tu aies été mandaté pour faire la police des commentaires, et désigner ce qui est un troll ou ne l'est pas…

          • [^] # Re: Vivement la suivante

            Posté par . Évalué à 1 (+1/-3).

            J'ai dis que c'est du troll, pas qu'il ne faudrait pas le faire.

            J'ai même à mon actif plusieurs troll de ce genre et tu dois pouvoir trouver un de mes journaux qui parle d'une des raisons qui peuvent le rendre intéressant.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Pour les très grands débutants, DFLinux-Stretch est en ligne !

    Posté par . Évalué à 7 (+5/-0).

    Pour les très grands débutants, DFLinux-Stretch est en ligne !

  • # GNOME 3.14 et 3.22 dans RHEL aussi

    Posté par (page perso) . Évalué à 9 (+7/-0).

    Red Hat Enterprise Linux (RHEL) 7.2 et 7.3 sont sur GNOME 3.14, et pour RHEL 7.4 ce sera GNOME 3.22. Ça tombe bien que Debian ait les mêmes versions, il y a des chances que ce soit plus stable (étant donné que Red Hat fait plus ou moins les 3/4 du boulot dans GNOME).

    Aussi, GTK+ 3.22 est et sera la dernière version de GTK+ 3, c'est donc une version LTS.

    Bon il faut que les mises à jour arrivent dans Debian, pour la version stable j'ai déjà vu pas mal de paquets GNOME qui n'étaient pas à jour (genre un certain module GNOME en était à la 3.14.4 et Debian stable était toujours à la 3.14.0).

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi

      Posté par (page perso) . Évalué à 6 (+4/-0).

      J'ai l'impression que leur vision de la stabilité diffère de celle des utilisateurs. Je peux me tromper, mais je vois plus une recherche de la stabilité dans le sens où une application qui ne proviendrait pas forcément de leurs dépôts (du style, une application propriétaire) aurait la garantie de pouvoir fonctionner à l'identique du début à la fin, sans surprise.

      À l'inverse d'utilisateurs qui aimeraient bien voir corriger des bugs (qu'on trouvera toujours, y compris chez Debian) pour obtenir un système toujours plus stable. La logique voudrait que si un développeur sort 36 versions correctives de son application ou de sa bibliothèque, sans ajouter de nouvelles fonctionnalités, elles soient toujours intégrées dans Debian. Mais ça ne semble pas être le cas, puisque j'imagine qu'ils ont trop peur qu'un correctif puisse avoir des effets de bords inattendus, qui iraient à l'encontre de leur vision de la stabilité.

      Donc pour moi, non, une Debian stable n'est pas stable. Y compris sur un serveur, puisque sur le miens, j'ai déjà rencontré un certain nombre de problèmes (allant jusqu'aux plantages) avec lftp, screen, rtorrent… Problèmes qui avaient été corrigés dans les versions plus récentes fournies par Ubuntu Server.

      Dans certains domaines qui peuvent partager cette vision de la stabilité, Debian est sans doute effectivement le meilleur choix possible. Mais je ne pense pas qu'il faille dire aux particuliers qu'avec une Debian ils auront un système bien plus stable et plus fiable qu'avec d'autres distributions.

      • [^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi

        Posté par (page perso) . Évalué à 7 (+4/-0).

        e vois plus une recherche de la stabilité dans le sens où une application qui ne proviendrait pas forcément de leurs dépôts (du style, une application propriétaire) aurait la garantie de pouvoir fonctionner à l'identique du début à la fin, sans surprise.

        Pour moi, c'est plus un système qui fonctionne pendant la durée de vie de la version sans nécessiter de changement de configuration. Contrairement, par exemple, à une rolling release qui nécessite de modifier la configuration des logiciels quand ceux-ci le demande. Tu configure tes logiciels et ils fonctionnent pour deux ans sans plus y toucher.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi

          Posté par (page perso) . Évalué à -5 (+2/-8).

          Oui, stable c’est dans le sens « ça change pas », pas dans le sens « ça fonctionne correctement ».

          Ils préfèrent avoir des trucs avec des bugs connus, plutôt que d’avoir un truc avec ces bugs connus corrigés mais avec peut-être de nouveaux bugs inconnus.

          • [^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi

            Posté par (page perso) . Évalué à 10 (+11/-0).

            Vu le nombre de corrections qui passent par stable-proposed-updates (en plus des correctifs de sécurité qui passent par un canal dédié), je pense qu'il y a un certain a priori, ou une certaine méconnaissance du fonctionnement de la distribution, ou bien un peu de mauvaise foi.

            Debian Consultant @ DEBAMAX

          • [^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi

            Posté par (page perso) . Évalué à 4 (+3/-0).

            "Ils préfèrent avoir des trucs avec des bugs connus, plutôt que d’avoir un truc avec ces bugs connus corrigés mais avec peut-être de nouveaux bugs inconnus."

            Il existe une troisième solution à cela, c'est d'avoir un truc où les bugs connus sont corrigés sans toutefois introduire de nouvelles fonctionnalités avec de nouveaux bugs inconnus. C'est la mise à jour à faible risque, et c'est ce que pratiquent les distributions de qualité entreprise comme RHEL/CentOS, SLES, Ubuntu LTS, etc.

            J'explique ça en détail dans le chapitre 1 de mon bouquin sur Linux. L'extrait est en ligne ici.

            http://www.editions-eyrolles.com/Livre/9782212137934/debuter-avec-linux

            Un gentil bonjour de la garrigue gardoise.

            Dyslexics have more fnu.

  • # De mieux en mieux

    Posté par (page perso) . Évalué à 7 (+6/-0).

    J'utilise Debian depuis 7 et j'ai l'impression que les dist-upgrade se passe de mieux en mieux. Avant il y avait toujours un pet de travers. La, la 9: Aucun soucis. Je me demande si le fait que Debian testing soit utilise par Ubuntu et Mint n'aide pas a avoir une meilleur stabilité de la branche stable.

    • [^] # Re: De mieux en mieux

      Posté par . Évalué à 4 (+4/-0).

      j'ai trois ordi qui ont commencé avec Debian Squeeze (6 ?) et jamais eu un seul problème de dist-upgrade que ce soit avec apt ou aptitude.
      Après, j'essaie toujours d'attendre quelques semaines que les bugs soient résolus.

      Je me demande si le fait que Debian testing soit utilise par Ubuntu et Mint n'aide pas a avoir une meilleur stabilité de la branche stable.

      J'ai toujours pensé que Canonical utilisait sid comme base de travail, ce qui expliquait une partie de l'aversion pour Ubuntu.

  • # systeme de fichier

    Posté par (page perso) . Évalué à 6 (+4/-0).

    Et sinon, pour une installation sur SSD (ordinateur personnel) ,c'est toujours ext4 qu'il faut privilegier?

  • # Fusion des usr (usrmerge) pour plus tard.

    Posté par . Évalué à 4 (+4/-0).

    Il semble que la fusion des arborescences /usr a été repoussée à la prochaine version depuis la RC1 de l’installeur.

  • # Une image stretch ?

    Posté par . Évalué à 3 (+1/-0).

    Quelqu'un a-t-il déjà tenté de construire une image de machine virtuelle pour debian stretch ? Je vais essayer de tenter le coup avec VMBuilder, mais si quelqu'un a déjà une méthode qui fonctionne je suis preneur !

    Membre de l'april, et vous ? http://www.april.org/adherer

    • [^] # Re: Une image stretch ?

      Posté par (page perso) . Évalué à 3 (+2/-0).

      J'ai aperçu des gens mentionner vagrant sur le canal IRC #debian-cd mais je ne suis pas familier de la problématique des images cloud. Cela dit, il existe une liste debian-cloud@ où les derniers messages parlent justement de cela. Un début de réponse, peut-être ?

      Debian Consultant @ DEBAMAX

    • [^] # Re: Une image stretch ?

      Posté par . Évalué à 3 (+2/-0). Dernière modification le 19/06/17 à 17:51.

      Perso j'installe à la main avec virt-manager ca me donne une image de base. J'installe ensuite mes petites affaire. Ma conf vim, exim, syslog, xymon etc. Ensuite je snapshot cette image de base pour créer de nouvelles vm. Au boot j'ai un rm -rf /var/log et une mise à jour du hostname et l'ajout dans xymon et c'est parti. J'ai commencé à tester avec stretch il y a quelques jours. Mise à part les interfaces réseau qui change de nom. Tout va bien.

    • [^] # Re: Une image stretch ?

      Posté par . Évalué à 2 (+1/-0).

      J'utilise packer, qui va utiliser un fichier de preseed pour l'install + qq tâches ansible pour provisionner et basta !

      Utilisé régulièrement sous Debian Jessie, j'ai testé dernièrement avec une Stretch, pas de problèmes rencontrés.

  • # GnuPG 1.4 → 2.1

    Posté par (page perso) . Évalué à 10 (+19/-0).

    Le passage de la version par défaut de GnuPG de 1.4 à 2.1 est très important, et pourrait surprendre les utilisateurs de Debian Stable sur desktop (il y en a ?), alors quelques petites remarques sur ce qui change, pêle-mêle.

    a) Là où GnuPG 1.x était monolithique (le binaire gpg faisait tout), GnuPG 2.1 a une architecture modulaire (déjà amorcée avec GnuPG 2.0, mais c’est vraiment la branche 2.1 qui a achevé cette transition), comprenant au minimum les composants suivants :

    • gpg, le programme principal ;
    • gpg-agent, l’agent de gestion des clefs privées ;
    • dirmngr, le démon réseau.

    (On peut éventuellement y ajouter scdaemon, le démon d’accès aux cartes à puce, si vous utilisez ce genre d’outils.)

    L’utilisation des démons auxiliaires est obligatoire (l’utilisation de gpg-agent était facultative avec GnuPG 1.x, ce n’est plus le cas avec GnuPG 2.x). Pas la peine de jouer avec l’option --no-use-agent, elle est silencieusement ignorée.

    b) Les clefs privées sont désormais stockées dans le dossier $GNUPGHOME/private-keys-v1.d. Le fichier $GNUPGHOME/secring.gpg n’est plus utilisé. À la première utilisation de GnuPG 2.1, les clefs privées présentes dans secring.gpg seront silencieusement migrées vers private-keys-v1.d.

    c) Tous les démons auxiliaires (gpg-agent, dirmngr, scdaemon) sont démarrés automatiquement quand ils sont nécessaires. Cela peut éventuellement surprendre ceux qui utilisaient précédemment GnuPG 2.0 (que Debian fournissait dans le paquet gnupg2), où un script /etc/X11/Xsession.d/90gpg-agent se chargeait de démarrer l’agent au démarrage d’une session.

    Similairement, la variable d’environnement GPG_AGENT_INFO, précédemment utilisée pour localiser la socket de l’agent, n’a plus lieu d’être.

    La socket en question, d’ailleurs, n’est plus placé dans $GNUPGHOME, mais dans /var/run/user/$(id -u)/gnupg, dossier qui est géré par Systemd. Vous n’avez normalement pas besoin de le savoir, mais ça peut occasionner des surprises voire des désagréments si vous aviez l’habitude de faire des choses un peu « exotiques » avec l’agent GnuPG (aeris devrait pouvoir vous en dire quelques mots — je crois qu’il s’est arraché quelques cheveux sur cette question).

    d) Les clefs OpenPGP au format v3 (qui datent de l’époque de PGP 2.6, au milieu des années 1990) ne sont plus du tout prises en charge. Si vous avez encore des données qui traînent chiffrées avec une clef v3, vous aurez besoin de GnuPG 1.x (que Debian fournit désormais sous le nom gnupg1) — auquel cas je vous invite instamment à déchiffrer ces données et à les re-chiffrer avec une clef plus récente.

    e) GnuPG 2.1 a introduit un nouveau format de stockage des clefs publiques, le format keybox (fichier $GNUPGHOME/pubring.kbx), plus efficace que l’ancien keyring (fichier $GNUPGHOME/pubring.gpg). Néanmoins, si vous avez déjà utilisé GnuPG ≤ 2.0 et que vous avez donc déjà un fichier pubring.gpg, GnuPG 2.1 continuera à utiliser le fichier existant. Pour migrer vers le nouveau format (ce qui n’est pas obligatoire, remarquez), l’approche recommandée est la suivante :

    cd ~/.gnupg
    # Exporter les valeurs de confiance
    $ gpg --export-ownertrust > otrust.lst
    # Renommer le trousseau publique (ancien format) pour qu’il ne soit plus reconnu par GnuPG
    $ mv pubring.gpg publickeys
    # Ré-importer les clefs publiques; en l’absence de pubring.gpg, GnuPG 2.1 créera automatiquement un fichier keybox
    $ gpg --import-options import-local-sigs --import publickeys
    # Ré-importer les valeurs de confiance
    $ gpg --import-ownertrust otrust.lst

    f) La procédure de génération de clefs a été simplifiée : GnuPG génère par défaut des clefs « standard » sans plus demander à l’utilisateur de choisir lui-même l’algorithme, la taille, la date d’expiration (la seule chose demandée est l’identité à associer à la clef). Utilisez la commande --full-gen-key au lieu de --gen-key pour retrouver l’ancienne procédure où vous pouvez spécifier vous-même les caractéristiques de la clef.

    g) GnuPG 2.1 prend en charge la cryptographie elliptique, mais par défaut la création de clefs ECC n’est pas accessible, même en utilisant la commande --full-gen-key. Il faut ajouter l’option --expert pour se voir offrir la possibilité de créer une clef ECC.

    • [^] # Re: GnuPG 1.4 → 2.1

      Posté par (page perso) . Évalué à 4 (+2/-0).

      Merci pour tes précisions. C’est quelque chose qui aurait pu être mis (en condensé) dans la dépêche.

      g) GnuPG 2.1 prend en charge la cryptographie elliptique, mais par défaut la création de clefs ECC n’est pas accessible, même en utilisant la commande --full-gen-key. Il faut ajouter l’option --expert pour se voir offrir la possibilité de créer une clef ECC.

      Ce qui est cool c’est que peut-être que les serveurs de clefs vont se mettre à les gérer correctement maintenant :)

      • [^] # Re: GnuPG 1.4 → 2.1

        Posté par (page perso) . Évalué à 7 (+6/-0).

        … les utilisateurs de Debian Stable sur desktop (il y en a ?)

        Oui, oui, moi par exemple o/

        Au boulot, je suis pas payé pour jouer avec mon bureau si il casse dans testing.
        À la maison, pareil pour les PCs que je gère (femme et enfants)
        Mes PCs perso (fixe et portable) sont sous testing par contre.
        /mavie, vous pouvez passer à la suite :)

        • [^] # Re: GnuPG 1.4 → 2.1

          Posté par . Évalué à 4 (+4/-0).

          Un peu la même chose. Mon PC de travail est sous Debian stable parce que besoin d'une machine qui soit disponible, je n'ai pas toujours le temps de mettre les mains dans le moteur et qui plus est je ne suis pas informaticien de formation. Avec quelques rétroportages (et maintenant Flatpack) pour mes outils, ça roule bien et tous les trois ans j'ai de grosses améliorations.

          Il faut aussi penser que DFlinux est basé sur stable et qu'il y a beaucoup de personnes ou de structures qui utilisent l'ordi pour de la gestion bureautique (compta, mailing, etc.) sans avoir de connaissances informatiques. Le passage d'un informaticien pour les dist-upgrade n'est quasiment plus indispensable, du moment que les protocoles de sauvegardes sont bien intégrés (dans les esprits et dans la machine).

    • [^] # Re: GnuPG 1.4 → 2.1

      Posté par (page perso) . Évalué à 4 (+3/-0).

      "les utilisateurs de Debian Stable sur desktop (il y en a ?)"

      Il y a même plus conservateur que ça. Sur mon portable aussi bien que sur ma station de travail, j'ai CentOS 7 avec KDE 4.14 et LibreOffice 5.0.6. Support officiel jusqu'en juin 2024, rétroportage de corrections de bugs et tout. J'ai une prédilection pour les systèmes "ennuyeux".

      Dyslexics have more fnu.

  • # Vim config par défault

    Posté par . Évalué à 3 (+2/-0).

    j'ai l'impression que la conf par défault de vim concernant la souris est en mode visual. C'est très perturbant. C'est que moi ?

    • [^] # Re: Vim config par défault

      Posté par (page perso) . Évalué à 2 (+1/-0).

      Non non, c'est bien la config par défaut qui a changé.
      Il faut updater ton ~/.vimrc (mais tu as l'air de gérer, je vais pas te faire l'insulte de te donner la ligne à ajouter :p).

  • # PHP 7.0 et non 7.1 ?

    Posté par . Évalué à 4 (+3/-0). Dernière modification le 19/06/17 à 20:24.

    Pourquoi la version de PHP intégrée est 7.0 et non 7.1 ?

    VirtualBox, du fait qu’Oracle refuse de partager les vulnérabilités à travers le CVE, cela rend difficile la gestion de la sécurité des paquets dans la branche stable ;

    Oracle, another crap :D

  • # Plus d'une façon d'utiliser Debian...

    Posté par . Évalué à 4 (+4/-0).

    Juste pour préciser que les versions de Debian peuvent être utilisé à partir du freeze sans réel problème et du coup on a automatiquement des logiciels plus récents sans réellement sacrifier la stabilité. La version téléchargeable de Firefox et Thunderbird se met à jour automatiquement en plus. Pour Chrome il y a un dépôt. Bref, pour une utilisation Desktop et aussi pour du développement web, je n'ai aucun problème à garder des logiciels vieux d'environ 1 ans (on peut déjà estimer que le "soft freeze" de Buster va être en novembre prochain)!

    Et puis ça évite les ennuis de Unstable lorsque tu as oublié de prendre ton café le matin! Genre un changement de Sysvinit à systemd avec des dépendances non résolus que tu fais pareil avec le plus grand des plaisirs! Ensuite quand tu reviens finalement avec un café, ton ordinateur ne démarre plus!

    Tant qu'a utiliser Unstable ou Testing en performance, il est préférable d'utiliser Arch qui est réellement une rolling-release…

    Vivre Debian!

  • # Utilisation bureau.

    Posté par . Évalué à 5 (+4/-0).

    Bonjour,

    Je vois beaucoup de monde dire que Debian stable n'est pas fait pour le bureau.

    Pourtant, j'utilise KDE Debian (pour l'instant Jessie) sans problème (et c'est bien la première fois que je suis content de mon système d'exploitation…En 2 ans, il n'a jamais eu un problème de démarrage, j'ai toujours pu compter dessus, les bugs étaient toujours les mêmes…:D )…

    Pourquoi donc Debian Stable est si "mal vue" pour le bureau ?

    • [^] # Re: Utilisation bureau.

      Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 20/06/17 à 20:19.

      Bah l’idée « Debian stable = pas pour le bureau » est quand même pas mal répandue par les Debianneux eux-mêmes…

      Par exemple, Raphaël Hertzog et Roland Mas, dans les Cahiers de l’admin – Debian Wheezy, écrivent :

      Les administrateurs systèmes, soucieux avant tout de la stabilité de leurs serveurs, se moquent de la dernière version de GNOME ; ils opteront pour la Debian Stable et en seront satisfaits. Les utilisateurs finaux, plus intéressés par la dernière version de GNOME ou de KDE que par une stabilité irréprochable, trouveront en Debian Testing un bon compromis entre absence de problèmes graves et logiciels relativement à jour.

      N’étant pas moi-même utilisateur de Debian (quelque version que ce soit) sur le desktop, c’est ce passage qui m’a fait demander, mi-ironiquement mi-sérieusement, s’il y avait des utilisateurs de Stable sur bureau…

      • [^] # Re: Utilisation bureau.

        Posté par . Évalué à 7 (+6/-0).

        D'accord.

        Pour tout t'avouer, en 10 ans, je suis passé par des tas de distributions et c'est bien Debian Stable à laquelle j'ai adhéré.

        Comme je le dis, les bugs du début sont les mêmes maintenant et ne me gênent pas (par exemple, l'instabilité de kdenlive à certains moments).

        Et pour le reste, je n'ai pas eu un seul démarrage foireux, une seule perte de connexion, un seul truc qui fonctionnait et qui ne fonctionnait plus ensuite (l'inverse est faux, puisque j'ai pu amélioré certaines fonctions).

        Mes parents, ma femme, mes oncles et tantes, cousins et des tas d'amis sont sous Debian Stable, aussi : c'est bien simple, je n'ai rien à faire pendant 3 ans pour les aider, hormis en ce qui concerne "l'apprentissage" (ce qui me convient très bien…d'une, je n'aime pas résoudre les problèmes nouveaux apparus je ne sais comment ou à cause de l'utilisateur, de deux, s'ils apprennent, c'est une bonne chose).

        Ainsi, la plupart savent se servir d'apt en ligne de commande, et c'est quand même pas rien ! :D

        (Pour les mises à jour)

        Voilà mon avis d'utilisateur "bureau", qui fait du Blender, libreoffice, du FTP, un peu de réseau, de l'Arduino, du jeu vidéo, de la vidéo tout court…:)

    • [^] # Re: Utilisation bureau.

      Posté par . Évalué à 5 (+7/-2). Dernière modification le 20/06/17 à 20:22.

      Parce que selon moi les gens aiment vivre avec l'utopie qu'un logiciel plus récent est nécessairement meilleur. L'exemple de Wayland est frappant! Les gens sont prêt a se séparer de plusieurs logiciels qui marchent bien pour quelque chose qui sera meilleur, mais qui n'est pas encore intégré parfaitement dans les distributions Linux. Une chose que j'ai comprit avec les années, c'est qu'un logiciel libre nouveau ou profondément modifié à toujours besoin de temps pour arriver à maturité et être utilisable et ce temps se compte parfois en années! Dans ce contexte Debian stable est parfaite!

      • [^] # Re: Utilisation bureau.

        Posté par (page perso) . Évalué à 7 (+6/-1).

        Parce que selon moi les gens aiment vivre avec l'utopie qu'un logiciel plus récent est nécessairement meilleur.

        Tu portes un jugement de valeur sur la question, ce qui me semble dénué de sens.
        Un logiciel nouveau, ou mis à jour, sert à corriger des soucis, ajouter des fonctionnalités, changer d'ergonomie… Peut être que tu t'en moques de la fonctionnalité X, mais pour certains ça vaut le coup.

        Les gens sont prêt a se séparer de plusieurs logiciels qui marchent bien pour quelque chose qui sera meilleur, mais qui n'est pas encore intégré parfaitement dans les distributions Linux.

        Mais heureusement qu'il y a des gens comme ça (j'en fais parti), si tu veux avoir Wayland stable avant 2025, il faut des gens pour tester, faire des retours, rapporter des bogues, tester sur l'ensemble des configurations matérielles / logicielles existantes.

        Personnellement j'aime quand ça bouge, je m'ennuie quand mon système n'a aucune modification pendant longtemps. Car oui, j'aime tester, j'aime profiter des nouvelles fonctionnalités qui apportent parfois un vrai confort.

        Bref, ne juge pas les gens qui n'ont pas la même optique que toi, il faut de tout pour faire un monde, Debian évoluerait bien moins vite si tout le monde se calquait sur son modèle de développement.

        • [^] # Re: Utilisation bureau.

          Posté par . Évalué à 1 (+3/-2). Dernière modification le 20/06/17 à 21:23.

          C'est pas pour porter un jugement. J’admets que Wayland corrige plusieurs choses, notamment au niveau de la sécurité. Dans ce cas particulier, le problème ne vient pas tellement du logiciel, mais de tous l'écosystème qui repose dessus.

          Je veux pas non plus insulter ceux qui essaie des nouveaux trucs, j'en fait partie moi aussi. J'essaie juste de dire que des personnes veulent avoir des logiciels "bleeding edge" seulement parce que c'est "bleeding edge" …

          Je dois t'avouer qu'après 1 ans sur Stable, j'ai hâte à la nouvelle version. Je migre toujours au "soft freeze" et parfois un peu avant.

          • [^] # Re: Utilisation bureau.

            Posté par . Évalué à 2 (+1/-1).

            Je veux pas non plus insulter ceux qui essaie des nouveaux trucs, j'en fait partie moi aussi. J'essaie juste de dire que des personnes veulent avoir des logiciels "bleeding edge" seulement parce que c'est "bleeding edge" …

            Y'a rien de mal à aimer la nouveauté, les nouvelles fonctionnalités, la sécurité …

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Utilisation bureau.

      Posté par . Évalué à 10 (+8/-0).

      Cas de figure 1 :

      Entreprise Machin sort le nouveau format VP11 de vidéo pour le web. En 3 mois elle est incluse dans les nouvelles versions des principaux brouteurs et encodeurs. Au bout d'un an les 3/4 des vidéos sur le web sont en VP11. Et encore 1 an après la nouvelle Debian sort, et les utilisateurs de stable sur le desktop peuvent profiter des vidéos du web en VP11. Pas de pot, on est déjà passés à VP12.

      Cas de figure 2 :

      Des utilisateurs communiquent sur une ML qui rajoute un titre en début de sujet (par exemple: [Râleurs] ) si celui-ci n'existe pas déjà. Kévin envoie un e-mail en mettant pour sujet sainul sa marchent pa xD, toute la ML recevra un e-mail ayant pour sujet [Râleurs] sainul sa marchent pa xD encodé en UTF-8. Un utilisateur avec un client à jour répond, le sujet de la réponse est Re: [Râleurs] sainul sa marchent pa xD. Un utilisateur en Debian stable avec un vieux icedove qui ne gère pas les changements d'encoding dans les sujets répond, le sujet devient Re: [R�leurs] Re: [Râleurs] sainul sa marchent pa xD. Au bout de 5 échanges de réponses ça devient :

      Re: [R�leurs] Re: [Râleurs] Re: [R�leurs] Re: [Râleurs] Re: [R�leurs] Re: [Râleurs] sainul sa marchent pa xD

      Dans l'affichage des threads d'un client mail c'est juste illisible. Déjà que le mail de Kévin à la base était tout pourri >:(

      Cas de figure 3 :

      Le nouveau jeu Battle For Bidule sort une nouvelle version stable. Un utilisateur de Debian stable veut jouer avec une bande de copains. Situation :

      — On joue à Bidule, version X.Y.
      — Ah mais j'ai pas la X.Y, elle est pas dans les dépôts.
      — Ben utilise les backports.
      — Elle est pas dans les backports
      — Ben fais de l'apt-pinning alors
      — Ok j'installe le paquet de testing. Ah zut il me demande de mettre à jour 250 paquets dont la libc.
      — Ouch attends un peu tu risques de tout péter.
      — T'inquiète, ça risque r
      *user disconnected*

      Pour résumer, le problème auxquels sont confrontés les utilisateurs de stable c'est qu'aujourd'hui les standards évoluent plus vite que ne sortent les nouvelles versions de Debian. Pour une utilisation sur serveur, ce n'est généralement pas un problème, parce que quand on fait évoluer les protocoles implémentés sur les serveurs, c'est généralement par petites incrémentations en faisant gaffe à casser le moins souvent la compatibilité avec les versions précédentes. Et ces petites incrémentations sont généralement bien gérées par les mainteneurs des backports Debian. Pour une utilisation sur Desktop, c'est plus problématique, parce que les standards implémentés sur les clients évoluent beaucoup plus vite (en peu de temps tu peux avoir un nouveau codec vidéo pour le web qui se déploie, un nouveau codec audio pour la VoIP, un nouveau champ dans les header des e-mails, une nouvelle version d'un jeu multijoueur), ils évoluent de façon plus massive (pour les jeux d'une version à une autre t'auras des changements de gameplay, ça va forcément casser), et les backports debian ne peuvent pas suffire.

      Donc mon conseil: n'utilisez pas stable sur votre desktop, sauf si vous n'allez jamais sur internet / n'interagissez jamais avec personne. Sinon, utilisez plutôt testing ou unstable. Personnellement à part quelques programmes que j'ai pas réussi à compiler parce qu'ils étaient écrits par des jeunots hyperactifs qui ont décidé que le C++11 c'était HaZBine et qu'ils étaient incapables de coder un hello world sans utiliser C++17, j'ai jamais eu de problèmes avec testing.

      splash!

      • [^] # Re: Utilisation bureau.

        Posté par . Évalué à 5 (+4/-0).

        Donc mon conseil: n'utilisez pas stable sur votre desktop, sauf si vous n'allez jamais sur internet / n'interagissez jamais avec personne. Sinon, utilisez plutôt testing ou unstable

        Utilisez stable quand elle vient de sortir. Unstable juste après la sortie d’une stable, il faut aimer être joueur. Testing, c’est un bon choix à partir du feature freeze. Avant, c’est risqué (certains paquets peuvent être cassés dans testing pendant très longtemps, et les mises à jour de sécurité ne sont pas garanties).

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

      • [^] # Re: Utilisation bureau.

        Posté par . Évalué à 3 (+3/-0).

        Donc mon conseil: n'utilisez pas stable sur votre desktop, sauf si vous n'allez jamais sur internet / n'interagissez jamais avec personne. Sinon, utilisez plutôt testing ou unstable.

        Je ne sais pas quel navigateur que tu utilises, mais je n'ai jamais eu de problème de codec avec Firefox et encore moins avec Chrome et ce, depuis environ 4-5 ans. Tu peux facilement avoir les versions à jours de Firefox et Chrome sur Stable et s'il te manque réellement un codec, tu le télécharges à partir du dépôt de Unstable et ça finit là parce que 99% du temps un codec n'a pas de dépendance.

        Pour Thunderbird je comprend pas plus ton point. Présentement j'utilise la 54 Beta… et elle se met à jour automatiquement…

        j'ai jamais eu de problèmes avec testing.

        Vraiment? La mémoire qui se remplit jusqu’à ce que ton ordinateur soit inutilisable. Plus capable d'aller sur internet parce que NetworkManager change de façon d'utiliser les adresse MAC. Personnellement c'est le genre de problème que j'ai déjà eu avec testing. Vraiment rien d'insurmontable, mais il faut savoir ou chercher quand sa arrive. Disons qu'un novice va se décourager et abandonner, un utilisateur intermédiaire va passer 1 semaines avant de trouver la solution et un utilisateur avancé va trouver le problème dans la même journée…

        Les changements dans Testing seront majeurs dans les prochaines semaines. J'ai de la misère a croire que tu vas effectuer un dist-upgrade prochainement!

        Le nouveau jeu Battle For Bidule sort une nouvelle version stable.

        La je te donne 100% raison, Debian Stable n'est pas fait pour jouer a des jeux décents! Sauf l’excellent Supertuxkart(l'équipe de développement fait vraiment du super boulot)!

        • [^] # Re: Utilisation bureau.

          Posté par . Évalué à 1 (+0/-1).

          Vraiment? La mémoire qui se remplit jusqu’à ce que ton ordinateur soit inutilisable.

          Jamais eu ce problème, sauf bêtise de ma part.

          Plus capable d'aller sur internet parce que NetworkManager change de façon d'utiliser les adresse MAC.

          Jamais eu ce problème. En même temps j'ai viré NetworkManager le jour où il a cessé d'être init-agnostique.

          Vraiment rien d'insurmontable, mais il faut savoir ou chercher quand sa arrive. Disons qu'un novice va se décourager et abandonner, un utilisateur intermédiaire va passer 1 semaines avant de trouver la solution et un utilisateur avancé va trouver le problème dans la même journée…

          2 conseils : 1) utiliser apt-listbugs, 2) utiliser des logiciels simples et stupides le plus possible (le deuxième conseil ne conviendra pas forcément à ceux qui aiment les environnement de bureau tout intégrés où il n'y a rien à configurer).

          Les changements dans Testing seront majeurs dans les prochaines semaines. J'ai de la misère a croire que tu vas effectuer un dist-upgrade prochainement!

          Non, je vais attendre : https://linuxfr.org/nodes/111860/comments/1701524

          splash!

      • [^] # Re: Utilisation bureau.

        Posté par . Évalué à 7 (+5/-0). Dernière modification le 22/06/17 à 08:43.

        Tes exemples ne sont pas du tout convaincants.

        L'histoire des codec vidéos, c'est pipotron, je n'ai jamais vu un format vidéo se généraliser aussi vite. C'est en général au contraire un des domaines où l'adoption a souvent pas mal d'inertie notemment à cause des encodeurs/décodeurs hardware qui mettent plus de temps à arriver que les solutions software.

        L'histoire des mails est bien gentillette mais il y'a une tétrachiée de clients mails disponibles dans les repos donc là encore, c'est idiot.

        Pour les jeux, la debian stable n'est pas la plus pertinente mais ce n'est pas vraiment ce que j'appelle une utilisation desktop. Le gaming sur pc c'est un truc marginal et encore plus sous linux.

        • [^] # Re: Utilisation bureau.

          Posté par (page perso) . Évalué à 5 (+4/-0).

          Je n'ai jamais eu de soucis de codecs, de formats, de mails, de bugs, ect… sur mes stables.
          Je m’ennuie souvent sur stable car j'aime bien les rollings et je suis souvent sous sid mais je dois admettre que stable est bien la seule distribution ou je peux fermer les yeux et être sur d’être tranquille.

          Dans la famille je ne met que du debian stable et avant ça c’était du ubuntu lts mais depuis que l'ubuntu m'a foutu des pc HS suite a une suppression de pilote graphique j'ai tout misé sur debian.

          De plus la stable n'est pas que prédisposé a être sur du serveur, mais bien sur du desktop comme des ordinateur de travail, ordinateur de personne qui veulent juste que ça marche, des gens comme moi qui n'ont plus le temps de passer des heures et des heures a faire de la maintenance, bref c'est une distribution universel.

  • # Virtualbox ?

    Posté par . Évalué à 3 (+3/-0).

    J'ai pas compris cette histoire avec Virtualbox.
    Est ce que ça veut dire que Virtualbox n'est plus présent dans les dépôts debian et donc plus installable sur debian ?

    • [^] # Re: Virtualbox ?

      Posté par (page perso) . Évalué à 3 (+2/-1).

      Est ce que ça veut dire que Virtualbox n'est plus présent dans les dépôts debian

      J'ai l'impression:
      https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=virtualbox

      et donc plus installable sur debian ?

      Gni? pourquoi "donc"? Démontre moi le lien entre "pas dans les dépôts" et "plus installable". Perso je vois "plus installable à partir des repos" certes, mais rien à voir avec "plus installable" général.

      J'ai survolé le rapport, le pb semble que Debian ne veut pas généraliser l'exception Firefox à prendre la dernière version aussi dans les versions stables (mais on y viendra à force à avoir plein de logiciels comme ça…), donc failles car Debian ne veut/peux pas faire comme des gens font avec le noyau Linux à regarder quel changement est pour un problème de sécurité et backporter.

      Mais je ne vois pas ce que ça change pour installer de Debian, à part changer de source.
      https://www.virtualbox.org/wiki/Linux_Downloads
      "Debian 9 ("Stretch") i386 | AMD64"
      Tu peux installer, certes avec quelques différences (faut faire confiance à oracle pour le binaire, pas repo…).
      Aussi https://packages.debian.org/sid/virtualbox est à jour donc il "suffit" de récupérer sid pour au moins virtualbox.


      Cette façon de faire à figer les versions pour une distro est de moins en moins tenable, de plus en plus de projet ne prennent pas le temps (qui est de l'argent, que personne ne veut mettre) de maintenir les vieilles versions ("Upgrade to a newer release" est une réponse valable quoiqu'en dise Debian, si personne ne veut payer pour autre chose), à force Linux en grandissant commence à ressembler à Windows, où on installe un OS de base et où on fait comme on peut (avec la sécurité en conséquence) pour avoir certains logiciels pas ou trop vieux dans les repos officiels. Pas facile de grandir et avoir du monde ;-). Ho souvenir de Linuxiens critiquant Windows, alors qu'en sortant un peu du 1% de part de marché les différences s'estompent :-D.

      PS : par contre, je serai curieux qu'on m'explique la différence entre Firefox (qui reste et est MAJ dernière version) et VirtualBox (qui dégage), ai-je loupé quelque chose ou "ça dépend (à débattre suivant ton poids")?

      • [^] # Re: Virtualbox ?

        Posté par . Évalué à 3 (+2/-0).

        PS : par contre, je serai curieux qu'on m'explique la différence entre Firefox (qui reste et est MAJ dernière version) et VirtualBox (qui dégage), ai-je loupé quelque chose ou "ça dépend (à débattre suivant ton poids")?

        VirtualBox n’est pas essentiel au quidam moyen, tandis qu’un navigateur web, si. Et, autre point, l’évolution des technos web impose une évolution rapide des navigateurs (quoique ça se soit un peu calmé ces derniers temps), avec un vieux navigateur certains sites n’étaient simplement plus utilisables. Côté virtualbox, il n’y a pas cette évolution fonctionnelle nécessaire qui justifie la montée de version.

        En gros, firefox est une énorme exception, qui ne passe que parce qu’il n’y a aucune autre solution viable (ne pas fournir un navigateur web, c’est juste pas envisageable).

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

      • [^] # Re: Virtualbox ?

        Posté par . Évalué à -1 (+1/-4).

        Cette façon de faire à figer les versions pour une distro est de moins en moins tenable, de plus en plus de projet ne prennent pas le temps (qui est de l'argent, que personne ne veut mettre) de maintenir les vieilles versions ("Upgrade to a newer release" est une réponse valable quoiqu'en dise Debian, si personne ne veut payer pour autre chose), à force Linux en grandissant commence à ressembler à Windows, où on installe un OS de base et où on fait comme on peut (avec la sécurité en conséquence) pour avoir certains logiciels pas ou trop vieux dans les repos officiels. Pas facile de grandir et avoir du monde ;-). Ho souvenir de Linuxiens critiquant Windows, alors qu'en sortant un peu du 1% de part de marché les différences s'estompent :-D.

        Ouais sauf que sous Windows j'ai une vraie sécurité du serveur graphique (hein Xorg), et j'ai pas de lecteur vidéo qui me ferme la session quand il plante (hein SMPlayer), et je perds pas ma session graphique quand le pilote graphique plante (merci les évolutions de Vista).

        Finalement, plus ça va, plus Windows est loin devant. :p

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Base stable et application rolling

    Posté par . Évalué à 2 (+0/-0).

    Le problème de Virtualbox est assez révélateur, et je suis content de la politique adoptée pour Firefox.

    La Debian idéale pour moi aurait le fonctionnement actuel pour la base du système et tout ce que j'installe sur mes serveurs, et le fonctionnement actuel du paquet Firefox pour les applications utilisateurs. Avec la partie base/serveur supportée plus longtemps (support plus simple, car nombre de paquets limités).

    On s'en approche avec le dépôt backport remarquez.

Envoyer un commentaire

Suivre le flux des commentaires

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